Authentication

 

The default protocol for network authentication in Microsoft® Windows® 2000 is the Kerberos v5 authentication protocol. An emerging authentication standard, the Kerberos protocol provides a foundation for interoperability. It also enhances the security of enterprise-wide network authentication. Key components of the protocol's implementation in Windows 2000 include the integration of initial authentication with the Winlogon single sign-on architecture, the use of Active Directory ™ (the directory service included in Windows 2000) as the domain's security account database, and the implementation of the Kerberos client as a Windows 2000 security provider through the Security Support Provider Interface (SSPI).

In This Chapter

Basic Concepts of Authentication

Authentication Protocols

How Kerberos Authentication Works

Kerberos Components in Windows 2000

Authorization Data

Logging on Interactively

Related Information in the Resource Kit

• For more information about how network clients find a domain controller, see "Name Resolution in Active Directory" in this book.

• For more information about authorization, see "Access Control" in this book.

Authorization Data

 

The Kerberos protocol is a protocol for authentication, not authorization. It verifies that security principals are who they say they are but does not determine the objects to which they can have access or what type of access they can have. The Kerberos protocol provides a field for authorization data in session tickets, but it does not specify the form of the data or how servers should use it. These decisions are left to whatever access control mechanism is available on the system.

 

 

 

How the KDC Prepares Authorization Data

 

When the Kerberos protocol is used for authentication, the list of SIDs that identify a security principal and the groups to which this principal belongs is transported to the local computer in the authorization data field of a session ticket. Authorization data is gathered in two separate steps — when the KDC in a Windows 2000 domain prepares a TGT and when the KDC prepares a session ticket for a server in the domain.

When a user requests a TGT, the KDC in the user's account domain queries the domain's Active Directory. The user's account record includes an attribute for the user's SID as well an attribute with SIDs for any domain security groups to which the user belongs. The list of SIDs returned by the KDC's query is placed in the TGT's authorization data field. In a multiple-domain environment, the KDC also queries the Global Catalog for universal groups that include the user or one of the user's domain security groups. If it finds any, the SIDs for these groups are added to the list in the TGT's authorization data field.

When the user requests a session ticket for a server, the KDC in the server's domain copies the contents of the TGT's authorization data field to the session ticket's authorization data field. If the server's domain is different from the user's account domain, the KDC queries Active Directory to find out whether any security groups in the local domain include the user or one of the user's security groups. If there are any such groups, their SIDs are added to the list in the session ticket's authorization data field.

 

 

Name-based vs. Identity-based Authorization

 

 

On some operating systems, applications are required to implement their own mechanisms for determining the level of a user's authorization. Applications often do this by maintaining private lists that contain the names of users who are authorized access. Database applications, for example, often maintain private authorization tables to control the fields in a record that a particular user can view or change. This kind of access control mechanism can be integrated with Kerberos authentication simply by ensuring that the authorization data field of a session ticket carries some form of the security principal's name.

Unfortunately, private authorization mechanisms are just that — private. A database application is powerless to prevent an unauthorized user from running another application and using it to edit the data file. On Windows 2000, access to resources is controlled by the operating system itself. Applications can implement their own private authorization mechanisms, but whether they do or not, the Windows 2000 operating system's access control mechanism protects all files and other objects that can be shared by two or more processes.

The header of every securable object includes a security descriptor with an ACL. The ACL is maintained by the object's owner, who decides which security principals can have access to the object and how they can gain access to it. The operating system enforces the owner's decisions by performing an access check whenever an application requests a handle to a protected object. Before the operating system returns the handle, it examines the object's ACL to see whether the security principal that is using the application is authorized access. If the security principal is not authorized access, the application is denied access.

Another important difference from other access control mechanisms is that security principals are not identified by name, either by the operating system or in ACLs. Instead, each security principal is assigned a unique security identifier (SID), an alphanumeric value with a structure similar to a telephone number. Like the country/region code used in international calling, the first part of a SID identifies the domain where the SID was issued. Like the number for a specific telephone within a country or region, the second part of a SID identifies an account within the issuing domain. The value for a domain is unique within an enterprise, and the value for an account is unique within a domain. Unlike telephone numbers, however, SIDs are never reused. There is no possibility that a user might be assigned a SID that once belonged to another user.

A third important difference from name-based access control is that authorization is determined by not only the user's identity but also the user's membership in one or more security groups. In fact, the preferred method of controlling resources is to grant access to groups rather than to individuals, adjusting the level of a group's authorization according to the needs of its members. This method of controlling access makes it easier to keep ACLs up-to-date on networks that have thousands of users and millions of objects. Group membership can be managed centrally by administrators, who can change a particular user's level of authorization for many resources simply by adding or removing the user from a group.

Windows 2000 makes resource security still easier to manage by allowing groups to be nested. A group created in one domain can be added to the membership of a group created in another domain or to the membership of a universal group used throughout a tree of trusted domains. As a result, when employees change jobs, their level of authorization can be changed throughout the enterprise without touching the ACLs on specific objects.

Like individual security principals, Windows 2000 security groups also have SIDs. A user's level of authorization is determined, then, by a list of SIDs — the SID for the user and the SID for each security group to which the user belongs.

For more information how the operating system determines a user's level of authorization, see "Access Control" in this book.

 

 

How Kerberos Authentication Works

 

 

The Kerberos authentication protocol provides a mechanism for mutual authentication between a client and a server before a network connection is opened between them. The protocol assumes that initial transactions between clients and servers take place on an open network — an environment where most clients and many servers are not physically secure and packets traveling along the network can be monitored and modified at will. In other words, the protocol is designed for an environment that is much like today's Internet, where an attacker can easily pose as either a client or a server and can readily eavesdrop on or tamper with communications between legitimate clients and servers.

 

How Services Use Authorization Data

 

In Windows 2000, services act in their own security contexts only when they are trying to gain access to resources on their own behalf. For the most part, this happens only when they are doing their own housekeeping — reading or writing configuration data stored in registry keys, binding to communications ports, and completing other tasks that are not related to work for a particular client. When a service is doing something for a client, it impersonates the client and acts in the client's security context. This means that in addition to verifying the identity of a client, Windows 2000 services also must take on some of their client's characteristics — specifically, the client's level of authorization on the system.

When a service sets up housekeeping on a computer that is running Windows 2000, it calls the SSPI method AcquireCredentialsHandle to gain access to its own credentials (the secret key for the account under which the service runs). The service then binds to a communications port, where it listens for messages from prospective clients.

