Re: ActiveDirectoryMembershipProvider & ValidateUser

In AD, the sAMAccountName is the part of the NT logon name after the \, so
it is basically <domain>\<sAMAccountName>. If the membership provider does
a search with an LDAP filter like (sAMAccountName=xxxx), it will only match
if the value it is using is the part after the \, or the unqualified part
(what I was getting at).

The membership provider may do some trickery to parse out a qualified name
that you typed in though, so you might as well test it to see how it
behaves. I'm basing my recommendation more on my knowledge of how the
actual LDAP query to find the user works than on direct knowledge of the
membership provider's behavior.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Craig Wagner" <MSDNNospam207@xxxxxxxxxxxxx> wrote in message
news:867B3630-3093-452F-BA45-F38541A5E9F0@xxxxxxxxxxxxxxxx
It's helpful for a couple of reasons:

1. Now I have a specific question I can ask our admins, whether we use
implicit userPrincipalNames.

2. Because we install our software in our clients' environments, it's good
to know that this is a possibility. Sounds like we might be better off
planning to use the sAMAccountName.

I just want to clarify one thing. When you said "If you need to use
sAMAccountName, make sure you are using the unqualified version of the
name",
you were referring to using cwagner instead of cwagner@xxxxxxxxxxxx or
stockamp\cwagner, correct? When I read that question it seems really
stupid
and basic, but I just want to make sure there isn't some other way what
you
said can be interpreted.

"Joe Kaplan" wrote:

It is entirely possible that your company is using implicit
userPrincipalName values instead of expliciting setting them. By
default,
if UPN isn't set, then the user will have an implicit UPN of
sAMAccountName@DNSDomainOfTheDomain. This works for authentication, but
I'm
not sure you can search for it that way. I wouldn't be surprised if you
can't in this particular case. I actually don't have an AD to play with
right now that uses implicit UPNs, so I'm not sure what the expected
query
behavior is.

If you need to use sAMAccountName, make sure you are using the
unqualified
version of the name.

In a multi-domain environment, sAMAccountName will be unique to a given
domain, but it won't necessarily be unique across the forest. UPN is
supposed to be unique forest wide, although the DS doesn't actually try
to
enforce that like it does with sAMAccountName at the domain level.

I hope that helps some. I wish I knew all the details here.



.