HELP! Problem authenticating admin user to AD...
Hi,
I've written a web application for resetting passwords in Win2K3/AD using LDAPJDK.This web app uses an LDAP 'modify' to change the user's 'unicodePwd' attribute, and it seems to work.
We have deployed this web app successfully in 3 different environments, with 3 different Win2K3/AD systems, but then we ran into a problem with it in a 4th environment today:
In order to do the password modification, this web app connects to AD (using an SSL connection), then it uses an admin username/password to do an 'authenticate()'. After a successful authenticate(), it then does the password modification.
The problem that I ran into today was that in this one environment (and only this one, so far), the authenticate() using the admin username/password is failing with an "INVALID_CREDENTIAL" exception, even though we KNOW that the admin username and password are valid (and again, this code has worked with 3 other Win2K3/AD systems in 3 different environments).
If ANYONE has any ideas about what this problem might be, I'd really appreciate if you could post. At this point, I'm really running out of ideas :(!!
Thanks in advance,
Jim
[1195 byte] By [
jimcpl1a] at [2007-11-26 15:53:11]
# 1
The problem is that the credentials you are using are invalid. Simple as that.
No if's, but's or maybe's.
Just because the code works in three other environments, and just because someone "tells" you that the username & password hasn't changed, you can be guaranteed that they indeed have changed.
# 2
Hi,
I actually fixed the problem at that site, but I don't know for sure why my 'fix' worked.
What I did was to change the admin username, which is in a configuration file (i.e., no code change) from the "UPN" format to the full DN format, and the bind then worked.
The funny thing is that I was testing tonight on my test system, switching the username format back-and-forth between the UPN format and the full DN format, and the bind started failing when I used the UPN format (again, this is on my test system).
I was initially elated, because I thought that I'd finally replicated the problem, but I eventually found that I had left the "cn=" in the UPN formatted username, i.e., "cn=myuser@mydomain.com" instead of simply "myuser@mydomain.com".
The onsite system is working for now, with the full DN formatted username, so I'll have to check the next time I go onsite, and this time maybe try to get "another pair of eyes" to look at the config file with me.
I'm hoping that you're right, and that the original installer just "fumble-fingered" AND that I just missed the erroneous username parameter when I went down there myself.
Thanks,
Jim
# 3
Hi,
As followup, I checked and double checked, multiple times, while I was onsite, and at least at this one site, the authentication definitely fails when the username is in the UPN format, and definitely works when using full DN format for the same user.
I also added more debug output, and the username and credentials that are used as parameters for the ld.authenticate() method are correct in both cases, so I've been puzzling over what is going on :(..
Jim
# 4
You may be making some incorrect assumptions about the userPrincipalName at your specific customer site.
I will simply use the terms upn prefix & upn suffix to denote the part of the upn that precedes the @ and the part of the upn after the @.
By default the upn prefix is usually the same as the samAccountName.
By default the UPN suffix is usually the Active Directory dns domain name.
Eg.
Domain distinguished name: dc=antipodes,dc=com
Domain dns name: antipodes.com
NT style Domain name: ANTIPODES (I've just uppercased it for clarity)
A users distinguished name:
cn=Albert Einstein,ou=Research,dc=Antipodes,dc=com
The users samAccountName & userPrincipalName:
alberte, alberte@antipodes.com
So assuming default values, you can authenticate a user with the following credentials
cn=Albert Einstein,ou=Research,dc=Antipodes,dc=com
ANTIPODES\alberte
alberte@antipodes.com
However, an organization may have registered alternative upn suffixes or they may have explicitly set the userPrincipalName to some other values, such that the following may be in fact be a valid upn:
einstein-a@relativity.physics.gov
If authentication fails when you supply a name in upn format, it is most likely because the upn you are presenting, does not represent a valid user.
# 5
Hi,
I understood the info that you posted, and I've checked a lot of things, including looking for UPN conflicts in different containers, UPN conflicts with default UPNs, etc..
Believe me, I do appreciate your comments and responses.
At this point, I'm just glad it's working with the full DN usernames, but I think I have to chalk this one up to "one of those mysteries" for now.
If I ever do find the real reason for this problem (and I suspect that it'll exhibit itself at some point, possibly with different symptoms), I'll post back here.
In the meantime, again, thanks for your help!
Jim
# 6
Hi,
Sorry, I just saw the other thread re. error 49, and want to let you know that, as I alluded do, I've done a lot of checking to eliminate possibilities, e.g.:
- I verified that the user entries all had both samAccountName and userPrincipalName populated, e.g., user "foo" had:
o samAccountName = foo
o userPrincipalName = foo@mydomain.com
- As mentioned, I also checked for UPN conflicts, and found none.
Thanks again. I hope I figure this one out one of these days :)...
Jim
