Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brandon,
On 2/3/2011 5:36 PM, Brandon DuRette wrote:
One of our customers had configured JNDIRealm to authenticate against Active
Directory using the userPattern="DOMAIN/{0}". This was working great with
Tomcat 6.0.20 (with my patch for 42579 applied (IIRC, the first time it was
applied in the trunk it was misapplied)). However, when we upgraded to
6.0.29 this began failing:
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've gone through the code trying to figure out if anything has changed in
JNDIRealm that would affect this, but I couldn't see anything. Has anyone
had success with this configuration or have any idea what might be causing
this error?
Take a look at the Changelog: there have been a number of changes to the
JNDIRealm betwene 6.0.20 and 6.0.29, including this one:
"
Various JNDI realm improvements for Active Directory. These include the
ability to specify a default role, optional handling for nested roles
and an option to ignore PartialResultExceptions (markt).
"
Unfortunately, there's no bug number listed and no revision number
mentioned, either, so you might have to dig through the svn logs to find
the appropriate update and see what changed.
I did notice this one, too:
"
Provide debug logging for JNDI lookups. (markt)
"
Have you enabled debug logging for JNDI lookups? It's not clear from the
description if this is for JNDIRealm or for other types of JNDI lookups
(like for DataSources).
It may be worth also having a look at this :
http://wikis.sun.com/display/SunJavaSystem/LDAP+Error+Codes
Error code 34 says "invalid DN syntax".
I am no LDAP specialist, but are you sure that the above "DOMAIN\username" is a valid way
of specifying the username ? It probably is so, in the Microsoft Active Directory version
of LDAP, but maybe they have replaced the server or changed its settings ?
Note also that if this is part of an SSO system which obtains the user's Windows Domain
userid, and then checks it with an AD or LDAP server : usually, you can obtain the user-id
in several forms, and the form "usern...@long.domain.name" may be more appropriate here.
Basically what I mean is that the error message above looks to me as if it is really an
error returned by the LDAP server, and which the Java part is just reflecting.
That may be why you are not finding any code changes that may explain the issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org