8.4 Windows and Unix Interoperability

In the previous chapters, we focused mostly on the design and implementation of a homogenous Kerberos network. However, the true allure of moving to a Kerberos-based authentication scheme network-wide is to enable centralized authentication, and more importantly, single-sign-on across all platforms. Cross-platform single-sign-on is considered to be a panacea of network authentication, and even with Kerberos, can be very difficult to achieve because of the wide variation between Kerberos implementations. The end objective is for users to have only one set of credentials, a username/password pair that will enable them to access all network resources regardless of the platforms these services may reside on.

These interoperability scenarios are also addressed in a Microsoft document, the Step-by-Step Guide to Kerberos 5 Interoperability, available at http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp.

8.4.1 Using a Windows Domain Controller as a KDC for Unix Clients

Using a Windows domain controller as a KDC for non-Microsoft platforms is trivial to set up; as long as the users have DES keys enabled in Active Directory, they will be able to kinit to the Windows domain controller without a problem. The only difference is in administration; you'll be using MMC to create and modify Kerberos users in this case. Since Microsoft does not implement a kadmin interface similar to MIT or Heimdal's, creating keytabs for Unix services when using a Windows domain controller is a bit different than the process of generating keytabs from Unix KDCs.

8.4.1.1 Creating Unix keytabs from a Windows domain controller

When using a Windows domain controller as the KDC for a mixed platform Kerberos environment, a method is required to extract keys from the Windows KDC into keytab entries for Unix hosts and services. The kadmin programs that are included with the MIT and Heimdal Kerberos distributions do not work with Windows domain controllers since Microsoft uses its own administration protocol for communication with the KDC. Instead, Microsoft includes a program to create a keytab file with a specified password (run through the Kerberos 5 string2key function to create the appropriate DES key).

This program, ktpass, is not installed by default. If your domain controller does not have a ktpass program installed, it can be found in the support/tool subdirectory of the Windows 2000 Server installation CD.

First, a user account for the service must be created in the Active Directory. Since Active Directory does not handle Kerberos-style username and instance principal formats, this username cannot be the desired principal name (as Windows does not allow the "/ " character in usernames, along with most other special characters). Instead, this name can be any valid Windows username, and will be mapped to the principal name later. It is recommended that these accounts be placed in a separate OU to distinguish them from other user accounts in the domain.

For example, for the host principal host/unix.wedgie.org@W2K.WEDGIE.ORG, an AD account named unixhost is created in the Unix services Organizational Unit. Figure 8-3 shows the new user wizard for this principal.

Figure 8-3. Creating a new user for a Unix service principal in Active Directory

Ensure that the password can never change on this user account by selecting the "Password never expires" and "User cannot change password" options on the next screen of the wizard.

After the user account for the Unix service has been created, the ktpass program will handle the tasks of producing the appropriate mapping between username and principal name in the Active Directory database, setting the user to accept DES encryption types, and creating a keytab file that can be imported into the Unix host's keytab. The ktpass program accepts the /? argument to get help on its parameters, and the most commonly used parameters are listed below:

Table 8-1. Common ktpass parameters

Parameter	Arguments	Description
-out	Filename of keytab	Designates the file the new keytab will be written to.
-princ	Kerberos principal name	Designates the principal name of the service that this keytab is for.
-pass	Password or "*" to prompt for password	The password associated with the username must be given, either as an argument to ktpass, or, if the argument to the pass parameter is "*", ktpass will prompt for the password on the console. This password must match the password for the username in AD; otherwise, ktpass will write out a keytab with the incorrect encryption key.
-mapuse	Username in AD	Designates that the username provided as an argument to this parameter is to be mapped to the Kerberos principal designated by the princ argument.

A keytab for the example host principal can be generated with ktpass through the following command:

D:\Documents and Settings\Administrator.DESKTOP.000>ktpass -out unixhost.keytab -princ
host/unix.wedgie.org@WEDGIE.ORG -pass * -mapuser unixhost
Successfully mapped host/unix.wedgie.org to unixhost.
Type the password for host/unix.wedgie.org:
Key created.
Output keytab to unixhost.keytab:

Keytab version: 0x502
keysize 59 host/unix.wedgie.org@W2K.WEDGIE.ORG ptype 1 (KRB5_NT_PRINCIPAL) vno 1 
etype 0x1 (DES-CBC-CRC) keylength 8 (0x973ec2ab52f48343)
Account has been set for DES-only encryption.

