HP-UX Kerberos Interoperability with Windows 2000

 

Deepak G. Hegde (hegde@india.hp.com)

 Shiddlinganagouda A Rati (sgouda@india.hp.com)

DCE/Kerberos Team

Hewlett-Packard, India Software Operation

30C Cunningham Road

Bangalore, India

Tel: +91-80-2251554

Fax: +91-80-220-0196

 

Jean-Marc Chevrot (jean-marc_chevrot@hp.com)

R&D Program Manager, DCE/Kerberos Project

Hewlett-Packard

19420 Homestead Road, MS 43 LF

Cupertino, California, U.S.A

Tel: (408) 447-2241

Fax: (408) 447-3660

1.      Introduction

 

Kerberos [1] has gained much importance after it was incorporated into the Windows 2000 Operating System, as the primary authentication mechanism. Kerberos along with Active Directory Service (ADS) and other components on Windows 2000 provide an enterprise wide security infrastructure. It is imperative to provide mechanisms on HP-UX to support its seamless integration with the Windows 2000 based environments. This paper examines some of the issues related to integrating the HP-UX Kerberos based mechanisms with Windows 2000. The first two sections provide a brief overview of Kerberos protocol and its use in Windows 2000. Later sections explore some of the issues related to Kerberos authentication, account management and application interoperability etc. with respect to HP-UX. This paper, however, does not discuss any detailed protocol level interoperability issues related to Windows 2000, which has been dealt in detail elsewhere [2][3][4].

2.      Kerberos authentication protocol – a brief overview

 

Kerberos is a trusted third party authentication protocol for authenticating a user or a request for a service in a network environment. The Kerberos protocol was developed during the Athena project at the Massachusetts Institute of Technology (MIT). The name comes from the Greek mythology where the three-headed dog Kerberos was guarding the gates of Hades. Kerberos allows a user to request a ticket from an authentication server. This is achieved without transmitting password in clear text over the network as explained below. The ticket can be used to access an application or service. Kerberos implementations use DES, which is a symmetric-key encryption technology.

 

Kerberos Protocol:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.        Request a Ticket Granting Ticket (TGT)

The client sends a request to the Authentication Service (AS) for a Ticket Granting Ticket (TGT)

2.        The AS builds a Session Key encrypted with the client secret key which is based on the user password stored in its local registry. The encrypted session key is sent along with TGT (encrypted in Ticket Granting Server’s secret key).

3.        Then the client sends his TGT to a Ticket Granting Server (TGS) to get access to a specific service.

4.        The TGS returns the time-stamped Service Ticket that the service provider will accept.

5.        The client sends the Service Ticket to the service provider. The time–stamped tickets may be reused until the ticket expires.

 

Note: The Authentication Server (AS) and the Ticket Granting Server (TGS) are usually part of the same Key Distribution Center (KDC) but this is not mandatory

3.      Microsoft Windows2000 Kerberos

 

Kerberos protocol has been fully integrated with Windows 2000 security architecture for authentication and access control and replaces the NTLM, which was the primary security mechanism. [2][3][4]. Windows 2000 Kerberos is based on RFC 1510 and implements a KDC on each Domain Controller. A Windows 2000 domain is equivalent to a Kerberos realm. Windows Active Directory is used as the Kerberos account database for users (principals).

 

The Kerberos version 5 protocol supports transport of authorization data, but the contents of authorization field are considered specific to the application service. The principal name in a Kerberos ticket can be used to validate the user’s identity while additional authorization information might be managed on the local system for access control. Windows 2000 uses the Authorization Data in Kerberos tickets to carry Windows Security IDs (SID) representing the user and group membership. Based on the authorization information, a security access token is built by the Local Security Authority on the server-side Windows 2000 machine. The server follows the Windows NT security model of impersonating the client, using the security access token to represent the client, before accessing local data protected by Access Control Lists (ACLs).

 

Clients that obtain initial Kerberos TGT or ticket from a non windows 2000 KDC server will use the Kerberos referral mechanism to request a session ticket from the KDC in the Windows 2000 service domain. The referral ticket is created by inter-realm trust relationships between the KDCs. For example, a ticket request originated from an MIT Kerberos authentication service will not contain the Authorization Data. When a session ticket does not contain Authorization Data, the Windows 2000 Kerberos security provider will try to use the principal name in the ticket and create a security access token for a designated user account, or use a default account defined for this purpose.  

4.      Windows 2000 Kerberos authentication on HP-UX

 

Many authentication mechanisms are now available on HP-UX, which have their own interfaces (e.g. UNIX passwords, SecureID, Kerberos etc). This requires that any application which uses authentication mechanism needs to support every possible authentication technology. Pluggable Authentication Module (PAM) [5] is a framework to provide easily configurable ‘pluggablity’ of the security technologies for authentication, account, session and password management.

 

