tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 50751] New: JNDIRealm invokes getAttributes with no attribute ids. Prevents using DOMAIN\{0} to login.
Date Thu, 10 Feb 2011 17:11:48 GMT

           Summary: JNDIRealm invokes getAttributes with no attribute ids.
                    Prevents using DOMAIN\{0} to login.
           Product: Tomcat 6
           Version: 6.0.29
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Catalina

Created an attachment (id=26633)
 --> (
Patch for this issue vs. 6_0_29.

I would like to configure JNDIRealm to authenticate to an Active Directory
server using userPattern=DOMAIN\{0}. Active Directory will accept this username
in bind requests, however context.getAttributes(...) will fail if that name is
used. JNDIRealm makes a request for user attributes before logging in, even
when there are no user attributes to request. As a result, the above
configuration fails with an InvalidNameException:

javax.naming.InvalidNameException: DOMAIN\username: [LDAP: error code 34 -
0000208F: LdapErr: DSID-0C090654, comment: Error processing name, data 0,
vece ]; remaining name 'DOMAIN\username

I have a patch for this (against 6.0.29) that I will attach. The patch fixes
the issue for my specific case (bind mode, no roles), but it seems like there
is a more fundamental problem in accessing the user's attributes before the
user is even authenticated. This makes sense if it is configured for password
comparison mode, but for bind mode it seems unnecessary until the user's
password is validated. If only there were a way to get the DN of the
authenticated user (not just the name that was used to authenticate), then it
would be straightforward to fix this to query for roles after auth. I could not
find such an API. I would be happy to write that patch if someone can point me
in the right direction on that API.

More discussion on this issue from the tomcat-users list:

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message