Compartilhar via

More Kerberos in SharePoint: The lifetime of a Kerberos ticket

  • Artigo

I had a great follow-up question from my last post on Kerberos in SharePoint:

"We are using Kerberos for our MOSS based server and there is one page which renders a list based on the current user's membership groups. The issue is that once the user is removed from the group, he should not see the list contents. However if the Kerberos token is obtained prior to the removal from the group, the user continues to see the list until the ticket expires. In other words, the ticket has to be purged in order to get the latest changes from AD."

The old adage that for every "yin" there is a "yang" holds true here. The reason why Kerberos performs so much better than NTLM over long-running conversations between a client and server is that NTLM requires the server to ask a DC to validate the client's response to a challenge every time authentication is required, whereas with Kerberos the server never has to contact a DC to validate a client's ticket, which once obtained by a client is valid by default for 10 hours. (This number was chosen as it is slightly longer than a typical working day).

The trade-off here is that a ticket can't be invalidated by the KDC. Once a client has one, it's good until it's expiry date or until the logon session is terminated (i.e. the client logs off) at which point the ticket cache is cleared. Since group membership information is embedded in a ticket, this means you can't use group membership to quickly grant or deny client access to a resource. With NTLM, group membership information is returned every time the server authenticates the client (although even with NTLM you can run into group membership caching problems if tokens are cached by the server).

Software solutions sometimes work round this by allowing you to deny access based on a client identity - however this isn't always particularly manageable and isn't an option in SharePoint.

A more extreme option is to configure the lifetime of a ticket. In Windows this is a policy applied to the whole Kerberos realm (Domain) via group policy. I recommend taking great care changing this setting as it may affect adversely performance in your domain - but it is an option. The specifc location and settings in the GPO are described here.

In general, I rarely come across situations where it is actually a business necessity to immediately deny a client access to a resource. Since Kerberos is an intranet protocol if you have a situation where a security concern arises with a user then you can do a number of things - remote log-off or shut-down their machine, or send a heavies from security round to see them for example!

If you absolutely need to do this in SharePoint, then granting and removing access to SharePoint based on SharePoint group membership (rather than Windows group membership) is probably your best bet.

If you want to know more about Kerberos I suggest starting with Keith Brown's guide items 59-62 and if that doesn't satiate you then move on to this monster:

https://technet2.microsoft.com/windowsserver/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx?mfr=true

Good luck!

James.

Comments