Guide to SASL, GSSAPI & Kerberos v.6.0

SYMLABS VIRTUAL DIRECTORY SERVER Guide to SASL, GSSAPI & Kerberos v.6.0 Copyright 2011 www.symlabs.com

Chapter 1 Introduction Symlabs has added support for the GSSAPI 1 authentication mechanism, which provides a standard method of supporting Kerberos implementations, to its Virtual Directory Server (VDS) product. This GSSAPI support is enabled using SASL, and will allow the application to better integrate into Kerberos enabled environments, such as Active Directory, which uses Kerberos as its default authentication mechanism (from Windows 2000 onward). Active Directory accounts are also Kerberos security principals. Since Active Directory provides support for authenticated connections using simple authentication through NTLM, SSL, and SASL/GSSAPI; the SASL/GSSAPI interface now included with VDS, will fully enable the product to integrate completely into an Active Directory domain infrastructure. This is an incredibly powerful feature, as the product will now be able to provide levels of access, that were previously not possible, to client applications that do not support Kerberos or SASL/GSSAPI. It is useful to note that while SASL/GSSAPI on VDS has been tested with Active Directory, it has also been tested in a more pure environment using MIT Kerberos and the Sun OpenDS directory server. In this type of environment, there is no reliance on hidden or unpublished libraries such as Windows DLL files, and VDS works just as well as it does with Active Directory. OpenDS runs on any Java supported operating system, and as a result, can be used to provide a Kerberos enabled directory within a Linux or Unix environment. While much of this document will focus on using VDS with Active Directory, Linux and Unix users should keep in mind that this functionality will work as well for directories within these environments. This document will set out to explain what SASL/GSSAPI is, how it works and how it can be used within VDS. 1.1 What is SASL/GSSAPI? Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. SASL is capable of supporting multiple authentication mechanisms, so that they can be decoupled from application protocols. This means that any application that uses SASL can effectively support any authentication mechanism supported by SASL. Authentication mechanisms can also support proxy authorization, a facility allowing one user to assume the identity of another. Authentication mechanisms can also provide a data security layer offering data integrity and data confidentiality services. Potentially, SASL could be used to expand support for other authentication 1 We understand GSSAPI to be equivalent to the SASL incorporated GSS-API for Kerberos V5. We support both GSSAPI and GSS-SPNEGO Kerberos (The SASL incorporated GSS-API using SPNEGO, with Kerberos). 2

1.1. WHAT IS SASL/GSSAPI? mechanisms in the future, however VDS makes use of SASL only in order to provide Kerberos authentication support using GSSAPI. The Generic Security Services Application Program Interface (GSSAPI) is an application programming interface that allows programs to access security services, and used in conjunction with Kerberos V, is one of the authentication mechanisms supported by SASL. The GSSAPI attempts to provide a single standard interface to the many similar but incompatible security services available. Since Kerberos implementations vary, the GSSAPI makes it possible for applications to make use of the security services provided by Kerberos regardless of the implementation. Kerberos is an authentication and network security protocol that was originally developed at MIT, and which is strongly supported by Microsoft in Active Directory. Kerberos provides a means for client applications and servers to authenticate each other over an insecure network in a secure manner through the use of symmetric key cryptography and the use of a trusted third party, called a Key Distribution Center composed of two logically separate parts: the Authentication Server (AS) and the Ticket Granting Server (TGS). We will discuss Kerberos in some more detail later in this document, as it is fairly fundamental to understanding the security mechanism that is made accessible through GSSAPI. From a developmental point-of-view, GSSAPI provides a means to use a single code base that is able to take advantage of the security provided by Kerberos, without needing to adapt it to different implementations or to changes in a particular implementation. The definitive feature of GSSAPI applications is the exchange of opaque messages (tokens) that hide the implementation detail from the higher level application. The client and server sides of the application are written to convey the tokens given to them by their respective GSSAPI implementations. GSSAPI tokens can usually be sent over an insecure network as the mechanisms provide inherent message security. After some number of tokens have been exchanged, the GSSAPI implementations at both ends inform their local application that a security context has been established. Once a security context is established, sensitive application messages can be encrypted by the GSSAPI for secure communication between client and server. 1.1.1 Some Notes on GSSAPI Terminology It may be useful when referring to some GSSAPI documentation to have an understanding of some of the terminology that is specific to GSSAPI. The following terms are frequently used: Name A binary string that labels a security principal (i.e., user or service program). For example, Kerberos uses names like user@realm for users and service/hostname@realm for programs. Credentials Information that proves an identity; used by an entity to act as the named principal. Credentials typically involve a secret cryptographic key. Context The state of one end of the authenticating/authenticated protocol. May provide message protection services, which can be used to compose a secure channel. Tokens Opaque messages exchanged either as part of the initial authentication protocol (contextlevel tokens), or as part of a protected communication (per-message tokens) Mechanism An underlying GSSAPI implementation that provides actual names, tokens and credentials. Known mechanisms include Kerberos, NTLM, Distributed Computing Environment (DCE), SESAME, SPKM, LIPKEY. Symlabs Guide To SASL, GSSAPI And Kerberos 3

1.2. MORE ON KERBEROS Initiator/acceptor The peer that sends the first token is the initiator; the other the acceptor. Generally, the client program is the initiator while the server is the acceptor. 1.2 More on Kerberos The GSSAPI support offered by VDS should be transparent and is really a means to ensure that differing Kerberos implementations are capable of working properly together. The primary level of interest in this support for VDS deployments will be in the implicit support for Kerberos. Kerberos offers the means to authenticate securely over a public network infrastructure, and ensures that communications between client and server applications are secured. It does this by relying on symmetric key cryptography that is dependent on the availability of a Key Distribution Center that is responsible for handling authentication requests, and which will issue tickets that can be used to encrypt communications. In this section, we will attempt to provide a description of how a client is able to authenticate and then to access a service on a server that is protected using Kerberos. In order for Kerberos authentication to work, a Kerberos KDC (Key Distribution Center) will need to be installed on a server. For Active Directory, this will require that you configure Kerberos correctly for your Active Directory Server. For Linux or Unix deployments, you will need to deploy and configure a Kerberos implementation such as the open source Kerberos software released by MIT and available from http://web.mit.edu/kerberos/. Later in this guide, we will explore the configuration of both of these Kerberos implementations to show how to set up a Kerberos enabled pass-thru proxy. In the following breakdown, we will explain each of the steps involved in the Kerberos authentication process. This description assumes that each of the components are in place and are properly configured and the client application is able to interact with a Kerberos implementation. The following figure illustrates the different transactions that take place during authentication. 1. The client application submits a request to the Authentication Server component of the KDC. This request is submitted in clear text and simply contains the UserID. No password is submitted, although the client application will have generated a secret key based on a hash of the password, which it will use later to decrypt the response from the Authentication Server. 2. The Authentication Server uses the UserID to lookup the password stored in its database. It uses the hash of the password to encrypt a generated session key for the client application to begin communications with the Ticket Granting Server (TGS). 3. The Authentication Server sends a response which contains two messages: a. The encrypted session key for the TGS b. A Ticket Granting Ticket, which contains the client ID, client network address, ticket validity period, and the TGS session key; all encrypted using the secret key of the TGS. 4. The client decrypts the session key using the password hash for the UserID that it is authenticating. The client then submits a service ticket request to the TGS. The request is composed of the Ticket Granting Ticket that it received from the Authentication Server (which the client will not have been able to decrypt), along with the Service ID being requested; and an Authenticator which includes the client s ID and a timestamp encrypted using the decrypted session key. Symlabs Guide To SASL, GSSAPI And Kerberos 4

