https://bz.apache.org/bugzilla/show_bug.cgi?id=61977
--- Comment #9 from marian.romasc...@nuance.com --- A bit too quick in crying victory. Here is the scenario: - using CombinedRealm with 2 JNDIREalm * 1 on testdomain1.example.org * 1 on testdomain2.example.org - using the ldap:///<domain> construct for the connectionURL in each JNDIREalm - having different userBase and roleBase in each of the JNDIREalm, like below userBase="OU=ouUserBase1,DC=testdomain1,DC=example,DC=org" roleBase="OU=ouRoleBase1,DC=testdomain1,DC=example,DC=org" userBase="OU=ouUserBase2,DC=testdomain2,DC=example,DC=org" roleBase="OU=ouRoleBase2,DC=testdomain2,DC=example,DC=org" - using a Kerberos SSO config (securityConstraints based on the userBase/roleBase above) Here are the issues observed so far: 1) with the patch the userBase and roleBase above result in LDAP searches with the domain part in double e.g : "OU=ouUserBase1,DC=testdomain1,DC=example,DC=org,DC=testdomain1,DC=example,DC=org" I had to remove the domain parts to move on and make it partially working (see issue #2) userBase="OU=ouUserBase1" roleBase="OU=ouRoleBase1" userBase="OU=ouUserBase2" roleBase="OU=ouRoleBase2" 2) With the above "hack" the first TGS-REQ trying to get an LDAP SPN will be OK w/o a trailing dot in the sname. However 2'nd TGS-REQ (for the other sub-domain) will come with the trailing dot. Does not matter the order - the 1'st can be for testdomain1 or testdomain2, it will work. The 2'nd SSO attempt for the other subdomain, as visible in the Wireshark trace, will produce a TCS-REQ with a ldap SPN sname with a trailing dot Thanks in advance for looking at what might cause the 2 issues above. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
