Session tickets are encrypted with the secret key for the account under which the service starts. When a service acquires a handle to its own credentials on the system, it gains access to that key. A rogue service could be installed by an unscrupulous user with a legitimate network account but limited authorization on the local computer. The user could request a session ticket for the service, and then the service could decrypt the ticket, modify the authorization data by adding the SID for a privileged group, encrypt the altered ticket, and present it to the LSA in a call to AcceptSecurityContext. The result would be to elevate the user’s level of authorization on the computer where the service is running.
To prevent tampering with authorization data, it is signed by the KDC before it is stored in a session ticket. Any attempt to alter the data will invalidate the signature. The LSA on a Windows Server 2003 computer always checks the validity of this signature when session tickets are presented by untrusted services.
The LSA can trust calls to AcceptSecurityContext from services running under the Local System account. This account is used by services installed with the operating system — by the native Server service, for example. Other services can be configured to use the Local System account, but this must be done by a member of the Administrators group. It is assumed that the administrator who installs the service can vouch for its security.
The LSA does not trust services running under any other account. If a session ticket is presented by an application that is not running as Local System, the LSA asks the KDC in its domain to verify the signature on the ticket’s authorization data. The question is asked and answered by a Remote Procedure Call (RPC) over the Net Logon secure channel to the domain controller. Requests for verification do not need to travel beyond the local domain because session tickets are always issued — and therefore authorization data is always signed — by the KDC for the target computer’s domain.
Implementation
When a user with an account in a Windows Server 2003 domain logs on at the keyboard of a computer running Windows Server 2003, the user’s logon request is processed in three stages:
1. The user asks for admission to the Ticket Granting Service for the domain.
This is accomplished by an AS Exchange between the Kerberos SSP on the computer and the KDC for the user’s account domain. The result of a successful exchange is a TGT that the user can present in future transactions with the KDC.
2. The user asks for a ticket for the computer.
This is accomplished by a TGS Exchange between the Kerberos SSP on the computer and the KDC for the computer’s account domain. The result is a session ticket that the user can present when requesting access to system services on the computer.
3. The user asks for admission to Local System services on the computer.
This is accomplished when the Kerberos SSP on the computer presents a session ticket to the LSA on the computer.
If the computer’s domain is different from the user’s domain, an extra step is involved.
Before requesting a session ticket for the computer, the Kerberos SSP must first ask the KDC in the user’s account domain for a TGT good for admission to the KDC in the computer’s account domain. It can then present the TGT to that KDC and get a session ticket for the computer.
Exactly how the logon process works will depend on how the computer is configured.
With standard configurations of Windows Server 2003, interactive users log on with a password. The operating system also includes the option to log on with a smart card. The basic process is the same for both configurations. Their differences will be examined after first stepping through the process for a standard logon with a password.
For example, suppose Alice has a network account in the domain example.com. The computer she normally uses, Machine01, also has an account in example.com. When Alice logs on to the network, she begins by pressing the key combination
CTRL+ALT+DEL, the Secure Attention Sequence (SAS) on computers with a standard Windows configuration.
In response to the SAS, the computer’s Winlogon service switches to the logon desktop and dispatches to the Graphical Identification and Authentication (GINA) dynamic-link library, a component loaded in Winlogon’s process. The GINA is responsible for collecting logon data from the user, packaging it in a data structure, and sending everything to the LSA for verification. Third parties can develop replacement GINAs, but in this case Winlogon has loaded the standard component supplied with the operating system, msgina.dll. Winlogon dispatches to it, and it displays the standard Logon Information Dialog.
Alice types her user name and password. From the domains in a drop-down list, she selects example.com. When she clicks OK to dismiss the dialog box, msgina.dll returns her logon information to Winlogon. It sends the information to the LSA for validation by calling LsaLogonUser.
On receiving a data structure with Alice’s logon data, the LSA immediately converts her cleartext password to a secret key by passing it through a one-way hashing function. It saves the result in the credentials cache, where it can be retrieved when needed for TGT renewal or for NTLM authentication to servers that are not capable of Kerberos
authentication.
To validate Alice’s logon information and set up her logon session on the computer, the LSA must obtain:
● A TGT good for admission to the Ticket Granting Service
● A session ticket good for admission to the computer
The LSA gets these tickets by working through the Kerberos SSP, which exchanges messages directly with the KDC in example.com, as shown in Figure 2.3.
LSA
Interactive Logon to a domain account
The messages follow this sequence:
1. The LSA sends the message KRB_AS_REQ to the KDC in example.com.
The message includes:
● The user principal name: Alice
● The name of the account domain: example.com
● Preauthentication data encrypted with the secret key derived from Alice’s password
2. If the client’s preauthentication data is correct, the KDC replies with KRB_AS_REP.
The message includes:
● A session key for Alice to share with the KDC, encrypted with the secret key derived from Alice’s password
● A TGT for the KDC in example.com, encrypted with the KDC’s secret key
The TGT includes:
● A session key for the KDC to share with Alice
● Authorization data for Alice
The authorization data includes:
● The SID for Alice’s account
● SIDs for security groups in the domain example.com that include Alice
● SIDs for universal groups in the enterprise that include either Alice or one of her domain groups
3. The LSA sends the message KRB_TGS_REQ to the KDC in example.com.
The message includes:
● The name of the target computer: Machine01
● The name of the target computer’s domain: example.com
● Alice’s TGT
● An authenticator encrypted with the session key Alice shares with the KDC
4. The KDC replies with KRB_TGS_REP.
The message includes:
● A session key for Alice to share with Machine01, encrypted with the session key Alice shares with the KDC
● Alice’s session ticket to Machine01, encrypted with the secret key Machine01 shares with the KDC
The session ticket includes:
● A session key for Machine01 to share with Alice
● Authorization data copied from Alice’s TGT
Having received Alice’s session ticket, the LSA decrypts it with the computer’s secret key and extracts her authorization data. It then queries the local SAM database to discover whether Alice is a member of any security groups local to the computer and whether she has been given any special privileges on the local computer. It adds any SIDs returned by this query to the list taken from the ticket’s authorization data. The entire list is then used to build an access token, and a handle to the token is returned to Winlogon, along with an identifier for Alice’s logon session and confirmation that her logon information was valid.
Winlogon creates a window station and several desktop objects for Alice, attaches her access token, and starts the shell process she will use to interact with the computer.
Alice’s access token is subsequently inherited by any application process that she starts during her logon session. This allows Alice to securely use Active Directory services on various Windows Server 2003 servers without having to reauthenticate.
Summary
In this chapter, the concepts of authentication and Kerberos have been expanded to build upon the initial foundations that were laid out in Chapter 1, "Network Security and
Directory Services." The Kerberos 5 protocol is in common use across all platforms and provides a secure, encrypted authentication and authorization solution.
The security services that are currently available on UNIX and Linux have been summarized. These summaries have included the features available from each of the operating systems, along with each of their strengths and weaknesses.
With the advent of Windows 2000, Microsoft implemented the Kerberos 5 standard as a part of Active Directory. Windows Server 2003 has built upon the standards based implementation of Kerberos found in Windows 2000.
Active Directory is fully Kerberos 5-compliant, and the concepts presented in this chapter will be expanded upon in later chapters. These chapters will also show how the
technologies present in Windows Server 2003 Active Directory can be used to create a heterogeneous security solution.