tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Leyden <john.ley...@nyu.edu>
Subject Configure JNDI Realm For Active Directory Under Tomcat 5.5.12 on OSX
Date Fri, 07 Apr 2006 21:35:26 GMT
After having searched the MARC archives and Google for the better  
part of a week I do not seem to be able to duplicate others' past  
success with getting Tomcat to use a JNDI realm to authenticate users  
via Active Directory.  Basically I'm just trying to get a simple web  
app straight from the Tomcat docs to work, but with JNDI instead of  
tomcat-users.xml. The app I'm using works fine, without modification,  
when run against tomcat-users. So there's something quirky about  
getting JNDI hooked up that necessarily varies from one  
organization's implementation of AD to another's. Would those of you  
who have trod this ground before mind suggesting where I might have  
gone astray?

Thank you.



Details
======

1) A fresh install of Tomcat 5.5.12 on OSX 10.4.6 as obtained from:   
http://www.versiontracker.com/dyn/moreinfo/macosx/27151

2) SERVER.XML excerpt:

     <!-- Define the top level container in our container hierarchy -->
     <Engine name="Catalina" defaultHost="localhost">

      [snip]

       <Realm className="org.apache.catalina.realm.JNDIRealm"
		debug="99"
		connectionURL="ldap://[primary domain controller ip]:389"
		alternateURL="ldap://[backup domain controller ip]:389"
		referrals="follow"
		userBase="CN=Users,DC=[mydepartment],DC=[mydivision],DC= 
[ourintranetdomain]"
		userSearch="(sAMAccountName={0})"
		userSubtree="true"
		userRoleName="memberOf"
		rolename="cn"
       />

      [big snip]

3) Excerpt from ldap directory (obtained via LDP):

Expanding base '	CN=Firstname  
Lastname,CN=Users,DC=mydepartment,DC=mydivision,DC=ourintranetdomain'...
Result <0> (null)
Matched DNs:
Getting 1 entries:
 >> Dn: CN=Firstname  
Lastname,CN=Users,DC=mydepartment,DC=mydivision,DC=ourintranetdomain
	4> memberOf:  
CN=GroupName1,CN=Users,DC=mydepartment,DC=mydivision,DC=ourintranetdomai 
n;
		 
CN=GroupName2,CN=Users,DC=mydepartment,DC=mydivision,DC=ourintranetdomai 
n;
	1> sAMAccountName=jl;

4) All other realms commented-out of server.xml.  I am led to believe  
that an engine may possess exactly one authentication realm.

