"Eugène Adell" <eugene.ad...@d2-si.eu> schrieb:
> >Thanks Felix, > >I will choose the easy way by allowing the anonymous to bind the >directory, against all security logics, and strengthen the ACL to >forbid anonymous search. > >Anyway, the bug 19444 is closed saying the new parameter (introduced in >7.0.9 and corrected in 7.0.30) allows role searching with the >authenticating user. That's true, but we still need either the >anonymous or a technical user for the startup binding. It's not really >compliant to real-life LDAP management. > I still wonder, why you are so reluctant to use a technical user. Especially since you have security concerns about the anonymous user. Regards Felix >best regards > > > >________________________________________ >De : Felix Schumacher [felix.schumac...@internetallee.de] >Envoyé : jeudi 14 mars 2013 14:22 >À : Tomcat Users List >Objet : RE:JNDI property roleSearchAsUser not working as expected > >Am 14.03.2013 13:40, schrieb Eugène Adell: >> This doc is self-contradictory because it suggests "to setup a >> technical user" when we "don't want to configure a technical user", >> and it doesn't give any solution when we are not the admin of the >> directory. > >I can't read that out of the docs for roleSearchAsUser as stated on >http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#JNDI_Directory_Realm_-_org.apache.catalina.realm.JNDIRealm > >It is just a mechanism to switch from the credentials when searching >for roles. > >That way you can restrict the rights to the anonymous/admin user, so >that it doesn't need to be able to lookup groups/roles for a user. > >> >> Here we learn that Tomcat JNDI Realm only works in "Administrator >> Login Mode" with an administrator login/password (in fact the >> "technical user" discussed above) : >> >> http://tomcat.apache.org/tomcat-7.0-doc/funcspecs/fs-jndi-realm.html > >I believe the "Administrator Login Mode" is used for retrieving >attributes out of an users object and comparing the values to some >given >credentials. The "User Login Mode" is used when a bind is performed to >check the credentials. But either way, you will have to setup a >technical user, or open the directory server to allow anonymous binds >and searches for the user dn's. > >> >> From this, it seems that roleSearchAsUser is only usefull when the >> anonymous bind is allowed. It's another contradiction here, because >it >> seems logical to use this parameter especially when anonymous is not >> allowed. > >You will not get to the point where the role is being searched, since >before that there are two points, where your directory is being >accessed. > 1. initial test of connection (which you reported in your first mail) > 2. look up of the user, which wants to login (and since the username >to bind with is not known, it will be hard to guess) > >So as stated before the easiest thing is to just use a technical user >to connect to the directory. > >Regards > Felix >> >> >> >> ________________________________________ >> De : Felix Schumacher [felix.schumac...@internetallee.de] >> Envoyé : jeudi 14 mars 2013 12:03 >> À : Tomcat Users List >> Objet : Re: JNDI property roleSearchAsUser not working as expected >> >> Am 13.03.2013 21:46, schrieb Eugène Adell: >>> Hello >>> >>> I am running the following : >>> java version "1.6.0_25" >>> Java(TM) SE Runtime Environment (build 1.6.0_25-b06) >>> Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing) >>> Tomcat 7.0.37 >>> CentOS release 6.3 >>> >>> with this REALM configuration in server.xml : >>> <Realm >>> className="org.apache.catalina.realm.JNDIRealm" >>> connectionURL="ldap://***.***.***.***:389"; >>> >>> userPattern="cn={0},ou=users,dc=example,dc=com" >>> roleBase="ou=groups,dc=example,dc=com" >>> roleSubtree="true" >>> roleNested="true" >>> roleName="cn" >>> roleSearchAsUser="true" >>> roleSearch="(uniqueMember={0})" /> >>> >>> and this triggers this error during the startup : >>> Mar 13, 2013 8:14:49 PM org.apache.catalina.realm.JNDIRealm open >>> WARNING: Exception performing authentication >>> javax.naming.AuthenticationNotSupportedException: [LDAP: error code >>> 48 - anonymous bind disallowed] >>> at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3032) >>> at >>> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987) >>> at >>> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2789) >>> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2703) >>> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293) >>> at >>> >com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) >>> at >>> >com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193) >>> at >>> >com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136) >>> at >>> >com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66) >>> at >>> >javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) >>> at >>> >javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) >>> at javax.naming.InitialContext.init(InitialContext.java:223) >>> at >>> javax.naming.InitialContext.<init>(InitialContext.java:197) >>> at >>> >javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82) >>> at >>> org.apache.catalina.realm.JNDIRealm.open(JNDIRealm.java:2150) >>> at >>> >org.apache.catalina.realm.JNDIRealm.startInternal(JNDIRealm.java:2241) >> ... >>> ... 27 more >>> Mar 13, 2013 8:14:49 PM org.apache.catalina.startup.Catalina start >>> INFO: Server startup in 34 ms >>> >>> >>> From what I understand, roleSearchAsUser property was designed for >>> people who need to bind on any LDAP where anonymous bind is not >>> authorized. But it's just impossible to do this if the JNDI Realm >>> tries to authenticate anonymously by itself during the startup. >> >> I read the docs as follows: >> >> If your directory server does not allow to scan for roles as >anonymous >> user and you don't want to configure a technical user (by specifying >> connectionName and connectionPassword) you can delegate the >> credentials >> of the user that is currently logging in. >> >> It is not intended to set the user credentials for all ldap >> operations. >> >> The easiest way to fix it, is to setup an technical user inside your >> directory, which has no right other than to login and lookup your >> users, >> which would be the next operation. >> >> Regards >> Felix >>> >>> I suppose it's necessary to investigate further this bug : >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=19444 >>> >>> >>> Thanks >>> >>> >--------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
