Does LDAPJDK "care" about domain suffixes?

ohaya <[email protected]>
Newsgroups gmane.comp.mozilla.devel.directory
Message-ID <[email protected]>
Hi,

I've not been able to trace down a very strange problem, and I'm hoping 
that someone here might be able to provide some insight and/or ideas.

I explained some of this in an earlier post, but basically, I have a 
webapp that uses the LDAPJDK to access Active Directory.  As part of 
what this webapp does, it establishes a LDAP connection to AD, then 
authenticates on the LDAPConnection with an admin username/password.

We had installed this webapp at several sites successfully, and at those 
previous sites, we had always configured the webapp to use an admin 
username with a "UPN formatted username", e.g., "[email protected]".

However, at this one site where I'm having a problem, we had a problem 
with the admin username authenticating (ld.authenticate()), and I 
finally got it working by changing the configured admin username to a 
full DN-formatted username (cn=admin,cn=users,dc=foo,dc=com).

I've been trying to figure out why this was necessary just in this one 
installation for a couple of weeks now, and at this point, am totally 
stuck :(...

Some additional "symptoms" are that at this one site, we can 
successfully authenticate using the UPN-formatted username using 
standard tools such as ldifde.exe and ldapsearch.  It's just my webapp 
that doesn't want to seem to work with UPN formatted usernames.

I'd be thinking that there must be some problem with my webapp, but this 
problem is only occurring at just at this one site, and we are using the 
same webapp/code at all the sites (with the same LDAPJDK version).

I've also been reviewing the AD and its contents, thinking that there 
may be something wrong with it.  I was able to come up with some 
scenarios that would cause an authentication with a UPN formatted 
username to fail (e.g., having two users with the same userPrincipalName 
attribute), but with these scenarios, authentication with 
ldifde/ldapsearch will ALSO fail, so they don't completely duplicate the 
problem we are seeing onsite.

I went onsite today, and wrote a small Java program (again, using the 
same LDAPJDK) that simply does a LDAP connection then ld.authenticate(), 
and, if I use the same UPN-formatted username with my small Java webapp, 
it authenticates fine with the same UPN-formatted username with which my 
webapp fails to authenticate.

So, again, this seems to point to something wrong in my webapp, but, 
again, this webapp works fine with the UPN-formatted usernames at the 
other sites, plus, I have debug code in my webapp, and log the 
parameters to ld.authenticate() and everything looks ok.

Now, one of the things that I've noted is that there is something not 
"normal" with the AD at this one site:  The root (top-level) of it's 
domain name is not one of the "normal" top-level domains.  This is a 
kind of testbed site, so I think that whoever installed the AD decided 
that it should have a domain name like "foo.foo1" (literally), instead 
of something like "foo.com" or "foo.org", etc.

So, per the Subject, the question that I have is:  Is there anything in 
the LDAPJDK that would relies on the domain suffix, or maybe the 
top-level domain in the domain suffix being a "normal" top-level domain 
name?

Sorry for the long post :(!!

Thanks in advance,
Jim
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.