NTLMAuthenticator for Apache Tomcat 6.0.18 (Intranet within a Microsoft domain)
Hi!
I wanted to:
* centralize the parameterization of user authentication at the container level;
* have a simple NTLM authentication for intranet users;
* be able to run Tomcat in a Microsoft Active Directory network where the
server is secured (absolutely no login allowed to regular users)
There is a Microsoft "specification" (bug?) by which all LDAP binds are
evaluated on the Domain Server (like if the user was attempting to login on the
Domain Server).
It would be better to have binds evaluated as if they were originating from the
LDAP client machine (the Tomcat Server).
To circumvent this, I have been obliged to remove the binding (the password
checking) but to ensure that it is NTLM (and nothing else) which provides the
username.
The users are therefore automatically logged with the username used to log on
their PC.
The attached patch is for current Apache Tomcat sources (6.0.18).
It adds:
An NTLM Authenticator: nothing to configure except in the web.xml of each
application:
NTLM
ThisIsApassword
The realm-name is the "password" which ensures that authentication is done by
NTLM and no other method.
A very long password is strongly recommended.
A modified JNDI Realm with new parameters:
preAuthenticatedPassword="ThisIsApassword"
This to suppress password checking if preAuthenticatedPassword is provided.
userIdentification="userPrincipalName" provides a standardized username,
whatever the retrieved user name (case of complex userSearch patterns)
userNamePrefix and userNameSuffix
This to suppress a prefix and/or a suffix from username before returning it to
the application: good to suppress domain identification, etc.
When you user complex userSearch pattern, this can be very useful. Example:
userSearch="(|(sAMAccountName={0})([EMAIL PROTECTED])(userPrincipalName={0}))"
userIdentification="userPrincipalName" userNamePrefix="domain\"
userNameSuffix="@domain.com"
Hopes this can be useful to the community!
Please do not hesitate to ask me if something can be done to make this
contribution perennial.
Wishing you a very nice day,
Christophe Dupriez
Centre Antipoisons - Antigifcentrum
C/o Hôpital Central de la Base Reine Astrid
Rue Bruyn - 1120 Bruxelles - Belgique
tel 32-(0)2.264.96.36 fax 32-(0)2.264.96.46-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: NTLMAuthenticator for Apache Tomcat 6.0.18 (Intranet within a Microsoft domain)
Hi David! Thank you for your questions. FIRST AN APOLOGY TO THE READERS: The proposed patch file misses the most important, a new java class NTLMAuthenticator.java: I will make available in a corrected patch FRIDAY (I am not back to my office before). For my goals: > > * centralize the parameterization of user authentication at the > > container level; The WCA (Web Container Authentication) main advantage is that all applications may have a consistent, coherent security enforcement. This comes from a central, common configuration in server.xml (Tomcat Container) removing many chores from the application itself. Authorizations based on this authentication is very well expressed in the web.xml file of each application. So I preferred to modify slightly Tomcat rather than modify each different applications (each propose a different security schemas when they are not using container based authentication). > Do you mean that you want intranet users to have their local MAD login > propagated automatically to the tomcat server with no explicit tomcat > login required? YES ! > If so the "official" way to support this is via > the JASPI spec (jsr 196) and (IIUC) a SPNEGO server authentication > module such as that at http://spnego.ocean.net.au/ (jboss might have > another one???) I spent a few weeks trying the different alternatives. All complex and I did not achieve a real success. Even JCIFS NTLM filter was not working correctly in our network. So the proposed patch is lot simpler (nearly no configuration) and it works (for us). Have a nice week, Christophe - Original Message - From: David Jencks [mailto:[EMAIL PROTECTED] To: Tomcat Developers List [mailto:[EMAIL PROTECTED] Subject: Re: NTLMAuthenticator for Apache Tomcat 6.0.18 (Intranet within a Microsoft domain) > I'm a little confused about your goals > > On Nov 10, 2008, at 11:41 AM, Christophe Dupriez wrote: > > > Hi Tomcat Developpers! > > > > I wanted to: > > What do you mean by this and how is this expressed? > > > * have a simple NTLM authentication for intranet users; > > * be able to run Tomcat in a Microsoft Active Directory network > > where the server is secured (absolutely no login allowed to regular > > users) > > Do you mean that you want intranet users to have their local MAD login > propagated automatically to the tomcat server with no explicit tomcat > login required? If so the "official" way to support this is via > the JASPI spec (jsr 196) and (IIUC) a SPNEGO server authentication > module such as that at http://spnego.ocean.net.au/ (jboss might have > another one???) > > At this point tomcat does not have a jaspi implementation although I > expect it to be a part of javaee 6, and I'm mostly interested in > trying to understand what you are trying to do rather than suggesting > an implementation strategy. > > thanks > david jencks > > > > > There is a Microsoft “specification” (bug?) by which all LDAP binds > > are evaluated on the Domain Server (like if the user was attempting > > to login on the Domain Server). > > It would be better to have binds evaluated as if they were > > originating from the LDAP client machine (the Tomcat Server). > > > > To circumvent this, I have been obliged to remove the binding (the > > password checking) but to ensure that it is NTLM (and nothing else) > > which provides the username. > > The users are therefore automatically logged with the username used > > to log on their PC. > > > > The attached patch is for current Apache Tomcat sources (6.0.18). > > > > It adds: > > An NTLM Authenticator: nothing to configure except in the web.xml of > > each application: > > > >NTLM > >ThisIsApassword > > > > The realm-name is the “password” which ensures that authentication > > is done by NTLM and no other method. > > A very long password is strongly recommended. > > A modified JNDI Realm with new parameters: > > preAuthenticatedPassword=”ThisIsApassword” > > This to suppress password checking if preAuthenticatedPassword is > > provided. > > userIdentification=”userPrincipalName” provides a standardized > > username, whatever the retrieved user name (case of complex > > userSearch patterns) > > userNamePrefix and userNameSuffix > > This to suppress a prefix and/or a suffix from username before > > returning it to the application: good to suppress domain > > identification, etc. > > When you user complex userSearch pattern, this can be very useful. > > Example: > > userSe
NTLMAuthenticator for Apache Tomcat 6.0.18 (Intranet within a Microsoft domain) (GOOD links to source files)
Hi again Tomcat Developpers!
(Message re-re-re-sent because attached files did not went through the MailList
management program and then Outlook resent an old version of my message): SORRY!
The patch file is accessible:
http://www.destin.be/tomcat/NtlmAuthentication.patch
The new authenticator class is accessible:
http://www.destin.be/tomcat/NtlmAuthenticator.java
I wanted to:
* centralize the parameterization of user authentication at the container level;
* have a simple NTLM authentication for intranet users;
* be able to run Tomcat in a Microsoft Active Directory network where the
server is secured (absolutely no login allowed to regular users)
There is a Microsoft "specification" (bug?) by which all LDAP binds are
evaluated on the Domain Server (like if the user was attempting to login on the
Domain Server).
It would be better to have binds evaluated as if they were originating from the
LDAP client machine (the Tomcat Server).
To circumvent this, I have been obliged to remove the binding (the password
checking) but to ensure that it is NTLM (and nothing else) which provides the
username.
The users are therefore automatically logged with the username used to log on
their PC.
The attached patch is for current Apache Tomcat sources (6.0.18).
It adds:
An NTLM Authenticator: nothing to configure except in the web.xml of each
application:
NTLM
ThisIsApassword
The realm-name is the "password" which ensures that authentication is done by
NTLM and no other method.
A very long password is strongly recommended.
A modified JNDI Realm with new parameters:
preAuthenticatedPassword="ThisIsApassword"
This to suppress password checking if preAuthenticatedPassword is provided.
userIdentification="userPrincipalName" provides a standardized username,
whatever the retrieved user name (case of complex userSearch patterns)
userNamePrefix and userNameSuffix
This to suppress a prefix and/or a suffix from username before returning it to
the application: good to suppress domain identification, etc.
When you user complex userSearch pattern, this can be very useful. Example:
userSearch="(|(sAMAccountName={0})([EMAIL PROTECTED])(userPrincipalName={0}))"
userIdentification="userPrincipalName" userNamePrefix="domain\"
userNameSuffix="@domain.com"
Hopes this can be useful to the community!
Please do not hesitate to ask me what I should do to make this contribution
perennial.
Wishing you a very nice weekend,
Christophe Dupriez
Centre Antipoisons - Antigifcentrum
C/o Hôpital Central de la Base Reine Astrid
Rue Bruyn - 1120 Bruxelles - Belgique
tel 32-(0)2.264.96.36 fax 32-(0)2.264.96.46
Tomcat 6.0.18, POST request.ContentLength() is 0 when entering the Authenticator
Hi Tomcat Developpers! Few days ago I provided an NTLM Authenticator. My users reported that their POST requests are now without content. I traced and I can confirm that, when entering the NtlmAuthenticator.authenticate method, request.ContentLength() is -1 for GET transactions (and it works) but it is 0 for POST. At the very entrance of BasicAuthenticator.authenticate, request.ContentLength() is -1 for GET transactions (and it works) but the real length is there for POST. So I can have 50 GET transactions without any problems : the NTLM authentication is done once with the first transaction. Then, if a POST comes, it will be 0 length. Any idea of what may be happening? As I did not found any real dependency on the word "BASIC" within Tomcat source, I am wondering if lower level Java Run Time could test explicitely the authentication method and "forget" to manage the ContentLength? It seems that some people have problem with FORM authentication. Could it be a similar problem? The patch file is accessible: http://www.destin.be/tomcat/NtlmAuthentication.patch The new authenticator class is accessible: http://www.destin.be/tomcat/NtlmAuthenticator.java Wishing you a very nice week, Christophe Dupriez Centre Antipoisons - Antigifcentrum C/o Hôpital Central de la Base Reine Astrid Rue Bruyn - 1120 Bruxelles - Belgique tel 32-(0)2.264.96.36 fax 32-(0)2.264.96.46
POST request.ContentLength() is 0 when using NTLM
When it is not your application, when it is not the HTTP server, it is the BROWSER!!! The following explains what the IE optimization I was not aware of: http://lists.samba.org/archive/jcifs/2006-September/006554.html http://dreamweaverforum.info/flex/118349-ntlm-filereference.html The following explains two different solutions: http://lists.samba.org/archive/jcifs/2004-December/004459.html (Solution 2 but in our case no need for a filter: the proposed logic will perfectly fit in the NTLM Authenticator) I will program and test them next week. Patches will be republished after few weeks of testing: current one support "GET" correctly and "POST" if the Registry of each user is modified (HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Internet Settings/DisableNTLMPreAuth to be set to 1). Wishing you a very nice day, Christophe Dupriez Centre Antipoisons-Antigifcentrum C/o Hôpital Central de la Base Reine Astrid Rue Bruyn 1120 Bruxelles Belgique tel 32-(0)2.264.96.36 fax 32-(0)2.264.96.46 - Original Message ----- From: Christophe Dupriez [mailto:[EMAIL PROTECTED] To: dev@tomcat.apache.org [mailto:[EMAIL PROTECTED] Subject: Tomcat 6.0.18, POST request.ContentLength() is 0 when entering the Authenticator > Hi Tomcat Developpers! > > Few days ago I provided an NTLM Authenticator. My users reported that their > POST requests are now without content. > I traced and I can confirm that, when entering the > NtlmAuthenticator.authenticate method, request.ContentLength() is -1 for GET > transactions (and it works) but it is 0 for POST. > At the very entrance of BasicAuthenticator.authenticate, > request.ContentLength() is -1 for GET transactions (and it works) but the > real length is there for POST. > > So I can have 50 GET transactions without any problems : the NTLM > authentication is done once with the first transaction. Then, if a POST > comes, it will be 0 length. > > Any idea of what may be happening? As I did not found any real dependency on > the word "BASIC" within Tomcat source, I am wondering if lower level Java > Run Time could test explicitely the authentication method and "forget" to > manage the ContentLength? It seems that some people have problem with FORM > authentication. Could it be a similar problem? > > The patch file is accessible: > http://www.destin.be/tomcat/NtlmAuthentication.patch > > The new authenticator class is accessible: > http://www.destin.be/tomcat/NtlmAuthenticator.java > > Wishing you a very nice week, > > Christophe Dupriez > Centre Antipoisons - Antigifcentrum > C/o Hôpital Central de la Base Reine Astrid >Rue Bruyn - 1120 Bruxelles - Belgique > tel 32-(0)2.264.96.36 fax 32-(0)2.264.96.46 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NTLM Authentication (POST now correctly supported)
Hi Tomcat Developers!
The new authenticator class (modified to support POST) is accessible:
http://www.destin.be/tomcat/NtlmAuthenticator.java
The previous patch file is accessible and UNCHANGED:
http://www.destin.be/tomcat/NtlmAuthentication.patch
Please let me know the procedures I may follow to make this modification
perennial.
I wanted to:
* centralize the parameterization of user authentication at the container level;
* have a simple NTLM authentication for intranet users;
* be able to run Tomcat in a Microsoft Active Directory network where the
server is secured (absolutely no login allowed to regular users)
There is a Microsoft "specification" (bug?) by which all LDAP binds are
evaluated on the Domain Server (like if the user was attempting to login on the
Domain Server).
It would be better to have binds evaluated as if they were originating from the
LDAP client machine (the Tomcat Server).
To circumvent this, I have been obliged to remove the binding (the password
checking) but to ensure that it is NTLM (and nothing else) which provides the
username.
The users are therefore automatically logged with the username used to log on
their PC.
The attached patch is for current Apache Tomcat sources (6.0.18).
It adds:
An NTLM Authenticator: nothing to configure except in the web.xml of each
application:
NTLM
ThisIsApassword
The realm-name is the "password" which ensures that authentication is done by
NTLM and no other method.
A very long password is strongly recommended.
A modified JNDI Realm with new parameters:
preAuthenticatedPassword="ThisIsApassword"
This to suppress password checking if preAuthenticatedPassword is provided.
userIdentification="userPrincipalName" provides a standardized username,
whatever the retrieved user name (case of complex userSearch patterns)
userNamePrefix and userNameSuffix
This to suppress a prefix and/or a suffix from username before returning it to
the application: good to suppress domain identification, etc.
When you user complex userSearch pattern, this can be very useful. Example:
userSearch="(|(sAMAccountName={0})([EMAIL PROTECTED])(userPrincipalName={0}))"
userIdentification="userPrincipalName" userNamePrefix="domain\"
userNameSuffix="@domain.com"
Hopes this can be useful to the community!
Wishing you a very nice day,
Christophe Dupriez
Centre Antipoisons - Antigifcentrum
C/o Hôpital Central de la Base Reine Astrid
Rue Bruyn - 1120 Bruxelles - Belgique
tel 32-(0)2.264.96.36 fax 32-(0)2.264.96.46
