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 people a lot of time, even though this is a less common question. This will help clarify, I hope, how to set the T2A4D value manually, and how it works in the user interface.
Windows Server 2003 Kerberos Extensions
http://technet2.microsoft.com/windowsserver/en/library/4c8b5ac7-368b-45b9-91d7-1ae7c5e0da311033...
In the article above the section titled “Enabling User Identification, Impersonation, and Delegation Through Extension Configurations” is where to look for a background on what we are discussing here.
On the face of it this can be some pretty confusing stuff. So let’s recap for a moment or two.
Delegation is where a user is trusting a service with their credentials so that service may do things on the users behalf. The things that service is doing is usually accessing and then providing resources back to that user. A typical idea here is that a web server is trusted with a users credentials and then that web service has code that (impersonating the users context to do so) queries a database for information and then ultimately supplies that information back to that user in their web browser on their client.
The concept is to reduce the need for users to manually enter their username and password while retaining a high level of security.
This concept is, well, extended with the Kerberos Extensions. You can do things like Protocol Transition where the user may never have to manually enter their credentials at all and still be secure but they instead start off their connection to (ultimately) the resource by using a different authentication method, such as SSL. Consider logging onto a web page which uses SSL- secured in part by a user side certificate issued to that user which verifies that users identity. On the web server you have connected to the web service will transition that user to Kerberos using code designed for that.
But there are checks done to make sure that the web service should be trusted to do such a very privileged thing. That’s where “trusted for delegation” and our good friend “trusted to authenticate for delegation” (abbreviated T2A4D) come in.
You are all probably painfully aware of the need for setting the user right for trusted for delegation and making sure that an account is not marked too sensitive to delegate in many Kerberos scenarios. To put it simply, T2A4D is an additional check done on the service account that is being trusted verifying that the service can get a ticket which can be forwarded on behalf of a user. Forwardable tickets of course can be sent to other services and those other services can then impersonate the user or pass those tickets along to another service on a different computer in order to gain access to a resource. Most importantly scenarios that use protocol transition and constrained delegation may require the T2A4D flag to be present in order for the forwadable ticket to be issued.
Failing to have the T2A4D set correctly could result in a ticket which cannot be passed to another service, or in some cases the ticket may not be passed at all. Keep in mind that in a lot of these cases it may not be obvious that not having T2A4D set correctly is your failing point. It’s just a good thing to check when you are using constrained delegation and/or protocol transition.
I’ll throw out one final caveat before we discuss the details of the setting. In most cases where this issue comes up there is room for someone’s custom code to be a factor. In other words there are a lot of folks out there that are writing applications which utilize (and rightly so, it’s very cool) the Kerberos extensions and our security scheme and there could be the possibility that a problem is not the settings in the Directory but actually a coding issue.
Let’s quickly move past the above comment as I sense there may be some developers out there cursing me.
The T2A4D setting has no actual check box or radio button which is intuitively titled “Click Here for Trust To Authenticate for Delegation”. Instead the setting is integrated with the constrained delegation settings interface on a computer account. Here’s a screenshot of that where the computer is not set to be trusted to delegate for authentication at all:
...and this is the same account in LDP.EXE:
Now, the above is often a service account on the server where the protocol transitions from X (where X is another authentication method) to Kerberos. But this could also be a middle tier server in a more traditional “double hop” scenario. These service accounts need to be actual computer objects created in your directory for the delegation tab to appear, and also keep in mind that the fancy delegation folder tab above will only be present when your forest is functional level of 2003.
So let’s follow through as we take a few screenshots of before and after settings where the T2A4D gets set in order to see when and where the T2A4D setting is set.
In this next picture we are set to use constrained delegation but have used the Kerberos only option (which really only constrains it to Kerberos Only, really), and not limiting the services on the remote destination we can get resources from:
Settings as above, and if you set a destination computer to constrain your delegation to, allow the T2A4D setting to be set.
The user interface works for telling if you have T2A4D set but is not the only place to look. Under the hood this setting is actually a flag on the useraccountcontrol value of the service account object. You can view this in ADSIEDIT.MSC or LDP.EXE easily. LDP.EXE is the preferred method since it will show you a clear text interpretation of the value, which is UF_TRUSTED_FOR_DELEGATION. Here’s a look at one that is set, taken from LDP.EXE:
Again, the above useraccountcontrol attribute will be present for when you specify to use Kerberos only, and even if you choose to specify the computer to delegate to. Once you limit the services the principal can delegate to, however, the T2A4D is removed:
Finally, I mentioned earlier in this post that the lack of T2A4D when needed may result in a ticket which is not set to be forwardable. The end result that is seen when there is a related problem is rarely a message stating that the ticket was not forwadable and therefore things failed. So, there are several easy ways to see if a ticket is forwardable or not. KERBTRAY.EXE and KLIST.EXE will work, however you must log on as that service account credential in order to use these.
Let’s finish up by making sure that things all make sense on this.
First, Kerberos has extensions which allow for us to begin authenticating a principals connection using some other authentication method besides Kerberos. In order for this to still be a safe thing there are some added checks the “trusted to authenticate for delegation” for the principal (service account, typically) setting in Active Directory to make sure this should be allowed.
In constrained delegation situations where we are specifying Kerberos only and we are narrowing both the destination computer that the principal can delegate to, and the services they can delegate with, the user interface will remove the “trusted to authenticate for delegation” flag from the principal’s AD object. So, if we narrow the services by using constrained delegation then T2A4D is removed. This is in order to make things more secure.
The general rule, just to drive this home once more, is that if you are constraining your delegation to specific service(s) then your T2A4D will not be set, and you’re tickets will not be forwardable.
Finally, for some interactions it may be necessary to add this back-while still constraining your delegation to only some or one service- in order to get a complex and very custom scenario working. This can be done using AD object editor of choice (LDP.EXE shown above) to add the circled value once you have set what you need for constrained delegation. Uh oh, here comes a big caveat….wait for it…
WARNING: The “trusted to authenticate for delegation” setting is intended to make your environment more secure and altering the setting is generally not recommended.
So we’ve discussed the less-than-intuitive and not-so-well-documented T2A4D flag, what it does and how it works. Hopefully this will help reduce the migraine pain if you’re in a situation where you are dealing with related problems in a complex Kerberos scenario.
In case I don’t post and have a chance to say it later, have a Happy Holiday’s everyone!