Intermittent Kerberos authentication failure

Intermittent Kerberos authentication failure
Secure Home | Search | About
Login Password
Register Now! Lost Password?

Microsoft Applications Security - Microsoft's general security discussions and announcements 

Bookmark this page:  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Intermittent Kerberos authentication failure chen 06-14-2007
Posted by chen on June 14, 2007, 2:26 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
We're running into intermittent authentication failure with Kerberos
with our web application that results in 401 Unauthorized errors.

Here is an overview of the environment:
. The webapp is running on server A. It is configured for
impersonation. The worker process is running under a service account
(which is a domain account) and is enabled for delegation. SPN is
setup appropriately & AuthenticationProvider is configured to use
kerberos (Negotiate).
. The web app turns around and calls a webservice running on Server B.
This is also configured similar to the first server (trusted for
delegation, correct SPN setup & AuthenticationProvider set to
Negotiate)

>From a client machine, accessing the webapp which in turn accesses the
webservice works well for the most part... the end-user kerberos
credentials are being passed to the web service as expected. But
occassionally (frequency ranges between rare to once a week to number
of clients exhibiting this symptom all at once) the client encounters
401 unauthorized errors.

So we wrote a simple app that mimics the web app behavior that calls
the web service & display the identity of the user, authentication
type, impersonation level etc. We do see the authentication type
mysteriously switch to NTLM for a brief while before switching back to
Kerberos again. That explains the failure of the webapp call to
webservice but we're not sure why the Kerberos authentication fails
sometimes. This is somewhat harder to explain why this fails at
seemingly random times. We've looked at Network Monitor captures,
Kerberos logs, played with KerbTray/Klist to purge the tickets and
mostly we see the expected behavior.

We're running out of ideas and are no longer sure what we should be
looking for... in logs, captures etc. Anyone else experiencing similar
issues? Ideas anyone?

Thanks.

chen


Posted by chen on June 15, 2007, 11:48 am
If you were  Registered and logged in, you could reply and use other advanced thread options
One thing we noticed in the NetMon captures, the TGS request usually
looks for the SPN using the FQDN as in: Realm: xyz.com SName: http/
ServerA.xyz.com.

Sometimes, we see the SName in TGS request as http/ServerA instead of
the FQDN. This returns the KRB_ERROR- KDC_ERR_S_PRINCIPAL_UNKNOWN
which probably leads to Kerberos failure to switch back to using NTLM
authentication.

Under what scenarios will a client be sending a TGS request which does
not use the FQDN?



Posted by Joe Kaplan on June 15, 2007, 12:11 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
I've seen this issue reported before, but I can't remember the details. The
exact behavior you are seeing, ticket being requested initially with the
full DNS-based SPN but then switching over to the NetBIOS style and
potentially causing failure, is a known issue that I think may have
something to do with IE. I believe if you do some additional searches on
the newsgroups and MS KB, you'll find more info.

It may be possible to work around the issue by creating the other SPN as
well.

Another thing you might consider would be protocol transition logon and
constrained delegation. If you are using 2003 web servers throughout and
have a 2003 native AD, then it is possible to configure things so that the
front end can authenticate with any protocol you want (Kerb, NTLM, Digest,
basic, etc.) and then transition to Kerberos to do the delegated call when
needed. This feature requires you to use constrained delegation as well,
but that is generally a good idea anyway as unconstrained delegation is a
potentially serious security risk.

Good luck with this one!

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
> One thing we noticed in the NetMon captures, the TGS request usually
> looks for the SPN using the FQDN as in: Realm: xyz.com SName: http/
> ServerA.xyz.com.
>
> Sometimes, we see the SName in TGS request as http/ServerA instead of
> the FQDN. This returns the KRB_ERROR- KDC_ERR_S_PRINCIPAL_UNKNOWN
> which probably leads to Kerberos failure to switch back to using NTLM
> authentication.
>
> Under what scenarios will a client be sending a TGS request which does
> not use the FQDN?
>
>



