• 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

    Authentication

    So far, we've met the supporting players in the pageant of network access security and we've seen how one part of the security triumvirate, authorization, functions to control access to resources. Now it's time to meet the star of the show, the process that controls authentication. Ladies and gentlemen, give it up for Kerberos.

    Kerberos was developed at MIT as part of Project Athena. Windows Server 2003 implements Kerberos version 5, update 6, as defined by RFC 1510, "The Kerberos Network Authentication Service V5." All modern Windows platforms (Windows Server 2003, XP, and Windows 2000) use this version of Kerberos, making them fully interoperable. Windows Server 2003 Server also makes it fairly easy to build transitive trust relationships with classic MITv5 Kerberos systems. This is covered in detail later in this section.

    Limitations of Classic NT Authentication

    The first question you might have concerning Kerberos is, "Why change?" After all, classic NTLM Challenge-Response authentication seems to work pretty well. And the improved security in NTLMv2 went a long way toward blocking attacks.

    In spite of the improvements in NTLMv2, classic authentication has several vulnerabilities and limitations. Here is a quick list:

    • Pass-through authentication. When a client touches a resource on a classic member server, the server must negotiate a Challenge-Response transaction with a domain controller on behalf of the client to verify the client's identity. This slows down the authentication process and opens the door to denial-of-service attacks and potential hijacking of the client's credentials.

    • One-way authentication. In NTLM, a domain controller or member server authenticates a client using pass-through authentication but the client never gets to verify the identity of the domain controller or member server. This raises the possibility of a man-in-the-middle attack.

      Origin of the Name "Kerberos"

      Kerberos takes its name from the mythological three-headed hound that guarded the gates of the underworld. This is because it uses three parties to carry out a transaction:

      • A client (called a security principal)

      • A target server (called a validating server)

      • A central credentials repository (called a Key Distribution Center, or KDC)

      If you're interested the spelling of the name Kerberos and details about the mythological origins of the name, take a look at the "Moron's Guide to Kerberos," www.isi.edu/~brian/security/kerberos.shtml.

    • Limitless logon time. After a user has negotiated domain access via NTLM, the user is free to stay on the domain forever unless an administrator has imposed a specific logoff time. This means that a bad guy who manages to hijack a set of credentials can use them indefinitely.

    • No support for transitive trusts. In a classic NT multi-master domain architecture, users from one domain can only access resources in a domain that directly trusts their domain. If Domain A trusts Domain B and Domain B trusts Domain C, users from Domain C cannot access resources in Domain A.

    • No support for delegation. If a client initiates a process on a remote classic NT server, that process cannot reach out and access a resource on another server. This limits the capability of NT to support multi-tiered network applications. (An example of a multi-tiered application would be a database where one server holds the processes that implement the business rules while another holds the database.)

    Authentication Methods Supported by Windows Server 2003

    In spite of the limitations of NTLMv2, Windows Server 2003 continues to support it for backward compatibility. In an Active Directory domain, the default authentication mechanism is Kerberos. This is negotiated in the background and works completely transparently to the user.

    Windows Server 2003 uses Kerberos authentication in the following instances:

    • Authenticating modern Windows clients (Windows Server 2003 and XP, Windows 2000) when they log on to an Active Directory domain.

    • Authenticating modern Windows clients when they access modern Windows servers that are members of an Active Directory domain.

    • Authenticating modern Windows clients who access an Active Directory domain from another Active Directory domain in the same forest, from a different Active Directory forest via a Forest Root trust, or from an MIT v5 Kerberos realm via a Realm trust.

    Windows Server 2003 uses NTLMv2 authentication in the following instances:

    • Authenticating modern Windows clients logging on to a classic NT domain.

    • Authenticating classic NT clients logging on to an Active Directory domain.

    • Authenticating classic or modern Windows clients accessing servers in an Active Directory domain via an external trust.

    • Authenticating users logging on to standalone modern Windows computers.

    • Authenticating modern Windows clients accessing resources on standalone modern Windows servers.

    • Authenticating downlevel clients accessing a modern Windows server if the client is configured with the Active Directory add-on.

    Windows uses LM authentication to support Windows 9x clients that not been configured with the Active Directory add-on, Dsclient.exe.

    You can verify the method used to authenticate a particular user by enabling logon/logoff auditing.

    Overview of Kerberos Transactions

    Kerberos uses three parties to authenticate users:

    • A security principal who wants access to network resources. This could be a user or a service running on a computer.

    • A validating server that receives the security principal's connection request and needs to verify the user's identity.

    • A Key Distribution Server that holds the credentials for both the security principal and the validating server and issues special messages called tickets that the two parties use to verify each other's identity.

    A Kerberos transaction resembles a scene from a John Le Carré spy novel. Imagine that a mole needs to contact her parent spy organization. She sends a prearranged signal and the parent organization agrees to send a runner to meet her. The mole has never seen the runner. The runner has never seen the mole. When they meet, how do they verify that they are genuine? Simple. They have a common acquaintance, the Chief back at headquarters. Procedure 11.5 shows how it works.

    Procedure 11.5 High-Level Kerberos Example

    1. The runner calls the Chief and says, "Give me a secret that only you and the mole know."

    2. The Chief, always security conscious, verifies that the runner is genuine by verifying that the message was encrypted using the runner's secret encryption key.

    3. The Chief then gets out the personnel files for the mole and the runner. The personnel files contain the secret encryption keys known only to the principals.

    4. The Chief then builds a message to the mole. The message has two parts:

      • Part one contains a random number thought up by the Chief and encrypted with the runner's secret key.

      • Part two contains the same random number, the runner's name, and the time and date the chief wrote the note. This part is encrypted with the mole's secret key.

    5. The runner uses his secret key to decode the random number in his portion of the message. If the result is gibberish, he assumes that someone has impersonated the Chief and given him a fake message. If the number looks right, he puts the mole's portion of the message in his wallet for safekeeping.

    6. That afternoon, the mole and the runner meet. They exchange names and the runner gives the mole the second part of the Chief's message. They watch each other closely. We now have a Quentin Tarantino moment. (If you haven't seen the movie Reservoir Dogs, stop now and rent it.) Here's what happens:

      • If the mole cannot decode the Chief's message, the mole knows the runner is bogus and shoots him.

      • If the mole can decode the message, but the contents inside are scrambled, the mole knows the runner has fiddled with the message and she shoots him.

      • If the mole decodes the message and the runner's name in the message is different from the name he gave when they met, she shoots him.

      • If the mole has ever seen the random number before, she shoots him.

      • If the current time is later than the time the Chief wrote the note, the mole throws away the message and walks on.

    7. If none of these unfortunate circumstances occur, the mole hands the runner a message. It contains her name, the current time, and the total number of letters in the message. This message is coded using the random number in the Chief's message as an encryption key.

    8. The runner uses the random number he obtained from his part of the Chief's message to decode the mole's message. If the contents are garbled, the mole is an imposter and he shoots her. If the contents are clear but the timestamp is out of date, the mole is presenting an old message and he shoots her.

    9. If the runner can decode the mole's message and the contents are acceptable, the authentication is complete and the two of them begin sharing information.

    Extended metaphors make for slippery examples, but this game of I Know A Secret, Do You? parallels a Kerberos authentication fairly closely. The actual transactions are a bit more complicated only because the principals cannot meet face to face, so to speak. They send out their messages over a public network and so must assume that a bogeyman is out there capturing packets and using them to infiltrate the network.

    Before examining the authentication transactions in detail, it's important to understand the terms and expressions used by Kerberos. They differ significantly from those used by classic NTLM.

    Kerberos Vocabulary

    Kerberos has existed in the public domain for years and has a colorful language all its own. The mix of this terminology with those used to describe classic NT authentication makes for a hodge-podge of lingo that is dense even by network systems standards. The following list of Kerberos terms explains their meaning and maps them to their classic NT counterparts.

    Security Principal

    An authentication mechanism verifies the identity of an entity who wants access to resources. The Kerberos term for such an entity is security principal, or often just principal. In Windows, users and computers are Kerberos security principals.

    Realm

    Every authentication systemKerberos is no exceptionrequires a database to hold credentials. A Kerberos realm is defined by the contents of this database. The terms domain and realm are synonymous in Windows Server 2003. All objects in a domain, including those representing security principals, are contained in a single Active Directory database.

    Ticket

    The ticket is the fundamental unit of currency in Kerberos transactions. The ticket contains encrypted information that can only be read by the three parties involved in the transaction. It contains special features that prevent hijacking, replaying, or modifying the contents.

    Key Distribution Center

    The KDC is a central service that authenticates security principals and distributes tickets. (MIT Kerberos implementations can use separate servers for these two functions.)

    Ticket-Granting Function

    Whenever a security principal reaches out across the network to touch a server, it must present a Kerberos ticket for that server. The security principal obtains this ticket from the ticket-granting service of the KDC. In Windows Server 2003, the ticket-granting service is incorporated into the main Kerberos security package and does not appear as a separate item on a process list.

    Authentication Function

    Before security principals can obtain a Kerberos ticket, the KDC must verify their identity. The authentication service in a Kerberos KDC performs this function by checking the security principal's credentials against the contents of the security database.

    When the KDC successfully authenticates a security principal at initial logon, it returns a special ticket called a ticket-granting ticket, or TGT. When the security principal needs to access a particular server, it must obtain a session ticket from the KDC specifically for the target server. It submits the TGT to speed up the process of issuing the session ticket.

    This system of TGTs and session tickets resembles a county fair. You pay at the gate and you get a little stamp on your hand. That stamp doesn't give you permission to get on the midway rides. You have to buy individual tickets to get on the rides. When you do so, the attendant looks for the stamp on your hand to verify that you came through the front gate.

    KRBTGT Account

    When a KDC issues a ticket-granting ticket (TGT) to a security principal, it needs a way to assure that the contents of the TGT ticket haven't been modified when the principal returns the TGT to get a ticket to a server.

    The KDC protects the TGT by encrypting the contents with a secret key known only to the KDC. This secret key comes in the form of a password hash that is an attribute of an account called KRBTGT. You can see this account in the Users container by using the AD Users and Computers console.

    The KRBTGT account is built automatically when you promote or upgrade the first domain controller in a domain. The account cannot be deleted or renamed. You can change the password, but this is not recommended. If the KRBTGT password is known, you've compromised your entire authentication system. The KRBTGT password is long and complex. The system changes the password regularly.

    Validating Server

    A Kerberos validating server is equivalent to a Windows Server 2003 member server. A validating server forms the third leg of the three-way Kerberos transaction. When a client attempts to access a resource on a member server, the system at the client includes a Kerberos session ticket for the validating server. The validating server checks the ticket to see if it contains information placed there by the KDC and encrypted with the validating server's secret key.

    A validating server must belong to the same Kerberos realm as the KDC that issued the session ticket. This is important to remember when we get to cross-realm authentication.

    Kerberos Ticket Details

    A Kerberos ticket is a highly important part of the authentication process, so it's worth taking a detailed look at its structure. Figure 11.10 shows a diagram of the ticket (or ticket-granting ticket) and the message that contains it.

    Figure 11.10. Kerberos reply containing ticket-granting ticket or session ticket.

    graphics/11fig10.jpg

    Ports Used by Kerberos

    If you're responsible for configuring firewalls, or communicating to those who do, you'll need to know the ports used by Kerberos. A Windows KDC listens on these ports:

    • TCP and UDP port 88: authentication and ticket granting.

    • TCP and UDP port 464: classic Kerberos kpasswd (password reset) protocol; not used by Windows.

    When a client requests a TGT or a session ticket, the reply from the KDC contains two parts: a header that can be read by the client and the TGT or session ticket itself.

    • The client information in the reply is encrypted with the client's password hash so it cannot be read by a bad guy on the network.

    • A TGT is encrypted with the password hash of the KRBTGT account. The TGT can only be read by a domain controller because only domain controllers have the password hash of the KRBTGT account. This helps validates the authenticity and origin of the TGT.

    • A session ticket is encrypted with the password hash of the member server, which is the Kerberos validating server. This helps validate the authenticity of the session ticket.

    Here are the major elements of the reply message:

    • Session Key. This important field contains a random number that uniquely identifies the TGT or session ticket. A copy of the session key is included in the TGT/session ticket. The session key becomes the shared secret that the security principal and validating server use when checking each other's identities.

    • Validating server name. The name of the server that the user wants to access.

    • Realm name. This is the Kerberos realmWindows domainof the KDC that issued the TGT or session ticket.

    • Flags. A series of flags assigned by the KDC determine how the TGT or session ticket can be used. This includes permission to forward the ticket to another realm, which permits users in one domain to access servers in a trusted domain. A KDC can also put a flag on a ticket that authorizes a member server to use it as a proxy for the original client when accessing another server. Windows calls this delegation of trust.

    • Start time and end time. This information determines an interval after which the TGT or session ticket is automatically invalid. After a ticket expires, the principal must obtain another. This limits the time that a bad guy who was able to compromise a ticket could do damage.

    • Ticket version number. Windows uses Kerberos version 5.

    The encrypted ticket or TGT includes the following major fields:

    • Session key. This is a copy of the session key delivered to the client.

    • Client's name and realm. This tells the validating server the identity of the client and the realm that holds the client's secret key. If the client declares an identity when submitting the ticket that does not match the ticket contents, the validating server knows that someone has hijacked the ticket.

    • Transited realms. A user from one realm may want to get access to resources on a validating server in another realm. This is possible if there is a trust between the realms. This trust takes the form of a security principal in one realm that can be used to validate the identity of the security principal in the trusted realm. With the trust in place, a KDC can issue cross-realm TGTs to principals in other domains. When a client submits a cross-realm TGT, the KDC looks at the entries in the Transited Realms field to ensure that the client comes from a realm that has a set of cross-realm trusts with the KDC's realm. This helps implement transitive trusts that Windows relies on for building Active Directory trees and forests.

    • Timestamps. A TGT or session ticket contains three different timestamps: The time the ticket was issued, the time it begins being valid (for postdated tickets), and the time it stops being valid. Windows does not use nor does it accept postdated tickets.

      The expiration time is determined by a Time-To-Live (TTL) value configured at the KDC. For Windows, the default TTL is 10 hours. For this timestamp to work correctly, all KDCs in a realm must have their times synchronized. Windows uses the W32Time service to synchronize time between domain controllers. The acceptable time skew is five minutes.

    • Authorization data. This very important field has garnered a lot of attention in Microsoft's implementation of Kerberos.

    Additional Kerberos Elements

    Because it's a big, bad world out there, Kerberos takes pains to prevent likely attack scenarios. This includes hijacking tickets, denial-of-service attacks, and man-in-the-middle attacks.

    Authenticator

    If a bad guy can nab a session ticket out of a packet, it would be possible to impersonate a client and do lots of damage. To prevent this, a connection request between a security principal and a validating server includes a little piece of data called an authenticator.

    The authenticator consists of the client's name and realm along with a timestamp. The client encrypts the authenticator with the session key, the random number assigned to the session ticket by the KDC. The client knows the value of the session key because it was included in the client portion of the session ticket reply.

    When the validating server receives the access request, it decrypts the ticket with its own password hash. Now come a series of decision points:

    • If the server cannot decrypt the ticket, or if the internals of the ticket have been changed, it rejects the connection attempt out of hand.

    • If the server can decrypt the session ticket, it extracts the session key from the ticket and uses it to decrypt the authenticator. If the server cannot decrypt the authenticator, it has to assume that a bad guy has stitched together a ticket and an authenticator. It rejects the connection attempt.

    • The server then compares the contents of the decrypted authenticator with the information in the connection request. If the client's name or realm does not match, the server assumes that a bad guy has fiddled with the authenticator. It rejects the connection attempt.

    • If the user's credentials match but the timestamp is outside the acceptable five-minute skew, the server assumes that a bad guy has nabbed the authenticator for use at a later time. It rejects the connection attempt.

    • If the timestamp exactly matches a timestamp in an earlier authenticator, the server assumes that a bad guy is replaying an earlier connection and it rejects the attempt. If the server should ever get confused about the connection requests from a client, it will reject all connection requests for the five-minute duration of the time skew.

    If the session ticket and the authenticator survive the scrutiny of the validating server, the client is given access. Now let's see how Kerberos helps to stop man-in-the-middle attacks.

    Preauthenticator

    In the evolution of acronyms, DOS has now stopped being short for Disk Operating System and has become an acronym for Denial Of Service. One likely DOS attack for Kerberos consists of bombarding a KDC with invalid authentication requests in the hopes that the server would be so busy saying "No. No. No." that it would not have time to say, "Yes. Yes. Yes." to authentic requests.

    To avoid this type of attack, a KDC has the option of accepting ticket-granting ticket requests only from clients that include a special data structure called a preauthenticator in their initial Kerberos TGT request. The preauthenticator is simply a timestamp that has been encrypted with the client's password hash.

    When a KDC receives a TGT request, it retrieves the password hash from Active Directory and uses it to decrypt the preauthenticator.

    If the preauthenticator decryption succeeds (the contents pass a cyclic redundancy check), the KDC begins processing the TGT request. If the decryption does not succeed, the KDC returns a bad name or password error to the client.

    The KDC also verifies that the timestamp in the preauthenticator is within five minutes of the system time on the server just in case a bad guy is trying to submit a rigged TGT request.

    It takes relatively few CPU cycles to process a preauthenticator, so even a moderately powerful KDC can withstand a fairly heavy DOS attack.

    Mutual Authentication

    A standard Kerberos transaction goes in one direction only. The client submits a ticket and the server accepts the ticket. But what if a bad guy puts up a server that pretends to be another server? This bogus server accepts Kerberos tickets but instead of giving back the requested files, it returns files filled with viruses and Trojan horse programs and other nasties.

    A smart Kerberos client always makes sure that the server accepting the ticket is the real server. This is called mutual authentication. It's up to the client to request mutual authentication. All Windows clients do so.

    A mutual authentication transaction is the mirror image of the session ticket submittal transaction. The validating server encrypts a timestamp with the session key from the ticket and returns the result to the client in a reply message. The client evaluates the authenticator and only continues with the connection transaction if the evaluation succeeds.

    Negative Kerberos Caching

    Starting with Windows 2000 SP2, if a DC that is not the PDC Emulator receives a set of bad credentials for a user, it caches the result locally to reduce traffic to the PDC Emulator. By default, the user is limited to 10 forwarded requests. From that point forward, the user is denied access based on the cached information for a period of 10 minutes.

    Authorization Data

    Kerberos is an authentication protocol, not an authorization protocol. The difference can be a bit subtle. Here's an example.

    Back during our nation's adventure in managing Southeast Asian affairs, I opted for a tenure in the U.S. Navy on nuclear submarines with the (entirely valid) assumption that it was far safer sleeping next to a few tons of red-hot fissile material than boating along the Mekong.

    In the military, you quickly learn the difference between authentication and authorization. When you come aboard a nuclear submarine, a topside watch checks your ID. If your face doesn't match the picture on your ID, or your name isn't on the submarine's access list, the topside watch shoots you. (Well, maybe not that drastic, but you are denied access.) This initial identity check is your authentication.

    When on board the sub, you can visit the galley and the berthing areas, but without specialized clearance, you aren't allowed into sensitive areas like the torpedo room, the reactor area, or the wardroom wine cellar. This additional clearance constitutes your authorization to access the sensitive areas.

    As we've seen, modern Windows uses Kerberos for its authentication mechanism and a combination of access tokens and security descriptors to control authorization. When Microsoft engineers developed their Kerberos implementation, they chose to fold part of the authorization function into the Kerberos transactions. They did this by taking advantage of a field in the Kerberos ticket called the authorization data field.

    When the KDC is ready to build a ticket-granting ticket, it asks the LSASS for a special data structure called a Privilege Access Certificate, or PAC. This PAC contains the user information necessary to build a local access token for a user at a remote server. The PAC is digitally signed with both the domain controller's private key and the private key issued to the KDC service. This prevents a client or a bogus KDC from forging a PAC.

    PAC Contents

    A quick review of the PAC contents reveals many interesting items that relate directly to system administration. You'll recognize the parameters from group policies and user settings. Here is a list of the PAC elements:

    • The time the user logged on and when the user's session expires, if that option is set. The PAC also defines if the user should be forcibly logged off when the session expires.

    • The last time the user set her password and when she is allowed to change her password again (if a minimum password age policy is set). The password expiration date is also included.

    • The user's flat logon name. This is the name stored in Active Directory as the SamAccountName and exposed in AD Users and Computers as the Pre-Windows 2000 Logon Name.

    • The user's full name, stored as the Display Name in Active Directory. This name is not used for any security purposes.

    • The name of the classic NT logon script assigned to the user's account, if any. The script must exist in the Netlogon share of the logon server.

    • The UNC path to the user's roaming profile, if one has been assigned.

    • The UNC path to the client's home directory, if one has been assigned, along with the drive letter to use when mapping the home drive to the directory path.

    • The number of concurrent logon instances for the user. This number represents connections at the domain controller that constructs the PAC, not the entire domain, so it is not an accurate measure of concurrent logons.

    • The number of unsuccessful logon attempts since the last successful attempt at the domain controller issuing the PAC.

    • The user's Relative ID (RID). This number is combined with the domain SID to form a unique SID for the user.

    • The RID of the user's primary group, used only in POSIX.

    • The number of groups in the domain that have the user as a member and the RID for each of those groups.

    • The well-known SIDs applicable to the user, such as Authenticated User, Network User, and Everyone.

    • The name of the user's domain and name of the domain controller that authenticated the user.

    • The SID of the domain, used in conjunction with the RIDs to create unique user and group SIDs.

    • The SID of the resource domain, if the user logged on from a machine in a classic NT resource domain, and the SID of any groups in the resource domain that have the user as a member.

    PAC Documentation

    Documentation for the contents and format of a Privilege Access Certificate can be downloaded from www.microsoft.com/Downloads/Release.asp?ReleaseID=20597.

    In addition, there is another data structure embedded in the PAC called User Account Control. This structure defines a number of user settings, many of which you'll recognize from check blocks in the Account tab of the user properties in AD Users and Computers. The User Account Control settings are as follows:

    • Account Disabled

    • Home Directory Required

    • Password Not Required

    • Temp Duplicate Account (no longer used)

    • Normal Account

    • MNS Logon Account (undocumented and unused)

    • Interdomain Trust Account (represents a trust to another domain)

    • Workstation Trust Account (represents a member computer in the domain)

    • Server Trust Account (represents a classic backup domain controller)

    • Don't Expire Password

    • Account Auto Locked

    • Encrypted Text Password Allowed

    • Smart card Required

    • Trusted For Delegation

    • Not Delegated

    • Use DES Key Only (LanMan authentication only)

    • Don't Require Preauthentication

    PAC Usage

    Kerberos includes the PAC in the authorization data field of the ticket-granting ticket that it issues to a client. The Kerberos client caches the TGT and submits a copy each time it requests a session ticket from the KDC. When the KDC builds the session ticket, it extracts the PAC from the TGT and puts a copy in the authorization data field of the session ticket.

    After the member server validates the session ticket, the Kerberos security package extracts the PAC from the ticket and delivers it to the LSASS, which uses the PAC to build a local access token for the client. This means that if you add a user to a group or change the user's security settings, the user must log off and then back on again to get a new TGT with a new PAC that contains the new group SIDs.

    By eliminating separate transaction to obtain the user's PAC, Microsoft avoided additional steps in the access process. It also avoided potential vulnerabilities caused by passing the authorization information in a second, proprietary transaction. Unfortunately, this method for passing the PAC information was poorly documented at the release of Windows 2000, which angered many developers who wanted to port their applications to Windows Kerberos but did not have enough information about the PAC.

    In the two years since Windows 2000 was released, Microsoft has documented the PAC but has not exactly gone out of its way to support efforts to incorporate the authorization data into third-party products. For example, Samba clients still must use NTLM rather than Kerberos because the developers of the advanced version of Samba are waiting to get a fuller understanding of how the PAC is processed.

    At a much more esoteric level, the PAC also changed the way Microsoft implements Kerberos messages. Standard Kerberos requests and replies are small enough to fit into a single datagram and are therefore usually sent via UDP. A large PAC can exceed the size of a standard datagram, forcing the system to use TCP to guarantee sequential delivery of the entire session ticket. This can affect interoperability if a third-party Kerberos KDC is not coded to listen and respond on TCP port 88.

    Summary of Kerberos Elements

    Figure 11.11 shows the three corners of the Kerberos triangle and how information flows between the parties. Here's a capsulization before we look at the gory details:

    • A Windows domain is a Kerberos realm.

    • A Windows domain controller is also a Kerberos KDC.

    • A Windows KDC performs both classic KDC functions: authentication and ticket-granting.

    • Separate Windows domains in the same forest are connected via cross-realm Kerberos trusts. These trusts are two-way and transitive.

    • A modern Windows computer that is a member of an Active Directory domain is also a Kerberos security principal. Services running on the computer that access resources on other servers obtain session tickets from the KDC.

    • A modern Windows server that is a member of a Windows domain requires a Kerberos session ticket when being accessed by a modern Windows client. The server falls back to NTLM authentication for downlevel clients.

    • A user logging on at the console of a modern Windows computer that is a member of an Active Directory domain will automatically authenticate in the domain using Kerberos. This is true even in a Mixed domain where a classic PDC or BDC is available for authentication.

    • The authorization data field of TGTs and session tickets contain a Privilege Access Certificate (PAC) that details the information necessary to build local access tokens for users.

    Figure 11.11. Kerberos components and transactions.

    graphics/11fig11.gif

    With all this in mind, it's time to see what happens when users log on via Kerberos and attempt to get access to resources.

      Previous Section Next Section