Performance issues With Impersonation and Delegation

Discussion in 'ASP .Net Security' started by Bill Ward, Oct 5, 2006.

  1. Bill Ward

    Bill Ward Guest

    Hi there,

    I have some severe performance issues that seem to be associated with
    impersonation and delegation. We are designing n-tier solutions with ASP.NET
    web services as the middle tiers and SQL databases and windows services on
    the back end. None of the traffic hits the internet. All of the machines and
    users are members of a single Windows domain that uses Kerberos for
    We would like the identity of the user propagated all the way down the chain
    of web services calls to the back end. That way we can use group membership
    to control access at any point. To enable this we have set up all the web
    services to use windows authentication and impersonation and we allow
    delegation between servers. This all seems to work correctly, but VERY
    slowly. I wrote a command line utility that calls a web service repeatedly
    with a web method that does nothing other than return. With the web service
    configured for windows authentication and impersonation I could make 3 calls
    per second (THREE!). By multi-threading the client I could get all the way
    up to nine. By allowing anonymous access to the web service, the call rate
    went up to about 450 calls/s.
    Sniffing the wire reveals that for every call, things roughly follow this
    pattern. First clients try anonymous access to the web service and are
    rejected. They then try again with an identity. The web service then goes
    off and checks with the domain controller via a DCE RPC call (presumably
    authenticating the caller's Kerberos ticket or something). The DC dutifully
    replies and eventually the web service replies to the client.

    Have I hit a fundamental limitation of this security model? If so, there
    must be an alternative somewhere. If not, have I missed something that makes
    the web server query the DC for every call. Can I configure the client
    somehow to know that the service requires authentication so that the first
    (wasted) round trip does not occur?

    I have no idea where to start looking for the solution. Suggestions will be
    gratefully received.


    Bill Ward, Oct 5, 2006
    1. Advertisements

  2. Bill Ward

    Joe Kaplan Guest

    Are you actually seeing any Kerberos traffic (port 88 TCP or UDP) with the
    client to the web server? If not, you are failing over to NTLM on the
    intial auth. It is generally slower than Kerb in my experience, especially
    on repeat visits, so that might be something to look into.

    If your domain and servers are all running 2003, you could be getting
    protocol transition from NTLM to Kerberos automatically (which would enable
    the delegation) and you might not even notice it.

    One thing that I've found very helpful when troubleshooting these issues is
    to enable auditing of all logon events on all machines in the stack and look
    at the security event log so you know exactly how each user or service is
    authenticating to the next tier. You'll be able to tell Kerb from NTLM in
    those cases.

    Joe K.
    Joe Kaplan, Oct 5, 2006
    1. Advertisements

  3. Bill Ward

    Bill Ward Guest

    I'm back to looking at this issue. Joe, you seem to be correct. I am seeing
    no traffic on port 88.
    I enabled Kerberos logging on the web service server and now for every web
    service call I can see an event about about assigning special priviliges to
    the new login (presumably this is the impersonation?) followed by an NTLM
    authentication event.
    So, the question is, how do I get Kerberos authentication to take precedence
    aver NTLM authentication? Do I need to set other parameters on the web
    service or do I need to make some changes to the client code? All I do at
    the moment on the client is set the Url property of the Web Service proxy
    and then the Credentials property to
    System.Net.CredentialCache.DefaultCredentials or DefaultNetworkCredentials
    (both seem to create identical network traffic).
    Bill W.
    Bill Ward, Oct 24, 2006
  4. Bill Ward

    Joe Kaplan Guest

    Typically, you don't get Kerberos auth because the name you are using to
    access the remote service doesn't have a matching SPN associated with the
    service account that is running the service. I always start there.
    Sometimes with IIS-based services, Kerb has actually been disabled in the
    metabase. You can discover this if the www-authenticate head returned by
    the server challenge only says NTLM instead of Negotiate. If that is the
    case, there is a metabase property you have to change to make it return

    Start with the SPNs though. They are all stored in AD. You can find the
    service account in AD with an LDAP query and return its servicePrincipalName
    attribute to see what SPNs are registered.

    Joe K.
    Joe Kaplan, Oct 24, 2006
    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.