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.