Active Directory Blog : Kerberos

When Smartcard Logon Doesn't

Tim Springston — Mon, 06 Apr 2009 17:48:00 GMT

Authentication is entering every facet of our lives nowadays. It is common to have multiple passwords: passwords for work, home email, and Internet websites to name a few. It’s easy to have a lot of different passwords, and equally easy to use only one...(read more)

Downgrade "Attack"? A little more info

Tim Springston — Fri, 20 Mar 2009 18:56:00 GMT

I decided that we needed some more detail and to give a walk through scenario on this downgrade attack deal I mentioned a while back in a blog post . As a recap, a customer called in after noticing the events below appearing intermittently but repeatedly-and...(read more)

Tabula Rasa

Tim Springston — Wed, 14 Jan 2009 17:15:00 GMT

I was well and truly stumped a few months ago. I joke that once a year I am flat out wrong, and rarely do I have nothing to say on a subject. The 'once a year I may be flat out wrong' statement may be true simply because after 15 years in the IT industry...(read more)

Scary Sounding Errors

Tim Springston — Fri, 12 Dec 2008 18:44:48 GMT

We have a temporary role in CSS where support folks will help out in supporting prerelease (also known as beta) software. I’ve worked a couple of Windows betas, and it’s a great experience. I mention this since I remember a few...(read more)

Why! Won't! PAC! Validation! Turn! Off!

Tim Springston — Mon, 29 Sep 2008 16:00:00 GMT

A while back I wrote a blog post regarding PAC (Privilege Attribute Certificate) validation in Microsoft Kerberos. We’ve had enough interest in this lately, particularly around the idea of disabling it, that it seemed like a good idea to post about this...(read more)

Trusted For Delegation in Services for User (S4U)

Tim Springston — Fri, 09 May 2008 19:20:00 GMT

A while back I did a blog post regarding the user interface and settings for configuring a service account correctly to allow the more complex Kerberos delegation scenarios to take place. I recently had a customer issue I helped with that gave a good...(read more)

Dude, where's my PAC?

Tim Springston — Mon, 21 Jan 2008 17:20:00 GMT

Something that is becoming more prevalent over the past few years has been great investments into our security technologies for application oriented reasons. Impersonation, people, that’s what I’m talking about. If anyone ever asks you what the big deal...(read more)

T2A4D (Coincidentally What I Would Name A Droid, If I Had One)

Tim Springston — Mon, 17 Dec 2007 18:04:00 GMT

Not another post about Kerberos! Sorry folks, my Momma said ‘stick with what you’re good with’. And since playing Halo 3 is not a paying job I’m doing another blog post on Kerberos. I thought this would be a good one to post since how this works can save...(read more)

Server 2008 and Windows Vista: Encryption Better Together

Tim Springston — Fri, 02 Nov 2007 15:00:00 GMT

A while back I did a blog post about some problems that were seen with people testing Windows Vista and then “rolling back” to Windows XP and some problems that could be seen when using the same computer object (also known as account) in AD. If you didn’t get a chance to read it here’s the post. What that scenario highlighted was the added level of encryption, by way of leaving behind a little of the supporting infrastructure in the msds-supported-encryptiontypes attribute value. In this post we’re going to talk about the Big Picture of the new authentication encryption available and a few things to keep in mind....(read more)

Kerberos Constrained Delegation, FE and BE Servers Must Be In Same Domain

Tim Springston — Wed, 24 Oct 2007 16:20:00 GMT