Posted by chen on June 15, 2007, 5:08 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
On Jun 15, 12:11 pm, "Joe Kaplan"
> I've seen this issue reported before, but I can't remember the details. The
> exact behavior you are seeing, ticket being requested initially with the
> full DNS-based SPN but then switching over to the NetBIOS style and
> potentially causing failure, is a known issue that I think may have
> something to do with IE. I believe if you do some additional searches on
> the newsgroups and MS KB, you'll find more info.
>
> It may be possible to work around the issue by creating the other SPN as
> well.
>
> Another thing you might consider would be protocol transition logon and
> constrained delegation. If you are using 2003 web servers throughout and
> have a 2003 native AD, then it is possible to configure things so that the
> front end can authenticate with any protocol you want (Kerb, NTLM, Digest,
> basic, etc.) and then transition to Kerberos to do the delegated call when
> needed. This feature requires you to use constrained delegation as well,
> but that is generally a good idea anyway as unconstrained delegation is a
> potentially serious security risk.
>
> Good luck with this one!
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services
Programming"http://www.directoryprogramming.net
>
>
>
>
> > One thing we noticed in the NetMon captures, the TGS request usually
> > looks for the SPN using the FQDN as in: Realm: xyz.com SName: http/
> > ServerA.xyz.com.
>
> > Sometimes, we see the SName in TGS request as http/ServerA instead of
> > the FQDN. This returns the KRB_ERROR- KDC_ERR_S_PRINCIPAL_UNKNOWN
> > which probably leads to Kerberos failure to switch back to using NTLM
> > authentication.
>
> > Under what scenarios will a client be sending a TGS request which does
> > not use the FQDN?- Hide quoted text -
>
> - Show quoted text -

Thanks Joe. We'll explore the constrained delegation option more. And
yes, all the web servers & DCs are running Windows Server 2003.

Originally, we thought that this is somehow IE related (or browser
related as Firefox exhibits the same symptoms). But the netmon capture
shows that other service classes exhibiting similar behavior as well.
For e.g. we see TGS requests for 'cifs/<fileserver>' fail for almost
identical reasons as well. Again the fileserver is not the FQDN but
the NetBIOS name.

This leads me to believe that it is not the client processes that are
issuing these requests - more a system component (LSASS perhaps?) that
affects all processes running under the context of the logged on user.
So once again, under what scenarios does the TGS request flip from
using FQDN to NetBIOS style server names?

chen

PS: We've added the SPN for the NetBIOS style names as well & so far
based one days worth of testing everything looks good but we aren't
sure if we fixed or even understood the underlying problem.


Posted by Joe Kaplan on June 15, 2007, 6:52 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
I wish I knew the underlying problem. The way I remember the question going
when I heard it, I thought it was a browser issue as well but that doesn't
not sound like it is the case. I think your suspicion that this is going on
down in the guts of Kerb/lsass is correct.

I'm glad to hear that adding the NetBIOS style SPN seems to have fixed it.
My guess is that you are fine with that, but given my incomplete
understanding of the problem, I certainly can't guarantee you that. I'm not
sure who could. I'm also not sure if this only happens in cases where the
DNS name maps directly to an account with a known NetBIOS identity. I'm
guessing that if you created some sort of "DNS-only" identity with an A
record pointing to specific arbitrary name that you created, this probably
wouldn't happen. I'm not sure though.

It does bring up the point that if you create a specific SPN for a service
based on a DNS, it would seem to be necessary to create the matching NetBIOS
style SPN and put it on the same account. Also, as with other SPN rules,
you must be careful to never accidentally create a duplicate in AD for fear
of getting a different class of errors (ERR_AP_MODIFIED).

Best of luck again,

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
>
> Thanks Joe. We'll explore the constrained delegation option more. And
> yes, all the web servers & DCs are running Windows Server 2003.
>
> Originally, we thought that this is somehow IE related (or browser
> related as Firefox exhibits the same symptoms). But the netmon capture
> shows that other service classes exhibiting similar behavior as well.
> For e.g. we see TGS requests for 'cifs/<fileserver>' fail for almost
> identical reasons as well. Again the fileserver is not the FQDN but
> the NetBIOS name.
>
> This leads me to believe that it is not the client processes that are
> issuing these requests - more a system component (LSASS perhaps?) that
> affects all processes running under the context of the logged on user.
> So once again, under what scenarios does the TGS request flip from
> using FQDN to NetBIOS style server names?
>
> chen
>
> PS: We've added the SPN for the NetBIOS style names as well & so far
> based one days worth of testing everything looks good but we aren't
> sure if we fixed or even understood the underlying problem.
>



Similar ThreadsPosted
How to set up Kerberos authentication? (some code :) August 18, 2005, 5:55 pm
Kerberos pre authentication question June 30, 2006, 9:21 am
Kerberos Authentication in Mixed environment January 10, 2006, 12:41 pm
Kerberos with Windows Integrated authentication January 2, 2009, 6:58 am
Forcing XP Clients to use NTLM instead of Kerberos Authentication July 11, 2006, 1:21 am
Kerberos with "Selective Authentication" over forest Trust October 30, 2006, 10:12 am
Logon Failure July 5, 2010, 2:00 am
Failure Event ID 560 on SC Manager October 6, 2005, 8:40 am
Failure Event ID 560 on SC Manager October 6, 2005, 8:43 am
Failure Audits in Security Log May 18, 2006, 12:00 pm

The site map in XML format XML site map

Contact Us | Privacy Policy