When a client requests a connection and presents a session ticket, the service asks the Kerberos SSP to verify the client's credentials by calling the SSPI method AcceptSecurityContext and passing as an argument the client's session ticket along with a handle to the service's secret key. The SSP verifies the ticket's authenticity, opens it, and passes the contents of the authorization data field to the LSA. If the data includes a list of SIDs, the LSA uses them to build an access token that represents the user on the local system. In addition, the LSA queries its own database to determine whether the user or one of the user's security groups is a member of a security group created on the local system. If any such groups are found, the LSA adds these SIDs to the access token. The LSA then confirms for the calling service that the client's identity has been authenticated and encloses a reference to the client's access token.

Upon receiving confirmation, the service completes its connection with the client and attaches the client's access token to an impersonation thread by calling ImpersonateSecurityContext. When the impersonation thread requires access to an object, it presents the client's token. The operating system performs an access check by comparing the SIDs in the client's token to the SIDs in the object's ACL. If the operating system finds a match, it checks to see that the entry in the ACL grants the level of access requested by the thread. If the authorized level of access matches the level of access requested, the thread is allowed access to the object. Otherwise, access is denied.

 

 

 

Why Authorization Data Is Signed

 

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 secret key. The difficulty is that an unscrupulous user with a legitimate network account but limited authorization on the local computer could install a rogue service on the computer. This user could request a session ticket for the service, and 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, authorization data is signed by the KDC before it is stored in a session ticket. Any attempt to alter the data invalidates the signature. The LSA on a Windows 2000 computer always checks the signature on authorization data in session tickets that untrusted services present in calls to AcceptSecurityContext. As far as the LSA is concerned, an untrusted service is any service that is not 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. The assumption is that the administrator who installs the service can vouch for its security.

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 an RPC over Net Logon's 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 in the destination computer's domain.

 

 

Kerberos Components in Windows 2000

 

 

Windows 2000 implements the KDC as a domain service. It uses Active Directory as its account database and gets additional information about security principals from the Global Catalog

As in other implementations of the Kerberos protocol, the KDC is a single process that provides two services.

Authentication Service    The authentication service issues TGTs that are good for admission to the ticket-granting service in its domain. Before network clients can get tickets for services, they must obtain a TGT from the authentication service in the user's account domain.

Ticket-Granting Service    The ticket-granting service issues tickets that are good for admission to other services in its own domain or for admission to the ticket-granting service of a trusted domain. When clients want access to a service, they must contact the ticket-granting service in the service's account domain, present a TGT, and ask for a session ticket. If the client does not have a TGT for admission to the ticket-granting service in the other domain, it must obtain one through the referral process that begins at the ticket-granting service in the user's account domain and ends at the ticket-granting service in the service's account domain.

The KDC is located on every domain controller, as is the Active Directory service. Both services are started automatically by the domain controller's Local Security Authority (LSA) and run in the process space of the LSA. Neither service can be stopped. Windows 2000 ensures availability of these services by allowing each domain to have several domain controllers, all peers. Any domain controller can accept authentication requests and ticket-granting requests addressed to the domain's KDC.

The security principal name used by the KDC in all Windows 2000 domains is krbtgt , as specified by RFC 1510. An account for this security principal is created automatically when a new Windows 2000 domain is created. The account cannot be deleted, nor can the account name be changed. A password is assigned to the KDC's account automatically. The password for the KDC's account is used to derive a secret key for encrypting and decrypting the TGTs that the KDC issues. The password for a domain trust account is used to derive a Kerberos inter-realm key for encrypting and decrypting referral tickets.

All instances of the KDC in a domain use the domain account for the security principal krbtgt. Clients address messages to a domain's KDC by including both the service's principal name (krbtgt) and the name of the domain. Both items of information are also used in tickets to identify the issuing authority.

 

 

Delegation of Authentication

 

 

In Windows NT, a service could impersonate its clients only to gain access to resources on the computer where the service process was running. In Windows 2000, a service can impersonate its clients not only when it gains access to resources on the service's computer but also when it gains access to resources on other computers. This is because the Kerberos authentication protocol supports delegation of authentication.

Delegation works only under the following conditions:

• The computers that are hosting the client process, the service process, and processes for any back-end services must all be running Windows 2000 in a Windows 2000 domain.

• The client's user account must be enabled for delegation.

• The service's account must be enabled for delegation.

To configure a user account for delegation, right-click the User object in Active Directory Users and Computers. Then click Propertiesand then the Account tab. In the Account options list, look for the option Account is sensitive and cannot be delegated ; make sure this option is not checked.

How you configure the service account depends on whether the service runs under a computer's Local System account or under its own domain user account. If the service is configured to run under the Local System account, the computer where the service runs must be trusted for delegation. To configure a computer account as trusted for delegation, right-click the Computer object in Active Directory Users and Computers, click Properties and then the General tab. Select the Trust computer for delegation check box.

Caution

When you trust a computer for delegation, you enable delegation for all services that run under the Local System account on the computer. If an unwary administrator installs an untrusted service on the computer and configures it to run as Local System, it too is going to be able to gain access to network resources while impersonating other users. A better practice is to configure services that use delegation to run under their own domain user accounts managed by domain administrators.

If the service is configured to run under its own domain user account, the user account of the service must be enabled to act as a delegate. To configure the user account of a service, right-click the User object, click Properties , and then click the Account tab. In the Account options list, check the option Account is trusted for delegation .

 

 

Finding the KDC

 

When the Kerberos SSP wants to send an initial authentication request to the KDC in a user's account domain, it must locate a domain controller for that domain. It finds the domain controller by using the domain controller locator. For more information about the locator, see "Active Directory Logical Structure" in this book.

The locator can only find KDCs that are in Active Directory–based domains. When computers that are running Windows 2000 participate in other Kerberos realms, the Domain Name System (DNS) names for KDC servers must be stored in the client computer's registry. The Kerberos SSP looks in the registry for the DNS domain name of the user's Kerberos realm and then resolves this name to an Internet Protocol (IP) address by querying a DNS server.

 

 

Kerberos Security Support Provider

 

The Kerberos authentication protocol is implemented as a security support provider (SSP) — a dynamic-link library (DLL) that is supplied with the operating system. Windows 2000 also includes an SSP for NTLM authentication. By default, both the Kerberos protocol and the NTLM protocol are loaded by the LSA on a computer that is running Windows 2000 when the system starts. In Windows 2000 domains, either of these SSPs can be used to authenticate network logons and client/server connections. Which SSP is used depends on the capabilities of the computer on the other side of the connection. The Kerberos SSP is always the first choice.

System services and transport-level applications have access to SSPs through the Microsoft Security Support Provider Interface (SSPI). The SSPI is a Microsoft® Win32® interface with methods for enumerating the SSPs available on a computer, selecting one, and then using it to obtain an authenticated connection. The methods provided in the SSPI are generic, black-box routines that developers can use without knowing the details of a particular protocol. For example, when a client/server connection is authenticated, the application on the client's side of the connection sends credentials to the server using the SSPI method InitializeSecurityContext. If the Kerberos SSP has been selected, InitializeSecurityContext generates a KRB_AP_REQ message from the client. The application on the server's side of the connection responds with the SSPI method AcceptSecurityContext, which generates a KRB_AP_REP message from the server. After the connection has been authenticated, the LSA on the server uses information from the client's session ticket to build an access token. The server then invokes the SSPI method ImpersonateSecurityContext to attach the access token to an impersonation thread for the service.