This has come up several times, and I suspect will continue to do so occasionally. So I thought I’d post about this real quick in order to get the word out and also make sure that I don’t give the wrong answer on this to someone again (I forgot, gave...(read more)

All The Logging In The World

Tim Springston — Mon, 08 Oct 2007 19:40:00 GMT

There’s normal troubleshooting and then there’s the stuff you do when the basic troubleshooting doesn’t get things resolved. Normal troubleshooting can be things like selecting “last known good” on a reboot after installing a new driver and having a blue screen. Or perhaps uninstalling and then reinstalling an application, or altering settings for the application or operating system to alleviate a problem. Sometimes we have to dig in and find out more. Many admins out there in the world live that every day. Which is why we add methods to find out more into our products. This post is all about listing all of the data gathering methods that a Directory Services person may ever need to know. Since there are so many it will be difficult to organize well in one uber post but I’m going to put out here for you all anyway, disorganized or not....(read more)

How To Disallow NTLM Authentication on a Per Resource Basis

Tim Springston — Tue, 04 Sep 2007 15:30:00 GMT

One of the most exciting and fulfilling things that I get out of my job is the opportunity to resolve unique customer concerns and scenarios. I’ve said this before in prior blog posts, but this one in particular, I think, will illustrate that.

One of my colleagues was working an issue where his customer mentioned that they are seeing a user being granted more access to a file resources on a share when than what they should have. Neither the user, nor a group he had been added to, was listed as having anything more than read allow access, yet the user could edit and even delete the files.

Typically what we do in these support situations is to use a tool like MYTOKEN.EXE or WHOAMI.EXE to “dump” the information in the user’s security token to list out the security groups and other access data that the user has when they have successfully logged on. We do a similar “dump” of the access control list (also known as permissions) on the object (file or folder typically) using SUBINACL.EXE or similar tools.

Then we compare the list of permissions with what the user has in their token. Sort of a poor man’s dry run access check, since a similar mask comparison is actually what is done “under the hood” when a user requests access to a resource.

In my colleagues case, though, there was no explicit or inherited permission for his user account or a group that was in his token which would appear to allow him access to the files he had access to. This was especially puzzling since most of us think of our permissions technology as complex but well understood. Unexpected stuff happening is, well, unexpected.

There was one entry that was different than what we normally see. Let me show you and see if you pick it out right off.

The access control list (ACL) on the folder and the files had an entry like this:

G:\SHARE1

BUILTIN\Administrators:(OI)(CI)F

BUILTIN\Backup Operators:(OI)(CI)C

DOMAIN1\Domain Users:(OI)(CI)R

NT AUTHORITY\NTLM Authentication:(OI)(CI)F

DOMAIN1\DOMADMINS:(OI)(CI)F

NT AUTHORITY\SYSTEM:(OI)(CI)F

Whoami /all from the user was (RIDs obfuscated to protect the innocent):

[User] = "DOMAIN1\joebob" S-1-5-21-8675309-8675309-1417005543-3544

[Group 1] = "DOMAIN1\Domain Users" S-1-5-21-8675309-748552-1417001333-513

[Group 2] = "Everyone" S-1-1-0

[Group 3] = "BUILTIN\Administrators" S-1-5-32-544

[Group 4] = "BUILTIN\Users" S-1-5-32-545

[Group 5] = "NT AUTHORITY\REMOTE INTERACTIVE LOGON" S-1-5-14

[Group 6] = "NT AUTHORITY\INTERACTIVE" S-1-5-4

[Group 7] = "NT AUTHORITY\Authenticated Users" S-1-5-11

[Group 8] = "LOCAL" S-1-2-0

[Group 9] = "DOMAIN1\janitors" S-1-5-21-8675309-92003306-1417001333-1199

If you looked at the permission ACE for “NT AUTHORITY\NTLM Authentication:(OI)(CI)F” as the culprit allowing the user access then you picked the right one. Removing that from the ACL removed JoeBobs full access to the folder and it’s files. He could only then get Read Allow via his Domain Users group membership, as originally planned.

Which leads us to our next question: Why?

We have different authentication mechanisms used for connections or network protocols, as you all likely know, and each has its own strengths. Kerberos is the most widely used for authenticating in a Windows 2000 or 2003 domain, but there is support for NTLM (the legacy authentication used most in NT 4.0), digest, and SChannel (SSL/TLS) to name a few others. The most secure of those named is Kerberos, and a best practice is to write applications so that they use Kerberos authentication rather than others, like NTLM, which are inherently less secure.

So back to the question of ‘why’. As it turns out this user had connected and authenticated to the server using NTLM, and once he had done so, the authentication package used was an additional part of his token. Now, this is somewhat of a simplification, but you can understand if we don’t get too specific in the details on this, right?

Bottom line was that the user connected to the server using RPC, and that connection was authenticated using NTLM (unfortunately, since NTLM is less secure than others like Kerberos). As a result, a new entry was added to his token which wasn’t readily apparent from the WHOAMI output: NTLM Authentication. It was this unseen but very present turdlet that allowed the access.

If we reason this out a bit further it becomes obvious that if the user had authenticated using Kerberos or some other mechanism then he would have received an access denied to the folder and its files.

Now let’s take that a bit further still. What if you were to deny access to the folder and its files for the NT Authority\NTLM Authentication group? That would mean that any user who had used that less-than-ideal authentication when connecting would be denied access to the resource. And that’s good since that would make only those connections who were less likely to be impersonated or spoofed the ones who would be able to read, edit, delete and such the contents of the directory.

That’s a cool thing indeed. By the way, it really works that way.

In your Active Directory domain there are a few objects in the Configuration container which are defined as foreignSecurityPrincipal objects and are used to represent authentication mechanisms. They are NTLM Authentication, Digest Authentication and SChannel Authentication. Each has its own Well Known Relative Identifier, or well known RID.

These are tied together in the operating system so that, when a user has connected via RPC which was authenticated using one of those mechanisms, then that RID will be added to the token. If you look at MSDN some of this is documented in the list of well known SIDs (below).

WELL_KNOWN_SID_TYPE (Windows)

http://msdn2.microsoft.com/en-us/library/aa379650.aspx

For the NTLM entry you’ll see this:

WinNTLMAuthenticationSid

Indicates a SID present when the Microsoft NTLM authentication package authenticated the client.

Does this mean that you can now, in a blanket manner, switch off all NTLM based authentication? Absolutely not. NTLM is still present, and you can mitigate it’s usage by altering the LMCompatibilitylevel of your environment and by making sure that DNS name resolution is working well throughout.

What it does mean is that if you have placed a deny access control entry (permission) on a file or folder for that authentication mechanism , and if the users connection via remote procedure call (RPC) was authenticated using that mechanism, then that user would be denied access to that file or folder. So you can, in effect, deny access based on NTLM being used by the users connection, or digest, or SSL.

Does this carry over to when accessing objects in AD? Good question O Reader. Below you’ll see my connection to a test domain of mine where I used LDP.EXE, specified NTLM in my bind and then tried to access objects which I had placed an explicit Deny Full entry for NTLM Authentication. The object I placed the deny on was OU=JP,OU=Regions,DC=tspringtest,DC=com.

I’m snipping some of the LDP.EXE output for brevity’s sake, but it’s still a bit so be ready to scroll.

ld = ldap_open("tspringdc1", 389);

Established connection to tspringdc1.

Retrieving base DSA information...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn:

1> currentTime: 08/29/2007 15:13:38 Central Standard Time Central Daylight Time;

<snip>

-----------

res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 4230); // v.3

