I did not expect to receive so much feedback by mail regarding this (not so fascinating) topic. Not to mention referring sites and so on… This brought the motivation to loop the loop by testing on Windows Server 2008 (SP2) as well as on 2008 R2 in-depth in order to cover the whole stuff.
So in summary, when will PAC signature verification will finally occur?
The table hereunder summarizes possible scenario’s:
Server OS/
Target Application or Service | Server 2003 pre SP2 | Server 2003 SP2 and above
with extra registry configuration | Server 2008,
Server 2008 R2 |
| File & Print Sharing | NO Validation | NO Validation | NO Validation |
| Exchange Server | Validation | NO Validation | NO Validation |
| SQL Server | Validation | NO Validation | NO Validation |
| IIS with application pool identity set to Local System or Network Service | Validation | NO Validation | NO Validation |
| IIS with application pool identity set to a domain account | Validation | Validation | Validation |
So in short, the only difference between Server 2003 and 2008/2008 R2 is that with from 2008, you do not need to modify registry anymore since the default value is inverted.
Once again, the important point here is: if you configure Kerberos on a IIS farm (SharePoint or “simple” ASP.Net), PAC Validation will ALWAYS occur, regardless what you will do to prevent it UNLESS the application is granted and makes use of the right “Act as part of the operating system”.
If the target application is granted seTCB making use of it:
Granting the seTCB privilege is not sufficient because it will be disabled by default until the application effectively requests it. But why would it need it? For various reasons this privilege might be needed by the server application. 2 common usages are described in the sections below.
Protocol transition
Protocol transition is the ability for a server application to delegate user credentials to a back-end service using Kerberos while they were not initially provided under that form by the client.
In clear, this means that a user may be authenticated by a service using non-Kerberos protocols such as Basic, NTLM, Digest and this service, making use of that feature, will transform the credentials in order to propagate them to another server. Example: a user authenticates against SharePoint using NTLM, want to use reporting service while it runs on a 2nd server, the SharePoint server will perform the necessary transition to push (aka “delegate”) the user’s credentials to the SRS server using Kerberos.
IIS MVP Ken Schaefer gives an excellent overview on his blog: IIS and Kerberos Part 5 - Protocol Transition, Constrained Delegation, S4U2S and S4U2P.
Services For User
SU4 extensions are tightly linked to Protocol Transitions. In very very short, they allow, under certain conditions, an application to perform a logon on behalf of a user without knowing his/her password.
This feature is, for example, used in IAM/SSO products such as IBM TAM/WebSEAL or CA SiteMinder
For both technologies, since the user does not initially authenticate using Kerberos, there is no PAC to validate.
OK but finally, why is disabling PAC validation so important?
Well I won’t say it is “so important”. I might help improving performances under some circumstances.
Since, in short, the PAC is verified by the server application before granting a Ticket-Granting-Service (TGS) to the client, it does not occur at every request as long as the TGS remains valid (note: there are some exceptions to this rule). BUT in some case, this initial verification can take some times because 1) the client’s AD is far (in term of network, hops, latency, bandwidth…) from the server’s AD or 2) the client’s AS is too busy. This could therefore give the wrong impression that client to server authentication seem slow while you expect a big boost by switching to Kerberos.
Additional Resources
Marc