After the LSA establishes the security context for an interactive user, another instance of the Kerberos SSP might be loaded by a process running in the user's security context to support message signing and sealing.

All distributed services in Windows 2000 domains use the SSPI for authentication. Thus, all domain services support the Kerberos protocol. Services that use the Kerberos protocol for authentication include:

• Print spooler services.

• Common Internet File System/Server Message Block (CIFS/SMB) remote file access.

• Lightweight Directory Access Protocol (LDAP) queries to Active Directory.

• Distributed file system management and referrals.

• Internet Protocol Security (IPSec) host-to-host security authority authentication.

• Reservation requests for network Quality of Service.

• Intranet authentication to Internet Information Services (IIS).

• Remote server or workstation management using authenticated remote procedure call (RPC).

• Certificate requests to the Certificate Services for domain users and computers.

Kerberos Policy

 

Kerberos policy is defined at the domain level and is implemented by the domain's KDC. Kerberos policy is stored in Active Directory as a subset of the attributes of domain security policy. By default, policy options can be set only by members of the Domain Admins group. The policy includes these options:

Enforce user logon restrictions    When this option is enabled, the KDC validates every request for a session ticket by examining user rights policy on the destination computer to verify that the user has the right to either Log on locally or Access this computer from network . Verification is optional because the extra step takes time and might slow network access to services. The default is enabled.

Maximum lifetime for service ticket.    A service ticket is a session ticket. Settings are in minutes. The setting must be greater than ten minutes and less than the setting for Maximum user ticket lifetime . The default is ten hours.

Maximum lifetime for user ticket    A user ticket is a TGT. Settings are in hours. The default setting is ten hours.

Maximum lifetime for user ticket renewal    Settings are in days. The default setting is seven days.

Maximum tolerance for computer clock synchronization    Settings are in minutes. The default is five minutes.

 

 

IP Transport

 

 

According to RFC 1510, when a client contacts the KDC, the client should send a User Datagram Protocol (UDP) datagram to port 88 at the KDC's IP address. The KDC should respond with a reply datagram to the sender's IP address.

UDP is a connectionless transport protocol, which makes it a logical choice when an exchange of messages must precede a connection. UDP is also well suited to applications that send one message and expect one response, such as the exchange between a client and the KDC. However, UDP works best when each datagram is transmitted as a single unit — that is, within a single frame. The Maximum Transmission Unit (MTU) for an Ethernet frame is 1500 octets. If the physical network is Ethernet, Kerberos messages that are sent as UDP datagrams can carry up to 1500 octets of data.

Windows 2000 authorization data can easily total more than 1500 octets. Because this data is needed only by computers that are running Windows 2000, it is omitted from session tickets to computers with other operating systems. As a result, messages to other systems are well within the limits of UDP transport, and that is how they are transmitted. Messages that carry session tickets for computers that are running Windows 2000 are transmitted by using the Transmission Control Protocol (TCP), which has a much greater capacity than UDP. The use of TCP transport in Windows 2000 is consistent with recently proposed revisions to RFC 1510.

 

 

Credentials Cache

 

 

Windows 2000 stores tickets and keys obtained from the KDC in a credentials cache, an area of volatile memory protected by the LSA. Only processes running in the LSA's security context have access to the cache. Its memory is never paged to disk. All objects stored there are destroyed when a security principal logs off or the system is shut down.

The credentials cache is managed by the Kerberos SSP, which runs in the LSA's security context. Whenever tickets and keys must be obtained or renewed, the LSA calls the Kerberos SSP to accomplish the task.

The credentials cache is also used to store a copy of an interactive user's password-derived key. If the user's TGT expires during a logon session, the Kerberos SSP uses its copy of the password-derived key to obtain a new TGT without interrupting the user's logon session. The password-derived key is not stored permanently on the computer, and the local copy in the credentials cache is destroyed when the credentials cache is flushed.

Password-derived keys for services and computers are handled differently. They are stored in a secure area of the computer's registry, just as they were in of Windows NT. Password-derived keys for user accounts on the local system, which are used only for access to computers in stand-alone mode, are also stored in the registry. These keys are never used for network access.

 

 

 

Preauthentication

 

 

By default the KDC requires all accounts to use preauthentication. This makes offline password-guessing attacks very difficult. However, preauthentication can be disabled for individual accounts when this is necessary for compatibility with other implementations of the protocol. To disable preauthentication, right-click the User object in Active Directory Users and Computers. Click Properties , and then click the Account tab. In the Account options list, check Do not require Kerberos preauthentication .

 

 

Account Database

 

 

The account database that provides information about security principals to the KDC is the domain's Active Directory. Each security principal is represented by an account object in Active Directory. The cryptographic key used in communications with a user, a computer, or a service is stored as an attribute of that security principal's account object.

Only domain controllers are Active Directory servers. Each domain controller keeps a writable copy of the directory so that accounts can be created, passwords reset, and group memberships modified at any domain controller. Changes made to one replica of the directory are automatically propagated to all other replicas. Windows 2000 does not, however, implement the Kerberos replication protocol. Instead, it replicates the information store for Active Directory by using a proprietary multimaster replication protocol over a secure channel between replication partners.

Physical storage of account data is managed by the directory system agent (DSA), a protected process that is integrated with the LSA on the domain controller. Clients of the directory service are never given direct access to the data store. Any client that wants access to directory information must use one of the supported Active Directory Service Interfaces (ADSI) to connect to the DSA and then search for, read, and write directory objects and their attributes.

Requests for access to an object or attribute in the directory are subject to validation by Windows 2000 access control mechanisms. Like file and folder objects in the NTFS file system, objects in Active Directory are protected by access control lists (ACLs) that specify who can have access to the object and in what way. Unlike the ACLs on files and folders, however, ACLs on Active Directory objects can allow or deny access not only to the entire object but also to individual attributes of the object. Thus, attributes for sensitive account information can be protected by permissions that are more restrictive than permissions granted for other attributes of an account object.

The most sensitive information about an account is, of course, its password. Although an account object's password attribute stores an encryption key that is derived from the password, not the password itself, this key is just as useful as the password to a would-be intruder. Therefore, access to an account object's password attribute is granted only to the account holder, never to anyone else, not even to administrators. Only processes with Trusted Computer Base privilege — processes running in the security context of the LSA — are allowed to read or change password information.

