AD Login failure when using ActiveDirectoryMembershipProvider

Discussion in 'ASP .Net Security' started by Craig Wagner, Feb 22, 2007.

  1. Craig Wagner

    Craig Wagner Guest

    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.
     
    Craig Wagner, Feb 22, 2007
    #1
    1. Advertisements

  2. 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
     
    Patrick.O.Ige, Feb 22, 2007
    #2
    1. Advertisements

  3. Craig Wagner

    Craig Wagner Guest

    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.
     
    Craig Wagner, Feb 22, 2007
    #3
  4. 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.
     
    Dominick Baier, Feb 23, 2007
    #4
  5. Craig Wagner

    Craig Wagner Guest

    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).
     
    Craig Wagner, Feb 23, 2007
    #5
  6. Craig Wagner

    Joe Kaplan Guest

    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.
     
    Joe Kaplan, Feb 23, 2007
    #6
  7. Craig Wagner

    Craig Wagner Guest

    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.
     
    Craig Wagner, Feb 23, 2007
    #7
  8. Craig Wagner

    Joe Kaplan Guest

    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.
     
    Joe Kaplan, Feb 23, 2007
    #8
  9. 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.
     
    Dominick Baier, Feb 23, 2007
    #9
  10. Craig Wagner

    Craig Wagner Guest

    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.
     
    Craig Wagner, Feb 23, 2007
    #10
  11. Craig Wagner

    Joe Kaplan Guest

    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.
     
    Joe Kaplan, Feb 23, 2007
    #11
  12. 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.
     
    Dominick Baier, Feb 23, 2007
    #12
  13. Craig Wagner

    Craig Wagner Guest

    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, Feb 23, 2007
    #13
  14. Craig Wagner

    Craig Wagner Guest

    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.
     
    Craig Wagner, Feb 23, 2007
    #14
  15. Craig Wagner

    Joe Kaplan Guest

    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.
     
    Joe Kaplan, Feb 23, 2007
    #15
  16. Craig Wagner

    Craig Wagner Guest

    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
     
    Craig Wagner, Feb 23, 2007
    #16
  17. 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!
     
    Dominick Baier, Feb 23, 2007
    #17
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.