Click here to get back home

Kerberos headache

 HomeNewsGroups | Search | About
 microsoft.public.windows.server.security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
Kerberos headache Tapio Kulmala 02-01-2008
Posted by Tapio Kulmala on February 1, 2008, 7:33 am
Please log in for more thread options
Hi!

I've found an interesting problem that might have something to do with
Kerberos.

I have a www application running in a Windows Server 2003 box. The
server did not have SP1 or SP2 installed. Everything was working
smoothly. Couple days ago we installed SP2 and weird authentication
errors started to occur occasionally.

The webapp is configured to use intergrated authentication ( and
impersonation). It makes calls to a webservice (on the same server) that
allows integrated and basic authentication.

I thought that the whole chain uses NTLM-authentication and Kerberos is
not used at all. Now it seems that sometimes the call from the webapp to
the webservice fails and the security-eventlog shows an failed logon.

Logon Failure:
        Reason: An error occurred during logon
        User Name:                 
        Domain:                
        Logon Type: 3
        Logon Process: Authz
        Authentication Package: Kerberos
        Workstation Name: MYSERVER
        Status code: 0xC000040A
        Substatus code: 0x0
        Caller User Name: MYSERVER
        Caller Domain: MYDOMAIN
        Caller Logon ID: (0x0,0x3E7)
        Caller Process ID: 828
        Transited Services:        -
        Source Network Address: -
        Source Port: -



What is going on? Why only some calls fail and not all? Why did't this
occur with the RTM version?


Tapio





--
****************************************************************
Tapio Kulmala

"Those are my principles. If you don't like them I have others."

- Groucho Marx
****************************************************************

Posted by Joe Kaplan on February 1, 2008, 10:16 am
Please log in for more thread options
Wow, that's actually an interesting problem you have there. The substatus
error code is this:

# for hex 0xc000040a / decimal -1073740790 :
STATUS_NO_S4U_PROT_SUPPORT ntstatus.h
# The Kerberos subsystem encountered an error. A service for
# user protocol request was made
# against a domain controller which does not support service
# for user.
# 1 matches found for "0xC000040A"

So then, what does that mean? It appears your application is using the
built in support for protocol transition/S4U login in IIS to transition from
NTLM to Kerberos login for clients that authenticate with the front end web
app via NTLM instead of Kerberos. I'm guessing you have front end web app
pool identity configured to "delegate using any protocol" and have it
configured to delegate to a specific service (the web service SPN), right?

Kerberos S4U is a feature available in 2003 AD that also requires 2003
server or higher to execute. So, it looks like a Win2K DC or a DC that is
still in 2003 mixed mode is being contacted to log in this user. Is it
possible that the affected user is from a different domain in a different
forest that hasn't been upgraded yet? There should be a logon audit for the
front end application for this user showing the NTLM authentication and the
user name for you to track this down.

You shouldn't need to use S4U if you can enforce Kerberos login to the front
end web app instead of NTLM.

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
--
> Hi!
>
> I've found an interesting problem that might have something to do with
> Kerberos.
>
> I have a www application running in a Windows Server 2003 box. The
> server did not have SP1 or SP2 installed. Everything was working
> smoothly. Couple days ago we installed SP2 and weird authentication
> errors started to occur occasionally.
>
> The webapp is configured to use intergrated authentication ( and
> impersonation). It makes calls to a webservice (on the same server) that
> allows integrated and basic authentication.
>
> I thought that the whole chain uses NTLM-authentication and Kerberos is
> not used at all. Now it seems that sometimes the call from the webapp to
> the webservice fails and the security-eventlog shows an failed logon.
>
> Logon Failure:
> Reason: An error occurred during logon
> User Name:
> Domain:
> Logon Type: 3
> Logon Process: Authz
> Authentication Package: Kerberos
> Workstation Name: MYSERVER
> Status code: 0xC000040A
> Substatus code: 0x0
> Caller User Name: MYSERVER
> Caller Domain: MYDOMAIN
> Caller Logon ID: (0x0,0x3E7)
> Caller Process ID: 828
> Transited Services: -
> Source Network Address: -
> Source Port: -
>
>
>
> What is going on? Why only some calls fail and not all? Why did't this
> occur with the RTM version?
>
>
> Tapio
>
>
>
>
>
> --
> ****************************************************************
> Tapio Kulmala
>
> "Those are my principles. If you don't like them I have others."
>
> - Groucho Marx
> ****************************************************************



Posted by Tapio Kulmala on February 1, 2008, 1:48 pm
Please log in for more thread options
Thanks Joe

Everything you said makes perfect sense.

However, I don't undestand why this hasn't happened before SP1/SP2. And
why most of those calls succeed and only a few fails. Same user can surf
around the website with no problems and suddenly the ws-call fails.

This problem occurred in our systems test env on the customers network
and I don't know all details of their ActiveDirectory domain. I guess,
I'll have to ask them for more info.