To hinder an offline attack by someone with access to a domain controller's backup tape, an account object's password attribute is further protected by using a system key to encrypt its value. This key can be stored on removable media so that it can be safeguarded separately, or it can be stored on the domain controller and protected by a dispersal mechanism. Administrators can choose where the system key is stored and which of several algorithms is used to encrypt password attributes. For more information about using system key protection, see " Encrypting File System" in this book.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Basic Concepts for the Kerberos Protocol

 

 

The Kerberos protocol relies heavily on an authentication technique that makes use of shared secrets. The basic concept is quite simple: If a secret is known by only two people, either person can verify the identity of the other by confirming that the other person knows the secret.

For example, let's suppose that Alice often sends messages to Bob and that Bob needs to be sure that a message from Alice really has come from Alice before he acts on its information. They decide to solve their problem by selecting a password, and they agree not to share this secret with anyone else. If Alice's messages can somehow demonstrate that the sender knows the password, Bob knows that the sender is Alice.

The only question for Alice and Bob to resolve is how Alice can show that she knows the password. She might simply include it somewhere in her messages, perhaps in a signature block at the end — Alice, Our$ecret . This would be simple and efficient and might even work if Alice and Bob can be sure that no one else is reading their mail. Unfortunately, that is not the case. Their messages pass over a network used by people like Carol, who has a network analyzer and a hobby of scanning traffic in hope that one day she might spot a password. So it is out of the question for Alice to prove that she knows the secret simply by saying it. To keep the password secret, she must show that she knows it without revealing it.

The Kerberos protocol solves this problem with secret key cryptography . Rather than sharing a password, communication partners share a cryptographic key. They use knowledge of this key to verify one another's identity. For this method of authentication to work, the shared key must be symmetric — a single key must be capable of both encryption and decryption. One party proves knowledge of the key by encrypting a piece of information, the other by decrypting it.

Authenticators

A simple protocol that uses secret key authentication begins when someone is outside a communications door and wants to go in. To gain entry, this person presents an authenticator in the form of a piece of information encrypted in the secret key. The information in the authenticator must be different each time the protocol is executed, otherwise an old authenticator could be reused by anyone who happens to overhear the communication. Upon receiving an authenticator, the person guarding the door decrypts it and knows from what is inside it whether the decryption was successful. If it was successful, the doorkeeper knows that the person presenting the authenticator has the correct key. Only two people have the key; the doorkeeper is one of them, so the person who presented the authenticator must be the other one.

If the person outside the door wants mutual authentication, the same protocol can be executed in reverse, with a slight difference. The doorkeeper can extract part of the information from the original authenticator, encrypt it in a new authenticator, and then give the new authenticator to the person waiting outside the door. The person outside the door can then decrypt the doorkeeper's authenticator and compare the result with the original. If there is a match, the person outside the door knows that the doorkeeper was able to decrypt the original, so he must have the correct key.

It might help to walk through an example. Suppose Alice and Bob decide that before transferring any information between their computers, each will use knowledge of a shared secret key to verify the identity of the party at the other end of the connection. In situations where Alice is the wary guest and Bob is the suspicious host, they agree to follow this protocol:

1. Alice sends Bob a message containing her name in plaintext and an authenticator encrypted in the secret key she shares with Bob. In this protocol, the authenticator is a data structure with two fields. One field contains information about Alice. For simplicity, let's say this is her name. The second field contains the current time on Alice's workstation.

2. Bob receives the message, sees that it is from someone claiming to be Alice, and uses the key he shares with Alice to decrypt the authenticator. He extracts the field that contains the time on Alice's workstation and evaluates the time.
   Bob's task is easier if his clock is reasonably synchronized with Alice's clock, so let's suppose both Alice and Bob use a network time service to keep their clock times fairly close. Let's say the time skew is never more than five minutes. This way, Bob can compare the time from the authenticator with the current time on his clock. If the difference is greater than five minutes, he can automatically reject the authenticator.
   If the time is within the allowable skew, it's probable that the authenticator came from Alice, but Bob still does not have proof that it actually came from her. Another person might have been watching network traffic and might now be replaying an earlier attempt by Alice to establish a connection with Bob. However, if Bob has recorded the times of the authenticators that were received from Alice during the past five minutes, he can defeat attempts to replay earlier messages by rejecting any message with a time that is the same as or earlier than the time of the last authenticator. If this authenticator yields a time later than the time of the last authenticator from Alice, then this message must be from Alice.

3. Bob uses the key he shares with Alice to encrypt the time shown on Alice's message and sends the result back to her.
   Note that Bob does not send back all of the information taken from Alice's authenticator, just the time. If he sent back everything, Alice would have no way of knowing whether someone posing as Bob had simply copied the authenticator from her original message and sent it back to her unchanged. He sends just a piece of the information in order to demonstrate that he was able to decrypt the authenticator and manipulate the information inside. He chooses the time because that is the one piece of information that is sure to be unique in Alice's message to him.

4. Alice receives Bob's reply, decrypts it, and compares the result with the time in her original authenticator. If the times match, she can be confident that her authenticator reached someone who knows the secret key needed to decrypt it and extract the time. She shares that key only with Bob, so it must be Bob who received her message and replied.

This process is illustrated in Figure 11.1.

Figure 11.1 A Simple Protocol for Mutual Authentication

Key Distribution

One problem with the simple protocol described in the preceding section is that it does not explain how or where Alice and Bob get a secret key to use in their communications with each other. If they are people, Alice and Bob can meet, perhaps in an alley, and agree on a secret key. But if Alice is a client program that is running on a workstation and Bob is a service that is running on a computer somewhere across the network, that method does not work. There is the further problem that the client, Alice, might want to talk to many services and will need keys for each of them. Likewise, the service, Bob, might talk to many clients and will need keys for each of them. If each client needs a key for every service and each service needs a key for every client, key distribution can quickly become a difficult problem to solve. The need to store and protect so many keys on so many computers presents an enormous security risk.

The name Kerberos suggests how the protocol resolves the problem of key distribution. Kerberos (also known as Cerberus) was a figure in classical Greek mythology, a three-headed dog who kept living intruders from entering the underworld. Like the mythical guard dog, the protocol has three heads, which in this case are a client, a server, and a trusted third party that mediates between the client and server. The trusted intermediary in the protocol is known as the Key Distribution Center (KDC).

The KDC is a service that runs on a physically secure server. It maintains a database with account information for all security principals in its realm — the protocol's equivalent of a Windows 2000 domain. Along with other information about each security principal, the KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long-term key . In most implementations of the protocol, the long-term key is derived from a user's logon password.

When a client wants to talk to a server, the client sends a request to the KDC, and the KDC distributes a unique session key for the two parties to use when they authenticate each other, as illustrated in Figure 11.2. The server's copy of the session key is encrypted in the server's long-term key. The client's copy of the session key is encrypted in the client's long-term key.

