Ticket-granting tickets and the logon process, part 1

In this article, Douglas A. Paddock shares what he has learned about ticket-granting tickets (TGTs) and session tickets.


When dazed and confused, I log on to my Windows 2000 system early on a Monday morning -- and usually end up typing the wrong thing. Of course, I get an error message that requires me to re-enter my password. That Monday morning "brain fog" is one reason why administrators typically give users three to five shots at logging on.

My logon mishaps led me to wonder whether Microsoft created the first-time logon error message especially for Monday mornings. My research didn't verify that, but I did run into some fascinating information about Windows 2000 system logons. In this article, I share things I learned about ticket-granting tickets (TGTs) and session tickets.

Our first stop is an interesting statement in Chapter 11 of The Windows 2000 Server Distributed Systems Guide, published by Microsoft. There it is written that most users think that logging on to their Windows 2000 domain account gives them access to the network, and that they are wrong. This surprised me when I first read it because this fact is not usually mentioned in logon process training sessions.

When logging on, you do get permission to request session tickets that will let you access other services on the network. This permission is in the form of a TGT, also known as a user ticket. TGTs let the user communicate with the Key Distribution Center (KDC) that runs on each Win2000 domain controller; they also let the user request session tickets that will allow him to use other services on both the local computer and the network.

You cannot use a domain account to log on to a system running Windows 2000 without a session ticket. This ticket's purpose is to prove that you are who you say you are. In fact, each service you utilize is not going to let you run it until it knows who you are. You are going to need authorization to log on, and you will receive that authorization through the use of both TGTs and session tickets.

Our user -- let's call him Frank -- logs on to the my.local domain interactively from a Win2000 workstation, not using a smart card for logon. Frank starts his logon by initiating the secure attention sequence (SAS) when he presses Ctrl+Alt+Delete. The Winlogon process takes note of the SAS and switches to the logon desktop. (For more information on the various desktops created as part of the start-up process, see the references at the end of this article.) Only the Winlogon process has access to this desktop, and no other process can access the data associated with this desktop. This protects the user's password.

Continuing the process, Winlogon accesses the Graphical Identification and Authentication (GINA) dynamic link library (DLL). GINA's task is to collect information about the user, put it together and pass it to the Local Security Authority (LSA).

At this point, I must add that there are some security issues with GINA. Microsoft's default msgina.dll can be replaced by third-party GINAs, but there are other issues associated with doing this. Check Microsoft's TechNet for further information about GINA's functionality and the process of replacing the default Microsoft GINA. There are also potential security issues related to illicit replacement of the default GINA by unauthorized personnel seeking access to your system. That security issue is beyond the scope of this article, however.

Back to Frank's process: when the LSA receives this information, it converts Frank's password to a secret master key through a one-way hash function. At this point, remember, Frank still doesn't have access to the workstation. The LSA is going to need a TGT, so it can use the ticket-granting service of the KDC, and a session ticket to let Frank use the workstation where he is attempting to log on.

The LSA doesn't directly communicate with the KDC to get these tickets. Instead, it works with the Kerberos Security Support Provider (SSP). Each Windows 2000 system has the Kerberos SSP installed. There are several different packets that get exchanged between the client computer and the KDC to accomplish this.

The KDC has several subordinate protocols that it runs to perform its duties. Frank's computer is going to use one of these -- the Authentication Service -- now. The Kerberos SSP service on Frank's computer sends a KRB_AS_REQ (Kerberos Authentication Service Request) to the KDC. This packet contains Frank's user principal name (UPN), the domain name, and preauthentication data encrypted with the secret key from Frank's password. The preauthentication data will be used by the KDC to prove that Frank's key was used to encrypt the message and thus the message is truly from Frank.

Frank has his foot in the door, but he hasn't passed through all the security checkpoints. In part two, our user takes on KDC's Authentication Service.

About the author: Douglas Paddock, MCSE, MCT, MCSA, is a CIW security analyst and CIW certified instructor. He is also A+ and N+ certified. He teaches at Louisville Technical Institute in Louisville, Ky.


This was first published in January 2003

Dig deeper on Windows Operating System Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close