{NtAuthIdentity: User='joebob'; Pwd= <unavailable>; domain = 'tspringtest'.}

Authenticated as dn:'joebob'.

Expanding base 'DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: DC=tspringtest,DC=com

3> objectClass: top; domain; domainDNS;

<snip>

-----------

Expanding base 'OU=Regions,DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: OU=Regions,DC=tspringtest,DC=com

<snip>

-----------

Expanding base 'OU=JP,OU=Regions,DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: OU=JP,OU=Regions,DC=tspringtest,DC=com

-----------

***Calling Security...

Error: Security: No Such Attribute. <16>

Server error: <empty>

*********

That last portion above, “Calling Security”, is where I attempted a modify operation against the security descriptor of the Regions OU. Didn’t get much did I? In fact, I wasn’t able to see much at all with that Deny for NTLM Authentication ACE in there, was I?

Now view the same attempted access to the Regions OU after I removed the deny ACE for NTLM Authentication:

-----------

Expanding base 'OU=JP,OU=Regions,DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: OU=JP,OU=Regions,DC=tspringtest,DC=com

2> objectClass: top; organizationalUnit;

1> ou: JP;

1> distinguishedName: OU=JP,OU=Regions,DC=tspringtest,DC=com;

1> instanceType: 0x4 = ( IT_WRITE );

