Encryption Algorithm Support Windows Issues

[ Team LiB ] [ Team LiB ]

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 usernamepassword 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.comwindows2000techinfoplanningsecuritykerbsteps.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; youll be using MMC to create and modify Kerberos users in this case. Since Microsoft does not implement a kadmin interface similar to MIT or Heimdals, 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 supporttool 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. [ Team LiB ] [ Team LiB ]

Chapter 9. Case Study

In the previous eight chapters, we examined the technical details behind the Kerberos system, and how to implement Kerberos in your network. Now, in this chapter, we will take a step back and examine a hypothetical organization that wants to implement a network-wide single-sign-on solution. This organization has chosen to use Kerberos. We describe the decision process as the necessary Kerberos realms are created and implemented. The example includes many of the decision processes that apply to organizations implementing Kerberos in their own networks. [ Team LiB ] [ Team LiB ]