1.2. MORE ON KERBEROS Figure 1.1: The Kerberos Authentication Process 5. The TGS decrypts the Ticket Granting Ticket to obtain the session key which it can use to Authenticate the user by decrypting the Authenticator. The TGS is also able to lookup the service in the database, using the Service ID, to obtain the secret key for the service. 6. The TGS sends a response to the client, which includes the requested Service Ticket (encrypted using the secret key of the service), and a Service Session Key generated by TGS and encrypted using the Client/TGS session key. 7. The client decrypts the Service Session Key, using the TGS session key that it obtained from the Authentication Server. It then generates a service request to the server that it wishes to access. The service request contains the Service Ticket (which the client has been unable to decrypt), along with the Service Session Key that it has received from the TGS. 8. The server is able to decrypt the Service Ticket using its own secret key. Within the service ticket is the information required to validate the Service Session Key that the client has submitted in its request. The server is able to respond to the client, securely by encrypting traffic using the Service Session Key, and can be certain that the client is properly authenticated. One of the most useful things about Kerberos is that the technology effectively provides a means to enable Single Sign On (SSO). The user only needs to authenticate once with the Authentication Server, and can then make use of the Ticket Granting Ticket to obtain service tickets to access a variety of Kerberos-enabled services within the infrastructure. Symlabs Guide To SASL, GSSAPI And Kerberos 5

1.2. MORE ON KERBEROS 1.2.1 Some Notes On Kerberos Terminology In the above description of Kerberos authentication, and through the rest of this document, we have liberally used generic Kerberos terminology. Some explanation of many of these terms may be required, and certainly you may need to substitute terms depending on your implementation of Kerberos. For instance, when referring to the KDC in an Active Directory environment, you are really simply referring to an Active Directory instance that has Kerberos configured. Client An entity that can obtain a ticket. This entity is usually either a user or a host. KDC Key Distribution Center. Any system that issues Kerberos tickets. In Windows environments this is usually an Active Directory instance. The KDC is comprised of an Authentication Server (AS) and a Ticket Granting Server (TGS). Principal A string that names a specific entity to which a set of credentials may be assigned. It can have an arbitrary number of components, but generally has three: Primary: the first part of a Kerberos principal. In the case of a user, it is the username. In the case of a service, it is the name of the service. Instance: the second part of a Kerberos principal. It gives information that qualifies the primary. The instance may be null. In the case of a user, the instance is often used to describe the intended use of the corresponding credentials. In the case of a host, the instance is the fully qualified hostname. Realm: the logical network served by a single Kerberos database and a set of Key Distribution Centers. By convention, realm names are generally all uppercase letters, to differentiate the realm from the internet domain. The realm name in a windows environment will usually be equivalent to the Windows Domain Name that the user or service belongs to. The typical format of a typical Kerberos principal is primary/instance@realm. For usernames, where the instance has been left null, it is acceptable to format the principal as primary@realm. Service Any program or computer you access over a network. Examples of services include "host" (a host, e.g., when you use telnet and rsh), "ftp" (FTP), "krbtgt" (authentication; cf. ticket-granting ticket), and "pop" (email). Usually when working with VDS, the service will be "ldap". Service Principal Name (SPN) Name by which a client uniquely identifies an instance of a service. An SPN always includes the name of the host computer on which the service instance is running. Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate. Ticket A temporary set of electronic credentials that verify the identity of a client for a particular service. Ticket-Granting Ticket (TGT) A special Kerberos ticket that permits the client to obtain additional Kerberos tickets within the same Kerberos realm. Symlabs Guide To SASL, GSSAPI And Kerberos 6

1.3. COMMON USAGE SCENARIOS 1.3 Common Usage Scenarios In this section, we will discuss a few of the common usage scenarios where using the SASL support built into VDS may prove useful to resolve integration problems within your infrastructure. 1.3.1 Password Changes over LDAP in an Active Directory Environment For obvious security reasons, Active Directory does not allow common LDAP applications to perform password modifications over an unprotected connection. This means that you either need to enable SSL on your Active Directory server, so that your client application can connect using LDAPS, or you will need to authenticate using Kerberos, and rely on Kerberos encryption to secure your connection. Enabling SSL on Active Directory is not only relatively complex to configure, it also adversely affects performance. Kerberos is enabled by default on Active Directory and is the preferred method of encrypting communications. There are many client applications that do not support Kerberos authentication and encryption by default. And while some clients may support an implementation of Kerberos, they may not be capable of integrating with Microsoft s implementation in Active Directory. In order for password modification requests to be accepted by Active Directory using SASL/GSSAPI, SASL communication needs to be encrypted (i.e. the GSSAPI mode needs to be set to Privacy). This is the default configuration in VDS, so password modification requests will work by default. VDS offers a seamless way to integrate applications, that may need to perform password modifications, into your Active Directory infrastructure by providing a SASL/GSSAPI gateway to Active Directory. By configuring VDS to connect to Active Directory using Kerberos, client applications are able to submit password modification requests to VDS using plain LDAP, LDAPS or LDAP secured using SASL. VDS can then ensure that the password modification request is submitted to Active Directory appropriately. 1.3.2 Expand Active Directory Functionality Many of your common administration tools within a Windows domain, are already SASL capable and interact with Active Directory normally. However, you may wish to expand the functionality provided by Active Directory by using virtualization, or by adding a middleware layer to manage your backend directories better. Now that VDS has full support for SASL/GSSAPI connections, you can implement this functionality into your Active Directory environment without impacting on your existing infrastructure. Commonly used applications can interact with VDS as if it were an Active Directory instance itself, even if VDS is performing some complex processing to merge data from repositories that do not function in the same way as Active Directory itself. 1.3.3 Better Security and Access Control By using Kerberos authentication, you can control who is capable of using the VDS service from within your usual authentication infrastructure. By controlling which users are registered to have access to the VDS service, you can ensure that users are first authenticated properly before accessing data that you may wish to limit access to. Symlabs Guide To SASL, GSSAPI And Kerberos 7

1.3. COMMON USAGE SCENARIOS Furthermore, VDS will function within a kerberos enabled SSO environment. This means that as long as your users have authenticated once, they will be able to connect to VDS using the tickets that they are allocated by your KDC. Symlabs Guide To SASL, GSSAPI And Kerberos 8

