Duplicate UPNs and "default UPN"
- From: ohaya <ohaya@xxxxxxx>
- Date: Sat, 27 Jan 2007 13:49:37 -0500
Hi,
I've been continuing to try to figure out what was going on with a situation that I described in an earlier thread where an LDAP authentication was failing when using the user's name in UPN format:
"HELP! Really strange problem w/AD and LDAP/LDIFDE"
I've been able to 'almost', but not quite, replicate the problem, and I think that I've run across some interesting tidbits, so I thought I'd post and see if any of this makes sense.
As mentioned at the end of the last thread, I was able to create a situation where attempting to authenticate using the user's UPN, as contained in the "userPrincipalName" attribute, would fail, by creating two different users, in two different containers, with both users having their userPrincipalName attribute set to the same value (foo@xxxxxxxxxxxx).
ldifde with a simple bind with that UPN formatted username would then fail, but using a full DN, I could authenticate.
I've been continuing to research this problem, and I ran across the following post:
http://groups.google.com/group/microsoft.public.adsi.general/msg/ad305465977c54c5
which mentions a "default UPN", which, if I'm reading correctly ALWAYS exists, whether or not users' userPrincipalName attributes are populated, and which is formed by:
<samAccountName>@<domain DNS name>
So, I did a test, again, with the two users with the same userPrincipalName, but whose samAccountNames were foo1 and foo2, respectively, and while ldifde simple bind would fail with foo@xxxxxxxxxxxx, binding with foo1@xxxxxxxxxxxx and foo2@xxxxxxxxxxxx (using the respective passwords) worked!
So, it seems like:
1) If a user's userPrincipalName attribute is not populated, you can still bind using the "default UPN", consisting of <samAccountName>@<domain DNS name>, and
2) If a user's userPrincipalName attribute IS populated, you can bind using either the contents of the userPrincipalName attribute, or the "implicit" "default UPN", consisting of <samAccountName>@<domain DNS name>
All of the above still doesn't fully explain the problem in my earlier post/thread, because there:
- We could bind with either the UPN or full DN using ldifde, but my web app was failing when I tried to bind using the UPN, and
- The user did have the userPrincipalName attribute populated with what we thought was the correct info, but...
I just thought that this was all kind of interesting (and complicated), so I figured I'd post, and see if the above info was correct?
Thanks in advance for your patience!
Jim
.
- Prev by Date: Re: How do I stop users from moving file directories using explore
- Next by Date: Re: Domain not available
- Previous by thread: Win2k3 Domain controller and win2k member server
- Next by thread: How to bypass active directory and use MAC open directory for user login
- Index(es):
Relevant Pages
|