PAM allows a system administrator to set authentication policies to choose authentication technologies without having to recompile programs that do authentication. With HP-UX PAM, administrator can control how the security modules are plugged into the programs by specifying it in a configuration file. Applications can rely on the PAM framework to redirect the authentication requests to the configured security module.

 

Integration of HP-UX authentication with Windows 2000 requires that the Kerberos account for each user on HP-UX to be created and maintained on Windows 2000. The Kerberos PAM module that is being implemented will use the standard Kerberos protocol and APIs to support authentication to Windows 2000. Windows 2000 Kerberos implementation also supports Public Key extension to the Kerberos protocol as defined in [6], with certain restriction [3]. However, this is not being considered at this point of time for HP-UX Kerberos interoperability with Windows 2000.

 

Kerberos tickets have expiry periods and are cached on the local HP-UX system for re-use, until expiry. Renewal of TGT can be done using the "kinit" command on HP-UX. However, if the HP-UX system isintegrated with the ADS (or any other directory server, which needs Kerberos authentication for access), then the ticket management should be done transparently. A daemon or the kernel can do this, for those users (or long running applications) using Kerberos authentication, in association with HP-UX PAM.

5.      HP-UX account management

 

During initial login, it is necessary to obtain the information containing User's ID, group, home directory and shell. Typically, this is available from the registry that is also used for authentication purpose (e.g. NIS+, DCE). Windows 2000 uses the Active Directory Service (ADS) as the Kerberos registry and all accounts are managed by the ADS. For integrating the HP-UX account information from the ADS, access to the ADS through LDAP is a pre-requisite. The HP-UX Name Service Switch (NSS) allows transparent access to account registries (e.g. NIS+, DCE, LDAP). The LDAP NSS would allow a HP-UX system to access and manage accounts on the ADS. The LDAP schema as defined by IETF RFC 2307 [8] can be implemented on ADS to support UNIX account information management.

 

Kerberos being a network authentication mechanism does not support the notion of an account as in UNIX. The principal in a "generic" Kerberos KDC does not contain user's UID, home directory or shell. However, it contains the user's password and can be managed by the "Kerberos Change Password Protocol" [7]. Windows 2000 implementation supports this protocol and the HP-UX Kerberos PAM for password changes would employ this mechanism.

 

 

The PAM configuration allows stacking of security modules such that two or more security registries can be updated when a password change is made. This mechanism can be used to synchronize the passwords on the two registries. The PAM configuration also allows to fall back to the /etc/password in case of failure to access ADS.

6.      Kerberos application interoperability

 

Windows 2000 supports interoperability between UNIX and Windows 2000 Kerberos applications by incorporating GSS-API specified by IETF RFC 1964 [9]. The Kerberos Security Support Provider provides GSS-API support on Windows 2000.  Applications employing GSS-APIs will be interoperable between Windows 2000 and any other operating system.

 

On HP-UX, the Kerberos client library is available as part of the HP-UX. The client library (libsis) supports the Kerberos and GSS-APIs with 56 bit DES encryption. Applications linked with this will be able to exploit these features. HP-UX Secure Internet Services product which includes Kerberized ftp, telnet etc., currently use this library. These applications will be able to inter-operate with Windows 2000 and use Windows 2000 as the KDC.

7.      Common authorization mechanism

 

In an "Enterprise Security Infrastructure" a common authorization mechanism is to be expected. Kerberos being an authentication mechanism does not support authorization per-se. However, it allows transport of authorization data along with tickets, leaving out the details of authorization data for implementation. DCE and Windows 2000 exploit this facility to carry authorization information for a principal. However, each have their own authorization data formats and are not interoperable, as of now.

 

Windows 2000 employs the ACL based authorization mechanism to control access to objects in a Windows environment. Authorization decision is arrived at based on the ACLs for an object and the security access token derived from the NT-PAC data from the tickets. As the authorization data may not be usable on HP-UX Kerberos clients, a mapping mechanism can be used between SID and UNIX user identity for carrying out name based authorization.

 

8.      References

 

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

[2]     Kerberos authentication in Windows NT 5.0 domains, Peter Brundrett, ;login, May 1998 Special Issue on Security, USENIX

[3]     Windows 2000 Kerberos Authentication, White Paper, Microsoft Corp.

[4]     Secure Networking Using Microsoft Windows 2000 Distributed Security Services, White Paper, Microsoft Corp.

[5]     Pluggable Authentication Modules, RFC 86.0, The Open Group

[6]     Public Key Cryptography for Initial Authentication in Kerberos, Clifford Neuman, John Wray, Brian Tung, J. Trostle, M. Hur, A. Medvinsky, Sasha Medvinsky, IETF Internet Draft, 05/17/1999

[7]     Kerberos Change Password Protocol, M. Horowitz, IETF Internet Draft, 08/11/1998.

[8]     An approach for using LDAP as a Network Information Service, L. Howard, IETF RFC 2307, March 1998

[9]     The Kerberos Version 5 GSS-API Mechanism, J. Linn, IETF RFC 1964, June 1996