5) Application WEB.XML excerpt:

    <security-constraint>
       <display-name>My Security Constraint</display-name>
       <web-resource-collection>
          <web-resource-name>Protected Area</web-resource-name>
	 <!-- Define the context-relative URL(s) to be protected -->
          <url-pattern>/*</url-pattern>
	 <!-- If you list http methods, only those methods are protected -->
	 <http-method>DELETE</http-method>
          <http-method>GET</http-method>
          <http-method>POST</http-method>
	 <http-method>PUT</http-method>
       </web-resource-collection>
       <auth-constraint>
          <!-- Anyone with one of the listed roles may access this  
area -->
          <role-name>GroupName1</role-name>
	 <role-name>GroupName2</role-name>
       </auth-constraint>
     </security-constraint>

     <!-- Default login configuration uses form-based authentication -->
     <login-config>
       <auth-method>FORM</auth-method>
       <form-login-config>
         <form-login-page>/login.html</form-login-page>
         <form-error-page>/error.html</form-error-page>
       </form-login-config>
     </login-config>

     <!-- Security roles referenced by this web application -->
     <security-role>
       <role-name>GroupName1</role-name>
     </security-role>
     <security-role>
       <role-name>GroupName2</role-name>
     </security-role>

6) The LOGIN.HTML and ERROR.HTML pages are again, straight from the  
docs and call j_securitycheck, etc.

Results
======

1) When I run build.xml (modified slightly from the sample provided  
in the Tomcat docs) I get:

% ant list
Buildfile: build.xml

list:

BUILD FAILED
build.xml:407: java.io.IOException: Server returned HTTP response  
code: 401 for URL: http://localhost:8080/manager/list

Total time: 1 second
%


I conclude from looking at the logs that the manager app has failed  
to authenticate. I am certain that I have the correct username and  
password in the build.properties file.
The list, install, and remove Ant tasks all work fine when Tomcat is  
using the stock UserDatabase realm.


2) The log excerpt:

DEBUG http-8080-Processor24  
org.apache.catalina.authenticator.AuthenticatorBase - Security  
checking request GET /manager/list
DEBUG http-8080-Processor24 org.apache.catalina.realm.RealmBase -    
Checking constraint 'SecurityConstraint[HTMLManger and Manager  
command]' against GET /list --> true
DEBUG http-8080-Processor24 org.apache.catalina.realm.RealmBase -    
Checking constraint 'SecurityConstraint[HTMLManger and Manager  
command]' against GET /list --> true
DEBUG http-8080-Processor24  
org.apache.catalina.authenticator.AuthenticatorBase -  Calling  
hasUserDataPermission()
DEBUG http-8080-Processor24 org.apache.catalina.realm.RealmBase -    
User data constraint has no restrictions
DEBUG http-8080-Processor24 org.apache.catalina.realm.RealmBase -    
User data constraint has no restrictions
DEBUG http-8080-Processor24  
org.apache.catalina.authenticator.AuthenticatorBase -  Calling  
authenticate()
DEBUG http-8080-Processor24  
org.apache.catalina.authenticator.AuthenticatorBase -  Failed  
authenticate() test

3) When I try to run the Tomcat Admin and Tomcat Manager  
applications, neither of which have been modified by me, I also fail  
to authenticate and the log shows:

DEBUG http-8080-Processor25  
org.apache.catalina.connector.CoyoteAdapter -  Requested cookie  
session id is 36F940547ADE4896755EA6B047744EC0
DEBUG http-8080-Processor25  
org.apache.catalina.authenticator.AuthenticatorBase - Security  
checking request GET /admin/
DEBUG http-8080-Processor25 org.apache.catalina.realm.RealmBase -    
Checking constraint 'SecurityConstraint[Protected Area]' against GET / 
index.jsp --> true
DEBUG http-8080-Processor25 org.apache.catalina.realm.RealmBase -    
Checking constraint 'SecurityConstraint[Protected Area]' against GET / 
index.jsp --> true
DEBUG http-8080-Processor25 org.apache.catalina.realm.RealmBase -    
Checking constraint 'SecurityConstraint[Protected Area]' against GET / 
index.jsp --> true
DEBUG http-8080-Processor25 org.apache.catalina.realm.RealmBase -    
Checking constraint 'SecurityConstraint[Protected Area]' against GET / 
index.jsp --> true
DEBUG http-8080-Processor25 org.apache.catalina.realm.RealmBase -    
Checking constraint 'SecurityConstraint[Protected Area]' against GET / 
index.jsp --> true
DEBUG http-8080-Processor25 org.apache.catalina.realm.RealmBase -    
Checking constraint 'SecurityConstraint[Protected Area]' against GET / 
index.jsp --> true
DEBUG http-8080-Processor25  
org.apache.catalina.authenticator.AuthenticatorBase -  Calling  
hasUserDataPermission()
DEBUG http-8080-Processor25 org.apache.catalina.realm.RealmBase -    
User data constraint has no restrictions
DEBUG http-8080-Processor25 org.apache.catalina.realm.RealmBase -    
User data constraint has no restrictions
DEBUG http-8080-Processor25  
org.apache.catalina.authenticator.AuthenticatorBase -  Calling  
authenticate()
DEBUG http-8080-Processor25  
org.apache.catalina.authenticator.FormAuthenticator - Save request in  
session '36F940547ADE4896755EA6B047744EC0'
DEBUG http-8080-Processor25  
org.apache.catalina.core.ApplicationDispatcher - servletPath=/ 
login.jsp, pathInfo=null, queryString=null, name=null
DEBUG http-8080-Processor25  
org.apache.catalina.core.ApplicationDispatcher -  Path Based Forward
DEBUG http-8080-Processor25 org.apache.catalina.core.StandardWrapper  
-   Returning non-STM instance
DEBUG http-8080-Processor25  
org.apache.catalina.core.ApplicationDispatcher - servletPath=null,  
pathInfo=null, queryString=null, name=action
DEBUG http-8080-Processor25  
org.apache.catalina.core.ApplicationDispatcher -  Named Dispatcher  
Include
DEBUG http-8080-Processor25 org.apache.catalina.core.StandardWrapper  
-   Returning non-STM instance
DEBUG http-8080-Processor25 org.apache.struts.util.ModuleUtils - Get  
module name for path /login.jsp
DEBUG http-8080-Processor25 org.apache.struts.util.ModuleUtils -  
Module name found: default
DEBUG http-8080-Processor25 org.apache.struts.action.RequestProcessor  
- Processing a 'GET' for path '/login'
ERROR http-8080-Processor25 org.apache.struts.action.RequestProcessor  
- Invalid path /login was requested
DEBUG http-8080-Processor25  
org.apache.catalina.core.ApplicationDispatcher -  Disabling the  
response for futher output
DEBUG http-8080-Processor25  
org.apache.catalina.authenticator.AuthenticatorBase -  Failed  
authenticate() test
DEBUG http-8080-Processor25  
org.apache.catalina.connector.CoyoteAdapter -  Requested cookie  
session id is 36F940547ADE4896755EA6B047744EC0
DEBUG http-8080-Processor25  
org.apache.catalina.authenticator.AuthenticatorBase - Security  
checking request POST /admin/j_security_check
DEBUG http-8080-Processor25  
org.apache.catalina.authenticator.FormAuthenticator - Authenticating  
username 'jl'
DEBUG http-8080-Processor25  
org.apache.catalina.core.ApplicationDispatcher - servletPath=/ 
error.jsp, pathInfo=null, queryString=null, name=null
DEBUG http-8080-Processor25  
org.apache.catalina.core.ApplicationDispatcher -  Path Based Forward
DEBUG http-8080-Processor25 org.apache.catalina.core.StandardWrapper  
-   Returning non-STM instance
DEBUG http-8080-Processor25  
org.apache.catalina.core.ApplicationDispatcher -  Disabling the  
response for futher output
DEBUG http-8080-Processor25  
org.apache.catalina.authenticator.AuthenticatorBase -  Failed  
authenticate() test ??/admin/j_security_check

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message