• Chapter 1. Installing and Configuring Windows Server 2003
  • software development Company Server 2003
  • Chapter 1. Installing and Configuring Windows Server 2003
  • New Features in Windows Server 2003
  • Best Practices
  • Moving Forward
  • Version Comparisons
  • Hardware Recommendations
  • Installation Checklist
  • Functional Overview of Windows Server 2003 Setup
  • Installing Windows Server 2003
  • Post Setup Configurations
  • Functional Description of the Windows Server 2003 Boot Process
  • Correcting Common Setup Problems
  • Chapter 2. Performing Upgrades and Automated Installations
  • New Features in Windows Server 2003
  • NT4 Upgrade Functional Overview
  • Upgrading an NT4 or Windows 2000 Server
  • Automating Windows Server 2003 Deployments
  • Moving Forward
  • Chapter 3. Adding Hardware
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Architecture
  • Overview of Windows Server 2003 Plug and Play
  • Installing and Configuring Devices
  • Troubleshooting New Devices
  • Moving Forward
  • Chapter 4. Managing NetBIOS Name Resolution
  • New Features in Windows Server 2003
  • Moving Forward
  • Overview of Windows Server 2003 Networking
  • Name Resolution and Network Services
  • Network Diagnostic Utilities
  • Resolving NetBIOS Names Using Broadcasts
  • Resolving NetBIOS Names Using Lmhosts
  • Resolving NetBIOS Names Using WINS
  • Managing WINS
  • Disabling NetBIOS-over-TCP/IP Name Resolution
  • Chapter 5. Managing DNS
  • New Features in Windows Server 2003
  • Configuring a Caching-Only Server
  • Configuring a DNS Server to Use a Forwarder
  • Managing Dynamic DNS
  • Configuring Advanced DNS Server Parameters
  • Examining Zones with Nslookup
  • Command-Line Management of DNS
  • Configuring DHCP to Support DNS
  • Moving Forward
  • Overview of DNS Domain Structure
  • Functional Description of DNS Query Handling
  • Designing DNS Domains
  • Active Directory Integration
  • Configuring DNS Clients
  • Installing and Configuring DNS Servers
  • Configuring Secondary DNS Servers
  • Integrating DNS Zones into Active Directory
  • Chapter 6. Understanding Active Directory Services
  • New Features in Windows Server 2003
  • Active Directory Support Files
  • Active Directory Utilities
  • Bulk Imports and Exports
  • Moving Forward
  • Limitations of Classic NT Security
  • Directory Service Components
  • Brief History of Directory Services
  • X.500 Overview
  • LDAP Information Model
  • LDAP Namespace Structure
  • Active Directory Namespace Structure
  • Active Directory Schema
  • Chapter 7. Managing Active Directory Replication
  • New Features in Windows Server 2003
  • Replication Overview
  • Detailed Replication Transaction Descriptions
  • Designing Site Architectures
  • Configuring Inter-site Replication
  • Controlling Replication Parameters
  • Special Replication Operations
  • Troubleshooting Replication Problems
  • Moving Forward
  • Chapter 8. Designing Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Design Objectives
  • DNS and Active Directory Namespaces
  • Domain Design Strategies
  • Strategies for OU Design
  • Flexible Single Master Operations
  • Domain Controller Placement
  • Moving Forward
  • Chapter 9. Deploying Windows Server 2003 Domains
  • New Features in Windows Server 2003
  • Preparing for an NT Domain Upgrade
  • In-Place Upgrade of an NT4 Domain
  • In-Place Upgrade of a Windows 2000 Forest
  • Migrating from NT and Windows 2000 Domains to Windows Server 2003
  • Additional Domain Operations
  • Moving Forward
  • Chapter 10. Active Directory Maintenance
  • New Features in Windows Server 2003
  • Loss of a DNS Server
  • Loss of a Domain Controller
  • Loss of Key Replication Components
  • Backing Up the Directory
  • Performing Directory Maintenance
  • Moving Forward
  • Chapter 11. Understanding Network Access Security and Kerberos
  • New Features in Windows Server 2003
  • Windows Server 2003 Security Architecture
  • Security Components
  • Password Security
  • Authentication
  • Analysis of Kerberos Transactions
  • MITv5 Kerberos Interoperability
  • Security Auditing
  • Moving Forward
  • Chapter 12. Managing Group Policies
  • New Features in Windows Server 2003
  • Group Policy Operational Overview
  • Managing Individual Group Policy Types
  • Moving Forward
  • Chapter 13. Managing Active Directory Security
  • New Features in Windows Server 2003
  • Overview of Active Directory Security
  • Using Groups to Manage Active Directory Objects
  • Service Accounts
  • Using the Secondary Logon Service and RunAs
  • Using WMI for Active Directory Event Notification
  • Moving Forward
  • Chapter 14. Configuring Data Storage
  • New Features in Windows Server 2003
  • Functional Description of Windows Server 2003 Data Storage
  • Performing Disk Operations on IA32 Systems
  • Recovering Failed Fault Tolerant Disks
  • Working with GPT Disks
  • Moving Forward
  • Chapter 15. Managing File Systems
  • New Features in Windows Server 2003
  • Overview of Windows Server 2003 File Systems
  • NTFS Attributes
  • Link Tracking Service
  • Reparse Points
  • File System Recovery and Fault Tolerance
  • Quotas
  • File System Operations
  • Moving Forward
  • Chapter 16. Managing Shared Resources
  • New Features in Windows Server 2003
  • Functional Description of Windows Resource Sharing
  • Configuring File Sharing
  • Connecting to Shared Folders
  • Resource Sharing Using the Distributed File System (Dfs)
  • Printer Sharing
  • Configuring Windows Server 2003 Clients to Print
  • Managing Print Services
  • Moving Forward
  • Chapter 17. Managing File Encryption
  • New Features in Windows Server 2003
  • File Encryption Functional Description
  • Certificate Management
  • Encrypted File Recovery
  • Encrypting Server-Based Files
  • EFS File Transactions and WebDAV
  • Special EFS Guidelines
  • EFS Procedures
  • Moving Forward
  • Chapter 18. Managing a Public Key Infrastructure
  • New Features in Windows Server 2003
  • Moving Forward
  • PKI Goals
  • Cryptographic Elements in Windows Server 2003
  • Public/Private Key Services
  • Certificates
  • Certification Authorities
  • Certificate Enrollment
  • Key Archival and Recovery
  • Command-Line PKI Tools
  • Chapter 19. Managing the User Operating Environment
  • New Features in Windows Server 2003
  • Side-by-Side Assemblies
  • User State Migration
  • Managing Folder Redirection
  • Creating and Managing Home Directories
  • Managing Offline Files
  • Managing Servers via Remote Desktop
  • Moving Forward
  • Chapter 20. Managing Remote Access and Internet Routing
  • New Features in Windows Server 2003
  • Configuring a Network Bridge
  • Configuring Virtual Private Network Connections
  • Configuring Internet Authentication Services (IAS)
  • Moving Forward
  • Functional Description of WAN Device Support
  • PPP Authentication
  • NT4 RAS Servers and Active Directory Domains
  • Deploying Smart Cards for Remote Access
  • Installing and Configuring Modems
  • Configuring a Remote Access Server
  • Configuring a Demand-Dial Router
  • Configuring an Internet Gateway Using NAT
  • Chapter 21. Recovering from System Failures
  • New Features in Windows Server 2003
  • Functional Description Ntbackup
  • Backup and Restore Operations
  • Recovering from Blue Screen Stops
  • Using Emergency Management Services (EMS)
  • Using Safe Mode
  • Restoring Functionality with the Last Known Good Configuration
  • Recovery Console
  • Moving Forward
  • Who Should Read This Book
  • Who This Book Is Not For
  • Conventions
  • Acknowledgments
  • About the Author
  • About the Technical Reviewers
  • Index
  • Index A
  • Index B
  • Index C
  • Index D
  • Index E
  • Index F
  • Index G
  • Index H
  • Index I
  • Index J
  • Index K
  • Index L
  • Index M
  • Index N
  • Index O
  • Index P
  • Index Q
  • Index R
  • Index S
  • Index SYMBOL
  • Index T
  • Index U
  • Index V
  • Index W
  • Index X
  • Index Z
  • Preface
  • Previous Section Next Section

    MITv5 Kerberos Interoperability

    If you have a network where you currently use MITv5 Kerberos for authentication, you are probably very interested in getting Windows Kerberos integrated into your system. By the same token, you may have an Active Directory domain where you want to use a Kerberos application that was coded to work in an MITv5 environment. In either case, you have a solid amount of work ahead of you to get the two systems to cooperate.

    It is possible for a Kerberos realm and an Active Directory domain live side-by-side. Users from one side must access services and resources on the other side. Our job is to make that transition as seamless as possible. This section covers the general steps you would take to create a cross-realm trust that can accommodate Kerberos services and principals from both sides.

    The Kerberos implementation in Windows follows RFC requirements that originated with MITv5 Kerberos, so the two versions can co-exist, but the operational details of the marriage vary widely depending on your platforms and applications.

    Even if you do not use MITv5 Kerberos and have no plans to do so, it may be worth the exercise to go through this section. Each subsection outlines the differences in the way Windows implements the classic MITv5 components and spells out potential difficulties in making them work together.

    MITv5 Kerberos References

    Here are some excellent references you should consult when the time comes to set up a classic Kerberos MITv5 realm:

    • The Moron's Guide to Kerberos, www.isi.edu/~brian/security/kerberos.shtml. Certainly not for a "moron," this well-written, concise overview from Brian Tung discusses how Kerberos operates and how it is implemented in a UNIX environment.

    • Kerberos: An Authentication Service for Computer Networks, www.isi.edu/gost/publications/kerberos-neuman-tso.shtml. This seminal 1994 work by B. Clifford Neuman and Theodore Ts'o still stands as one of the best industrial-strength explanations of Kerberos operation. It does not contain implementation details, but you'll learn operational nitty-gritty that isn't spelled out anywhere else.

    • Kerberos FAQ, www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.shtml. Like most FAQs, this is a sprawling document. Fire up your search tools and be prepared to do some digging.

    • Kerberos V5 Installation Guide, www.lns.cornell.edu/public/COMP/krb5/install/install_toc.shtml (among others). This authoritative reference describes exactly how to install UNIX-based MITv5 Kerberos in a diverse university environment. The document assumes you are running executables built from the MIT source code, but the steps are generally applicable to other implementations.

    • Step-by-Step Guide to Kerberos 5 Interoperability, www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp. This guide came out in conjunction with the initial release of Windows 2000 in response to many queries from universities about how Microsoft Kerberos would work with MITv5 Kerberos. The working level detail in the paper is very good and can be applied to a variety of Kerberos implementations.

    • Red Hat v7.1 Reference Guide, www.redhat.com/support/manuals. If you are interested in implementing Kerberos in a Red Hat Linux environment, this is a good place start. Don't take the instructions too literally because they are sometimes not quite up to date with the new features and changes in version 7.1.

    • Debian documentation, www.mit.edu/afs/sipb/project/debian/cvs/krb5/doc/krb5-install.info-1,v. These documents are a lot more detailed than the Red Hat documentation, as you might expect from the Debian distro, but they tend not to be as current as you might like.

    • Services for UNIX (SFU), Microsoft Corp and Mortis Kerns Systems (MKS) partner together to produce SFU. The package has an extension that updates the AD schema to include UNIX attributes such as UID, GID, homedirectories, and so forth. This can be handy if you want to store and access UNIX information in Active Directory to support Kerberized applications.

    Kerberized Applications

    Before getting down to work, it's a good idea to define what we want to accomplish. It's not enough to say, "I want all my users to get authenticated with Kerberos," because that's only half of the challenge. The other half is to connect the users with services that take advantage of their Kerberos credentials.

    A so-called Kerberized application generally consists of a client/server pair where the server side expects the client process to present a Kerberos session ticket when it attempts to access the application. The client side of the process is coded to obtain a session ticket from a KDC using the underlying functions of the operating system.

    This means that for a Kerberized application to work on Windows, the developer must incorporate function calls with parameters that are compatible with Windows Kerberos. Kerberos clients that work fine in a classic MITv5 Kerberos environment may not work when run in a Windows Kerberos environment, and vice versa. For example, a Kerberized LDAP application running on a UNIX/Linux host might not connect correctly to Active Directory because the developer did not include function calls that the Kerberos security package on Windows expects to see.

    In Windows Server 2003, the following applications depend on Kerberos for authentication:

    • LDAP connections to Active Directory (SASL/GSSAPI)

    • CIFS/SMB file access

    • Secure dynamic DNS updates

    • IPSec connections intermediated with Internet Key Exchange (IKE)

    • Secure web services

    • Enterprise Certification Authority (CA) certificate requests

    • DCOM/RPC

    Of these, the CIFS/SMB service probably garners the most attention because many organizations use Samba, the open source SMB protocol, to connect to Windows servers. Administrators in organizations that use Samba generally want to have a single Kerberos implementation, either MITv5 or Windows.

    The news in this arena is not so good. A Kerberized version of Samba is available, but it does not enable a UNIX/Linux client to access CIFS/SMB services in a Windows domain using Kerberos credentials. The most current version of Samba that was available as of this writing was still limited to NTLMv2 authentication. See us2.samba.org/samba/development.shtml for information on the current state of development in this area.

    Several other important applications in Windows are not Kerberized, meaning that UNIX/Linux clients must use some other form of authentication (NTLMv2, Digest, or clear text) to access these services running on a Windows server:

    • Telnet. The Microsoft implementation of telnet does not use GSSAPI so there is no interface for Kerberos ticket implementation. As of this writing, Microsoft has no plans for reworking either their telnet client or the Tlntsvc service to use Kerberos. The only authentication supported by Tlntsvc is NTLMv2.

    • Ftp. The Microsoft ftp service runs under the IIS framework. The fundamentals are in place for Microsoft ftp to use Kerberos, but the version that ships with Windows Server 2003 does not expose this functionality. The command-line ftp client in Windows Server 2003 and XP is largely unchanged from Windows 2000 and only supports NTLMv2, Digest, or clear-text authentication.

    • Transport Layer Security (TLS). RFC 2712, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)," describes a mechanism for incorporating Kerberos into TLS, but Microsoft did not incorporate this into either its Windows Server 2003 implementation of TLS or the IE client.

    • Internet Mail Access Protocol (IMAP). The IMAP4 service in Windows Server 2003 runs as part of IIS. It does not support Kerberos authentication from clients such as Netscape Communicator and Eudora. The IMAP4 client in Outlook and Outlook Express does not support Kerberos authentication.

    • Secure Shell (SSH). There is no native implementation of SSH in Windows Server 2003 or XP, Kerberos or otherwise. Commercial SSH servers for Windows are available from SSH Communications (www.ssh.com) and Pragma Systems (www.pragmasys.com). OpenSSH and its associated VNC tunnel are available at www.cygwin.com.

    Cross-Realm Architecture

    To start off, let's take a look at the components of MITv5 Kerberos and compare them to the Kerberos components in Windows Server 2003.

    Kerberos Database

    The Kerberos database holds the names and secret keys for security principals in the realm. The secret keys are used to encrypt various portions of the Kerberos tickets and ticket-granting tickets.

    MITv5 Kerberos stores the Kerberos database in a file called Principal.db. (In Linux, the filename is simply Principal.) This file is typically stored in /var/ kerberos/krb5kdc.

    Administrative access to the Kerberos database is controlled by the Kadm5.acl file. This is a text file that is also stored in /var/kerberos/krb5kdc.

    Other important files, from a security perspective, are the Kadm5.keytab file, which contains keys that authenticate the KDC, and the Kerberos stash file, .k5stash, that contains the master key that encrypts the Kerberos database. These files must be carefully guarded to prevent exposing the Kerberos database to attack.

    An administrator creates the Kerberos database manually using the kdb5_util utility as follow:

    [root@rhs1 sbin]# kdb5_util create -s
    Initializing database '/var/kerberos/krb5kdc/principal' for realm 'RH.COM',
    master key name 'K/M@RH.COM'
    You will be prompted for the database Master Password.
    It is important that you NOT FORGET this password.
    Enter KDC database master key:
    Re-enter KDC database master key to verify:
    

    This process is automated in Windows. The DCPROMO Wizard creates the Active Directory database and populates it with security principals. The LDAP objects that represent these security principals contain password hashes that satisfy the same requirements as the entries in a classic Kerberos database.

    The password hashes used in Windows Server 2003 are created using MD4. The algorithm used to encrypt Kerberos TGTs and session tickets in Windows is RC4-HMAC. This method was chosen because it is compatible with the password hashes used in Windows Server 2003 and previous versions of Windows.

    RC4-HMAC is not one of the standard Kerberos encryption algorithms. Microsoft briefly proposed a change to the list of commonly approved algorithms in Kerberos, but that proposal has elapsed. For this reason, a UNIX/Linux Kerberos client authenticating in an Active Directory domain must maintain a separate local account. It is up to the administrator to provide a way to keep the local account password in sync with the domain password. This is typically done with a script that calls password change functions for the two platforms.

    Kerberos Policies

    A classic Kerberos realm has a short set of configuration parameters called policies. A realm can have multiple policies. Sets of principals can be assigned to each policy. You can list the available policies using kdadmin listpols. You can view the contents of a particular policy using kadmin getpol <policy_name>:

    kadmin:  getpol Standard_Policy
    Policy: Standard_Policy
    Maximum password life: 31536000
    Minimum password life: 0
    Minimum password length: 1
    Minimum number of password character classes: 2
    Number of old keys kept: 5
    Reference count: 20
    

    The password character class entry defines how many different elements are required to be in a password. There are five choices: uppercase, lowercase, numbers, punctuation, and control characters. The more classes you require, the stronger the passwords will be, but the harder they will be to remember.

    Windows defines these classic Kerberos policies as a subset of password policies. The Kerberos policies in Windows define parameters such as ticket lifetimes and permissible clock skew. In MITv5 Kerberos, these parameters are defined in the Krb5kdc.conf file. This file is generally found under /var/kerberos/.

    Kerberos Services

    Classic MITv5 Kerberos splits the Ticket Granting and Authentication functions between two daemons (services) called krb5kdc (ticket granting) and kadmin (authentication and database administration).

    The krb5kdc daemon listens for ticket requests on UDP/TCP port 88. The kadmin daemon handles administration requests over UDP/TCP port 749 and handles password changes submitted via the kpasswd protocol over UDP port 464.

    In Windows, Active Directory functions as the Kerberos database. There is no analog to the kadmin daemon. Windows does not listen on port 749. The kdc service in Windows runs as part of the Local Security Authority (LSA) and handles authentication and ticket granting over port 88 and classic Kerberos password changes over port 464. This is documented in draft-trostle-win2k-cat-kerberos-set-passwd-02.txt, "Windows 2000 Kerberos Change Password and Set Password Protocols."

    Kerberos Clients

    A UNIX Kerberos client obtains a ticket-granting ticket by running the kinit application. The user gives a password (used the validate the user's entry in the principal database) and if the credentials are valid, the user gets a TGT. The kinit utility caches the TGT so Kerberized applications on the machine can submit copies to the KDC when requesting session tickets to applications on specific servers. UNIX/Linux system administrators typically embed the kinit transaction into the initial logon routine.

    When a UNIX/Linux user finishes up a work session and is ready to log off, she runs kdestroy to flush the ticket cache. Most system administrators incorporate kdestroy into a sign-off routine. If the user doesn't sign off, the cache stays populated until the tickets expire.

    In Windows, the Kerberos security package handles ticket-granting ticket requests in conjunction with Winlogon. This is done transparently to the user. The TGTs and tickets are cached in memory, never on disk. When the user logs off, the tickets are wiped from memory.

    Many Kerberos implementations also expose an API library described in RFC 1964, "The Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) Mechanism." Windows Kerberos does not expose the GSS API directly. Instead, it uses a similar set of function calls exposed by the Security Support Provider Interface (SSPI).

    The reason this is important to system administrators is that you may have developers who are trying to get their applications to work on both Windows and UNIX/Linux. As you work with them to iron out the interoperability issues, you should keep in mind that some of the most basic mechanisms in the application might not work because of the difference in support for the GSS API.

    Kerberos Service Location

    UNIX/Linux Kerberos clients locate a KDC by reading a file called /etc/krb5.conf. This file also spells out supported encryption packages, library files, and log file locations. Here is an example for a realm called RH.COM and a KDC called kerberos.rh.com: (Uppercase names indicate realms and lowercase names indicate fully qualified DNS host names.)

     [logging]
     default = FILE:/var/log/krb5libs.log
     kdc = FILE:/var/log/krb5kdc.log
     admin_server = FILE:/var/log/kadmind.log
    
    [libdefaults]
     ticket_lifetime = 24000
     default_realm = RH.COM
     dns_lookup_realm = false
     dns_lookup_kdc = false
    
    [realms]
     RH.COM = {
      kdc = rhs1.rh.com:88
      admin_server = rhs1.rh.com:749
      default_domain = rh.com
     }
    
    [domain_realm]
     .rh.com = RH.COM
     rh.com = RH.COM
    
    [pam]
     debug = false
     ticket_lifetime = 36000
     renew_lifetime = 36000
     forwardable = true
     krb4_convert = false
    

    Windows Kerberos clients do not need a Krb5.conf file. They use SRV records in DNS to locate domain controllers. The ticket lifetimes and other Kerberos configuration options are defined in group policies linked to the Domain object in Active Directory.

    Kerberized Services

    Both Windows and UNIX have Kerberized services (daemons) that must obtain session tickets (on the client side) and validate those tickets (on the server side). This means that client services must have Kerberos credentials that can be submitted to a KDC to obtain session tickets. On the flip side, a server-side service must have Kerberos credentials so it can decrypt the session tickets submitted by clients.

    Classic MITv5 Kerberos stores the server credentials in a file called /etc/krb5. keytab. Windows stores the credentials in the Registry. See the "LSA Secrets" sidebar for more information.

    LSA Secrets

    Kerberized services in Windows store their local Kerberos credentials in the Security hive in the Registry. This hive is also called the Local Security Authority (LSA) database. The credentials are stored in a set of subkeys under a key called Secrets, so the contents of this key are often called LSA Secrets. Figure 11.17 shows a typical structure for keys in LSA Secrets.

    Figure 11.17. Security hive showing LSA Secrets.

    graphics/11fig17.jpg

    A surprising amount of secure information gets stored in LSA Secrets. Some of it is not as secure as you might think. A hacker tool called LSADUMP2 can show you some of the contents of many keys in LSA Secrets. For instance, it can show the dial-up passwords saved by users. Because users tend to use the same passwords for dialup and network authentication, this is a major security weakness.

    As of this writing, LSADUMP2 does not run on Windows Server 2003 or XP. It's likely that by the time you read this, someone will have "fixed" the utility.

    In a classic Kerberos environment, an administrator takes two actions to prepare a Kerberized application for authentication. Both of these actions are performed using the kadmin utility:

    • Create an account in the Kerberos database representing the service and its host. The service account name uses a Service Principal Name, or SPN, format.

    • Create an entry in the Krb5.keytab file on the server running the service. This keytab entry has the same secret key used to create the account in the Kerberos database. The entry is generated using a special function call that does not expose the secret key over the wire.

    When the Kerberized service initializes, it authenticates at the KDC and obtains a TGT. When a client uses the service, it obtains a session ticket that is encrypted with service's secret key. The service uses its copy of the secret key stored in the keytab file to decrypt the session key and complete the authentication transaction.

    Service Principal Names

    Kerberos identifies services with an SPN, both in the Kerberos database and in the keytab file. For example, the SPN for the ftp service running on a host named rhs1 in the rh.com DNS domain and RH.COM realm would have an SPN of ftp/rhs1.rh.com@RH.COM. The syntax elements are as follows:

    <primary>/<instance>@<realm>
    
    • <primary>. Identifies the service, such as ftp or host (used for telnet and rsh). The <primary> element can also identify a Kerberos role, such as admin or changepw. An SPN can also identify a user, although that format is generally called a User Principal Name, or UPN. A user named mmantle with the privilege to manage the Kerberos database in the RH.COM realm would have a UPN of mmantle/admin@RH.COM.

    • <instance>. Identifies the fully qualified domain name of the host. In the case of services provided by a KDC, the <instance> element is the realm name. For example, the ticket-granting ticket service would have an SPN of krbtgt/RH.COM@RH.COM.

    • <realm>. Identifies the name of the Kerberos realm. The uppercase letters differentiate it from the DNS domain. In Windows, the DNS name and realm name always match because a Windows domain must conform to a DNS namespace.

    Windows stores SPNs in Active Directory as attributes of the associated computer object. For instance, the LanMan Server service on a server named server1 in the Company.com domain registers itself with the SPN cifs/server1.company.com@COMPANY.COM. (CIFS stands for Common Internet File System, another term for SMB.)

    As we'll see in the next section, Windows also uses SPNs that diverge from the classic format. These can cause interoperability problems.

    Some classic Kerberized services do not use specific service names in the <primary> element of their SPN. For instance, the rlogin, rsh, and telnet services all use host as a <primary> identifier, as in host/rhs1.rh.com@RH.COM. Microsoft uses the host identifier somewhat loosely to identify any machine running Kerberos.

    You can enumerate the SPNs and UPNs in the Kerberos database using kadmin getprincs. Here is a sample listing. Notice that UPNs only specify the realm:

    K/M@RH.COM
    ftp/rhs1.rh.com@RH.COM
    host/rhs1.rh.com@RH.COM
    kadmin/admin@RH.COM
    kadmin/changepw@RH.COM
    kadmin/history@RH.COM
    krbtgt/RH.COM@RH.COM
    root/admin@RH.COM
    root@RH.COM
    

    The K/M@realm designator represents the master key used to encrypt the entire database. The administrator provides this key when the database is created.

    Interoperability and SPNs

    Microsoft made a few changes to the structure of the SPNs used in Windows to accommodate two situations that don't exist in classic MITv5 Kerberos:

    • Windows-based domains

    • Name resolution based on NetBIOS flat names

    The best way to see the difference is to view the SPNs on a Windows computer using the SETSPN utility from the Resource Kit. As an alternative, you can use the ADSI Editor (Adsiedit.msc) from the Support Tools to view the Computer object for the domain controller. The SPNs are stored in the ServicePrincipalName attribute.

    Here is a listing of the SPNs registered on an example Windows Server 2003 domain controller: (Each of these entries gets a @COMPANY.COM extension to form a full SPN.)

    C:\>setspn -L server1.company.com
    Registered ServicePrincipalNames for CN=SERVER1,OU=Domain Controllers,DC=company,DC=com:
        SMTPSVC/SERVER1
        SMTPSVC/server1.company.com
        NtFrs-88f6d2bd-b746-11d2-a6d3-00d04fc9b242/server1.company.com
        DNS/server1.company.com
        exchangeAB/SERVER1
        GC/server1.company.com/company.com
        HOST/server1.company.com/COMPANY
        HOST/SERVER1
        HOST/server1.company.com
        HOST/server1.company.com/company.com
        E3514235-4B06-11D1-AB04-00C04FC2DCD2/a54acff0-8185-4086-8d35-d1cff06b1e09/company.com
        LDAP/a54acff0-8185-4086-8d35-d1cff06b1e09._msdcs.company.com
        LDAP/server1.company.com/COMPANY
        LDAP/SERVER1
        LDAP/server1.company.com
        LDAP/server1.company.com/company.com
    

    Notice that some SPNs represent hosts and domains by their flat NetBIOS names and others use hierarchical DNS names. Windows clients can use either name to get a session ticket for the service. The GUIDs represent domains uniquely in DNS so that clients can contain their service requests to their own domains.

    This change to the SPN format in Windows creates an interoperability challenge. Programmers accustomed to working with classic Kerberos SPNs when they make well-known function calls are forced to change their code if they want to use Windows Kerberos for their authentications.

    Name Mapping

    SPN format has another subtle impact on system administration. Windows does not have a facility for creating classic multipart Kerberos <primary> elements. For example, you cannot create a Windows account called jane/admin@COMPANY.COM. Multipart usernames are recognized by MITv5 Kerberos, so a UNIX/Linux administrator might attempt to authenticate as jane/admin. This requires a little sleight-of-hand called name mapping.

    An Active Directory user or computer object has an attribute called AltSecurityIdentities that can contain a multipart Kerberos name. You can populate this attribute by right-clicking a user object in AD Users and Computer and selecting NAME MAPPINGS from the flyout menu. Figure 11.18 shows an example.

    Figure 11.18. User object showing Name Mappings window.

    graphics/11fig18.gif

    Creating a Cross-Realm Trust

    At this point, we have all the components we need to build a trust between a Windows Server 2003 domain and a classic Kerberos realm. Here's the sequence of events to build the trust:

    • Create a two-way trust in the Windows domain that names the Kerberos realm as the trust partner. This creates the necessary Kerberos principals in Active Directory to support issuing cross-realm ticket-granting tickets.

    • Create krbtgt principals in the Kerberos realm representing the Windows domain. These principals support the trust by permitting a KDC in the Kerberos realm to issue cross-realm TGTs to clients from the Windows domain.

    In these examples, I'll use a Red Hat Linux 7.1 server as a MITv5 KDC. Detailed instructions are located at www.redhat.com/support/manuals/RHL-7.1-Manual/ref-guide/s1-kerberos-server.shtml. If you have an existing Kerberos realm, you can skip this section.

    Install and Configure MITv5 Kerberos

    Figure 11.19 shows a KDC and client configuration for a cross-realm trust. The MITv5 KDC is named rhs1. The name server is running BIND and hosts the zone table for rh.com. The realm name is RH.COM.

    Figure 11.19. Cross-realm trust configuration.

    graphics/11fig19.gif

    Here is a quick rundown of the steps to create the MITv5 realm; you must be logged on with an account that has administrator privileges, such as root:

    1. Install the krb5-workstation and krb5-server packages.

    2. Use kedit (or your favorite text editor) to make the /etc/krb5.conf file look like the following:

      [logging]
      default = FILE:/var/log/krb5libs.log
      kdc = FILE:/var/log/krb5kdc.log
      admin_server = FILE:/var/log/kadmind.log
      [libdefaults]
       ticket_lifetime = 24000
       default_realm = RH.COM
       dns_lookup_realm = false
       dns_lookup_kdc = false
      
      [realms]
       RH.COM = {
        kdc = rhs1.rh.com:88
        admin_server = rhs1.rh.com:749
        default_domain = rh.com
       }
      
      [domain_realm]
       .rh.com = RH.COM
       rh.com = RH.COM
      
      [kdc]
       profile = /var/kerberos/krb5kdc/kdc.conf
      
      [pam]
       debug = false
       ticket_lifetime = 36000
       renew_lifetime = 36000
       forwardable = true
       krb4_convert = false
      
    3. Edit the /var/Kerberos/krb5kdc/kdc.conf file to make it look like this:

      [kdcdefaults]
       acl_file = /var/kerberos/krb5kdc/kadm5.acl
       dict_file = /usr/share/dict/words
       admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
      
      [realms]
       RH.COM = {
        master_key_type = des-cbc-crc
        supported_enctypes = des-cbc-crc:normal des3-cbc-raw:normal des3-cbc-sha1:normal
      des-cbc-crc:v4 des-cbc-crc:afs3
       }
      
    4. Create the Kerberos database as follows (binaries located in /usr/Kerberos/sbin):

      kdb5_util create -s
      
    5. Edit the /var/kerberos/krb5kdc/kadm5.acl file to make it look like this:

      */admin@RH.COM *
      
    6. Change directory to /etc/rc.d/init.d and start the Kerberos daemons as follows:

      sh krb5kdc start
      sh kadmin start
      sh krb524 start
      
      
    7. Run gkadmin to add principals to the Kerberos database. At a minimum, you need a principal for the root account and your own account. The account must already exist in Linux before you can add it to the Kerberos database. The passwords are not kept in sync automatically. The users can run kpasswd to change their Kerberos passwords.

    8. Run kinit to issue yourself a ticket.

    9. Run klist to check that the ticket was issued correctly. (The graphical tool is krb5.) Here's an example:

       [root@rhs1 Admin]# klist
      Ticket cache: FILE:/tmp/krb5cc_p2722
      Default principal: Admin@RH.COM
      
      Valid starting     Expires            Service principal
      10/05/01 13:47:51  10/05/01 23:47:51  krbtgt/RH.COM@RH.COM
      
      Kerberos 4 ticket cache: /tmp/tkt0
      klist: You have no tickets cached
      
    Create the Cross-Realm Trust

    At this point, we have a Windows domain and a classic Kerberos realm. We now want to create cross-realm trusts so that users authenticated in either the Kerberos realm or the Windows domain can access resources everywhere. Here are the major points of interest for creating the trust:

    • The Windows domain controller where the trust is created must know the location of a KDC in the MITv5 realm. This is done using the Windows equivalent of a keytab entry. The entry is stored in the Registry. It is created using KSETUP.

    • The Windows Trust Wizard creates an object in Active Directory with a secret key that is shared by security principals in the Kerberos realm. This object essentially "represents" the realm when it comes to distributing ticket-granting tickets. The object is under cn=System,dc=<domain>,dc=<root>. It has the same name as the Kerberos realm. You provide the secret key (a password) when you create the trust.

    • You must create two krbtgt principals in the Kerberos realm that represent both sides of the two-way trust relationship. These security principals use the same password as the trust object. One of them issues ticket-granting tickets to users from the Windows domain. The other issues referral ticket-granting tickets to users from the Kerberos realm when they access the Windows domain.

    • You must provide a "mapping" between principals in the Kerberos realm and users in the Windows Active Directory. This mapping permits generating a local access token for the classic Kerberos client.

    • You must provide a way for Windows clients to locate classic Kerberos KDCs. This is because classic Kerberos doesn't register SRV records in DNS. Windows stores the realm name and fully qualified DNS names of classic MITv5 KDCs in the Registry. (This is the Windows equivalent of Krb5.conf file entries.)

    With all this in mind, let's create a two-way, transitive trust between a Windows domain and a classic Kerberos realm. The example shown in Procedure 11.8 uses the principals and servers shown in Figure 11.19.

    Procedure 11.8 Configuring a Cross-Realm Trust

    1. Select a domain controller in the root domain of the Windows forest.

    2. Log on with Enterprise Administrator permissions.

    3. Install the Support Tools on the server. This installs the MITv5 Kerberos utilities.

    4. Run this command at the console:

      ksetup /addkdc RH.COM rhs1.rh.com
      
    5. Open AD Domains and Trusts.

    6. Right-click the root domain of the forest and open the Properties window.

    7. Select the Trusts tab.

    8. Click New Trust. The New Trust Wizard starts.

    9. Click Next. The Trust Name and Password window opens.

    10. Under Name, enter the name of the Kerberos realm. For example, RH.COM.

    11. Under Trust Password, enter a strong password to use for negotiating the trust. You'll need this password when creating the security principals in the Kerberos realm.

    12. Click Next. The Trust Type window opens. The Realm Trust option should be selected. If it is not, select it.

    13. Click Next. The Transitivity of Trust window opens. Select the Transitive option to let other domains in the forest use the trust relationship.

    14. Click Next. The Direction of Trust window opens. Select Two-Way to permit principals from either side to access resources in each other's domain/realm.

    15. Click Next. The Trust Selections Complete window opens. Review the selections you made and change any that are incorrect.

    16. Click Next. The Completing the New Trust Wizard window opens. Click Finish to save your changes and create the trust.

      At this point, you've built the Windows half of the trust. Now go to the KDC in the Kerberos realm and complete the job as follows:

    17. Run kadmin and give Kerberos administrator credentials.

    18. Add the following two security principals (replace the word password with the password you used to create the trust in Windows):

      ank -pw password krbtgt/COMPANY.COM@RH.COM
      ank -pw password krbtgt/RH.COM@COMPANY.COM
      

      The final steps create name mappings between security principals in the Kerberos realm and user accounts in Active Directory.

    19. Open AD Users and Computers.

    20. Create a user that corresponds to a security principal in the Kerberos realm.

    21. Right-click the user object and select NAME MAPPINGS from the flyout menu.

    22. Select the Name Mappings tab.

    23. Click Add. The Add Kerberos Principal Name window opens.

    24. Enter the Kerberos principal name corresponding to the user, such as root@RH.COM.

    25. Click OK to save the change.

      The final step must be done at every workstation or server in the Windows domain where a user will log on to the Kerberos realm. This step tells the computer where to find a KDC in the classic Kerberos realm. This step requires the KSETUP utility from the Support Tools.

    26. At the workstation or server, run the following (where rhs1 is the KDC in the RH.COM realm):

      ksetup /addkdc RH.COM rhs1.rh.com
      
    Testing Cross-Realm Trusts

    After you've configured the cross-realm trust, test it to make sure users can get tickets. Follow the steps in Procedure 11.9 at the console of the workstation where you ran KSETUP.

    Procedure 11.9 Testing Cross-Realm Kerberos Ticket Generation

    1. Press Ctrl+Alt+Del to log on. Select the name of the Kerberos realm in the pick list of the Winlogon window.

    2. Enter the name and password of the Kerberos principal that you configured with a name mapping.

    3. Press Enter. The logon should succeed.

    4. Open a command prompt.

    5. Run klist tgt to see the contents of the ticket-granting ticket issued to the client. Here is an example:

      C:\>klist tgt
      Cached TGT:
      ServiceName: krbtgt
      TargetName: krbtgt
      FullServiceName: root
      DomainName: RH.COM
      TargetDomainName: RH.COM
      AltTargetDomainName: RH.COM
      TicketFlags: 0x40c00000
      KeyExpirationTime: 256/0/29920 0:102:8048
      StartTime: 10/6/2001 13:19:02
      EndTime: 10/6/2001 23:19:02
      RenewUntil: 10/6/2001 13:19:02
      TimeSkew: 10/6/2001 13:19:02
      
    6. Run klist tickets to see the tickets issued to the user. Note that some come from the Windows domain (via the trust) and others come directly from the Kerberos realm. Here is an example:

      C:\>klist tickets
      Cached Tickets: (6)
      
         Server: krbtgt/RH.COM@RH.COM
            KerbTicket Encryption Type: Kerberos DES-CBC-CRC
            End Time: 10/6/2001 23:19:02
            Renew Time: 10/6/2001 13:19:02
      
         Server: krbtgt/COMPANY.COM@RH.COM
            KerbTicket Encryption Type: Kerberos DES-CBC-CRC
            End Time: 10/6/2001 23:19:02
            Renew Time: 10/6/2001 13:19:02
      
         Server: krbtgt/RH.COM@RH.COM
            KerbTicket Encryption Type: Kerberos DES-CBC-CRC
            End Time: 10/6/2001 23:19:02
            Renew Time: 10/6/2001 13:19:02
      
         Server: cifs/server1.company.com@COMPANY.COM
            KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
            End Time: 10/6/2001 23:19:02
            Renew Time: 10/6/2001 13:19:02
      
         Server: ldap/server1.company.com/company.com@COMPANY.COM
            KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
            End Time: 10/6/2001 23:19:02
            Renew Time: 10/6/2001 13:19:02
      
         Server: host/server1.company.com@COMPANY.COM
            KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
            End Time: 10/6/2001 23:19:02
            Renew Time: 10/6/2001 13:19:02
      

    At this point, you should test access to Kerberized services on both sides of the trust. Some applications are not cross-platform compatible. For example, a Kerberized version of rlogin on a Windows platform may not be able to connect to the klogin or eklogin service on a UNIX/Linux host.

      Previous Section Next Section