Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

As mentioned earlier in this chapter, Kerberos is an open standard that is implemented on different platforms. Because of this Kerberos can be used as an SSO solution between Windows and other platforms.

5.7.1 Non-Windows Kerberos implementations

Table 5.14 lists other Kerberos implementations and the platforms on which they are available.

5.7.2 Comparing Windows Kerberos to other implementations

Before going into the details of the interoperability scenarios, it is interesting to look at what makes Windows 2000 and Windows Server 2003 Kerberos different from the other implementations. The Microsoft implementation of Kerberos is different in the following ways:

• It is tightly integrated with the Windows 2000 and Windows Server 2003 OS kernel: Every Windows 2000 and Windows Server 2003 system runs the Kerberos Security Support Provider (SSP) and every DC has a KDC service.

• Kerberos principals locate the KDC using DNS. Windows 2000 and Windows Server 2003 DNS includes special SRV records that provide the location of a Kerberos KDC.

• MS implemented the RC4-HMAC encryption algorithm (56/128 bit keys) as the preferred Kerberos encryption type. MS still supports DES-CBC-CRC and DES-CBC-MD5 (56-bit keys) for interoperability reasons. See Section 5.4.3 for more information about this.

• The MS implementation does not support the MD4 checksum type.

• Windows Kerberos KDCs require Kerberos clients to perform preauthentication by default. More information about this is available in Section 5.5.2.

• The MS implementation does not include support for DCE-style cross-realm trust relationships.

• Microsoft uses their proprietary SSPI API (see Chapter 4) to access

Kerberos services. They do not support the raw krb5 API.

• Microsoft uses the authdata field in the ticket to embed authorization data. Microsoft refers to this field as the Privilege Attribute Certificate (PAC). See also Section 5.4.3 for more information about this.

5.7.3 Interoperability scenarios

In this section we will focus on setting up Kerberos interoperability between Windows 2000 or Windows Server 2003 Kerberos and a Kerberos implementation that runs on top of UNIX platforms. Kerberos authentication interoperability can be set up in three different ways:

• The Windows Kerberos KDC is the KDC for both Windows and UNIX security principals (the principals are administered from the Windows KDC) (Scenario 1).

• The UNIX KDC is the KDC for both Windows and UNIX security principals (the principals are administered from the UNIX KDC). This scenario includes no Windows domain controllers (Scenario 2).

• A cross-realm trust relationship is defined between a Windows domain and a UNIX Kerberos realm. A part of the principals is administered from the Windows KDC, another part is administered from the UNIX KDC. In this case, there are two KDCs—one KDC on each side of the trust relationship (Scenario 3).

Next we will explain these three scenarios using examples of Windows- UNIX Kerberos authentication interoperability.

Lots of valuable information on how to set up interoperability can be found in the following white papers:

• “Windows 2000 Kerberos interoperability” available from http:// www.microsoft.com/windows2000/techinfo/howitworks/security/ kerbint.asp

• “Windows 2000 Kerberos Interoperability” by Christopher Nebergall available from http://www.sans.org/rr/paper.php?id=973

Principals defined on a Windows KDC

This scenario allows for Kerberos principals on both Windows and non- Windows platforms to log on using Windows credentials and a Windows KDC. To enable a user to log on to Windows from a UNIX workstation, the UNIX krb5.conf Kerberos configuration file must be edited to point to the Windows KDC. Afterward, the user can log on using his or her Windows account and the “kinit” command (kinit is the equivalent of logon in UNIX Kerberos implementations).

The setup gets a little bit more complicated when enabling a service, running on a UNIX platform, to log on using Windows credentials and a Windows KDC. In this scenario the Windows administrator has to run through the following configuration steps:

• Edit the krb5.conf file on the UNIX machine to point to the Windows KDC.

• Create a service account for the UNIX service in the Active Directory.

• Use ktpass.exe to export the newly created service account’s credentials from AD and create a keytab file. The keytab file contains the password that will be used by the UNIX service to logon to the Windows domain.

• Copy the keytab file to the UNIX host and merge it with the existing keytab file.

Ktpass comes with the Windows support tools. It allows an administrator to configure a UNIX computer or UNIX-based service as a security principal in the Active Directory.