1> whenCreated: 01/19/2007 11:39:45 Central Standard Time Central Daylight Time;

1> whenChanged: 08/29/2007 15:19:58 Central Standard Time Central Daylight Time;

1> uSNCreated: 74464;

1> uSNChanged: 312236;

1> name: JP;

1> objectGUID: 47c6909b-e7da-4f69-8297-4040c8dfaaef;

1> objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=tspringtest,DC=com;

1> gPLink: ;

1> gPOptions: 0;

-----------

Expanding base 'OU=Tokyo,OU=JP,OU=Regions,DC=tspringtest,DC=com'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: OU=Tokyo,OU=JP,OU=Regions,DC=tspringtest,DC=com

2> objectClass: top; organizationalUnit;

1> ou: Tokyo;

1> distinguishedName: OU=Tokyo,OU=JP,OU=Regions,DC=tspringtest,DC=com;

1> instanceType: 0x4 = ( IT_WRITE );

1> whenCreated: 01/19/2007 11:39:45 Central Standard Time Central Daylight Time;

1> whenChanged: 01/19/2007 11:39:45 Central Standard Time Central Daylight Time;

1> uSNCreated: 74466;

1> uSNChanged: 74467;

1> name: Tokyo;

1> objectGUID: ca9a1171-cb3e-4d0e-a160-ad1670cf4108;

1> objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=tspringtest,DC=com;

1> gPLink: ;

1> gPOptions: 0;

-----------

***Calling Security...

Security Descriptor:

String Format:

