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: > > <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})([EMAIL PROTECTED]) > > (userPrincipalName={0}))" > > userIdentification="userPrincipalName" userNamePrefix=”domain\” > [EMAIL PROTECTED] > > ” > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