Chapter 2 Using VDS for Kerberos LDAP In this chapter we will discuss Kerberos configuration in VDS with an example, in which we will set up an instance to function as a SASL/GSSAPI enabled pass-thru proxy. This will allow the configured proxy instance to accept SASL/GSSAPI requests on its Listener interface and then to access a backend Active Directory instance via SASL/GSSAPI through its servergroup interface. While this example will illustrate one configuration type, it is possible to use the proxy to translate requests that are authenticated using SIMPLE BIND to SASL enabled requests, and vice versa. This means that you can use the VDS to fully integrate non-sasl capable applications into a Kerberos enabled environment, such as that provided by Active Directory. The following basic settings have been chosen for the example: Domain: MYDOMAIN.COM AD machine: master.mydomain.com VDS machine: vds.mydomain.com It is important that you understand that in this example, Active Directory is being used in two roles. Firstly, Active Directory will act as the KDC for all Kerberos authentication and ticket issuing. This means that when a client wishes to access the VDS instance, the client will first need to authenticate with Active Directory. Active Directory will then issue a service ticket to the client, and the client will be able to present this ticket to VDS for validation. However, Active Directory is also acting in a second role, in that it is providing an LDAP service. In this role, Active Directory becomes a backend server accessed by VDS, and possibly inaccessible directly to the client application. The architecture of the solution may be more apparent in the following illustration. 2.1 Configuring DSGUI To configure the VDS instance so that it is ready to receive and issue SASL/GSSAPI LDAP operations, we will use the DSGUI configurator and set up an instance to act as a pass-thru proxy with SASL enabled on both the frontend Listener interface and the backend ServerGroup interface. Open DSGUI and create a new local configuration. 9

2.1. CONFIGURING DSGUI Figure 2.1: Example architecture, illustrating the different roles that Active Directory will play in the solution Create a new Automatic ServerGroup under the Output part of your configuration. Provide the hostname or IP address of the Active Directory instance that you are connecting to, and set the port number to 389, or whichever port your Active Directory instance is accepting LDAP requests. Click on the SASL tab and check the SASL Enabled checkbox. For now, you can use the default options. Figure 2.2: The SASL Tab in the ServerGroup Configuration Click on the Connection Pooling tab and check the Use Connection Pooling option. Select the SASL radio-button. The username and password credentials are not needed as the credentials available in the environment will be used instead. Symlabs Guide To SASL, GSSAPI And Kerberos 10

2.1. CONFIGURING DSGUI Figure 2.3: The Connection Pooling Tab in the ServerGroup Configuration Create a new Listener under the Input section of the configuration. Set any other parameters, such as the port number that you wish the Listener to function on, and set the Default Server- Group to the ServerGroup that you have just created. Under the SASL tab, check the SASL Enabled checkbox. For now, you can use the default settings provided for the remaining options. Figure 2.4: The SASL Tab on a Listener With these settings in place, your configuration is ready to work with your SASL enabled Active Directory instance and your SASL enabled client applications. 2.1.1 Additional Configuration Options There are a number of other SASL related configuration options available to you that do not need any modification at this point, but which we will discuss here for the sake of completeness. Global Parameters There are some global parameters relevant to the implementation and support of SASL within the VDS product. These options may be of some use when resolving SASL related problems with the Symlabs Support Team. The following options are available under the SASL section of the Global Parameters configuration within DSGUI. Symlabs Guide To SASL, GSSAPI And Kerberos 11

2.1. CONFIGURING DSGUI SASL Library If the Use Default SASL Values checkbox is set, this setting will expect that the Kerberos GSSAPI library for your operating system is available in the default paths: For linux systems, /usr/lib/libgssapi_krb5.so will be used; while for Windows systems, it will be../../lib/symgss.dll. If you are using an alternate implementation, or the library is in other path, you may need to specify the path to the external SASL/GSSAPI Library that should be used for Kerberos processing. VDS requires that Kerberos library files are available on your operating system in order to function correctly. In Windows systems VDS brings a Kerberos DLL implementation by default (symgss.dll). We recommend that you install MIT s Kerberos libraries if you are using a Linux or Unix variant. SASL Prefix This setting does not need to be edited either since it comes set by default (empty). It would only need to be configured if a different SASL library is used and its GSSAPI functions have some kind of prefix in their names. Debug Level for automatic Server Groups This debug level will help you debug issues with SASL connections as it sets the log level for all I/O management related to automatic servergroups. Figure 2.5: The Global Parameters SASL configuration options Listener SASL Parameters In our configuration example, we suggested that the SASL parameters available for the Listener be left at their default settings. In this section we will describe the options here in more detail. When a SASL bind is completed, one important parameter is obtained. It is the Client Name, which is the Principal that sent the operation as client: This information is stored in the BIND_DN entry of subsequent pdus to allow access control. SASL Mechanism This will be used in future to choose a different SASL Mechanism such as DIGEST-MD5. Currently only GSSAPI is supported Confidentiality Mode With this setting it is possible to specify the mode in which the confidentiality of the communication will be handled. There are three values to choose from: Negotiate: Either Integrity or Privacy will be accepted. This is the default setting. Integrity: Only Integrity will be offered and accepted. Privacy: Only Privacy will be offered and accepted. Symlabs Guide To SASL, GSSAPI And Kerberos 12

2.1. CONFIGURING DSGUI Acquire client delegated credentials With this option selected, whenever an incoming SASL connection is processed, VDS will try to obtain delegated SASL credentials sent by the client. These credentials are stored in the session and can be used later to open a SASL connection to the backend (provided the Enable client delegation option is active) ServerGroup SASL Parameters In our configuration example, we suggested that the SASL parameters available for the ServerGroup be left at their default settings. In this section we will describe the options here in more detail. SASL Mechanism This will be used in future to choose a different SASL Mechanism such as MD5. Currently only GSSAPI is supported Confidentiality Mode Similar to the confidentiality mode option for a SASL Enabled listener, this option specifies the mode in which the confidentiality of the communication will be handled towards the servergroup. There are three possible values to choose from: Negotiate: Both Integrity and Privacy are acceptable, but Privacy is preferred. This is the default option. Integrity: Only Integrity will be used and the communication will not be established if not possible. Privacy: Only Privacy will be used and the communication will not be established if not possible. Enable client delegation In configurations without connection pooling, if the client sent credentials for delegation it is possible to use them to open connections to the backend. In order to do this, this option must be checked, as well as Acquire client delegated credentials in the corresponding listener Enable constrained delegation This setting activates an alternative delegation method that makes use of the S4U protocol extensions to achieve delegation. The main difference is that in this case, the client does not need to forward its credentials for delegation to happen. When both delegation methods are active, the former one (client delegation) takes precedence ServerGroup Server Parameters On the Servers tab of the ServerGroup configuration panel, there is now an additional column that will allow you to specify an SPN entry for each server in the ServerGroup. Servers/SPN The optional SPN column of the Server entries allows the specification of the ServicePrincipalName for which tickets will be requested when initiating a security context with the backend. This field will usually be left empty as the default ldap@host SPN will be used. An example SPN entry for the Active Directory server used in the example configuration discussed in this document, would look like this: ldap@master.mydomain.com Symlabs Guide To SASL, GSSAPI And Kerberos 13

2.2. KERBEROS ENVIRONMENT CONFIGURATION Figure 2.6: The ServerGroup Server Parameters 2.2 Kerberos Environment Configuration The set up depends on the operating system where VDS is running. When in Windows, the integration is much simpler since the GSSAPI library included in VDS uses native SSPI calls. In Linux, integration is possible via an external GSSAPI library such as the MIT kerberos library, which needs some additional set up steps. In both environments it is necessary to assign the LDAP service we are setting up to the account object (user or computer) that the service instance uses to log on. This is done by registering the SPN that uniquely identifies the service to the account (ldap/vds.mydomain.com). It s important to make sure that this SPN has not been assigned before to any other user or computer, or the ticket generation will not work later. 2.2.1 VDS Running in Windows In principle, the account under which the SPN must be registered is the computer object where VDS is located, since the configuration instances are registered to run as Local System Account. You can use the setspn.exe tool available in the "Support Tools" package to perform this registration: setspn -A ldap/vds.mydomain.com VDS Check it succeeded with: setspn -L VDS Registered ServicePrincipalNames for CN=VDS,CN=Computers,DC=mydomain,DC=com: ldap/vds.mydomain.com HOST/VDS HOST/VDS.mydomain.com Other way to perform the registration is simply through an LDAP Modify operation, adding "serviceprincipalname: ldap/vds.mydomain.com" to the CN=VDS,CN=Computers,DC=mydomain,DC=com entry. Symlabs Guide To SASL, GSSAPI And Kerberos 14