O:S-1-5-21-2237654438-801274086-1301698106-512G:S-1-5-21-2237654438-801274086-1301698106-513D:AI(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-<snip>

---

Security Descriptor:SD Revision: 1

<big ole snip of more SDDL data>

-----------

What’s the point of showing all of that data from LDP.EXE? To demonstrate that you can use the NTLM Authentication as a method to disallow access to specific resources when a user’s connection has been authenticated with a less secure mechanism in the Active Directory as well as on a network share. The above shows, similar to what you would see any instance you connect and query the directory and do not have sufficient access to read the directory object, that the objects properties are shown when there is access and no properties are shown when a Deny entry is added for NTLM Authentication.

So let’s summarize things a bit regarding what we’ve discussed in this post.

· Is it possible to “turn off” NTLM authentication? No.

· Can we use the NTLM Authentication group and its peers to prevent access for users who have authenticated using NTLM? Yes, if the user connected via an RPC connection.

· Will this work to prevent access to resources when connecting via IIS, ISA or other product? Not really. Each has its own unique code for authentication interactions that work with the platform’s SSPI. But perhaps you could alter the permissions on the resource objects the application serves out to do this. I encourage you to test it.

· When should I do this in my environment? You should set permissions to disallow NTLM (or others)for specific resources (files in a share or on disk, or objects in AD) which you deem valuable enough that you want only our most secure authentication protocols to be used to allow access to them.

· Are there dangers in setting denies for an authentication group? Much like any deny entry, there are dangers associated with over-restricting access. In this case, there are added concerns to be kept in mind regarding when you may have a problem authenticating using a more secure method like Kerberos you will not be able to failover to NTLM and still gain access to the resource.

· Can I place Deny access control entries based on Digest Authentication and SChannel Authentication as well as NTLM Authentication in order to deny access to those resources for people authenticated using those methods? Yes, it does.

I encourage everyone to test this in their environment, particularly when it comes to altering permissions in your directory. As you test if you see any unexpected behavior, such as access when its unexpected, take a network trace of the connection to verify what authentication is negotiated. I can personally attest from my own repros in preparing this post that Kerberos is one resilient and robust authentication mechanism since I had some trouble getting it to not work. But that’s just one more reason everyone should use our product.

Finally, some folks have sent questions to me which I haven’t answered. My apologies for the delayed replies, I’ll be replying as soon as I

can. Have a great day everyone!

Vista Issue: Time Skew Error When Logging on Across a Trust

Tim Springston — Fri, 25 May 2007 01:53:00 GMT

One of the cool things about this job is the way we get to trail blaze new issues as they happen and before any solution or workaround is in sight. We’re the pioneers in a way. This is one example.

We’ve had a few customer’s recently mention that they had seen an odd behavior from their Vista clients. When their environment fit certain criteria they found that the Vista workstations could not successfully log into the domain. Those criteria were: logging in across a trust (where user account was in one domain, computer account in another), the workstation was Windows Vista (didn’t occur on other operating system clients of the same domains), and the users account properties in AD were set to “do not require Kerberos preauthentication”. Removing the “do not require Kerberos preauthentication” check box from the user properties would make the problem magically disappear.

So, when a user tried to logon to that “accounts” domain in this manner they would fail to logon successfully and would instead get a message with a white X in a red circle that said “There is a time and/or date difference between the client and server”. This would occur when no significant time difference existed. Keep in mind that the allowed skew (difference in time) here is by default 300 seconds, or 5 minutes.

At first I thought this was simply a result of some uniqueness in their environment, like a custom password filter, since we have seen some surprising behaviors from custom code like that in the past. However, all of our testing resulted in that not being it.

Next, I explored the thought that perhaps this has to do with a new feature in Windows Vista. Specifically, the fact that Vista clients do not automatically send their pre authentication data to the KDC during the initial TGT request traffic (or AS_REQ for your die-hard Kerberos folks out there). This is intentionally done as a method to negotiate using the highest level of encryption that Vista can support to encrypt that preauth data with. Namely, Advanced Encryption Standard (AES). The way this goes is that the DC responds with an AS_REP with the KDC_ERR_PREAUTH_REQUIRED error as well as a list of the encryption methods which the DC supports. For Longhorn DCs the response will also include AES, so when the Vista workstation sees that it resends the AS_REQ-with preauthentication data this time!- but it encrypts it using AES which it now knows the KDC supports. For non-Longhorn DCs it simply resends the AS_REQ encrypted using one of the encryption methods supported by that responding DC.

Sadly, that was not the origin of this little gem of a problem.

Then we discovered that we could reproduce this in our own test environments. Quell surprise that was. This led to a few other revelations, like there is one other unique circumstance needed, in addition to those we already knew about. Namely, if you have a later version of KdcSvc.dll on your Server 2003 domain controller then you will not see this behavior. We found that a security update, and Server 2003 Service Pack 2 includes a newer version of KdcSvc.dll as well, and that also prevents this issue.

So, what do you do if you see this in your environment?

· First, check the time on workstation and server with Mark One Eyeball to make sure that there isn’t in fact any time or date difference.

· Second, makes sure this only occurs for Vista clients.

· Third, verify that the “do not require Kerberos preauthentication” check box is set on the user experiencing the problem, and that deselecting it and logging on as that user makes issue go away.

· Finally, check the version of KdcSvc.dll on the accounts domain (domain where the user account resides). You can do this by going to StartàRunàMSINFO32. Once System Information is open, go to Software EnvironmentàLoaded Modules and look for KDCSVC.DLL.

If you have this version or earlier on your “accounts” domain domain controllers then we would expect you to see the problem occur in this scenario:

kdcsvc 5.2.3790.1830 (srv03_sp1_rtm.050324-1447) 213.50 KB (218,624 bytes) 5/14/2007 5:22 PM Microsoft Corporation c:\windows\system32\kdcsvc.dll

If you have the security update below, or the SP2 version of the file then you should not see this issue:

Security update For Windows Server 2003 KB899587

kdcsvc 5.2.3790.3959 (srv03_sp2_rtm.070216-1710) 214.50 KB (219,648 bytes) 5/11/2007 2:21 PM Microsoft Corporation c:\windows\system32\kdcsvc.dll

Solution then is to update your accounts domain DCs with the latest version of kdcsvc.dll.

***Note: The time and date above are not indicative of version and "newness" of the file. Only the file version and "tree" info (such as 5.2.3790.3959 (srv03_sp2_rtm.070216-1710)) are the valid things to look at. Thanks to my colleague Robert Stampfer in Germany for pointing that out.***

In the off chance that the customers who experienced this issue in their environment see this blog post I’d like to give a big thank you for all of your patience on this issue.

Stay tuned for the next post folks-it’s another unique Vista issue and just as interesting!

A Reply: SPNs and Multiple NICs

Tim Springston — Tue, 01 May 2007 22:08:00 GMT

I recently received a few questions from the blog. I usually ask if the person minds if I post the question and reply, and in this case the person said he didn’t mind.

Special thanks to Matt Sinfield for his good question. Hopefully this will help everyone’s understanding of this. Here it is:

Hey Tim,

Thanks for the informative blog posts. I've been reading your entries from the viewpoint of healthy background stuff. Now on my current project I'm thrust into the limelight of trying to fix some authentication issues we're having in the scenario of IE-IIS-NAS and constrained delegation - it's fun but hard work.

However, while performing diagnosis I keep asking myself if having multiple NIC's in a machine (whether IIS or NAS) matters. From what I've seen it shouldn't as long as you cover the various names the service can be known by through appropriate SPN setting but I've not yet discovered the right docs that explicitly state this. For example say the IIS box has 1 NIC for Management, 1 NIC (teamed with another) for data etc. should I really care?

It just feels 'odd' that my colleagues have the AD DNS name as server@childdom.parentdom for IIS using the Management NIC IP yet the same server accessed via it's www.server.com http address (using a Unix DNS that AD DNS integrates with just to make it easy) have it resolving to the data NIC. I believe the key is SPN rather than IP but just wanted to run it past an expert....!

Cheers,

Matt

…and here’s my reply:

Hi Matt-

Sorry for the delayed reply. There is no document that I'm aware of which discusses multiple NICs and the impact on SPN creation and usage.

Simple answer: it does matter. It is not necessarily a bad thing however. It's just good to keep in mind in making sure that the correct SPN is being asked for and it's getting a ticket (that can be used successfully to gain access to resources).

The common concern is that an incorrect SPN is being registered by server, or requested by client, and it is either not given to the client who requested or not used by the destination that holds the resource a client wants access to. Having multiple NICs, and more pertinently, different or multiple domain suffixes on them, can complicate matters in that the client or server may use the incorrect NIC or suffix when doing SPN related functions.

Bottom line is that two things will tell you of a potential problem. First is a trace-if an error is present in the Kerberos traffic requesting a service ticket it's as obvious as a slap in the face. Second is to see if whatever is supposed to happen (like-I'm guessing-a web page on client that is actually a remote access to a file share via a web server) is working as expected. If you see no trouble in the above then you should be in the clear.