After generating a keytab entry with ktpass, it must be securely copied over to the Unix host and installed in the appropriate keytab file. This can be done either by copying the keytab onto a floppy and physically moving the file to the Unix host, or through another encrypted channel, such as Secure Shell.

8.4.2 Using a Non-Microsoft KDC for Windows Clients

This section describes the two methods by which a Windows network can authenticate against a non-Microsoft KDC. The first option, cross-realm trust between a Windows domain and a non-Microsoft KDC, is best used when there's an extensive network of Windows machines that requires centralized administration and already has a Windows domain established. The second option is best applied to networks that have few Windows machines that are not already members of a Windows domain. These scenarios are useful when a large, non-Microsoft Kerberos realm has been installed, and moving the users to a new Active Directory domain would be difficult.

Each user who will access the Windows box or domain must still be created either in the Active Directory (for the cross-realm trust option) or on the local Windows machine (for the standalone Windows machine option). This is done so that a SID is created for authorization purposes for users authenticated through the non-Microsoft Kerberos realm. Mappings will be set up in either case to associate principals in the Kerberos database with these Windows usernames. Windows will still require these users in the AD database or local security database to have valid passwords, and these passwords must be secure, as they can be used to bypass the non-Microsoft Kerberos realm and login directly to the Windows machine.

The interoperability presented here only functions for Windows services that use Kerberos authentication. There are several applications, notably Microsoft Exchange (2000 and below), that still use the older NTLM-style authentication that Windows provides. Since these applications do not use the Microsoft Kerberos implementation for authentication, there's no way to make them authenticate against a non-Microsoft source. The application has to be rewritten to use Kerberos authentication. In addition, as discussed earlier in the section on the PAC, some Windows services will not accept tickets that do not have a PAC generated by a Windows domain controller. Also, older Microsoft operating systems, released before Windows 2000, XP, and 2003, cannot participate in Kerberos realms, even if they are part of a Windows domain, as those older operating systems do not include Kerberos support. If compatibility with older Windows operating systems or applications that utilize NTLM authentication is required, the passwords in the Windows domain or local security database must be synchronized with the Kerberos realm through external means.

8.4.2.1 Cross-realm trust

If there is already an existing Windows domain, then a cross-realm trust between that domain and the Unix-based Kerberos realm is the best option for authenticating users against a non-Microsoft KDC. A cross-realm trust is established between the Windows domain and the non-Microsoft Kerberos realm, so that users who provide their Kerberos credentials are authorized for access to resources inside of the Windows domain. In addition, since the Windows domain still exists, the administration advantages, such as centralized administration, login scripts, and more that come with establishing a Windows domain still function.

Each Windows machine in the Windows domain participating in the cross-realm trust must have the appropriate values inserted into its registry. The ksetup tool (see the sidebar The Microsoft ksetup Tool) is a command-line utility that inserts the appropriate entries into the registry. Each KDC for the non-Windows domain must be specified with the ksetup tool:

D:\>ksetup /addkdc WEDGIE.ORG freebsd.wedgie.org

If your realm has more than one KDC, the command can be repeated with each KDC's DNS name. Define your non-Windows KDCs through ksetup on your domain controller as well. Each machine needs to be rebooted for the registry entries to take effect.

The Microsoft ksetup Tool The ksetup utility is a program that establishes a few entries in the Windows registry describing the non-Windows Kerberos realm and KDCs. The registry entries that ksetup modifies can be found in HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains, which can be compared to the /etc/krb5.conf file on an MIT or Heimdal Kerberos client host. Whenever a Windows machine participates in a non-Microsoft Kerberos realm, either through cross-realm trust with a Windows domain, or directly with the non-Microsoft KDCs, ksetup is used to create the appropriate configuration entries in the registry. Unfortunately, ksetup is not installed by default with Windows, but you can find a copy in the support\tool subdirectory of the Windows 2000 Server installation CD. Note that whenever any Kerberos settings are changed, either directly through the registry entry above or through the ksetup tool, the machine will need to be rebooted for the changes to take effect. The ksetup tool recognizes the following flags: /SetDomain This flag designates the non-Microsoft Kerberos realm that the Windows machine will be communicating with. /MapUser This flag creates a user mapping between usernames in the local Windows user database and principal names in the Kerberos realm. MapUser takes two parameters: the first parameter is a Kerberos principal name, and the second parameter is the local username on the Windows host that the principal will be authorized as. An asterisk can be used in either field to match all possible principal names and usernames, respectively. For example /MapUser * * will map all Kerberos principals with the corresponding username on the Windows machine or domain. /AddKdc This flag creates a mapping between Kerberos realm names and a KDC that serves the realm. This flag can be specified multiple times in different ksetup commands in order to select multiple KDCs per realm. /AddKpasswd This flag creates a mapping between a Kerberos realm and the master KDC that is used to change user passwords in the realm. /SetMachPassword This flag sets the password on the host key for the Windows machine. The required argument to this flag is the password associated with the Windows machine's host principal in the Unix KDC's database.

