Performance issues With Impersonation and Delegation

B

Bill Ward

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
authentication.
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.

Thanks

Bill
 
J

Joe Kaplan

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.
 
B

Bill Ward

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).
Thanks
Bill W.
 
J

Joe Kaplan

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
Negotiate.

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.
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,969
Messages
2,570,161
Members
46,705
Latest member
Stefkari24

Latest Threads

Top