First published on CloudBlogs on Jan, 21 2008
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 with Kerberos authentication is you can some it up with that one word: impersonation.
Impersonation, or delegation as it is also called, allows a trusted identity act on behalf of another identity to do an action or actions. The trusted identity is often an account in Active Directory which is being used as a service while the trusting identity is usually a regular user. Along with this higher level of trust we are placing in a service account we have to take extra care that nothing happens to purposefully or inadvertently betray the extra trust.
This is where PAC validation comes in. For those that didn’t recall offhand the PAC stands for Privilege Attribute Certificate. The PAC is a chuck of data which hold information about the user in the Microsoft Kerberos implementation. A critical portion of that information it holds is a list of the security group memberships the user is a member of. PAC validation is an additional check done on the PAC to make user it hasn’t been altered.
What does PAC validation actually do? PAC validation occurs as the PAC is verified to make sure it hasn’t been altered. It does this by sending traffic to the Global Catalog (GC) of the forest the user account is in and is essentially a request to see if the PAC matches what the domain would issue for that user. You can see this traffic on the wire (in a network trace)-it will appear with the typical Kerberos filter in most network trace utilities and uses RPC as the application layer protocol for this task.
If the PAC validation fails then the PAC cannot be used and hence the user authenticated session will no longer be authenticated. In an application a user who was previously authenticated, authorized and working would suddenly fail with access denied (error 5). Not an exciting situation for you if you’re the admin the help desk calls are sent to for resolution where every caller is basically asking “Dude, where’s my PAC?” whether they know it or not since it is stripped off when it cannot be verified.
A few important caveats to keep in mind for this scenario.
First, the PAC validation occurs in the system context of the computer which the user is being impersonated on-regardless of what context you have delegated the user to. In other words the account you have trusted for delegation is not the identity who is sending the PAC validation. The local system does the validation, and for that reason if the user is from another forest there must be a trust between the two domains involved. Remember that the PAC validation sends the PAC to a GC for verification? Well, this send will fail from an untrusted computer. So, there must be a trust.
Within a forest this is not a concern since there is an implicit trust that takes care of things like this. Nice product, that Active Directory!
So, what if you are in a situation where you cannot set up a two way trust for business reasons and you have two separate forests?
One option would be to give the service account which the application pool is running under
SeTcbPrivilege
, otherwise known as Act As Part of the Operating System. You can do this by adding that account to the user rights of the web server in SecPol.msc. You could alternatively use NTRights.exe to add it which could work around the reboot requirement by adding it in SecPol.msc but keep in mind that doing it the
NTRights.exe
way will not persist after a reboot. This option works around the PAC validation by basically elevating the service account to a much more privileged level of access on the computer so keep that in mind. For security reasons this is typically not recommended but every persons situation is unique.
Here’s the Knowledge Base article on how to use
NTRights.exe
:
How to Set Logon User Rights with the Ntrights.exe Utility
http://support.microsoft.com/kb/279664
Another option is to disable PAC validation from taking place by disabling it on the server altogether.
To do this, add the ValidateKdcPacSignature registry entry to the following registry subkey:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters
Add the
ValidateKdcPacSignature
entry as an entry of type DWORD on the servers that are authenticating users in application services. These servers may include domain controllers.
When the value of this entry is 0, Kerberos does not perform PAC validation on a pr
ocess that runs as a service. When the value of this entry is 1, Kerberos performs PAC validation as usual. You do not have to restart the computer after you modify this registry entry. When this entry is not present, the system behaves as if the entry were present and has a value of 1. The default value in Windows Server 2008 for this entry is 0.
The
.. LsaKerberosParameters…
registry value addition requires a reboot so if you’re in a tight spot and need immediate relief (sounds like I’m working up to a commercial here doesn’t it?) use the
NTRights.exe
method I mentioned above to get things working well immediately.
Have a great week out there folks!