As far as the name being UPN format for SPN, if I recall correctly there is some code which deals well with using slightly different formats like that so it doesn't shout out to me offhand as being a problem. If you see otherwise, please let me know.

Hopefully I haven't muddied the waters for you. Also, would you mind if I posted your email below and the reply on the blog? I would post it without your name unless you state otherwise.

Tim Springston

Microsoft Corporation

These postings are provided "AS IS" with no warranties, and confer no rights.

Please feel free to send me your questions. I may not be the quickest in replying, but I promise to reply as soon as I can. Have a great week everyone!

Unusual Kerberos Failure...User to User to What?

Tim Springston — Fri, 13 Apr 2007 02:28:00 GMT

We get some really unique issues at times that strain patience and understanding. With Kerberos this is doubly true since it is already as complex and extensible as any person could ever ask for. This one may be particularly interesting to those who are creating new solutions using our Kerberos implantation, or are troubleshooting an already customized solution using it.

Recently we had an interesting scenario that I’ll relate here since it was both difficult to set up correctly, and even more difficult to troubleshoot with certainty. Specific applications, users, companies, and products have been removed to protect the innocent.

The scenario went like this. A partner company had a solution that would have a user connect to an IIS web server (call it Web Server A) from an Internet Explorer client. The connection was authenticated via a smartcard based certificate for client-authentication required HTTPS. Smartcards typically specify an universal principal name (UPN) for the user that will be using the smartcard, like billybob@craziness. This is “hard-coded” into the certificate in the smartcard for obvious reasons.