The following example illustrates this last scenario. A company has a UNIX database server whose content should be accessible through a Web interface for every Windows user. To set this up, configure the database service as a principal in the Windows domain, and install an IIS server as a Web front end for the database server. To allow for credential forwarding between a Windows user and the IIS server, the IIS server must be “trusted for delegation.”

Principals defined on a non-Windows KDC

This scenario allows for Kerberos principals on both Windows and non- Windows platforms to log on using UNIX credentials and a UNIX KDC. For a stand-alone Windows workstation or member server to use a UNIX KDC, the following has to be done:

• Create a host for the workstation in the UNIX realm.

• Configure the Windows workstation or member server using ksetup.exe to let it point to the UNIX KDC and realm and to set the machine password (this will automatically switch the workstation or member server to workgroup mode). Ksetup.exe also comes with the Windows support tools.

• Restart the workstation or member server and run ksetup.exe again to map local machine accounts to UNIX principals.

Cross-realm trust

This is probably the most flexible interoperability scenario available. This scenario will enable non-Windows Kerberos principals to log on to their UNIX KDC and to access resources in a Windows domain and also the other way around: For Windows principals to log on to their Windows KDC and to access resources in a UNIX realm.

The setup of a cross-realm trust between Windows and a UNIX realm is relatively straightforward. On the Windows side two things must be done: A trust relationship must be created using the AD Domains and Trusts snap-in, and a realm mapping for the UNIX realm should be added to the system registry. To add a realm mapping, use the ksetup tool. A realm mapping should not only be added on the Windows Domain controller, but also on every machine from which resources will be accessed in the UNIX realm. On the UNIX side, a trust relationship can be created using the kadmin tool.

If all user accounts are defined in the UNIX realm, a domain layout that is very similar to the NT4 master domain model of account domains and resource domains is created. In that case, the UNIX realm acts as a master account domain containing all the accounts. The Windows domain acts as a resource domain, containing resources and mappings from the UNIX accounts to Windows SIDs.

If you are planning to use this domain-realm layout, some extra configuration, besides the creation of a cross-realm trust, is needed on the Windows side. The reason for this is the difference in the accounting and aauthorization systems used in Windows and UNIX. Whereas UNIX relies on principal names for both accounting and authorization, Windows relies entirely on security identities (SIDs). Even though there is a trust relation- ship between the UNIX realm and the Windows domain, users authenticated through the KDC in the UNIX account domain can by default not access any resource in the Windows, because they do not have an SID.

To resolve this problem, shadow or proxy accounts must be created on the Windows side. A proxy account is an attribute (the “altSecurityIdentities” attribute) of a Windows account that contains a UNIX principal name. In other words, proxy accounts provide a way to map a UNIX account to a Windows account or SID.

Setting Up Kerberos Proxy Accounts Kerberos proxy or shadow accounts can be defined from the AD Users and Computers MMC snap-in.

• In the MMC snap-in’s View menu option, select Advanced Features…

• Right-click the user account for which you want to define the proxy account and select Name Mappings… This will bring up the Security Identity Mapping dialog box (illustrated in Figure 5.36).

  Figure 5.36: Defining Kerberos account mappings.

• Select the Kerberos Names tab, and then Add… to add the UNIX Kerberos Principal Name.

Let’s look at what will happen now when a UNIX principal wants to access a resource that is hosted on a machine that is a member of a Windows domain (illustrated in Figure 5.37):

• The UNIX principal is logged on to the UNIX domain; his or her credential cache contains a TGT for the UNIX domain.

• The UNIX principal wants to access resource A in the Windows domain. His or her local KDC refers him to the Windows KDC.

• The Windows KDC creates a new service ticket for the UNIX principal to access resource A. Because the TGT used by the UNIX principal contains an empty PAC, the Windows KDC will query the Active Directory for an account mapping between the UNIX principal and a Windows SID. The newly issued service ticket will contain the PAC data corresponding to the Windows SID.

  Figure 5.37: UNIX-Windows Server 2003 Kerberos interoperability using a cross-realm trust.

• Using the service ticket, the UNIX principal authenticates to the machine hosting resource A.

In case the Windows domain also contains NT4 servers that can only authenticate using NTLM, this scenario also requires some password synchronization tool between the UNIX Realm (where the accounts and their passwords are defined) and the Windows domain. Such a tool is available in CyberSafe’s Trustbroker product.