Kerberos authentication in Windows NT 5.0 domains

by Peter Brundrett
<[email protected]>

Peter Brundrett is program manager for Windows NT security in the Distributed Systems Group at Microsoft. He has fifteen years' experience in software engineering in operating systems, distributed applications, and consulting in large-scale systems integration.

Enterprise networks using Windows NT are growing in size and complexity. Windows NT 5.0 uses the Kerberos Version 5 authentication protocol and the Active Directory for network security in Windows NT domains. The Windows NT implementation of the Kerberos Version 5 protocol is based on RFC 1510, which has gone through a wide industry review and is well known in the security community [1]. Kerberos authentication provides many features that support performance and security objectives for Enterprise networks. Microsoft's implementation will support any RFC 1510-compliant clients, but will be required for full support of Windows NT networks because the Microsoft version includes permitted extensions to the standard.

Windows NT 5.0 integrates the Kerberos protocol into the existing Windows NT distributed security model. Windows NT uses the extensibility features of the protocol, as have other security architectures, such as DCE and SESAME [2]. The Kerberos protocol is just one of the security protocols supported in Windows NT 5.0. Others include NTLM for backward compatibility, SSL and the IETF standard Transport Layer Security (TLS) for public-key authentication, Simple Protected Negotiation (SPNEGO) of security mechanisms, and IP security (IPsec) for network layer security using either shared-key or public-key authentication.

Windows NT Distributed Security Model

Windows NT has a distributed security model for network services based on three fundamental components. First, every workstation and server has a direct trust path to a Domain Controller (DC) for the domain in which it is a member. The trust path is implemented by the Netlogon service through an authenticated RPC connection to the trusted domain authority, namely, the DC. A secure channel extends to other Windows NT domains through interdomain trust relationships. The secure channel is used to obtain and verify security information, including Security Identifiers (SIDs) for users and groups.

Second, network services impersonate the client's security context before carrying out requested operations. Impersonation is based on the security access token created by the Local Security Authority (LSA) that represents the client's authorizations on the server computer. A server thread impersonates the client and executes with the authorization of the client rather than the security identity of the server. Impersonation is supported by all Windows NT services, including, for example, the CIFS/SMB remote fileserver service. Authenticated RPC and DCOM security support impersonation for distributed applications. BackOffice services like Exchange, SNA Server, and Internet Information Server also use impersonation.

Third, the Windows NT kernel supports object-based access control by verifying SIDs in the access token against granted access rights defined in the access control list (ACL) on an object. Every object in Windows NT (registry keys, NTFS files and directories, file shares, kernel objects, print queues, etc.) has an object-specific ACL. The Windows NT kernel performs an access check on every attempt to open a handle to an object. Access control and auditing are managed by setting the security properties of the object to grant permissions to a user, or preferably a group. Authorization is centrally managed by adding users to the Windows NT groups that are granted the appropriate access rights.

These components of the distributed security model are an important part of all secure application servers on Windows NT. Windows NT 5.0 adds new security protocols, including public-key client authentication using SSL/TLS and Kerberos Version 5, which are integrated into the security model.

Integrated Kerberos Authentication

Windows NT 5.0 integrates Kerberos authentication into Windows NT domains for single sign-on and support for the Windows NT distributed security model. The Kerberos protocol provides mutual authentication, faster authentication, and transitive trust for authentication anywhere in a tree of Windows NT domains. Windows NT 5.0 uses Kerberos authentication to perform a user's interactive logon to a Windows NT domain account. Public-key extensions to the initial Kerberos authentication provide the protocol support for smart card logon to Windows NT 5.0 [3]. The Kerberos protocol is implemented as a security provider under the Security Support Provider Interface (SSPI).

The Kerberos security provider is used by the SMB Client and Server and is available for DCOM, authenticated RPC, and any application protocol designed to use SSPI for network security. SSPI is a Win32 security interface available on Windows NT since the 3.5 release and is also supported on Windows 95. SSPI is designed using the same architectural concepts as the Generic Security Services API (GSS-API, RFC 1964) and isolates applications from the details of network security protocols. More information on SSPI is available on the Microsoft Developer Network CD.

Windows NT 5.0 implements a Kerberos Key Distribution Center (KDC) and Active Directory as services on the Domain Controller. Any Windows NT 5.0 DC replica has a KDC service for availability. The KDC runs as a privileged process along with the Active Directory. Both services manage sensitive information, including passwords for user accounts. The Active Directory implements multiple-master update and replication, so creating a new user account, making changes to a user's group membership, or resetting a password can be done at any available DC. Multiple-master update means that updates are no longer restricted to the Primary Domain Controller (PDC) with Backup Domain Controllers providing read-only copies. Every replica of the Active Directory is an updateable copy of the Domain Controller for a domain.

