ActiveDirectoryMembershipProvider & ValidateUser

[Craig Wagner]

In all the documentation I've read, the default behavior for ValidateUser on
the ActiveDirectoryMembershipProvider is that user names must be in
username@domain format.

My web.config contains:

<membership defaultProvider="AspNetActiveDirectoryMembershipProvider">
<providers>
<add name="AspNetActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider...
connectionStringName="ADService"
/>
</providers>
</membership>

I have tried calling ValidateUser with (e-mail address removed),
stockamp\craig_wagner, and craig_wagner and all three return false,
indicating that my credentials are invalid.

When I change my web.config to the following then, as expected, I can use
craig_wagner and authenticate.

<membership defaultProvider="AspNetActiveDirectoryMembershipProvider">
<providers>
<add name="AspNetActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider...
connectionStringName="ADService"
attributeMapUsername="sAMAccountName"
/>
</providers>
</membership>

Any idea what I should look for to try to determine why the initial case is
not authenticating with (e-mail address removed)?

 

[Joe Kaplan]

What happens if you change:

attributeMapUsername="sAMAccountName"

to:

attributeMapUsername="userPrincipalName"

And then try the user@domain format?

Joe K.

 

[Craig Wagner]

I just tried your suggestion and it still fails.

Could this have anything to do with the way the Active Directory itself is
configured? If so, what information do I need to ask our support guys for?

 

[Joe Kaplan]

I doubt that anything in AD needs to change. My guess is that my lack of
detailed knowledge of how the membership provider is designed is the problem
here.

A few more questions:
- Is the AD in question a single domain forest or are there multiple
domains involved?
- If multiple domains, is the user you are trying to authenticate in a
different domain than what you've configured the provider to access?

I'll try to do some poking around this afternoon to see if I can figure out
what the likely cause of the problem is.

Joe K.

 

[Craig Wagner]

I believe we have multiple domains, but the user I'm trying to authenticate
(me) is in the domain that the provider is configured to access.

I did just discover one interesting thing. I have an Active Directory on my
home network. I took my proof-of-concept code to my home environment and ran
it. There I was able to authenticate using user@domain.

What my POC does is authenticates using the
ActiveDirectoryMembershipProvider then uses DirectorySearcher to get
information about a username that was entered. Finally it spits out the
values of all the properties associated with the DirectoryEntry.

On my home environment, one of the properties that shows up in the output is
userPrincipalName. In my work environment the userPrincipalName is not in the
property collection.

 

[Joe Kaplan]

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.

Joe K.

 

[Craig Wagner]

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 (e-mail address removed) 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]

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.

 

[Craig Wagner]

I reverse-engineered System.Web so I could see what the ADMP was doing. It
doesn't do anything tricky with the input value for the user identifier.

I was able to find out from our IT staff that we do not explicitly set the
userPrincipalName, so your suggestion that that was the problem was bang on.

Thanks again.

 

[Joe Kaplan]

Cool. I learned a bunch too from this. I've still got a lot to learn about
the ADMP, but it is less frequent that I learn something about AD like this.
I'll keep the implicit UPN thing in mind for future reference.

Joe K.

 

[Mike Voissem]

Craig,
I'm trying to do much like you mentioned in your MSDN post titled
ActiveDirectoryMembershipProvider & ValidateUser. I'm wondering if I could
get some direction from you. I think what I'm trying to do is the same. I'd
like for an asp.net page with the login control to authenticate the user to
AD vs. using the ugly windows authentication login. For the life of me, I
have not been able to find any good example of how this all has to work.
There are bits and pieces but nothing makes any sense if I try to put it all
together. Plus, the web admin's aren't very familiar with asp.net for web
development. I appreciate ANY insight or direction you might be able to give
me.
Regards,
Mike

 

[Craig Wagner]

Sorry, I wasn't using the supplied login control. I was managing all the
authentication myself through a custom login form. I'm actually no longer
with that company, so the details of how I implemented the authentication
process are starting to fade.

 

[Joe Kaplan]

Have you looked at the MS Patterns and Practices article on using the AD
membership provider to authenticate with AD?

Note that there are a variety of drawbacks with using forms auth. The
primary thing you loose is the actual Windows security token for the user
which contains all of their group membership information and can be used for
impersonation and delegation. You may or may not need those features, but
if you do, they aren't so easy to get back with forms auth.

Joe K.