• 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

    Analysis of Kerberos Transactions

    Modern Windows clients use Kerberos authentication in the following three situations:

    • Initial computer startup. The client computer uses credentials stored in the LSA database to authenticate with an Active Directory domain controller. It then establishes a secure channel to that logon server.

      Kerberos Authentication in Mixed Domains

      A modern Windows computer that belongs to a Mixed domain will always authenticate with an Active Directory-based domain controller if one is available. This is true even if the computer must authenticate across the WAN to get to the AD-based domain controller.

      Modern Windows clients check for service locator (SRV) records in DNS every time they start. As long as they don't see any indication of an AD-based domain, they're happy to use NTLM to authenticate. But after they see SRV records, they will insist on using Kerberos.

      This behavior can come as a surprise if you've deployed hundreds or thousands of Windows 2000 and XP desktops while you are still running a classic NT4 domain. As soon as you upgrade your PDC to an AD-based domain controller, every modern Windows client will see the SRV records and go right to that AD-based domain controller to authenticate. They may come from all corners of the globe.

      You can inhibit this behavior, but to do so you must put a Registry entry in place. See Chapter 9, "Deploying Windows Server 2003 Domains," for details.

    • Service account authentication. Some services use Kerberos authentication when connecting to other servers. These so-called Kerberized applications register themselves as distinct security principals in Active Directory. Examples of Kerberized connections include LDAP connection to Active Directory, CIFS/SMB file access, and secure dynamic DNS updates.

    • Initial user logon. A user logging on to an Active Directory domain from a modern Windows computer authenticates at the same domain controller as the computer.

    Let's take a look at this last transaction, a user who logs on to an Active Directory domain from a modern Windows client. The transaction details are the same for Windows Server 2003, Windows XP, and Windows 2000.

    Initial User Logon Authentication

    Figure 11.12 shows a user logon in a single Active Directory domain. Here are the key points to watch for:

    • The user must present domain credentials to get access to a domain member computer.

    • The user's plain-text and encrypted password is never transmitted over the wire.

    • The user is issued a ticket-granting ticket (TGT) during the initial domain authentication.

    Figure 11.12. Logon transaction in a single AD-based domain.

    graphics/11fig12.gif

    Determining the Identity of the Logon Server

    You can identify a user's logon server by opening a command prompt and running SET. Here's a partial listing. The LOGONSERVER variable is in bold:

    C:\>set
    ALLUSERSPROFILE=C:\Documents and Settings\All Users
    APPDATA=C:\Documents and Settings\Administrator\Application Data
    CommonProgramFiles=C:\Program Files\Common Files
    COMPUTERNAME=SRV1
    ComSpec=C:\WINDOWS\system32\cmd.exe
    HOMEDRIVE=C:
    HOMEPATH=\Documents and Settings\Administrator
    LOGONSERVER=\\SERVER1
    

    Procedure 11.6 traces the transaction starting from the initial logon.

    Procedure 11.6 User Logon Transaction Using Kerberos

    1. The user initiates logon by pressing Ctrl+Alt+Del. This is called the Secure Attention Sequence. It wakes up Winlogon and displays the logon credentials window defined in Gina.dll. This foils any Trojan horse programs that might get in ahead of the operating system and nab a user's password.

    2. The user enters an account name and password and selects a domain in the Domain field of the logon window. As an alternative, the user could enter a User Principal Name (UPN) in the format user@domain.root. Either name format results in the same actions on the part of the security system.

      UPN Versus Domain\Name Logon Format

      A persistent rumor in the Windows administrator community asserts that entering a username and domain in Winlogon results in a classic NTLM authentication, whereas entering a UPN results in a Kerberos authentication. Unlike the protestations of a certain ex-president, there is absolutely no truth to this rumor. If the local computer has authenticated in an AD-based domain, the user will be authenticated using Kerberos regardless of the logon format. The only difference between using domain\name\password and a UPN is that the UPN requires a query to a Global Catalog server to extract the username and domain. Windows Server 2003 and XP clients cache the results of this query in case a GC server is not available.

    3. Winlogon takes the user's credentials and passes them to the Local Security Authority Subsystem, LSASS, which hashes the user's password using MD4 and then works with the Kerberos package to authenticate the user.

    4. The Kerberos package takes the user's password hash and uses it to construct a TGT request that contains the preauthenticator (a timestamp encrypted with the user's password hash). (This transaction does not require Netlogon at either the client or the domain controller.)

    5. The KDC service at the domain controller receives the TGT request. If the user's name exists, the service obtains the user's password hash from Active Directory and uses it to decrypt the preauthenticator.

    6. If the KDC fails to decrypt the preauthenticator, or if the timestamp indicates that it has been replayed or is out of the acceptable time skew, the authentication fails. The KDC sends a logon failure notification to the client.

    7. If the KDC accepts the preauthenticator as genuine, it gets help from LSASS to create a PAC for the user. It places the PAC in the authentication data field of the TGT and returns it inside a reply message to the user. The TGT is encrypted with the password hash of the krbtgt account. The entire reply is encrypted with the user's password hash.

    8. The Kerberos client decrypts the reply and caches the session key and TGT in memory, not on disk. It turns the PAC over to LSASS.

    9. The LSASS uses the information in the PAC to build a local access token for the user. (It adds the SIDs of any machine local groups that have the user as a member and any local security policies that apply to the user.)

    10. When the TGT expires (the default Time-To-Live is 10 hours), the client obtains a new TGT from the KDC. This happens transparently with no service interruption unless no domain controller is available, in which case the client loses access to the domain until a domain controller can be made available.

    At this point, the console logon is complete. Winlogon passes control over to Userinit, which downloads and processes Registry-based group policies and then fires off the Explorer shell in the user's security context. Any subsequent processes spawned by the user get the user's access token.

    Authentication When Accessing Member Servers

    Following domain authentication, the user then accesses resources on member servers in the domain. Let's take a look at what happens. The key points to watch for are as follows:

    • The client must go back to its logon server to get a session ticket for the target server.

    • The client presents the session ticket to the member server inside the first connection transaction along with an authenticator and a mutual authentication request.

    • The member server decrypts the ticket, validates the authenticator, and responds with an authenticator of its own. It also creates a local access token for the user.

    • The client validates the server's authenticator.

    Procedure 11.7 traces the transaction from the point where the user reaches out to touch a network resource.

    Procedure 11.7 Server Access Transaction Using Kerberos

    1. The user opens My Network Places, navigates to a server icon, and double-clicks the icon.

    2. The network redirector calls on LSASS to get a Kerberos ticket for the target server. LSASS turns right around and calls on the Kerberos security package for help.

    3. The Kerberos package gets a copy of the cached ticket-granting ticket (TGT) and uses it to build a session ticket request specifying the target server's name. The request is encrypted using the session key that came with the TGT.

    4. The KDC receives the request and decrypts it with its copy of the session key. If the decryption fails, the KDC knows that someone has hijacked the ticket. If the contents do not pass CRC (Cyclic Redundancy Checking), the KDC knows that someone fiddled with the contents.

    5. The KDC then builds a ticket for the target server. The ticket contains a new session key specific to this particular transaction. The KDC delivers the ticket to the client in a reply message. The ticket itself is encrypted with the target server's password hash. The entire reply is encrypted with the user's password hash.

    6. The Kerberos package decrypts the reply and caches the session key and the ticket. It uses the session key to build an authenticator. It includes the authenticator and the ticket in an access request that it hands over to the network redirector.

    7. The redirector builds a Server Message Block (SMB) message asking the server to create a session and to let the client connect using that session. It includes the Kerberos access request with that initial SMB message.

    8. The target server extracts the access request from the SMB and passes it to LSASS, which calls on the local Kerberos package to decrypt the ticket and validate the authenticator.

    9. When the client has been validated, the Kerberos package extracts a copy of the session key from the ticket and uses it to build an authenticator of its own, which it returns to the client in an access reply.

      At the same time, the server extracts the PAC from the authorization data field of the ticket and gives it to LSASS, which uses it to build a local access token for the user. (LSASS adds the SIDs of any machine local groups that have the user as a member and any local security policies that apply to the user.)

    10. The client validates the authenticator returned by the server and then completes the SMB session setup.

    11. When the session ticket expires (10 hours by default), the Kerberos package obtains another ticket from the KDC. It does this transparently to the user unless a domain controller is not available, in which case the user loses access to the member server.

    Viewing Kerberos Tickets

    You'll find two tools in the Resource Kit that help troubleshoot Kerberos transactions by listing the ticket-granting tickets and tickets obtained by a client:

    • Kerbtray. This utility places an icon in the System Tray that you can double-click to view a list of tickets and details about the ticket contents. Figure 11.13 shows an example.

      Figure 11.13. Kerbtray window showing ticket list.

      graphics/11fig13.gif

    • KLIST. This command-line utility is derived from the classic MITv5 Kerberos utility of the same name. Here is an example listing:

      C:\>klist tickets
      Cached Tickets: (2)
         Server: krbtgt/COMPANY.COM@COMPANY.COM
            KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
            End Time: 11/25/2001 19:55:37
            Renew Time: 12/2/2001 9:55:37
      
      
         Server: SERVER1@COMPANY.COM
            KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
            End Time: 11/25/2001 19:55:37
            Renew Time: 12/2/2001 9:55:37
      

    Cross-Domain Authentication

    One of the most powerful features of Kerberos is its capability to handle transitive cross-realm authentications. This means that a user in one domain can access a security object (NTFS file or folder, AD object, Service, or Registry key) in any other domain in a forest as long as an administrator has configured the object's security to authorize access.

    Figure 11.14 shows an example of a cross-domain authentication transaction. In the example, a user in a child domain in one tree is trying to access a shared folder on a member server in a child domain in another tree. The roots of the two trees share a two-way trust.

    Figure 11.14. Forest of domains showing cross-domain authentication.

    graphics/11fig14.gif

    Domain controllers in one domain cannot issue session tickets for member servers in another domain. Recall that domains form separate naming contexts in Active Directory. A domain controller only has access to its own naming context. (A global catalog server has a partial replica of every Domain naming context, but the GC does not contain all the information necessary to build a session ticket.)

    For the same reason, Kerberos clients from one domain cannot go directly to a KDC in a remote domain to obtain a session ticket to a server in that domain. The client has no credentials in the remote Domain naming context.

    The local domain controller supports cross-domain access by obtaining a cross-realm TGT from its parent domain on behalf of the user. It returns this cross-realm TGT to the client along with a referral to the parent domain.

    The domain controller can obtain the cross-domain TGT thanks to a Kerberos feature called delegation. Using delegation, a service on one machine can obtain TGTs or session tickets on behalf of a user on another machine. This is a powerful feature and one that represents a security vulnerability if it is not handled correctly. We'll take a closer look at delegation in the next topic.

    The client follows up on the referral by submitting the cross-realm TGT to a domain controller in the parent domain and asking once again for a session ticket to the target server. If the server is not in that domain, the domain controller obtains a cross-realm TGT either to its own parent or to the top domain in the tree that contains the target domain.

    Using this process, the client "walks the tree," asking each domain in its path for a ticket to the target server and obtaining a cross-realm TGT and a referral until it finally arrives at the domain that contains the target server. At this point, the client submits its cross-realm TGT to a domain controller in the target domain. The domain controller validates the TGT and issues a session ticket to the target server.

    Part of the validation performed by the domain controller includes a determination that each domain transited (crossed by) by the client is trusted by domains on either side. The domain controller knows the domains transited by the client because that information is stored in the cross-realm TGT. The domain controller knows the forest structure based on partition information in Active Directory (also known as knowledge).

    From this point, the transaction proceeds very much like a regular Kerberos transaction. The client submits the session ticket and an authenticator to the member server and is granted access. The PAC in the session ticket originated in a remote domain, so the user will only be authorized to access resources on the server if someone has added the user to the DACL on the resources.

    Short-Cut Trusts

    The example in the previous section demonstrated how transitive, two-way Kerberos trusts make it possible for a user to access resources anywhere in the forest by logging on to one domain.

    In an extensive, multi-domain environment, you may experience performance problems with cross-domain authentication. This slowdown is caused because the client is forced to communicate across the WAN when it walks the tree to get cross-realm authentication, as shown in Figure 11.15.

    Figure 11.15. Forest showing short-cut trust between two child domains.

    graphics/11fig15.gif

    If the delays are too long and your users complain, you can shorten the process by creating a short-cut trust between one domain and another in a forest. The short-cut trust tells the KDC that it can go directly to the target domain for a cross-domain TGT and avoid walking the tree.

    Kerberos Delegation

    In the classic NTLM authentication shown in Figure 11.16, there is no support for pass-through authentication from one server to another server. This limits the ability of NT to support so-called n-tier applications. N-tier applications use a middle server to field user requests and then pass the request to one or more back-end servers.

    Figure 11.16. Forest showing short-cut trust between two child domains.

    graphics/11fig16.gif

    Because of the restrictions in NTLM, applications such as web front ends or Object Resource Brokers (ORBs) are required to log on to the back-end server using credentials stored at the middle server. This is commonly done using accounts and passwords embedded in ODBC connections or ActiveX Data Object (ADO) connections or third-party application data structures.

    The problem with this sort of configuration is that all the user accounts essentially multiplex through the middle server into a single account that touches the backend servers. This creates a security problem if the application on the middle server is somehow compromised. You also lose accountability for user access to the back-end server.

    Kerberos makes it possible for a middle server to obtain a user's credentials and to use those credentials when accessing a back-end server. This can be done in one of two ways:

    • Forwardable tickets. In this configuration, the middle server asks the client to obtain a session ticket for the back-end server. The middle server then uses this ticket to make connection to the application running on the back-end server. The ticket must be flagged as forwardable for this trick to work.

    • Proxiable tickets. In this configuration, the middle server asks the client to obtain a ticket-granting ticket for the domain and to give that TGT to the middle server. The middle server then uses the TGT to obtain a session ticket to the back-end server on behalf of the user. This TGT must be flagged as proxiable.

    The difference between forwardable and proxiable tickets is the difference between lending a friend $10 for lunch and giving the friend a power of attorney and your checkbook.

    The middle server can obtain Kerberos tickets to make it appear to be any user in the forest, so it occupies a highly secure position. For this reason, standard servers cannot obtain forwardable or proxiable tickets. A server must be flagged as "Trusted for Delegation" before it can obtain Kerberos tickets on behalf of a user.

    Additional Kerberos Benefits

    You might look at all these Kerberos features and say to yourself, "Fine. I like them. But we still have thousands of Windows 98 and NT4 workstations and hundreds of NT4 servers and we aren't going to be upgrading them overnight. I guess we'll have to forgo all those nifty features for a good, long while."

    Fortunately, you don't have to wait as long as you might expect. As soon as you shift the domains in your forest to Native, the downlevel clients can participate in transitive trusts. In Native, domain controllers use transitive Kerberos trusts to obtain cross-domain TGTs and tickets on behalf of downlevel clients. Here's how it works.

    When an LM or NTLM client attempts to touch an NT server in another Native domain, the server in the remote domain uses NTLM pass-through authentication to contact a domain controller in its domain.

    The domain controller uses delegation to walk backward through the tree to obtain a cross-realm TGT on behalf of the client. This TGT is sufficient to authenticate the user in the remote domain.

    The domain controller then completes the pass-through authentication and informs the member server that the user has been authenticated. It includes a classic NT data structure with the user's SIDs and security privileges that it obtained from the PAC in the cross-realm TGT.

    Here's the bottom line. If you have Native domains in your forest, your NT, Windows 9x, and Samba clients get the following benefits:

    • Domain Local groups can be placed on local ACLs.

    • Users on the downlevel can access resources on any server in any domain (assuming they are on the local ACLs).

    The reason this doesn't work in Mixed is because the Active Directory domains retain their classic NT limitations. After all, a client might authenticate on a classic BDC rather than an Active Directory domain controller and that eliminates the possibility of a cross-realm transaction.

    Kerberos Policies

    You can change certain Kerberos parameters by setting group policies. The policies are set in the Default Domain group policy. They are located under Computer Configuration | Windows Settings | Security Settings | Account Policies | Kerberos Policies. The polices are as follows:

    • Enforce user logon restrictions. Each member server in a domain has a set of local account policy restrictions. These restrictions stipulate things like local logon permissions and who has permission to access the computer across the network. By default, the KDC validates that a user meets a server's local account restrictions prior to issuing the user a session ticket to the server. This adds more steps to the logon process but saves traffic by preventing the user from getting a session ticket that cannot be used anyway because of the local restriction.

    • Maximum lifetime for service ticket. A service ticket is the same as a session ticket. Every session ticket has a default Time-To-Live of 10 hours. You can shorten this interval, but be careful not to make it too short or you will force the clients to obtain new tickets too often. The setting must be longer than 10 minutes and shorter than the Maximum lifetime for user ticket setting.

    • Maximum lifetime for user ticket. A user ticket is the same as a ticket-granting ticket. By default, a TGT has a 10-hour lifetime, after which it must be renewed. The minimum setting is 10 minutes and should not be set lower than the Maximum lifetime for service ticket setting.

    • Maximum lifetime for user ticket renewal. By default, TGTs can be renewed for a period of seven days. After that, the TGT expires and a new TGT must be obtained.

    • Maximum tolerance for computer clock synchronization. By default, the maximum clock skew is five minutes. This value should not be changed.

      Previous Section Next Section