Clients and servers use Kerberos messages for mutual authentication. The Kerberos request carries the Kerberos session ticket and authenticator issued by the KDC to prevent replays of the session ticket. The Kerberos security provider on the client integrates with the Local Security Authority, which provides a Kerberos ticket cache. When the client initializes a security context, the Kerberos security provider retrieves a session ticket for the target service from the Local Security Authority ticket cache or requests a new session ticket from the KDC. The Kerberos request message created by the Kerberos security provider conforms to RFC 1964, the GSS Kerb5 Mechanism token formats. Clients can authenticate to any service in the domain or trusted realm that supports the Generic Security Services (GSS) Kerb5 mechanism. The Kerberos security provider can accept a Kerberos request generated by any client system that supports RFC 1964 GSS Kerb5 mechanism token formats.

This level of interoperability provides support for traditional name-based Kerberos authentication in a cross-platform network environment. For Windows NT services, Windows NT authorization data in session tickets are essential to support impersonation and access control in the Windows NT distributed security model.

Kerberos Protocol and Windows NT Authorization

Windows NT impersonation requires that the Local Security Authority on the server have the ability to obtain the user's SID and list of group membership SIDs for a client in a secure manner. These SIDs are issued by a trusted domain authority and are used by the Local Security Authority to create an impersonation access token. After connection setup, a server thread impersonates the client, and the client's security access token is verified against ACLs on objects by the Windows NT kernel. Using NTLM authentication, the user's SID and the group's SIDs are received directly from the server's DC, and any trusted domains, using the Netlogon secure channel. Using the Kerberos protocol, user and group SIDs are transmitted in the authorization data of the Kerberos session ticket.

Windows NT uses KDC-supplied authorization data in tickets to provide the list of SIDs that identify the user and group membership. The Local Security Authority uses the authorization data to support impersonation for the Kerberos security provider.

The Kerberos protocol permits the use of application-defined authorization data in Kerberos tickets. Windows NT use of authorization data is consistent with revisions to RFC 1510 submitted to the IETF by Theodore Ts'o of MIT and Cliff Neuman of USC/ISI and was reviewed by the authors to minimize interoperability problems.

The Windows NT KDC adds authorization data to the Ticket Granting Ticket during initial domain logon that includes the user's SID and groups from the account domain. Group membership is expanded at initial logon. The Windows NT KDC copies the authorization data from the Ticket Granting Ticket into the session tickets used to authenticate to target application servers. In a multiple-domain network, the KDC handling the session ticket request for a target server may add additional groups to authorization data to include any groups in the target domain to which the user may belong.

The format of the Windows NT authorization data is subject to change until the release of Windows NT 5.0. Microsoft will publish the format of Windows NT KDC-issued authorization data about the same time as the final release. In general, the authorization data format will be a list of security identifiers in Network Data Representation (NDR) for cross-platform support and contain an integrity signature by the KDC.

Leveraging Kerberos in Windows NT Networks

Kerberos authentication is used by many Windows NT domain services. SSPI is used for network authentication in most system services and it is fairly straightforward to update those services from NTLM to Kerberos with minimal effort. The most complex change was to the SMB server, which did not use SSPI prior to Windows NT 5.0. Many new distributed services in Windows NT 5.0 use Kerberos authentication. Here is a partial list of how Kerberos authentication is used in Windows NT 5.0:

• authentication to the Active Directory using LDAP for queries or directory management
• CIFS/SMB remote file access protocol
• distributed filesystem management and referrals
• secure DNS address update
• print spooler services
• optional IPsec host-host authentication in ISAKMP/Oakley
• reservation requests for network Quality of Service
• Intranet authentication to Internet Information server
• authentication of public-key certificate requests to the Microsoft Certificate Server for domain users and computers
• remote server or workstation management using authenticated RPC and DCOM

In addition to these services, one of the goals of Windows NT 5.0 is the ability to turn off NTLM authentication in networks where all machines are running Windows NT 5.0.

Network Security Interoperability

Windows NT 5.0 domains must be able to support Windows NT 3.x-4.0 workstations and servers, Windows 95/98 clients, as well as Windows NT 5.0 desktops and servers. To provide that support, Windows NT 5.0 supports NTLM authentication for downlevel clients and servers. Microsoft will also provide a Distributed Systems Client upgrade for Windows 9x systems with the Windows NT 5.0 release that includes a directory client based on LDAP and Kerberos security for authentication.