2.2. KERBEROS ENVIRONMENT CONFIGURATION 2.2.2 VDS Running in Linux In this example, it is assumed that the MIT Kerberos packages have already been installed under Linux, as this is a requirement for the GSSAPI interface to work within VDS. Kerberos Configuration on Active Directory Active Directory supports Kerberos out-of-the-box, and provides a GSSAPI interface that VDS will be able to connect to using SASL, however you will still need to configure Active Directory to include a dedicated user that can be used by the VDS instance when it creates a connection pool. You will also need to create a keytab file to assign this user to the service that you want to allow access to. The keytab file will serve two purposes. Once installed on the VDS, it will be used to get a Ticket- Granting Ticket (TGT) that can be used by the VDS instance to establish a connection to the backend Active Directory server. Secondly, if enabling SASL on a Listener interface for VDS, the keytab file is required to handle Kerberos authentication. In order to create the keytab file, you will need to install the "Support Tools" package, available for Windows 2003 Server onward. This package includes the ktpass executable that you will require in the following steps. Please note that if you are using Windows 20084.2 you should read the section at the end of this guide. On the Active Directory instance, a user (e.g. "VDSLDAP") needs to be chosen or created so that it can be assigned to the service that VDS will be offering. You will need to specify a password (VDSLDAP_password) for the user, which you will use in the next step. Once you have created a user for the VDS service, you will need to create a keytab file that will assign the user to the service (SPN registration). To do this, from the command prompt run: ktpass -princ ldap/vds.mydomain.com@mydomain.com -mapuser VDSLDAP -pass VDSLDAP_password -ptype KRB5_NT_PRINCIPAL -out c:\krb5.keytab Note that if using Windows 2008, you will need to also specify the crypto switch for this command, as described in the Windows 20084.2 section at the end of this document. Finally, the keytab file has to be copied to the system that will run the VDS instance. The krb5.keytab file can be copied directly to /etc/krb5.keytab. You can copy the krb5.keytab file to any path and configure its location in your Kerberos configuration file. Kerberos Configuration for VDS VDS has been tested with the libraries provided by the MIT Kerberos implementation. This means that in Linux and most Unix systems you should install the MIT Kerberos packages, which should be available in your normal software package repositories. Alternately, you could build from the source files provided directly by MIT. Source files are available at http://web.mit.edu/kerberos/dist/index.html. To be able to use The S4U protocol extensions it is required that the MIT Kerberos version is at least 5.1.8. VDS has the potential to work with other libraries for different Kerberos implementations, however the MIT implementation has been thoroughly tested and the instructions provided here assume that you are making use of this particular implementation. Symlabs Guide To SASL, GSSAPI And Kerberos 15

2.2. KERBEROS ENVIRONMENT CONFIGURATION Kerberos Configuration File You will first need to configure some basic Kerberos settings, used mainly when the VDS instance is acting as client (for example, when accessing the AD user repository). These settings are also used by the kinit command (see kinit2.2.2), which you will use later. The settings are configured within the krb5.conf file, which is usually located in the /etc directory by default. Sample content: [libdefaults] default_realm = MYDOMAIN.COM default_keytab_name = /etc/krb5.keytab [realms] MYDOMAIN.COM = { kdc = master.mydomain.com admin_server = master.mydomain.com } [domain_realm].mydomain.com = MYDOMAIN.COM default_keytab_name: Path and filename of the keytab file (see krb5.keytab2.2.2). This setting is not needed for the default location (/etc/krb5.keytab). The keytab file is only required if you are configuring SASL on a frontend Listener interface on VDS, although it can be useful in conjunction with the kinit command to obtain a TGT when authenticating against a backend ServerGroup that uses Kerberos. kdc: Kerberos Domain Controller The sample file provided above will work for the configuration that we are discussing in this example. Naturally you may need to change particular settings to suit your own environment. krb5.keytab This file stores the keys used by a service (in this case, the LDAP service hosted by VDS) to decrypt and be able to process incoming kerberos service requests. You will have generated this file on the Active Directory server that VDS will be accessing (see Kerberos Configuration on Active Directory2.2.2). The keytab file is only required if you are configuring SASL on a frontend Listener interface on VDS, although it can be useful in conjunction with the kinit command to obtain a TGT when authenticating against a backend ServerGroup that uses Kerberos. Its default location is in the etc directory, but a different one can be specified in the Kerberos Configuration File (see krb5.conf2.2.2) Its contents can be listed with the klist -k command: Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 ldap/vds.mydomain.com@mydomain.com Symlabs Guide To SASL, GSSAPI And Kerberos 16

2.3. DELEGATION It is important to understand that this file is essentially equivalent to a password file and should be treated with the same security considerations. A safe rule of thumb is that they should be stored so that the user has no read or write access to them, and Read and Write privileges should be exclusive to root. kinit This command creates a Kerberos session by authenticating as a certain user to the Active Directory server in this example. It stores the resulting Kerberos ticket in a file called "Credentials Cache". The kinit command is only required for authenticating VDS to a backend ServerGroup that makes use of Kerberos, you do not need to use it if only implementing SASL on a frontend Listener interface. The kinit command can be run to authenticate as any user: kinit VDSLDAP@MYDOMAIN.COM or, kinit VDSLDAP or, if logged in as VDSLDAP, kinit Note, that kinit will prompt you for the password of the user that you are authenticating as. You will need to enter this correctly in order for the Kerberos session to be authenticated. It is possible to avoid the password prompt by relying on the key stored in the keytab file. To do this, issue the command: kinit -k ldap/vds.mydomain.com@mydomain.com The contents of the Credentials Cache can be viewed with the klist command and will look something like this: Ticket cache: API:krb5cc Default principal: VDSLDAP@MYDOMAIN.COM Valid starting Expires Service principal 09/21/09 14:29:12 09/22/09 00:28:40 krbtgt/mydomain.com@mydomain.com renew until 09/22/09 00:29:12 Symlabs Guide To SASL, GSSAPI And Kerberos 17

2.3. DELEGATION Figure 2.7: Without delegation, a connection pool is set up and a different set of credentials is used on the backend. 2.3 Delegation 2.3.1 Overview Earlier in this guide, we explained how to set up SASL backends using connection pooling. This working mode implies that when VDS goes to the backend to perform any operation, it will always use the credentials that it has available in its Kerberos context. The backend will therefore enforce its access control based on these credentials, which will typically be those of a super user. The access control towards the client, if needed, is left as something that VDS can handle by itself in a separate layer of functionality. VDS supports a different working mode that is called "Delegation". Delegation means that when VDS is opening a connection to the backend, instead of using context credentials available by external means as before, it reuses the credentials that the client application sends when opening a connection to VDS. Figure 2.8: With delegation, the connection credentials used on the listener are used to open a separate connection to the backend. For this to happen the Kerberos ticket in the client s context must be forwardable, and also the client application has to initialize the security context towards VDS with the Delegation flag set (which is not a common thing). These potentially cumbersome requirements can be avoided by taking advantage of the S4U (Services for User) Kerberos extensions to achieve Constrained Delegation. It is discussed in more detail later in this document, in the section titled The S4U Kerberos Protocol Extension2.4. 2.3.2 Configuration The way to configure Delegation is simple: In Active Directory, the user or computer associated with VDS (CN=VDS,CN=Computers,DC=mydomain,DC=com in Windows or VDSLDAP in Linux) Symlabs Guide To SASL, GSSAPI And Kerberos 18