The next step is to establish the cross-realm trust between the Windows domain and the non-Microsoft Kerberos realm. A random password must be chosen for the cross-realm Ticket Granting Server key, and this password will have to be provided to kadmin on the Unix side, and Active Directory on the Windows side. On a Unix host, use kadmin to generate the cross-realm krbtgt keys.

For an example Windows domain of W2K.WEDGIE.ORG, and a Kerberos realm of WEDGIE.ORG, the krbtgt/W2K.WEDGIE.ORG@WEDGIE.ORG principal will have to be added to the WEDGIE.ORG realm to provide the one-way trust required for Windows users logging into the WEDGIE.ORG realm to gain access to Windows resources in the W2K domain. If you wish to create a two-way trust, then the principal for the opposite direction, krbtgt/WEDGIE.ORG@W2K.WEDGIE.ORG, will also have to be created. These principals can have different passwords associated with them. We'll create both principals here:

% kadmin
Authenticating as principal jgarman/admin@WEDGIE.ORG with password.
Enter password:
kadmin:  addprinc -e des:normal krbtgt/W2K.WEDGIE.ORG@WEDGIE.ORG
WARNING: no policy specified for krbtgt/W2K.WEDGIE.ORG@WEDGIE.ORG; defaulting to no policy
Enter password for principal "krbtgt/W2K.WEDGIE.ORG@WEDGIE.ORG": 
Re-enter password for principal "krbtgt/W2K.WEDGIE.ORG@WEDGIE.ORG": 
Principal "krbtgt/W2K.WEDGIE.ORG@WEDGIE.ORG" created.
kadmin:  addprinc -e des:normal krbtgt/WEDGIE.ORG@W2K.WEDGIE.ORG
WARNING: no policy specified for krbtgt/WEDGIE.ORG@W2K.WEDGIE.ORG; defaulting to no policy
Enter password for principal " krbtgt/WEDGIE.ORG@W2K.WEDGIE.ORG ": 
Re-enter password for principal " krbtgt/WEDGIE.ORG@W2K.WEDGIE.ORG ": 
Principal " krbtgt/WEDGIE.ORG@W2K.WEDGIE.ORG " created.

Now the trust has to be established on the Windows side. Log into an account with Domain Administrator privileges and open Active Directory Domains and Trusts. Right-click on the Windows domain in the left-hand tree view, and select Properties. Select the Trusts tab in the Properties dialog and click Add in "Domains trusted by this domain group" at the top. Your screen should look similar to Figure 8-4.

Figure 8-4. Establishing cross-realm trusts between Active Directory and a non-Microsoft Kerberos realm

In our example, the Windows domain is W2K.WEDGIE.ORG and the Unix-based Kerberos realm is WEDGIE.ORG. When setting the password under the "Domains trusted by this domain" on the Active Directory server, use the password associated with the krbtgt/W2K.WEDGIE.ORG@WEDGIE.ORG principal created above. Similarly, when setting the password under the "Domains that trust this domain," you must use the password associated with the krbtgt/WEDGIE.ORG@W2K.WEDGIE.ORG principal.

Enter the appropriate realm and password in the dialog box, and click OK. An error dialog, pictured in Figure 8-5, will appear.

Figure 8-5. Warning message generated when establishing a cross-realm trust between Active Directory and a non-Microsoft Kerberos realm

Click OK on this error dialog, and the realm will now appear in the top listbox. This process establishes the one-way trust from the non-Microsoft Kerberos realm to the Windows domain. If you want the trust to operate both ways, repeat the process by clicking the Add button in the Domains that trust this domain group, and ensure that both krbtgt principals were created in kadmin earlier.

