AD Login failure when using ActiveDirectoryMembershipProvider

[Craig Wagner]

Here's my configuration:

- ASP.NET application
- Windows XP Pro running IIS
-Vdir is configured to allow anonymous access
- Anonymous access account is my domain account (for testing purposes it's
quicker and easier to do this than to try to get another domain account set
up)
- Web application has impersonation turned on (i.e. <identity
impersonate="true" />)

My web.config contains:

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

With the above configuration, when I hit the following line of code I get an
exception of "Logon failure: unknown user name or bad password."

Membership.ValidateUser( txtUsername.Text, txtPassword.Text );

If I change the web.config to the following, it works.

<membership defaultProvider="AspNetActiveDirectoryMembershipProvider">
<providers>
<add name="AspNetActiveDirectoryMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider...
connectionStringName="ADService"
connectionUsername="mydomainaccount"
connectionPassword="mydomainpassword"
connectionProtection="Secure"
attributeMapUsername="sAMAccountName"
/>
</providers>
</membership>

What has me baffled is that everything I've read says that if you don't
supply the connectionUsername and connectionPassword it will use the process
identity to connect to AD. The process identity SHOULD be my domain account,
because that's the anonymous access account and impersonation is turned on,
and it obviously works when I use my domain account credentials.

 

[Patrick.O.Ige]

hm.. Craig maybe what they mean is that if you want to use the process
identity to connect then use
<identity impersonate="true" /> with your username and passoword
Patrick

 

[Craig Wagner]

I just tried that and, to my surprise, it worked. That's very unusual,
because it's certainly not necessary for, say, file system or SQL Server
access.

However, it doesn't really solve the problem because my goal was to arrive
at a solution that doesn't require me to put a username and password in the
configuration file. If I have to put it in the config file anyway, I might as
well leave it where it was (in the membership area) and encrypt that section.

 

[Dominick Baier]

the problem is that XP is just not a realistic test environment!

to access AD you need a domain account, but ASP.NET runs under the local
ASPNET account on XP. IIS6 on Windows Server 2003 behaves totally different
as it uses a machine account that is a domain member when the machine gets
joined to the domain (or you manually set a domain account of your choice
for the worker process).

If XP is only your testing environment then you can temporarily use the <identity>
element.

 

[Craig Wagner]

I'm afraid I don't understand your comments.

You're right that the default process identity is the local machine ASPNET
account. However, as I stated, I changed the anonymous user to a domain
account and enabled impersonation, so the process credentials are now my
domain credentials.

Why is this not realistic? It's the same way I would configure the Windows
2003 server (i.e. change the anonymous account to a domain account and enable
impersonation).

 

[Joe Kaplan]

The AD membership provider disables impersonation when it does its DS
access, so that might explain the problem. If you are using XP and want
default credentials, you need to change the credentials in your processModel
in machine.config to a domain account for testing purposes.

Joe K.

 

[Craig Wagner]

That would explain it.

This is one reason I always have trouble with security-related items. If
I've got an app that's misbehaving when it makes database queries I can
always fire up Profiler and see what the heck it's doing when it connects to
the SQL Server.

Is there any sort of similar tool so that I can monitor what identity my app
is exposing when it makes resource requests?

It would also explain why the following, running in the same configuration,
works just fine (and was adding to my confusion):

DirectoryEntry entry =
new DirectoryEntry( "myconnectstring", null, null,
AuthenticationTypes.Secure );

There probably is no 'magic' going on behind the scenes that is disabling
the impersonation.

 

[Joe Kaplan]

You are correct. The DirectoryEntry code just uses the current security
context. The provider uses DirectoryEntry as well, but they have code that
actually reverts back to the process identity before doing the directory
access.

AD can tell you what happened when the logon failed, but the problem with it
is usually that you don't have any access to the domain controllers if you
are a developer unless this is a test lab, so it makes it much harder. A
network sniffer is very helpful, although they are so low level that it can
take a fair bit of practice to figure out what you are looking at.

The way I figured this out was by using .NET Reflector to reverse compile
the assembly for the provider and looking at the source code.

I agree that Windows security can be painful. At least the newsgroups don't
suck when you have questions. I've been putting off learning about the
AD membership provider for a while as I haven't needed it in my own work so
far and we never got to it in our book, so the education is useful for me.

Joe K.

 

[Dominick Baier]

No - thats not how you would configure an IIS6 -

you would configure the app pool to run as a domain account and use no impersonation.

 

[Craig Wagner]

Let me correct my previous statement.

That IS how we configure machines at the client site, and have been
configuring them for over a year.

Perhaps it is not how we SHOULD be configuring them, but that's a different
issue.

 

[Joe Kaplan]

I agree with Dominick. Use the app pool identity and create separate app
pools for each app if you need different credentials.

Also, in many cases you don't need to use a fixed domain account for the app
pool since the app pool runs as network service by default. Network service
IS a domain account when accessing resources on the network (the machine's
domain account), so this is often all you need.

Joe K.

 

[Dominick Baier]

and thats why you are having problems -

with a properly configured app pool you get a strong process token - with
impersonation just a weak thread token.

 

[Craig Wagner]

I had tried this approach when configuring Reporting Services. I set the
identity of the Reporting Services application pool to be Network Service,
but I was having trouble getting RS to successfully connect to its database.
I figured I'd end up having the same challenges in getting our apps to
connect to a SQL Server as well, so the fixed domain account seemed to be the
way to go.

I'll have to have another look at it.

 

[Craig Wagner]

One other reason I just thought of for using the fixed domain account...

It makes it more consistent when testing on the development workstations,
which are WinXP Pro. We can just set the domain account to be the anonymous
account and enable impersonation.

 

[Joe Kaplan]

If you want to use a fixed domain account, you can. I'd just suggest
setting the app pool identity instead of using the anonymous account with
impersonation. For WinXP development, change the processModel tag in
machine.config. I realize that is less flexible, but it gives you a better
simulation of how production will behave. The alternative is to dev on 2003
server (which is what a lot of us have ended up doing).

The trick you need to be aware of with using a fixed domain account for the
process account is that it can complicate how things work with Kerberos
authentication. Essentially, you need to manually set the appropriate
service principal name values on the account in AD for the service account
to do Kerberos authentication properly (assuming you need Kerberos
authentication, but it is always a good idea to use it if possible).

Joe K.

 

[Craig Wagner]

Earlier today I tried changing one of my Win2003 test servers to disable
impersonation and use the app pool identity (with a fixed domain account). We
are already putting our apps into their own pool, so this actually simplifies
configuring the server (we don't have to muck with the anonymous user
settings or the web.config file). That will be my recommendation to the
powers that be for future deployment.

I am going to mention using Win2003 as our development platform, but I don't
think it'll go very far, so I need to plan for that. I suspect cost will be
an issue. I'm personally a little leery of the idea because our 'development
workstations' are 1.7 GHz laptops with 1 GB of memory, and they need to run
PointSec (a hard drive encryption layer). As it is they are pretty slow, so
I'd be concerned about trying to run the beefier OS on them. I dunno, maybe
Win2003's resource requirements aren't that much more than XP's. Any feedback

 

[Dominick Baier]

I actually experienced better performance with W2K3 than XP on the same machine
(also laptop).

I've been running w2k3 2 years on my 1.8 Ghz Thinkpad - still rocks!