Figure 11.2 Key Distribution (in Theory)

In theory, the KDC can fulfill its role as a trusted intermediary by sending the session key directly to each of the security principals involved, as illustrated in Figure 11.2. But, in practice, that procedure would be extremely difficult to implement. For one thing, it would mean that the server would have to retain its copy of the session key in memory while it waited for the client to call. Moreover, the server would need to remember a key not just for this client but for every client who might ask for service. Key management would consume considerable resources on the server and would thus limit its scalability. In addition, given the vagaries of network traffic, a client's request for service might reach the server before the KDC's message arrived there with the session key. The server would have to suspend its reply to the client while it waited to hear from the KDC. This would require the server to save state, imposing still another burden on the server's resources. What actually happens in the Kerberos protocol is considerably more efficient.

Session Tickets

The KDC responds to the client's request to talk to a server by sending both copies of the session key to the client, as shown in Figure 11.3. The client's copy of the session key is encrypted with the key that the KDC shares with the client. The server's copy of the session key is embedded, along with authorization data for the client, in a data structure called a session ticket . The entire structure is then encrypted with the key that the KDC shares with the server. The session ticket — with the server's copy of the session key safely inside — becomes the client's responsibility to manage until it contacts the server.

Figure 11.3 Key Distribution (in Practice)

Note that the KDC is simply providing a ticket-granting service. It does not keep track of its messages to make sure they reach the intended address. No harm is done if the KDC's messages fall into the wrong hands. Only someone who knows the client's secret key can decrypt the client's copy of the session key. Only someone who knows the server's secret key can read what is inside the ticket.

When the client receives the KDC's reply, it extracts the ticket and the client's copy of the session key, putting both aside in a secure cache, which is located in volatile memory, not on disk. When the client wants admission to the server, it sends the server a message that consists of the session ticket, which is still encrypted with the server's secret key, and an authenticator, which is encrypted with the session key, as illustrated in Figure 11.4. The session ticket and authenticator together are the client's credentials to the server.

Figure 11.4 Mutual Authentication (Client/Server)

When the server receives credentials from a client, it decrypts the session ticket with its secret key, extracts the session key, and uses the session key to decrypt the client's authenticator. If everything checks out, the server knows that the client's credentials were issued by a trusted authority, the KDC. If the client has asked for mutual authentication, the server responds by using the session key to encrypt the timestamp from the client's authenticator. The server then returns the encrypted timestamp to the client, just as Bob returned the encrypted timestamp to Alice in the communication illustrated in Figure 11.1.

One benefit of using session tickets is that the server does not have to store the session key that it uses with this client. It is the client's responsibility to hold a session ticket for the server in its credentials cache and present the ticket each time it wants access to the server. Whenever the server receives a session ticket from a client, it can use its secret key to decrypt the ticket and extract the session key. When the server no longer needs the session key, it can discard it.

Another benefit of using session tickets is that the client does not have to go back to the KDC each time it wants access to a particular server. Session tickets can be reused. As a precaution against the possibility that someone might steal a copy of a ticket, session tickets have an expiration time that is specified by the KDC in the ticket's data structure. How long a session ticket is valid depends on the Kerberos policy for the domain. Tickets usually are good for no longer than eight hours, about the length of a normal logon session. When the user logs off, the credentials cache is flushed and all session tickets — as well as all session keys — are destroyed.

Ticket-Granting Tickets

A user's long-term key is derived from a password. When Alice logs on, for example, the Kerberos client on her workstation accepts her password and then converts it to a cryptographic key by passing the text of the password through a one-way hashing function.

The KDC gets its copy of Alice's long-term key from her record in its account database. When it receives a request from the Kerberos client on Alice's workstation, the KDC searches its database for Alice, pulls up her account record, and takes her long-term key from a field in the record.

This process of computing one copy of the key from a password and fetching another copy of the key from a database actually takes place only once, when a user initially logs on to the network. Immediately after accepting the user's password and deriving the user's long-term key, the Kerberos client on the user's workstation asks the KDC for a session ticket and session key that it can use in subsequent transactions with the KDC during this logon session.

The KDC responds to the client's request by returning a session ticket for itself. This special session ticket is called a ticket-granting ticket (TGT) . Like an ordinary session ticket, a TGT contains a copy of the session key that the service (in this case the KDC) uses in communicating with the client. The message that returns the TGT to the client also includes a copy of the session key that the client can use in communicating with the KDC. The TGT is encrypted in the KDC's long-term key. The client's copy of the session key is encrypted in the user's long-term key.

When the client receives the KDC's reply to its initial request, it uses its cached copy of the user's long-term key to decrypt its copy of the session key. It can then discard the long-term key derived from the user's password, for it is no longer needed. In all subsequent exchanges with the KDC, the client uses the session key. Like any other session key, this key is temporary, valid only until the TGT expires or the user logs off. For that reason, it is called a logon session key .

From the client's point of view, a TGT is just another ticket. Before it attempts to connect to a service, the client first checks its credentials cache for a session ticket to that service. If it does not have one, it checks the cache again for a TGT. If it finds a TGT, the client fetches the corresponding logon session key from the cache, uses this key to prepare an authenticator, and sends both the authenticator and the TGT to the KDC, along with a request for a session ticket for the service. In other words, gaining admission to the KDC is no different from gaining admission to any other service in the domain — it requires a session key, an authenticator, and a ticket (in this case, a TGT).

From the KDC's point of view, TGTs allow it to shave a few nanoseconds off the turnaround time for ticket requests. The KDC looks up the user's long-term key only once, when it grants an initial TGT. For all other exchanges with this client, the KDC can decrypt the TGT with its own long-term key, extract the logon session key, and use that to validate the client's authenticator.

Authentication Across Domain Boundaries

The functions of the KDC are divided into two distinct services: an authentication service, whose job is to issue TGTs, and a ticket-granting service, whose job is to issue session tickets. This division of labor allows the Kerberos protocol to operate across domain boundaries. A client can get a TGT from the authentication service of one domain and use it to get session tickets from the ticket-granting service of another domain.

The easiest way to grasp how cross-domain authentication works is to consider the simplest case — a network that has only two domains. For our example, let's say one domain is East and the other domain is West. If the administrators for these domains are members of the same organization (or if for some other reason they are willing to treat each other's domain users as their own), they can enable authentication across domain boundaries by sharing interdomain keys. (In Windows 2000 this happens automatically when two domains establish a trust relationship.) After this is accomplished, the ticket-granting service in each domain is registered as a security principal with the other domain's KDC. This means the ticket-granting service in each domain can treat the ticket-granting service in the other domain as just another service, something for which properly authenticated clients can request and receive session tickets.

When a user with an account in East wants access to a server with an account in West, the Kerberos client on the user's workstation sends a request for a session ticket to the ticket-granting service in the user's account domain, East. The ticket-granting service in East sees that the desired server is not a security principal in its own domain, so it replies by sending the client a referral ticket . This is simply a TGT that is encrypted with the interdomain key shared by the KDC in East and the KDC in West. The client uses the referral ticket to prepare a second request for a session ticket, and this time sends the request to the ticket-granting service in the server's account domain, West. The ticket-granting service in West uses its copy of the interdomain key to decrypt the referral ticket. If decryption is successful, it sends the client a session ticket to the desired server in its domain.

The referral process is more complicated on networks with more than two domains. In theory, the KDC in each domain could establish a direct link to the KDC in every other domain on the network, in each case sharing a different inter-domain key. In practice, the number and complexity of these relationships can easily become unmanageable, especially on a large network. The Kerberos protocol solves the problem by making direct links unnecessary. A client in one domain can get a ticket to a server in another domain by traveling a referral path through one or more intermediate domains.

For example, consider a network with three domains, East, West, and CorpHQ. The KDC in East does not share an inter-domain key with the KDC in West, but both East and West do share inter-domain keys with CorpHQ. In this case, when a user with an account in East wants access to a server with an account in West, the referral path begins at the KDC for the user's account domain, East, passes through an intermediate domain, CorpHQ, and ends at the KDC for the server's account domain, West. The client must send its request for a session ticket three times, to three different KDCs.

1. The client asks the KDC for East to give it a ticket to the server in West.
   The KDC for East sends the client a referral ticket to the KDC for CorpHQ. This ticket is encrypted in the interdomain key East shares with CorpHQ.

2. The client asks the KDC for CorpHQ to give it a ticket to the server in West.
   The KDC for CorpHQ sends the client a referral ticket to the KDC for West. This ticket is encrypted in the interdomain key CorpHQ shares with West.

3. The client asks the KDC for West to give it a ticket to the server in West.
   The KDC in West replies by sending a ticket for the server in West.

 

Tickets

 

 

What is in a ticket, how ticket expiration times are calculated, and how much of a ticket's content is known by the client are important things to know when you want to configure Kerberos policy; therefore, they deserve a closer look.

What Is in a Ticket

Kerberos messages and tickets have a precise data structure and format. For more information about ticket fields and flags, see the Request for Comments (RFC) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources . Follow the links to RFC 1510.

How the KDC Limits a Ticket's Lifetime

Kerberos tickets have a start time and an expiration time. At any time after the start time but before the expiration time, a client holding a session ticket for a particular service can present the ticket and gain access to the service, no matter how many times the client has used the ticket previously. To reduce the risk of a ticket or its corresponding session key being compromised, administrators can set a maximum lifetime for tickets. This value is one element of Kerberos policy an administrator can set for the domain.

When a client asks the KDC for a session ticket to a service, it can request a specific start time. If this time is missing from a request or it is a time already past, the KDC sets the ticket's starttime field to the current time.

Whether or not clients specify a start time, their requests must include an expiration time. The KDC determines the value of a ticket's endtime field by adding the maximum ticket life fixed by Kerberos policy to the value of the ticket's starttime field. It then compares the result with the requested expiration time. Whichever of these times is earliest becomes the ticket's endtime .

Renewable Tickets

Encryption keys wear out with frequent use. The more often an encryption key is used, the more examples of the key an attacker has available to study and the greater the temptation for this person to expend the effort necessary to break the code. The keys used most often in the Kerberos protocol are the session keys. Clients use the same key each time they connect to a server, for as long as the session ticket remains valid. When the ticket expires, the client gets a new ticket with a fresh session key, but until then, the key is not changed.

One way to limit the exposure of session keys to potential attackers is to force the session keys to change often. You can do this by setting Kerberos policy so that the maximum session ticket life is relatively short. Another strategy is to permit tickets to be renewed, which allows session keys to be refreshed periodically without having to issue a completely new ticket. If Kerberos policy permits renewable tickets, the KDC sets a RENEWABLE flag in every session ticket it issues and sets two expiration times in the ticket. One expiration time limits the life of the current instance of the ticket. The second expiration time sets a limit on the cumulative lifetime of all instances of the ticket.

The expiration time for the current instance of a session ticket is held in the endtime field. Just as for nonrenewable session tickets, endtime is the value of the starttime field plus the maximum ticket life specified by the Kerberos policy. A client holding a renewable ticket must present it to the KDC for renewal before the endtime is reached and present a fresh authenticator as well. When the KDC receives a session ticket for renewal, it checks a second expiration time held in the renew-till field. This time is set when the ticket is first issued; the value is the session ticket's starttime plus the maximum cumulative ticket life specified by the Kerberos policy. When the KDC renews the ticket, it checks to see that the renew-till time has not yet arrived. If it has not arrived, the KDC issues a new instance of the session ticket with a later endtime and a new session key.

This means that administrators can set Kerberos policy can so that session tickets must be renewed at relatively short intervals — every day, perhaps. When tickets are renewed, a new session key is issued, which minimizes the value of a compromised key. At the same time, administrators can also set the cumulative session ticket life for a relatively long period — one month, one year, or whatever. At the end of that time, the session ticket expires and is no longer valid for renewal.

What Happens When Tickets Expire

When a session ticket expires, ongoing operations are not interrupted. Session tickets are used only to authenticate new connections with servers. After a connection has been set up, it no longer matters whether the session ticket is still valid. However, when a TGT expires, the Kerberos client might have to interrupt the activities of the user to ask for a password.

The KDC does not notify clients when their session tickets or TGTs are about to expire. In fact, it does not keep track of transactions with clients beyond the short-term records required to prevent replay attacks. If a client presents an outdated TGT to the KDC's ticket-granting service, the service responds with an error message. Network servers also return error messages when they receive expired tickets. All responsibility for renewing or replacing tickets rests with the client.

What Clients Know About Tickets

Clients have to know some of the information that is inside session tickets and TGTs in order to manage their credentials cache. When the KDC returns a ticket and session key as the result of an AS Exchange or TGS Exchange, it packages the client's copy of the session key in a data structure that includes the information in the ticket's flags, authtime, starttime, endtime, and renew-till fields . The entire structure is encrypted in the client's key and returned in a KRB_AS_REP or KRB_TGS_REP reply message.

 

 

 

Delegation of Authentication

 

 

Multi-tier client/server applications present a special situation for the Kerberos protocol. In this kind of application, a client might connect to a server that must connect to a second server on the back end. For this to happen, the first server must have a session ticket to the second server. Ideally, this session ticket should limit the first server's access on the second server to what the client is authorized to do, rather than what the server is authorized to do.

The Kerberos protocol deals with this situation through a mechanism known as delegation of authentication . Essentially, the client delegates authentication to a server by telling the KDC that the server is authorized to represent the client.

Delegation can be done in two ways. One way is for the client to get a session ticket for the back-end server and give it to the front-end server. Tickets obtained in this way — by a client for a proxy — are called proxy tickets . The difficulty with using proxy tickets is that the client must know the name of the back-end server. This difficulty is overcome by the second method of delegation, which allows the client to give the front-end server a TGT that the front-end server can use to request session tickets for the back-end server as needed. Session tickets obtained in this way — with credentials forwarded by a client — are called forwarded tickets . Whether the KDC allows clients to obtain proxy tickets or forwardable TGTs is determined by the Kerberos policy set by an administrator for the domain.

Proxy Tickets

When the KDC issues a TGT to a client, it checks the Kerberos policy for the domain to see if proxy tickets are allowed. If they are allowed, the KDC sets the PROXIABLE flag in the TGT that the KDC issues to the client.

The client obtains a proxy ticket by presenting a TGT to the ticket-granting service and asking for a session ticket to the back-end server. The client's request includes a flag that signals that it wants a proxy ticket; the request also includes the name of the server that will represent the client. When the KDC receives the client's request, it creates a session ticket for the back-end server, sets the PROXY flag in the session ticket, and sends the ticket back to the client. The client then sends the session ticket to the front-end server, which uses it for access to the back-end server.

Forwarded Tickets

If a client wants to delegate the task of obtaining session tickets for a back-end server to a front-end server, it must ask the KDC for a forwardable TGT. It does this through an AS Exchange by indicating to the KDC the name of the server that will act on the client's behalf. If Kerberos policy permits forwarding, the KDC creates a TGT for the front-end server to use in the client's name, sets the FORWARDABLE flag in the TGT, and sends the ticket back to the client. The client then forwards the TGT to the front-end server.

When the front-end server requests a session ticket to the back-end server, it presents the client's TGT to the KDC. When the KDC issues a session ticket for the back-end server, it sees the FORWARDABLE flag in the TGT, sets the FORWARDED flag in the session ticket for the requested server, and returns the session ticket to the front-end server. The option of setting the FORWARDED flag in a session ticket provides an added level of security because it permits administrators to configure individual servers to reject session tickets that have been forwarded.

 

 

Subprotocols

 

 

The Kerberos protocol is comprised of three subprotocols. The subprotocol in which the KDC gives the client a logon session key and a TGT is known as the Authentication Service (AS) Exchange. The subprotocol in which the KDC distributes a service session key and a session ticket for the service is known as the Ticket-Granting Service (TGS) Exchange. The subprotocol in which the client presents the session ticket for admission to a service is called the Client/Server (CS) Exchange.

To see how the three subprotocols work together, let's look at how Alice, a user at a workstation, gets access to Bob, a service on the network.

AS Exchange

Alice begins by logging on to the network. She types her logon name and her password. The Kerberos client running on Alice's workstation converts her password to an encryption key and saves the result in its credentials cache.

The client then sends the KDC's authentication service a Kerberos Authentication Service Request (KRB_AS_REQ). The first part of this message identifies the user, Alice, and the service for which she is requesting credentials, the ticket-granting service, as illustrated in Figure 11.5. The second part of the message contains preauthentication data that ** proves Alice knows the password. This data is usually a timestamp encrypted with Alice's long-term key, although the protocol permits other forms of preauthentication data.

Figure 11.5 AS Exchange

When the KDC receives KRB_AS_REQ, it looks up the user, Alice, in its database, gets her long-term key, decrypts the preauthentication data, and evaluates the timestamp inside. If the timestamp passes the test, the KDC can be assured that the preauthentication data was encrypted with Alice's long-term key and thus that the client is genuine.

After it has verified Alice's identity, the KDC creates credentials that the Kerberos client on her workstation can present to the ticket-granting service. First, the KDC invents a logon session key and encrypts a copy of it with Alice's long-term key. Second, it embeds another copy of the logon session key in a TGT, along with other information about Alice, such as her authorization data. The KDC encrypts the TGT with its own long-term key. Finally, it sends these credentials back to the client in a Kerberos Authentication Service Reply (KRB_AS_REP).

When the client receives the reply, it uses the key derived from Alice's password to decrypt her logon session key and stores the key in its credentials cache. Then the client extracts the TGT from the message and stores that in its credentials cache as well.

TGS Exchange

The Kerberos client on Alice's workstation requests credentials for the service, Bob, by sending a Kerberos Ticket-Granting Service Request (KRB_TGS_REQ), as illustrated in Figure 11.6. This message includes the user's name, an authenticator encrypted with the user's logon session key, the TGT obtained in the AS Exchange, and the name of the service for which the user wants a ticket.

Figure 11.6 TGS Exchange

When the KDC receives KRB_TGS_REQ, it decrypts the TGT with its secret key and extracts Alice's logon session key. The KDC then uses the logon session key to decrypt the authenticator and evaluates it. If the authenticator passes the test, the KDC extracts Alice's authorization data from the TGT and invents a session key for the client, Alice, to share with the service, Bob. The KDC encrypts one copy of this session key with Alice's logon session key. It embeds another copy of the session key in a ticket, along with Alice's authorization data, and encrypts the ticket with Bob's long-term key. The KDC then sends these credentials back to the client in a Kerberos Ticket-Granting Service Reply (KRB_TGS_REP).

When the client receives the reply, it uses Alice's logon session key to decrypt the session key to use with the service, and stores the key in its credentials cache. Then it extracts the ticket to the service and stores that in its cache.

CS Exchange

The Kerberos client on Alice's workstation requests service from Bob by sending Bob a Kerberos Application Request (KRB_AP_REQ), as illustrated in Figure 11.7. This message contains an authenticator encrypted with the session key for the service, the ticket obtained in the TGS Exchange, and a flag indicating whether the client wants mutual authentication. (The Kerberos protocol can provide mutual authentication but does not require it. In Windows 2000, clients always ask for mutual authentication. Clients using other implementations of the protocol might not.)

Figure 11.7 CS Exchange

The service, Bob, receives KRB_AP_REQ, decrypts the ticket, and extracts Alice's authorization data and the session key. Bob uses the session key to decrypt Alice's authenticator and then evaluates the timestamp inside. If the authenticator passes the test, Bob looks for a mutual authentication flag in the client's request. If the flag is set, he uses the session key to encrypt the time from Alice's authenticator and returns the result in a Kerberos Application Reply (KRB_AP_REP).

When the client on Alice's workstation receives KRB_AP_REP, it decrypts Bob's authenticator with the session key it shares with Bob and compares the time returned by the service with the time in the client's original authenticator. If the times match, the client knows that the service is genuine, and the connection proceeds. During the connection, the session key can be used to encrypt application data, or the client and server can share another key for this purpose.

 

 