2.3. DELEGATION needs to be allowed to perform Delegation. By opening the properties of this entry in Active Directory Users and Computers (ADUC) and going to the Delegation tab, you will be able to select "Trust this computer for delegation to any service (Kerberos only)" to enable this feature. You may need to raise the domain functional level to "Windows Server 2003" if the Delegation tab is not present. Figure 2.9: Delegation Properties of an entry in ADUC In the Listener panel of the GUI, the "SASL Enabled" setting must be on, as well as "Acquire client delegated credentials". In the ServerGroup panel of the GUI, the "SASL Enabled" setting must be on, as well as "Enable client delegation". Additionally, the "Use Connection Pooling" checkbox must be disabled. VDS will automatically use the delegated credentials if available. Symlabs Guide To SASL, GSSAPI And Kerberos 19

2.4. THE S4U KERBEROS PROTOCOL EXTENSION 2.4 The S4U Kerberos Protocol Extension 2.4.1 Overview Microsoft has developed two extensions to their implementation of the Kerberos protocol 1 : S4U2Self Enables a service to acquire a ticket from an arbitrary principal to itself S4U2Proxy Enables a service to use a client s ticket to itself to request another ticket for delegation Together, these extensions are referred to as Services4User, or S4U, and ultimately allow Symlabs VDS to achieve kerberos delegation without obtaining a user s TGT at the Listener. By combining these two extensions, VDS can acquire credentials to act on behalf of a user without any requirement to forward the client s TGT. This makes it significantly easier to configure delegation. For VDS instances running on Unix or Linux systems, the S4U protocol extension has been incorporated into MIT Kerberos from version 1.8. 2. In Windows, the symgss.dll library delivered with the product provides this functionality as well. 2.4.2 Configuration The way to configure Constrained Delegation is simple: In Active Directory, the user or computer associated with VDS (CN=VDS,CN=Computers,DC=mydomain,DC=com in Windows or VDSLDAP in Linux) needs to be allowed to perform Constrained Delegation. By opening the properties of this entry in Active Directory Users and Computers (ADUC) and going to the Delegation tab, you will be able to select "Trust this computer for delegation to specified services only" to enable this feature. You may need to raise the domain functional level to "Windows Server 2003" if the Delegation tab is not present. Then select "Use any authentication protocol" and add the description of the backend service: - Service Type: ldap - User or Computer: master.mydomain.com In the Listener panel of the GUI, the "SASL Enabled" setting must be on. In the ServerGroup panel of the GUI, the "SASL Enabled" setting must be on, as well as "Enable constrained delegation". The "Use Connection Pooling" checkbox must be disabled. One thing to keep in mind is that if the former client delegation is active and available it will take precedence, so to make sure constrained delegation is used, the "Enable client delegation" setting should be unselected. VDS will automatically use the constrained delegated credentials if available. 1 These extensions are well documented at http://msdn.microsoft.com/en-us/library/cc246071(v=prot.13).aspx 2 Further documentation can be found at http://k5wiki.kerberos.org/wiki/projects/services4user Symlabs Guide To SASL, GSSAPI And Kerberos 20

2.4. THE S4U KERBEROS PROTOCOL EXTENSION Alternately, the impersonation feature provided by the S4U extension allows VDS to set up connection pools that can send operations to the backend as any user. If the "Use Connection Pooling" checkbox is enabled, the "SASL Impersonation" connection pool type can be selected and VDS will try to obtain credentials for the user name chosen in the "Bind DN" field when establishing the pools. Symlabs Guide To SASL, GSSAPI And Kerberos 21

Chapter 3 Using VDS for Kerberos HTTP Until now this document has been referring to the GSSAPI/Kerberos support in the context of LDAP protocol. But Kerberos is also supported in HTTP protocol to a certain extent. The main benefit of this authentication method is obtained in Active Directory environments, and is known as "Integrated Windows Authentication" (IWA). By using a Kerberos-enabled HTTP client such as Internet Explorer, the user can achieve a Single-Sign-On experience since he will be able to login at all the Kerberos-enabled services available in his environment, not needing to provide his username and password every time: The authentication is carried out behind the scenes by an exchange of Kerberos tokens that are made available to the user session when he logs in. VDS working as an HTTP server can be easily configured to perform Kerberos authentication. This has many benefits including a significant reduction of complexity both for users and administrators: Users do not need to remember more account names and passwords or reenter credentials, and administrators only need to worry about Active Directory. Furthermore, since it is able to run in platforms other than Windows, it can provide cross-platform authentication extending these benefits to non-windows services. In this chapter we will discuss step by step the typical set up of this scenario, from a practical point of view. 3.1 Overview 3.1.1 Kerberos in LDAP versus Kerberos in HTTP Most of the concepts described for LDAP in this guide apply as well for HTTP. The service is different but the Kerberos protocol operations, environment configuration and terminology remains the same. The main difference is that while in LDAP Kerberos is used in a SASL context, which besides authentication takes care of the securing of the exchanged data, in HTTP Kerberos is used only for authentication and the data is transferred the same way as in non-authenticated connections. This means that for the HTTP communication to be encrypted you need to rely on other methods such as SSL / HTTPS. A second difference between Kerberos Support for LDAP and Kerberos Support for HTTP is that under HTTP, Kerberos is only implemented on the server-side. This means that in a VDS instance, you will only ever configure Kerberos on the Input / Listener for an HTTP implementation. Within an HTTP 22

3.2. CONFIGURING DSGUI Kerberos deployment, there is no requirement for the VDS instance to establish a connection to the server or to obtain any tickets (in Linux kinit is not needed anymore). 3.1.2 Conceptual Background With all this in mind, the introduction to GSSAPI and Kerberos provided in chapter one of this guide equally applies to the HTTP protocol. In this case, when a Kerberos-enabled client application (a web browser, typically Internet Explorer) tries to access a HTTP server, it will first request a service ticket from the KDC (Active Directory). When this ticket is obtained and presented to the server, it will be able to authenticate the user. Just as in the LDAP implementation, where the client application requests a ticket for the service ldap/vds.mydomain.com@mydomain.com; in the HTTP implementation, the client will request a ticket for the service HTTP/vds.mydomain.com@MYDOMAIN.COM. For the ticket generation to work, the HTTP service must have been registered previously. 3.2 Configuring DSGUI To configure the VDS instance so that it is ready to authenticate incoming HTTP operations using SPNEGO/Kerberos, we will use the DSGUI configurator. 1. Open DSGUI and create a new local configuration. 2. Create a new Listener under the Input section of the configuration. 3. Choose HTTP as protocol and set any other parameters, such as the port number that you wish the Listener to function on (the default HTTP port is 80). 4. Under the SPNEGO tab, check the "Require Kerberos Authentication" checkbox. If this flag is set, all incoming HTTP operations received at the Listener that do not have valid Negotiate credentials will be rejected with a request for authentication. Figure 3.1: The SPNEGO Tab on a HTTP Listener With these settings in place, your configuration is ready to work with Kerberos enabled client applications (web browsers). 3.2.1 Additional Configuration Options There are a number of other related configuration options available to you that do not need any modification at this point, but which we will discuss here for the sake of completeness. Symlabs Guide To SASL, GSSAPI And Kerberos 23