I don't want to enforce Kerberos and I think there might be some other
issues that could even prohibit that. For example, we have two app-pools
that use a different account ( Network Service & a domain-account ).
It's a major pain to get Kerberos working right and i don't want to do
it unless i don't have any other choice. Not having any control over
their AD makes it even harder.

Tapio


joseph.e.kaplan@removethis.accenture.com says...
> Wow, that's actually an interesting problem you have there. The substatus
> error code is this:
>
> # for hex 0xc000040a / decimal -1073740790 :
> STATUS_NO_S4U_PROT_SUPPORT ntstatus.h
> # The Kerberos subsystem encountered an error. A service for
> # user protocol request was made
> # against a domain controller which does not support service
> # for user.
> # 1 matches found for "0xC000040A"
>
> So then, what does that mean? It appears your application is using the
> built in support for protocol transition/S4U login in IIS to transition from
> NTLM to Kerberos login for clients that authenticate with the front end web
> app via NTLM instead of Kerberos. I'm guessing you have front end web app
> pool identity configured to "delegate using any protocol" and have it
> configured to delegate to a specific service (the web service SPN), right?
>
> Kerberos S4U is a feature available in 2003 AD that also requires 2003
> server or higher to execute. So, it looks like a Win2K DC or a DC that is
> still in 2003 mixed mode is being contacted to log in this user. Is it
> possible that the affected user is from a different domain in a different
> forest that hasn't been upgraded yet? There should be a logon audit for the
> front end application for this user showing the NTLM authentication and the
> user name for you to track this down.
>
> You shouldn't need to use S4U if you can enforce Kerberos login to the front
> end web app instead of NTLM.
>
> Joe K.
>
>

Posted by Joe Kaplan on February 1, 2008, 2:07 pm
Please log in for more thread options
I'm actually really surprised that something like that would happen in a
test environment. They usually don't have lots of DCs, so the opportunity
to bounce around between domain controllers and have things flake out that
way should not exist.

It might be something along the lines of the browser auth switching between
Kerberos and NTLM and having this fail when NTLM is used since that causes
the S4U login to be attempted.

Is there a multi-forest thing going on here? It should not have been
possible for your front end web app pool identity to have been abled for
"delegation to any protocol" (the thing that allows S4U login to be used)
unless the forest was 2003 native mode. That should mean that all DCs in
that forest are 2003 and CAN do S4U. The only thing I can think of is that
there is another forest involved that isn't 2003 native. It is also
possible that something is royally screwed up in the test environment such
that my assumptions are no longer valid.

If that is the case, then you probably need to make sure that you do get
Kerberos authentication reliably on the front end web app. That probably
just boils down to ensuring you have the right SPNs set on the right
accounts in AD.

Kerb is a blast, isn't it? :) I've spent many hours playing around with
this stuff and getting it to work as design in production environments and I
still see cases (like yours) where I really don't know what's going on and
don't really know where to look to figure that out. I'm not sure how MS
expects typical admins to figure this stuff out.

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
>
> Everything you said makes perfect sense.
>
> However, I don't undestand why this hasn't happened before SP1/SP2. And
> why most of those calls succeed and only a few fails. Same user can surf
> around the website with no problems and suddenly the ws-call fails.
>
> This problem occurred in our systems test env on the customers network
> and I don't know all details of their ActiveDirectory domain. I guess,
> I'll have to ask them for more info.
>
> I don't want to enforce Kerberos and I think there might be some other
> issues that could even prohibit that. For example, we have two app-pools
> that use a different account ( Network Service & a domain-account ).
> It's a major pain to get Kerberos working right and i don't want to do
> it unless i don't have any other choice. Not having any control over
> their AD makes it even harder.
>
> Tapio
>
>



Posted by Tapio Kulmala on February 1, 2008, 2:49 pm
Please log in for more thread options
Typical admins can't figure these things out. I'll have to write them
instructions. :(

This customer is a quite small company and they propably don't have many
DC's. Like I said, I'll have to ask them for more details. I'll post
more info here when I get some.

Tapio

Similar ThreadsPosted
sharePoint and kerberos November 6, 2005, 5:35 pm
IPSec and Kerberos September 27, 2006, 10:17 am
Kerberos delegation December 7, 2006, 12:53 pm
[Q] Kerberos DES encryption April 20, 2007, 6:11 am
LSASS & Kerberos Documentation July 8, 2005, 11:35 am
Kerberos/ASP/Delegation/W2K3 July 19, 2005, 2:24 pm
How to set up Kerberos authentication? (some code :) August 18, 2005, 2:55 pm
Win2k3/IIS Kerberos challenges December 22, 2005, 1:42 pm
Kerberos and HOST Headers December 31, 2005, 6:40 pm
IPSec Kerberos issue? March 19, 2007, 9:39 pm

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap