How does Kerberos fit into the big picture? NT 5.0 addresses Kerberos' three components--the KDC, client (C1) program, and network server (S1)--in various ways. NT 5.0 implements KDCs on each domain controller and substitutes the Kerberos term realm for the NT term domain. NT 5.0 integrates the KDC with the Windows NT directory service. The KDC uses the NT directory service as the account database for the clients' passwords and names. NT 5.0 implements C1 as a Security Service Provider (SSP) written to the Security Support Provider Interface (SSPI). The WinLogon service invokes the C1 SSP during the Ctrl-Alt-Del sequence that NT uses to prevent Trojan Horse attacks.

Specifically, C1 logs on to the NT domain (or Kerberos realm) with the WinLogon service and obtains the TGT encrypted with the C1 hashed password. C1 then obtains the TGT from the KDC service running on the domain controller. C1 stores the TGT with other user logon information in the workstation cache. When C1 tries to communicate with a network service, the client runtime checks the ticket cache for a valid ticket for that specific server. If a valid ticket isn't available, C1 sends the TGT that it received from the logon process to the KDC to obtain a specific ticket for the desired server. C1 adds the session key and ticket to the ticket cache so that C1 can use the ticket for future sessions until it expires.

The NT domain security policy determines ticket expiration. The default is eight hours. If a ticket expires during an active session, the client Kerberos SSP returns error codes internally and automatically renews the ticket. The Kerberos SSP then requests a new KDC-generated ticket with a shared session key, and the client resumes the connection with the server--all without user intervention.

Kerberos is an identity authentication protocol, not an access control protocol. As a result, once the client and the server authenticate each other's identity, NT uses security IDs (SIDs) and access control lists for discretionary access to resources on the network.

NT 5.0 Kerberos supports forwarding flags in the tickets. NT uses this feature to let servers with client tickets communicate with other servers on behalf of the client. The secondary server can also pass client tickets to other servers to continue the distributed delegation chain. This feature is important for distributed client/server applications, such as Systems Management Server (SMS) and Exchange Server.

NT 5.0 supports the Kerberos KDC messages defined in KFC 1510 and the Generic Security Service API (GSS API) security formats (as defined in Request for Comments--RFC--1964) to provide interoperability with non-NT operating systems. The NT domain controller can refer a client from another network operating system to the KDC. The foreign client then requests a session ticket from the KDC. Because this request will probably not contain the SID-based authorization information, NT 5.0 lets the administrator map the UNIX Kerberos principal name to an NT account for authorization information and to create a ticket for the foreign client.

Microsoft is working with the Internet Engineering Task Force (IETF) Common Authentication Technology (CAT) working group on extensions to Kerberos RFC 1510 to include private/public key technology to broaden foreign systems' ability to communicate securely with NT. If the RFC is extended, the NT KDC will be able to encrypt tickets with a client's public key obtained from an X.509 certificate on an NT server, a third-party server (such as VeriSign), or even a NetWare directory service. This extension would let an administrator give a user outside the NT directory service permission to use an NT resource.