3.3. KERBEROS ENVIRONMENT CONFIGURATION Global Parameters You can review the section about Global Parameters2.1.1 in LDAP, since those configuration settings apply in the same way to HTTP and are shared between the implementation of two protobols. Listener SPNEGO Parameters No other configuration parameters for SPNEGO in HTTP are currently defined. 3.3 Kerberos Environment Configuration The set up depends on the operating system where VDS is running. When in Windows, the integration is much simpler since the GSSAPI library included in VDS uses native SSPI calls. In Linux, integration is possible via an external GSSAPI library such as the MIT kerberos library, which needs some additional set up steps. In both environments it is necessary to assign the HTTP service we are setting up to the account object (user or computer) that the service instance uses to log on. This is done by registering the SPN that uniquely identifies the service to the account (HTTP/vds.mydomain.com). It is important to make sure that this SPN has not been assigned before to any other user or computer, or the ticket generation will not work later. 3.3.1 VDS Running in Windows In principle, the account under which the SPN must be registered is the computer object where VDS is located, since the configuration instances are registered to run as Local System Account. You can use the setspn.exe tool available in the "Support Tools" package to perform this registration: setspn -A HTTP/vds.mydomain.com VDS Check it succeeded with: setspn -L VDS Registered ServicePrincipalNames for CN=VDS,CN=Computers,DC=mydomain,DC=com: HTTP/vds.mydomain.com HOST/VDS HOST/VDS.mydomain.com Alternatively, registration can be performed by simply submitting an LDAP Modify operation, adding "serviceprincipalname: HTTP/vds.mydomain.com" to the CN=VDS,CN=Computers,DC=mydomain,DC=com entry. Symlabs Guide To SASL, GSSAPI And Kerberos 24

3.3. KERBEROS ENVIRONMENT CONFIGURATION 3.3.2 VDS Running in Linux In this example, it is assumed that the MIT Kerberos packages have already been installed under Linux, as this is a requirement for the GSSAPI interface to work within VDS. Kerberos Configuration On Active Directory You will need to configure Active Directory to include a dedicated user to assign the HTTP service to and to create a keytab file. In HTTP the keytab file will only serve one purpose: to handle Kerberos authentication. It is used when validating the credentials provided by the client application. In order to create the keytab file, you will need to install the "Support Tools" package, available for Windows 2003 Server onward. This package includes the ktpass executable that you will require in the following steps. On the Active Directory instance, a user (e.g. "VDSHTTP") needs to be chosen or created so that it can be assigned to the HTTP service that VDS will be offering. You will need to specify a password (VDSHTTP_password) for the user, which you will use in the next step. Once you have created a user for the VDS service, you will need to create a keytab file that will assign the user to the service (SPN registration). To do this, from the command prompt run: ktpass -princ HTTP/vds.mydomain.com@MYDOMAIN.COM -mapuser VDSHTTP -pass VDSHTTP_password -ptype KRB5_NT_PRINCIPAL -out c:\krb5.keytab Finally, the keytab file has to be copied to the system that will run the VDS instance. The krb5.keytab file can be copied directly to /etc/krb5.keytab. You can copy the krb5.keytab file to any path and configure its location in your Kerberos configuration file. Kerberos Configuration for VDS VDS has been tested with the libraries provided by the MIT Kerberos implementation. This means that in Linux and most Unix systems you should install the MIT Kerberos packages, which should be available in your normal software package repositories. Alternately, you could build from the source files provided directly by MIT. Source files are available at http://web.mit.edu/kerberos/dist/index.html. VDS has the potential to work with other libraries for different Kerberos implementations, however the MIT implementation has been thoroughly tested and the instructions provided here assume that you are making use of this particular implementation. Kerberos Configuration File This file, which by default is /etc/krb5.conf, is only relevant to the HTTP scenario due to the default_keytab_name parameter, which sets the location (path and filename) of the krb5.keytab file. This field does not even need to be configured if the keytab is placed in the default location (/etc/krb5.keytab) so it is even possible to function without this configuration file. Sample content: Symlabs Guide To SASL, GSSAPI And Kerberos 25

3.4. KERBEROS CONFIGURATION ON CLIENT [libdefaults] default_keytab_name = /var/tmp/krb5.keytab krb5.keytab This file stores the keys used by a service (in this case, the HTTP service hosted by VDS) to decrypt and be able to process incoming kerberos service requests. You will have generated this file on the Active Directory server (see Kerberos Configuration on Active Directory3.3.2). Its filename and path can be configured in the Kerberos configuration file. Its contents can be listed with the klist -k command: Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 HTTP/vds.mydomain.com@MYDOMAIN.COM It is important to understand that this file is essentially equivalent to a password file and should be treated with the same security considerations. A safe rule of thumb is that they should be stored so that the user has no read or write access to them, and Read and Write privileges should be exclusive to the System Administrator. 3.4 Kerberos Configuration On Client When talking about clients in HTTP, the usual case is a web browser. 3.4.1 Internet Explorer In the Integrated Windows Authentication scenario the default client is Internet Explorer. This web browser has built-in Kerberos capabilities, so the set up needed to enable it is quite simple: You only need to add the hostname of the machine where VDS is running to the local intranet: Add "*.mycompany.com" in Tools -> Internet Options -> Security -> Local Intranet -> Sites For more information please refer to the "Client Side-Internet Explorer" section of http://msdn.microsoft.com/en-us/library/ms995329.aspx 3.4.2 Firefox It is also possible to use Firefox as client, even in Linux. Similarly to Internet Explorer, it is required as well that the hostname (or suffix) of the VDS server is added to the trusted uris list: 1. Open "about:config" in Firefox 2. Edit "network.negotiate-auth.trusted-uris" 3. Add "mycompany.com" (multiple values are comma separated) When running in Linux, you will need to perform a kinit to obtain Kerberos credentials as a step prior to accessing the HTTP service located at the VDS instance. The Firefox process has to run as the same user, so that it is able to access the Kerberos credentials when going to the server. Symlabs Guide To SASL, GSSAPI And Kerberos 26

3.5. HTTP CONFIGURATION FOR VDS 3.4.3 Google Chrome Another valid client is Google Chrome. In this case the hostname (or suffix) of the VDS server is added when starting the browser: google-chrome --auth-server-whitelist="*mycompany.com" Same as with Firefox when running in Linux, you will need to perform a kinit as the same user to obtain Kerberos credentials as a step prior to accessing the HTTP service located at the VDS instance. For more information please refer to the following web page: http://www.chromium.org/developers/design-documents/http-authentication 3.5 HTTP Configuration for VDS At this point all the Kerberos setup is in place and the VDS instance is prepared to authenticate clients based on the Kerberos credentials exchanged. However if the configuration was created from scratch, it will be missing all the HTTP-specifics: What web pages are served when the instance is accessed. When a SPNEGO/Kerberos authentication completed, one important parameter is obtained. It is the Client Name, which is the Principal that sent the operation as client: This information is stored in the CLNAME entry of the pdu to allow access control at a latter stage. You can use the following function in a manual stage for testing and as an example to illustrate how to use the client name in a script: #define _CLNAME_ "\0CLNAME\0" function return_page (pdu) { content = "<html><body>logged in as: ${pdu{_clname_}}</body></html>"; ds_http_response(hash[_header_ => hash [ CONTENT-TYPE => text/html ], _CONTENT_ => content]); return PDU_DONE; } With that functionality active at a hook for HTTP Get requests, by browsing to the http://vds.mycompany.com URL, you will be authenticated and see a message such as "Logged in as: User@MYCOMPANY.COM". Symlabs Guide To SASL, GSSAPI And Kerberos 27