Once the HTTPS session was started, code running in the application pool on Web Server A would use Kerberos Protocol Transition to transition from TLS to Kerberos authentication. Then, since the identity the application running in Web Server A’s application pool was trusted for delegation, the app would contact Web Server B using HTTP (at this point, again, authenticated by Kerberos as the original IE calling user).

Keep in mind here that the smartcard/certificate is tied to the domain user’s account which is part of what enables us to transition from HTTPS- authenticated using that certificate as credential- to Kerberos as that domain user principal. In addition, in this scenario the customer had configured that Web Server A was constraining delegation from itself to just the HTTP service (web) running on Web Server B.

So, we’ve reached the Web Server B which also has an application running in the application pool. This application is intended to access a local resource (a file) on Web Server B on that users behalf and supply information or usage of that file resource back to the user in his IE browser window running on his client. It’s also intended to do that on the users behalf (that old “trusted for delegation” thing) and without having to get a ticket granting ticket for that users session prior to getting a service ticket to the local resource as that user.

Huh? you say. Exactly, I respond.

Here the customer was using a programmatic (available in our Solution Developers Kit, or SDK) method to do something called S4U2Proxy, a type of User to User authentication. Developers may wince when I describe this simply as a method to impersonate a user and request a service ticket on behalf of that user without ever getting a TGT to supply in the service ticket request. Normally, like when you logon to your domain member computer, you request a TGT from the KDC and then once you have that you request the service tickets (like for your local session) that you need using that TGT as your ‘credential’. That’s why TGT stands for Ticket Granting Ticket. You got TGT, KDC grant service ticket.

The “service for user to proxy” or “user to user” methods are a way to write a program to accept a service ticket for a local resource it has from a user and then turn around and use that ticket to request a new ticket to a resource on behalf of that user without having a TGT, having to request a TGT and without having any real access to the users “secrets” like password or private key. This is a good thing, from a security standpoint. Keep in mind that the application is running in a context that is trusted for this otherwise this wouldn’t happen.

In addition, this extension to our Kerberos implementation is often done in conjunction with constrained delegation, adding an additional bit of security.

A more general article about this type of thing is available at the URL below. It’s a good a good reference in that it goes over all of the points of configuration in some detail, as opposed to looking at it holistically like I do.

Exploring S4U Kerberos Extensions in Windows Server

http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/

The problem (that’s right, I just now got to it) was that the supplied information was not provided successfully to the user in his or her IE browser window, and they were instead prompted for credentials.

If you’ve read my prior blog posts regarding Kerberos then you know that I’m a big proponent of viewing all of these transaction “on-the-wire”-network captures. This scenario was not different in that respect and I was hopeful that it would tell us how far along in the scenario we got before things did not work as expected.

So we gathered network captures, all taken at the same time, of the client computer, Web Server A and Web Server B. In them we saw HTTPS traffic from client to Web Server A and no errors. Step one done, no problem.

We then looked at the network traffic from Web Server A to Web Server B. As previously mentioned, this traffic was also HTTP. In viewing the HTTP authentication information displayed in the packets we could tell that a service ticket was being supplied successfully there as well, and no errors were seen in the capture. This told us that our constrained delegation was not a factor otherwise we never would have sent that traffic with that service ticket.

So that suggested that there was something happening once we reached Web Server B successfully. At this point we did some head scratching and decided we needed to look a little deeper. We decided we needed to enable Kerberos debug logging on Web Server B and see what’s happening.

As an aside, Kerberos debug logging, when described as a debug log, is a registry value change that takes the debug entries in our Kerberos code and dumps them to a log file called %systemroot%\system32\lsass.log. This file can be opened and read using Notepad or Wordpad. I took a moment to explain this since some folks may be familiar with another similar technique where you can increase the verbosity (and frequency as a result) of the Kerberos specific events which appear in the System event log. That’s a different thing, and in my opinion, and usually not as helpful.

The link below, Troubleshooting Kerberos Errors, has the step on how to enable Kerberos debug logging. Just search it for “lsass.log”.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

In that log is a lot of information that can be pretty confusing at first glance.

