How Kerberos Fits into the Windows NT 5.0 Security Model
NT 5.0 addresses Kerberos' three components--the KDC, client (C1) program, and network server (S1).
September 30, 1997
How does Kerberos fit into the big picture? NT 5.0 addressesKerberos' three components--the KDC, client (C1) program, and network server(S1)--in various ways. NT 5.0 implements KDCs on each domain controller andsubstitutes the Kerberos term realm for the NT term domain. NT5.0 integrates the KDC with the Windows NT directory service. The KDC uses theNT directory service as the account database for the clients' passwords andnames. NT 5.0 implements C1 as a Security Service Provider (SSP) written to theSecurity Support Provider Interface (SSPI). The WinLogon service invokes the C1SSP during the Ctrl-Alt-Del sequence that NT uses to prevent Trojan Horseattacks.
Specifically, C1 logs on to the NT domain (or Kerberos realm) with theWinLogon service and obtains the TGT encrypted with the C1 hashed password. C1then obtains the TGT from the KDC service running on the domain controller. C1stores the TGT with other user logon information in the workstation cache. WhenC1 tries to communicate with a network service, the client runtime checks theticket cache for a valid ticket for that specific server. If a valid ticketisn't available, C1 sends the TGT that it received from the logon process to theKDC to obtain a specific ticket for the desired server. C1 adds the session keyand ticket to the ticket cache so that C1 can use the ticket for future sessionsuntil it expires.
The NT domain security policy determines ticket expiration. The default iseight hours. If a ticket expires during an active session, the client KerberosSSP returns error codes internally and automatically renews the ticket. TheKerberos SSP then requests a new KDC-generated ticket with a shared session key,and the client resumes the connection with the server--all without userintervention.
Kerberos is an identity authentication protocol, not an access controlprotocol. As a result, once the client and the server authenticate each other'sidentity, NT uses security IDs (SIDs) and access control lists for discretionaryaccess to resources on the network.
NT 5.0 Kerberos supports forwarding flags in the tickets. NT uses thisfeature to let servers with client tickets communicate with other servers onbehalf of the client. The secondary server can also pass client tickets to otherservers to continue the distributed delegation chain. This feature is importantfor 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 theGeneric Security Service API (GSS API) security formats (as defined in Requestfor Comments--RFC--1964) to provide interoperability with non-NT operatingsystems. The NT domain controller can refer a client from another networkoperating system to the KDC. The foreign client then requests a session ticketfrom the KDC. Because this request will probably not contain the SID-basedauthorization information, NT 5.0 lets the administrator map the UNIX Kerberosprincipal name to an NT account for authorization information and to create aticket for the foreign client.
Microsoft is working with the Internet Engineering Task Force (IETF) CommonAuthentication Technology (CAT) working group on extensions to Kerberos RFC 1510to include private/public key technology to broaden foreign systems' ability tocommunicate securely with NT. If the RFC is extended, the NT KDC will be able toencrypt tickets with a client's public key obtained from an X.509 certificate onan NT server, a third-party server (such as VeriSign), or even a NetWaredirectory service. This extension would let an administrator give a user outsidethe NT directory service permission to use an NT resource.
About the Author
You May Also Like