Kerberos interoperability testing is ongoing using the MIT Kerb5 1.0 release with available updates. CyberSafe and other vendors with Kerberos-based products are also carrying out independent interoperability testing between UNIX systems and Windows NT 5.0. The primary interoperability objective is to allow application clients that use Kerberos SSPI or GSS-API on UNIX to authenticate to application servers that also support Kerberos authentication. Windows NT 5.0 Beta1 demonstrates some of that interoperability. Additional support for cross-realm trust and full support for UNIX application servers is available in the Windows NT 5.0 Beta2 release. These features depend on Windows NT 5.0 naming support for Kerberos services and not necessarily the Kerberos security protocol itself.

NT and UNIX KDC

The question often arises: how will Windows NT 5.0 work with existing UNIX-based Kerberos servers? There are two ways Windows NT can interoperate with MIT Kerberos-based KDCs. First, the Windows NT 5.0 workstation can be configured to use a UNIX KDC. Users can logon to Windows NT using an account defined in the UNIX KDC. This is just like the UNIX workstation support for Kerberos logon.

Any Windows NT or UNIX application that requires only name-based authentication can use a UNIX KDC as the Kerberos server. For example, a database application server with its own database authorization table can authenticate Windows NT clients using Kerberos tickets issued by a UNIX KDC. Because the database server does not use Windows NT access control, the server could also run on Windows NT without using impersonation. The application server calls the Kerberos security provider to accept session tickets issued by the UNIX KDC and query the security context for the client name. The tickets issued by the UNIX KDC can be used for mutual authentication and message privacy. However, without authorization data, the security context cannot be used for NT impersonation.

The second way Windows NT interoperates with MIT Kerberos is through cross-realm trust between a UNIX realm and Windows NT domain. Cross-realm trust is the best way to support Windows NT services that use impersonation and access control. Cross-realm trust is similar to the widely used Windows NT multiple-domain model of account domains and resource domains. In this case, the UNIX KDC acts as an account domain, and Windows NT-based services are located in the Windows NT resource domain. The Windows NT KDC is the authorization server for Windows NT-based services. Windows NT authorization data are added by the Windows NT KDC to session tickets for target servers in the Windows NT domain. The authorization data are based on name mapping between principals in the UNIX realm and shadow or proxy user accounts and their group membership in the Windows NT Active Directory. These accounts in the Active Directory can be synchronized and managed remotely using LDAP.

Can the UNIX KDC be the authorization server for Windows NT services? The Windows NT distributed security model depends on more than a list of SIDs for authorization data in Kerberos tickets. For example, the ACL editor used to manage security on NTFS files requires a domain server for SID-to-name lookup that uses RPC over the Netlogon secure channel to the DC. Without the RPC interface to translate identifiers, the ACL editor displays all NTFS file access rights granted to "<Account Unknown>" for SIDs that cannot be resolved.

Another requirement is support for the user interface to select accounts to grant access rights. This dialog allows the administrator to select a user or group from a list of accounts. The account list results from an LDAP query to the Active Directory and translates the account names to SIDs when building ACL entries.

A third requirement is support for NetBIOS naming by the KDC. Windows NT users are familiar with NetBIOS computer names, and applications must be able to authenticate to servers using names like \\project1\projectshare. Finally, the Kerberos security provider verifies authorization data in Kerberos tickets presented by untrusted applications using a secure RPC to the domain controller. The secure RPC is used to verify the KDC signature to prevent unauthorized use of group membership privileges.

To replace the domain controller with a UNIX KDC would require enhancing the current MIT Kerberos implementation with support for the Netlogon secure channel, authenticated RPC, NetBIOS naming support, and the LDAP protocol. These protocols go well beyond the authentication services provided by the MIT Kerberos server.

Conclusion

Microsoft is working hard at providing interoperable cross-platform network security using industry standard protocols such as SSL, Transport Layer Security, ISAKMP/Oakley for IP security, and Kerberos Version 5. Windows NT 5.0 demonstrates that commitment to interoperability and opens new opportunities for secure distributed computing in heterogeneous enterprise networks. Managing the security infrastructure in large-scale enterprise networks requires multiple protocols to support a distributed security model. Active Directory and Kerberos Version 5 authentication are important parts of the Distributed Systems infrastructure in Windows NT 5.0.

Notes

[1] "The Kerberos Network Authentication Service (V5)," J. Kohl and C. Neuman, Internet RFC 1510, September 1993.

[2] Information on SESAME is available at <http://www.esat.kuleuven.ac.be/cosic/sesame/doc-txt.html>.

[3] Windows NT 5.0 implements the current draft of the IETF CAT draft for PKINIT except that the protocol draft requires encryption of an arbitrary protocol element using a 512-bit RSA public key, which an exportable product such as Windows NT cannot fully comply with. Windows NT uses the PKCS #7 standard for encrypted data instead in this particular instance, and this issue has been discussed with the protocol authors.