Here’s a snippet of what we saw:

1060.1188> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x396f98, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1204> Kerb-Warn: Trying to delegate but no forwardable TGT

1060.1204> Kerb-Warn: KerbBuildGssChecksum failed to get delegation TGT: 0x8009030e

1060.1156> Kerb-Error: KerbS4UToSelfLogon failed - c000000d

1060.1196> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x39eaa8, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1200> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x39ec94, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1188> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x39ecfa, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1196> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x39ed66, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1204> Kerb-Warn: Trying to delegate but no forwardable TGT

1060.1204> Kerb-Warn: KerbBuildGssChecksum failed to get delegation TGT: 0x8009030e

1060.1244> Kerb-Error: KerbS4UToSelfLogon failed - c000000d

1060.1196> Kerb-Error: KerbS4UToSelfLogon failed - c000000d

1060.1200> Kerb-LSess: KerbFindCommonPaEtype using current password of billybob@craziness@(null)

1060.1200> KSupp-Warning: KerbUnpackData failed to unpack typed data, trying error method data

1060.1200> Kerb-Error: KerbCallKdc failed: error 0x18. d:\nt\ds\security\protocols\kerberos\client2\logonapi.cxx, line 1715

1060.1200> Kerb-Warn: KerbFindCommonPaEtype using old password of billybob@craziness@(null)

1060.1200> Kerb-LSess: KerbFindCommonPaEtype using current password of billybob@craziness@(null)

1060.1200> Kerb-Warn: KerbFindCommonPaEtype using old password of billybob@craziness@(null)

1060.1200> Kerb-Error: GetAuthenticationTicket: Failed to build pre-auth data: 0xc000006a. d:\nt\ds\security\protocols\kerberos\client2\logonapi.cxx, line 1482

1060.1200> Kerb-Warn: LogonUser: Failed to get TGT for (null)\billybob@craziness : 0xc000006a

1060.1188> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x3edc3f, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1244> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x3ee61a, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1156> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x3ee6a7, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1188> Kerb-LSess: KerbCreateLogonSessionFromTicket creating logon session for 0:0x3ee714, accepting 0:0x3e7, client billybob@craziness@DOMAIN1

1060.1204> Kerb-Warn: Trying to delegate but no forwardable TGT

1060.1204> Kerb-Warn: KerbBuildGssChecksum failed to get delegation TGT: 0x8009030e

1060.1200> Kerb-Error: KerbS4UToSelfLogon failed - c000000d

1060.1244> Kerb-Error: KerbS4UToSelfLogon failed - c000000d

A quick overview of this log. The left hand portion is not a time index (there isn’t one). This is process ID and thread. The type of entry which appears next is a general group of what kind of entry it is (Kerb-Warn, Kerb-Error, et cetera). Don’t be fooled by how scary things may look when you see Error and such. You will often see things like that in these logs, even when there is no problem at all.

The final entries are the actual debug entry information. These will contain the function (API) and the description entered in there. Some may contain some or all of the variable values that were being used. Therein lies some of the value you may find in looking at this log sometimes.

In the issue I’ve described this log was interesting for two general reasons. First, the list of calls being done and the order they are being done suggests that we are trying a S4ULogon using a service ticket that has been received. Second, the principal, or user, name being passed is some permutation of billybob@craziness, rather than deriving it from that user name.

What do I mean by that? A user of the UPN billybob@craziness may also be represented as craziness\billybob or similar. You don’t typically see the principal represented like billybob@craziness@DOMAIN1 or (null)\billybob@craziness. These are not names that can be parsed out and used to contact a domain controller and request services for. They are munged.

In this issue, knowing what the problem is half the battle (sorry for the GI Joe reference). For the above issue, it let our partner know that they needed to workaround this problem by adding a routine that does a name lookup on the user and then passes it to the authentication layer un-munged.

Why is this interesting to you? If you have a complex, customized single sign on scenario, and you are darned certain you’ve verified the configuration steps have been done well (outlined in the troubleshooting Kerberos delegation whitepaper) then review your network traces and lsass.log. Maybe you’re seeing a similar behavior. And knowing is half the battle.