Also, this trust can be marked as transitive; that is, child domain members can also authenticate against the non-Microsoft Kerberos realm.

D:\>netdom trust W2K.WEDGIE.ORG /Domain:WEDGIE.ORG /Transitive:yes

Finally, username mappings must be established between Kerberos principals in the non-Microsoft KDC and usernames that exist in the Windows Active Directory. This mapping forms an authorization relationship between a Kerberos principal in the non-Microsoft Kerberos realm and a user identity in the Microsoft Active Directory. The process is performed through the Active Directory Users and Computers tool. The following procedure is used to map a Kerberos principal to a Windows username:

Now, when the user logs in to Windows with the username and password associated with the Kerberos principal, and the non-Microsoft Kerberos realm showing in the "Log on to" drop-down box, the user is authorized as the selected Windows username in the Active Directory.

8.4.2.2 Standalone Windows machine

It is also possible to set up standalone Windows clients that are not part of a Windows domain to authenticate directly against a Unix-based KDC. For authorization purposes, user entries will still have to be created, only they'll be created in the local user database in this case, since there is no Windows domain involved. Then information describing the Kerberos realm and KDCs will be input into a Microsoft tool named ksetup, and finally, user mapping will be established between Kerberos principals and the local usernames on the Windows machine. The command-line parameters for ksetup are covered in the sidebar, The Microsoft ksetup Tool.

The first task when adding a standalone Windows machine to a Kerberos realm is to create a host key for the Windows machine on the KDC. The encryption type of this key must be single DES. In addition, since the key is set on the Windows host through a password specified on the command line, the administrator must generate a random password manually for this purpose.

For example, the following commands create a principal for the Windows host desktop.w2k.wedgie.org, using an MIT KDC:

> kadmin
Authenticating as principal jgarman/admin@WEDGIE.ORG with password.
Enter password:
kadmin:  addprinc -e des:normal host/desktop.w2k.wedgie.org@WEDGIE.ORG
WARNING: no policy specified for host/desktop.w2k.wedgie.org@WEDGIE.ORG; defaulting 
to no policy
Enter password for principal "host/desktop.w2k.wedgie.org@WEDGIE.ORG": 
Re-enter password for principal "host/desktop.w2k.wedgie.org@WEDGIE.ORG": 
Principal "host/desktop.w2k.wedgie.org@WEDGIE.ORG" created.

Now the information about the non-Windows Kerberos realm must be set up on the Windows host; this is accomplished through the ksetup utility. While Windows systems have no problems using DNS to find the appropriate Domain Controllers for Active Directory domains, they cannot use DNS to find the addresses of the KDCs for non-Windows Kerberos realms.

For our example, the following commands will have to be entered on the Windows host to create the appropriate configuration:

D:\>ksetup /setdomain WEDGIE.ORG
D:\>ksetup /addkdc WEDGIE.ORG freebsd.wedgie.org
D:\>ksetup /addkdc WEDGIE.ORG slave.wedgie.org
D:\>ksetup /addkpasswd WEDGIE.ORG freebsd.wedgie.org
D:\>ksetup /setmachpassword host principal's password

These commands create the configuration entries in the Windows host's registry for the WEDGIE.ORG Kerberos realm. The registry entries function similarly to the krb5.ini file used by MIT Kerberos to define the KDC information for Kerberos realms. In addition, the machine password set here must correspond to the host principal password set earlier in kadmin.

Next, mappings must be established between Kerberos principal names and local user names on the Windows host. These mappings are used for authorization purposes during the login process. The mappings are created with the ksetup tool's MapUser command-line argument.

The ksetup command can map a particular Kerberos principal to a given Windows username by explicitly specifying their identities in the mapuser command:

D:\>ksetup /mapuser fgump@WEDGIE.ORG guest

This command maps the Kerberos principal fgump@WEDGIE.ORG to the Windows username guest. As you can see, the principal name and Windows username do not have to match. A shortcut is available to map all Kerberos principals in a realm to the same-named counterpart in the Windows user database. This can be specified by using an asterisk for both parameters of the MapUser argument. For example:

D:\>ksetup /mapuser * *

If there is a Kerberos principal with a user component of fgump, and a Windows user named fgump, the mapping will authorize the user to login to the fgump Windows account via his Kerberos credentials in the non-Microsoft Kerberos realm.