Chapter 4 Additional Notes In this chapter we discuss some issues that may be relevant when working with MIT s Kerberos libraries. Since the Windows version of VDS delivers a custom GSSAPI library developed by Symlabs, in principle these sections will not apply when running in this platform. 4.1 Kerberos For Windows As explained before, in Windows there is no need to install external libraries as in Linux. Still, as most GSSAPI calls are standard, it is perfectly valid to replace this library with other implementations such as MIT s Kerberos For Windows (which was recommended in older versions of VDS). In this case, all the configuration steps discussed for Linux related to keytab files and Kerberos Configuration File need to be performed as well. In Windows 2008 there are some additional issues that should be made clear for users of Windows Server 2008, that may be useful when trying to set up GSSAPI connectivity. 4.1.1 Kerberos Environment Configuration Kerberos Configuration File In Windows the name of the configuration file is krb5.ini, which is usually located in the C:\WINDOWS directory. You will first need to configure some basic Kerberos settings, used mainly when the VDS instance is acting as client (for example, when accessing the AD user repository). These settings are also used by the kinit command (see kinit4.1.1), which you might use later. Sample content: [libdefaults] default_realm = MYDOMAIN.COM default_keytab_name = C:\WINDOWS\krb5.keytab [realms] MYDOMAIN.COM = { kdc = master.mydomain.com admin_server = master.mydomain.com 28

4.1. KERBEROS FOR WINDOWS } [domain_realm].mydomain.com = MYDOMAIN.COM default_keytab_name: Path and filename of the krb5.keytab4.1.1 file. The keytab file is only required if you are configuring SASL on a frontend Listener interface on VDS, although it can be useful in conjunction with the kinit command to obtain a TGT when authenticating against a backend ServerGroup that uses Kerberos. kdc: Kerberos Domain Controller The sample file provided above will work for the configuration that we are discussing in this example. Naturally you may need to change particular settings to suit your own environment. krb5.keytab This file stores the keys used by a service (in this case, the ldap service hosted by VDS) to decrypt and be able to process incoming kerberos service requests. You will have generated this file on the Active Directory server that VDS will be accessing (see Kerberos Configuration on Active Directory2.2.2). This file is required if using SASL on the Listener interface of VDS, and is useful for obtaining a TGT if using SASL to interface with a backend ServerGroup. Its filename and path can be configured in the krb5.ini file (see krb5.ini4.1.1) Its contents can be listed with the klist -k command: Keytab name: FILE:C:\WINDOWS\krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 ldap/vds.mydomain.com@mydomain.com It is important to understand that this file is essentially equivalent to a password file and should be treated with the same security considerations. A safe rule of thumb is that they should be stored so that the user has no read or write access to them, and Read and Write privileges should be exclusive to the System Administrator. kinit This command creates a Kerberos session by authenticating as a certain user to the Active Directory server in this example. It stores the resulting Kerberos ticket in a file called "Credentials Cache". The kinit command is only required for authenticating VDS to a backend ServerGroup that makes use of Kerberos, you do not need to use it if only implementing SASL on a frontend Listener interface. Furthermore, kinit is not needed in principle on 32-bit Windows platforms, as the Kerberos library is able to access the Local System Account credentials (that is, the tickets that are automatically obtained just by logging on to the computer in the domain). For this to happen, the domain must have been properly set up in the krb5.ini file, especially the default_realm parameter. Under these conditions, the connection pools will be fully established when the instance is started, not requiring any extra steps. Symlabs Guide To SASL, GSSAPI And Kerberos 29

4.1. KERBEROS FOR WINDOWS But in 64-bit environments there is a limitation that prevents this and the tickets have to be obtained using kinit. kinit can be run to authenticate as any user: kinit VDSLDAP@MYDOMAIN.COM or, kinit VDSLDAP or, if logged in as VDSLDAP, kinit Note, that kinit will prompt you for the password of the user that you are authenticating as. You will need to enter this correctly in order for the Kerberos session to be authenticated. It is possible to avoid the password prompt by relying on the key stored in the keytab file. To do this, issue the command: kinit -k ldap/vds.mydomain.com@mydomain.com The contents of the Credentials Cache can be viewed with the klist command and will look something like this: Ticket cache: API:krb5cc Default principal: VDSLDAP@MYDOMAIN.COM Valid starting Expires Service principal 09/21/09 14:29:12 09/22/09 00:28:40 krbtgt/mydomain.com@mydomain.com renew until 09/22/09 00:29:12 4.1.2 SASL Connection Pooling for Windows using kinit As explained before, kinit is not needed in principle on 32-bit Windows platforms, as the Kerberos library is able to access the Local System Account credentials. In 64-bit environments there is a limitation that prevents the Kerberos library from accessing the Local System Account credentials and the tickets have to be obtained using kinit. It is also possible to use kinit in 32-bit Windows systems, but it will not be needed normally. The preferred approach to setting up a SASL Connection Pool is to open the Kerberos connection to the Backend system prior to running the VDS instance. A way to share the Kerberos credentials between the user and the VDS instance, which will typically run as as Local System Account, is through a common credentials cache file. This can be set using the "KRB5CCNAME" environment variable: In this example, we chose "C:\cc" as the credentials cache file. Open the Control Panel and then open the System window. Click on the Advanced tab and then on the Environment Variables button. Symlabs Guide To SASL, GSSAPI And Kerberos 30

4.2. WINDOWS 2008 COMPATIBILITY WITH MIT KERBEROS TOOLS Figure 4.1: Set an environment variable to provide the path to your credentials cache file Under the System Variables panel, add a new entry with the variable name "KRB5CCNAME" and the value "C:\cc". Naturally the value should match the location of your credentials cache file. With this variable set, the MIT Kerberos commands such as kinit, klist and kdestroy will use this credentials cache file as default (if not, in all these commands you can specify the file location with the -c c:\cc parameter). Open a Command Prompt and perform a file-based kinit: kinit vdsuser Now you can start the configuration to ensure that it is working correctly. 4.2 Windows 2008 Compatibility with MIT Kerberos Tools What is said in the following sections about Windows 2008 applies to Windows 2008 R2 as well. 4.2.1 Fix Needed There is a bug in Windows 2008 s implementation of Kerberos that has been fixed with a Hotfix, now incorporated into Service Pack 2. This bug causes MIT Kerberos client connections to fail authentication Symlabs Guide To SASL, GSSAPI And Kerberos 31