Logging on with a Smart Card

 

In standard logons, a user initially proves his or her identity to the KDC by demonstrating knowledge of a secret known only to the user and to the KDC. This shared secret is the cryptographic key derived from the user's password. The same key is used for both encryption and decryption. For this reason, shared secret keys are said to be symmetric. The cryptographic key derived from the user's password is used only during the AS Exchange for the following:

• When the client encrypts preauthentication data.

• When the KDC decrypts preauthentication data.

• When the KDC encrypts the logon session key.

• When the client decrypts the logon session key.

To support logging on with a smart card, Windows 2000 implements a public key extension to the Kerberos protocol's initial AS Exchange. In contrast to shared secret key cryptography, public key cryptography is asymmetric ; that is, two different keys are needed — one to encrypt, another to decrypt. Together, the keys needed to perform both operations make up a private/public key pair.

When a smart card is used in place of a password, a private/public key pair stored on the user's smart card is substituted for the shared secret key derived from the user's password. The private key is known only to the owner of the pair and is never shared. The public key can be made available to anyone with whom the owner wishes to exchange confidential information.

In the public key extension to the Kerberos protocol, the initial AS Exchange is modified so that the KDC encrypts the user's logon session key with the public half of the user's key pair. The client decrypts the logon session key with the private half of the pair.

The logon process begins when the user inserts a smart card into a card reader attached to the computer. When a computer that is running Windows 2000 is configured for smart card logon, the insertion of the card signals the SAS, just as the key combination CTRL+ALT+DEL signals the SAS on computers configured for password logon. In response, Winlogon dispatches to MSGINA, which displays a logon dialog box. But in this case, the user types just one item of information, a personal identification number (PIN).

MSGINA sends the user's logon information to the LSA by calling LsaLogonUser, just as it does with a password logon. The LSA uses the PIN for access to the smart card, which contains the user's private key along with an X509 v3 certificate that contains the public half of the key pair. All cryptographic operations that use these keys take place on the smart card.

The Kerberos SSP on the client computer sends the user's public key certificate to the KDC as preauthentication data in its initial authentication request, the KRB_AS_REQ message. The KDC validates the certificate, extracts the public key, and then uses the public key to encrypt a logon session key. It returns the encrypted logon session key and a TGT in its KRB_AS_REP reply message to the client. If the client is in possession of the private half of the key pair, it can use the private key to decrypt the logon session key. Both the client and the KDC then use this logon session key in all further communications with one another. The remainder of the authentication process is the same as for standard logon.

For information about the types of smart cards and smart card readers supported by Windows 2000, see the Microsoft Windows Hardware Compatibility List link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources .

 

 

Logging on with a Password

 

Suppose Alice has a network account in the domain named West. The computer she usually uses, Workstation, also has an account in West. When Alice logs on to the network, she begins by pressing the key combination CTRL+ALT+DEL, which is the Secure Attention Sequence (SAS) on computers with a standard Windows 2000 configuration.

In response to the SAS, Winlogon switches to the logon desktop and dispatches to a DLL called the Graphical Identification and Authentication (GINA), a component loaded in Winlogon's process. GINA is responsible for collecting the 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 (MSGINA.dll) supplied with the Windows 2000 operating system. MSGINA displays the standard logon dialog box.

Alice types her user name and password. She selects West from the list of domain names. When she clicks OK to dismiss the dialog box, MSGINA returns her logon information to Winlogon. Winlogon then sends the information to the LSA for validation by calling LsaLogonUser.

Upon receiving a data structure with Alice's logon data, the LSA immediately converts Alice's plaintext password to a secret key by passing it through a one-way hashing function. It saves the result in the credentials cache, where the hashed password can be retrieved when it is needed for encryption and decryption.

To validate Alice's logon information and set up her logon session on the computer, the LSA must obtain the following:

• A TGT that is good for admission to the ticket-granting service.

• A session ticket that is good for admission to the computer.

The LSA gets these tickets by working through the Kerberos SSP, which exchanges messages directly with the domain's KDC, as illustrated in Figure 11.8.

Figure 11.8 Kerberos Exchanges for Logging on Interactively

The messages follow this sequence:

1. The LSA sends a KRB_AS_REQ message to the KDC's authentication service in the domain West.
   The message includes:

   • The user's principal name (Alice).

   • The name of the account domain (West).

   • Preauthentication data encrypted with the secret key derived from Alice's password.

2. The KDC's authentication service replies with a KRB_AS_REP message.
   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 the domain West, encrypted with the KDC's secret key. The TGT includes a session key for the KDC to share with Alice and authorization data for Alice.

   The authorization data includes the SID for Alice's account, SIDs for security groups in the domain West that include Alice, and SIDs for universal groups in the enterprise that include either Alice or one of her domain groups.

3. The LSA sends a KRB_TGS_REQ message to the KDC's ticket-granting service in the domain West.
   The message includes:

   • The name of the destination computer (Workstation).

   • The name of the destination computer's domain (West).

   • Alice's TGT.

   • An authenticator encrypted with the session key Alice shares with the KDC.

4. The KDC replies with a KRB_TGS_REP message.
   The message includes:

   • A session key for Alice to share with Workstation, encrypted with the session key Alice shares with the KDC.

   • Alice's session ticket to Workstation, encrypted with the secret key Workstation shares with the KDC.

   The session ticket includes a session key for Workstation to share with Alice and authorization data copied from Alice's TGT.

Upon receipt of Alice's session ticket, the LSA decrypts it with the computer's secret key and extracts her authorization data. It then queries the local Security Accounts Manager (SAM) database to determine whether Alice is a member of any security groups local to the computer and whether she has been given any additional user rights 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. A handle to the access token is then returned to Winlogon, along with the identifier for Alice's logon session and confirmation that her logon information is 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.

 

 

Logon Process

 

 

When a user with an account in a Windows 2000 domain logs on at the keyboard of a computer that is running Windows 2000, 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 through an AS Exchange between the Kerberos SSP on the computer and the KDC in the user's account domain. The result is a TGT that the user can present in future transactions with this KDC.

2. The user asks for a ticket for the computer.
   This is accomplished through 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 he or she requests 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 account domain is different from the user's account domain, an extra step is involved. Before the Kerberos SSP can request a session ticket for the computer, it must ask the KDC in the user's domain for a TGT that is good for admission to the KDC in the computer's domain. The SSP can then present the TGT to the KDC in the computer's domain and get a session ticket for the computer.

Exactly how the logon process works depends on how you configure the computer. With standard configurations of Windows 2000, interactive users log on with a password. In another optional configuration of Windows 2000, users log on with a smart card. Although the basic process is the same for both configurations, there are some differences.