You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christophe Dupriez <ch...@poisoncentre.be> on 2008/11/10 20:41:39 UTC

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:
   <login-config>
       <auth-method>NTLM</auth-method>
       <realm-name>ThisIsApassword</realm-name>
   </login-config> 
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})(userPrincipalName={0}@domain.com)(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

Re: NTLMAuthenticator for Apache Tomcat 6.0.18 (Intranet within a Microsoft domain)

Posted by David Jencks <da...@yahoo.com>.
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:
> * centralize the parameterization of user authentication at the  
> container level;

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:
>    <login-config>
>        <auth-method>NTLM</auth-method>
>        <realm-name>ThisIsApassword</realm-name>
>    </login-config>
> 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})(userPrincipalName={0}@domain.com) 
> (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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org