4.3. HANDLING TICKET EXPIRY AND RENOVATION WITH KINIT with an error: "KERB5KDC_ERR_C_PRINICPAL_UNKNOWN". The problem occurs when ktpass, the Windows executable used to generate a keytab file, has been used to create a keytab file and this is used by an MIT Kerberos client. When the client requests a ticket-granting ticket (TGT) by specifying the host principal name as the client name, authentication fails and the error is returned. Since VDS makes use of the MIT Kerberos libraries, this will have affect its ability to use GSSAPI to connect to Windows 2008 backend systems. As a result, it is highly recommended that you either install the appropriate Hotfix, or you ensure that you have Service Pack 2 installed. For more information please refer to Microsoft s bug report on this at: http://support.microsoft.com/kb/951191 4.2.2 Encryption used by Windows 2008 Windows 2008 poses an issue regarding encryption when using MIT Kerberos libraries with VDS. The encryption type required when authenticating to the KDC is normally AES256, but the type obtained when generating keytabs with ktpass is by default RC4-HMAC. So if the keytab is meant to authenticate and use SASL/GSSAPI against the backend, it should be generated by specifying an additional crypto AES256-SHA1 option: ktpass -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -princ ldap/machine.mycompany.local@mycompany.local -mapuser VDSLDAP -pass VDSLDAP_password -out c:\krb5.keytab This will however make the keytab not usable to decode SASL/GSSAPI communications arriving at the frontend, since they will typically be encrypted using RC4-HMAC. The reason behind this is that the principal associated with the VDS service (via ktpass) will have its supported encryption types by default set to none. A solution is setting "This account supports Kerberos AES 256 bit encryption" in the Account tab of the user in ADUC. It is also possible to set this value manually (for instance with an ldapmodify command) by changing the value of the msds-supportedencryptiontypes attribute in the user entry to 0x10. If for some reason other encryption types are required, the ktpass command can be issued with the crypto ALL option instead (which results in a keytab with keys for all types), and the msds- SupportedEncryptionTypes value set to 0x1F (meaning all types supported). 4.3 Handling Ticket Expiry and Renovation with Kinit There are two kinds of Kerberos tickets: The Ticket Granting Ticket (TGT) and the Service Ticket. The Service Ticket is the one used by VDS to access the backend service (ldap). The TGT is used to obtain service tickets. Each has an expiration date of its own. VDS (through the GSSAPI library) takes care of the Service Ticket, obtaining one initially and getting a fresh one whenever it expires. However, for this to happen a valid TGT must be present in the environment or else the Service Ticket renewal will fail. The TGT management is handled externally (as explained before). Therefore, it is quite possible that a TGT ticket may expire and VDS will no longer be able to obtain renewed Service Tickets. In order to Symlabs Guide To SASL, GSSAPI And Kerberos 32

4.4. MERGING KEYTABS avoid this problem, Symlabs recommends that the task of obtaining new TGTs, before they expire, is handled by a periodic job that can be scheduled on your operating system. Note that since any automated system of running the kinit command will typically not be able to provide the password, you will need to run kinit command with the -k switch in order to force it to use the keytab file. TGTs typically have a lifetime of 10 hours. We suggest a period of 8 hours between renovations, which has the advantage that they will happen at the same times every day. You can check at any time the remaining validity with the klist command. Under Linux and Unix systems, this can be achieved by creating a cronjob by adding a line similar to the following to /etc/crontab: 0 */8 * * * root sys kinit -k ldap/vds.mydomain.com@mydomain.com On Windows systems, it is unlikely that you will need kinit in most environments. However, if you are using MIT s Kerberos For Windows library in a 64-bit environment, you may need to run kinit as a scheduled task. To do this, create a batch script with the kinit command: @echo off kinit -k ldap/vds.mydomain.com@mydomain.com Then go to Start -> Control Panel -> Scheduled Tasks -> Add Scheduled Task Browse and locate the batch script. Set "Perform this task" to "Every Day". Choose your start time and date. Choose the Username under which the task will run and provide its password. Mark the Advanced Properties edit and in "Schedule->Advanced" mark "Repeat Task / Every 8 hours / Duration 23 hours" 4.4 Merging Keytabs In some situations you may want to merge a number of keytabs that you have generated on different domain servers. This is particularly useful when you are using GSSAPI on the Listener interface of your VDS instance, to provide a cross-domain authentication facility. In this case, you will use the standard method to generate your keytab file on each Active Directory instance (i.e. KTPass.exe). When you copy the keytab file across to the system that you are running your VDS instance on, make sure that you name the file in a way that you will be able to recognize which server it belongs to (e.g. servername.keytab). When you have finished creating all of the keytab files that you wish to merge together, and you have stored them in a common location on the system that will be running VDS, you can run the ktutil application that comes with MIT Kerberos. ktutil invokes a subshell that allows you to specify a number of commands to read, write, or edit entries in a Kerberos V5 keytab. The commands that we are interested in are the the rkt command, which reads a keytab file and adds it to a keytab list, and the wkt command, which writes the current keytab list to a keytab file that can be used by Kerberos. Symlabs Guide To SASL, GSSAPI And Kerberos 33

4.5. REPLAY CACHE FILE # ktutil ktutil: rkt eng_http.keytab ktutil: rkt www_http.keytab ktutil: rkt sales_http.keytab ktutil: list slot KVNO Principal ------ ------ -------------------------------------- 1 1 HTTP/eng.example.com@EXAMPLE.COM 2 1 HTTP/sales.example.com@EXAMPLE.COM 3 1 HTTP/www.example.com@EXAMPLE.COM ktutil: wkt spnego.keytab ktutil: quit So, in the example above, we have run the ktutil command. This opens the ktutil subshell. We run the rkt command against each of the three keytab files that we have created on our individual domain systems. We use the list command to check that the service entries have been added for each of these keytabs. Finally, we use the wkt command to write the merged keytab to a file, which we have named spnego.keytab. This file can now be used by Kerberos to validate tickets presented by clients for any of these services. 4.5 Replay Cache File The MIT Kerberos library used in conjunction with VDS is able to detect replay attacks by storing the received message IDs in what is called a "replay cache file". By default, in Linux/Unix environments, this file is located at "/var/tmp/ldap_(uid)" and in Windows environments, at "C:\Documents And Settings\(user)\Local Settings\Temp\ldap". For Kerberos HTTP the behavior is just the same except for the file names being "http" instead of "ldap". The file options can be controlled with the following environment variables: - KRB5RCACHETYPE: The replay cache file can be deactivated if this variable is set to "none". Other valid value is "dfl" for default - KRB5RCACHEDIR: Sets the directory where the file is stored In most situations, you will not need to adjust these variables, but you may find it useful to know about them. Symlabs Guide To SASL, GSSAPI And Kerberos 34

Chapter 5 References MIT Kerberos: http://web.mit.edu/kerberos Microsoft Kerberos Authentication: http://www.microsoft.com/windowsserver2003/technologies/security/kerb Microsoft Kerberos Authentication Technical Reference: http://technet.microsoft.com/enus/library/cc739058(ws.10).aspx Simple Authentication and Security Layer (SASL) RFC 4422: http://tools.ietf.org/html/rfc4422 Kerberos V5 RFC 4120: http://tools.ietf.org/html/rfc4120:http://tools.ietf.org/html/rfc4120 Generic Security Service Application Program Interface Version 2, Update 1 RFC 2743: http://tools.ietf.org/html/rfc2743 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism RFC 4752: http://tools.ietf.org/html/rfc4752 35