First published on CloudBlogs on Nov, 13 2006
A few times of the past we’ve received calls from customers where they had some really interesting concerns with using smartcards for domain authentication.
There’s some base knowledge to be had with respect to Kerberos. Just a quick mention-yes, when you talk about Microsoft Windows and the Kerberos authentication protocol, we are compliant. Wikipedia has a good reference (you know, if you want an overview plus links to the RFCs) here:
http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
Keep in mind that the RFCs are not light reading, and may not be wholly useful when gauging that usefulness against what a network or domain administrator needs for his or her day to day job.
An important thing to keep in mind is this sentence; taken directly from the RFC 4120. “Kerberos provides a means of verifying the identities of principals, (e.g., a workstation user or a network server) on an open (unprotected) network”. Why would that sentence be important to mention? Because how you identify that principal and where you store that identifier is vitally important.
In a normal Windows logon situation, the user logs onto a domain client by providing a username (giving their uniqueness as a principal), the domain (read realm) that principal resides in, and their password. This information is used to request a TGT, and whatever service tickets that principal needs to get access to requested resources. This information (username, password, TGT, TGSs) are locally cached and provided as needed “behind the scenes” in Windows.
With smartcard logon there is a slightly different, and more secure, way of doing things. This can lead to unexpected things at times.
One of the behaviors that makes Kerberos authentication secure in that way we love so much is the (configurable) renewal and renewal lifetime for the ticket granting ticket. Our customers who have begun a transition to a smartcard logon only environment have noticed the following scenario.
The user logs on to the computer using his or her smartcard. Once logged on and the user environment created, the user starts some long-running task (like a SQL query) that takes a very long time. Then the user’s day is over and he or she goes home to do whatever it is real people do when they are not using Microsoft products. I won’t speculate about what that may be, I can’t conceive of it. Let’s forge ahead.
When they come back into the office the next morning they discover that the job they had running has failed with an error 5 (access denied). Why would that be? The credentials were correct at logon or it wouldn’t have ever successfully started, not to mention the fact that the access denied would have been thrown in the user’s face at the beginning of the job, not at some indeterminate time later. What gives?
In the above situation the situation was a result of the ticket renewal process whereby the TGT is renewed at default 10 hour intervals. Picture the user logging on, working their typical eight hour or whatever day and running this job which takes, say, 12 hours to complete. Sometime in this 12 hour interval, after logging on and after starting the job, the TGT needed to be renewed (seen as the End Time in kerbtray and other tools). In Windows 2000 and XP, this renewal required the smartcard to be present in order for it to succeed. Since the user requires the smartcard for everything at the office, perhaps even opening doors, they naturally took it with them with they left, so the smartcard was not present at renewal time. Result: failed TGT renewal, and since the TGT was not renewed service tickets-like those being used for that long-running job-would be expired as well. For those out there who are wondering, you should not see this with Windows 2003 SP1 or Windows Vista. I’ll add a little caveat there since some of this could be altered by the CSP being used or the application which that job is and how it utilizes the SSPI. Use your tools (system information file or debugger to ascertain CSP, kerbtray et cetera) to find out more if you see other results.
Another scenario was one protocol transition and the smartcard required to logon mask in useraccountcontrol. More and more folks out there are setting some or all of their users to require the smartcard be used for user logon to the domain. In some authentication interactions you can see some unexpected behavior. Take an example of a server application which utilizes protocol transition. In this scenario, a user logs on a server via an authentication method other than Kerberos (say, a secure web page). This is then transitioned to Kerberos (since the server itself is trusted for this delegation) so that the credentials can then be used for accessing other resources on that server and perhaps gain access to resources on other servers for this user using Kerberos authentication (picture this data or resources being provided to the user at that web page they logged onto). For those who are interested in this, you would expect to see an AS_REQ/AS_REP and TGS_REQ/TGS_REP on the wire from that server to a KDC as this part happens. Getting back to this scenario though, what may be seen is that the ticket is never requested as expected but only for users who have smartcard required for logon, and hence they fail to access the resources they need. In a similar vein to the first scenario we mentioned, this is a result of the smartcard not being present. Well, worry not avid reader. This obstacle is also alleviated in Windows 2003 SP1, in other words you should not reach a protocol transition barrier (of otheràKerberos) with smartcard required users any longer.
As a final comment, I asked the Magic Eight-Ball whether this blog post would be really good prior to writing it. The answer: “Forget about it”.
You be the judge (please be kind).
