Windows 2000 Authentication

Windows IT Pro

- Advertise

Windows 2000 Authentication
View the book table of contents

Author:	Jan De Clercq Micky Balladelli
Published:	March 2001
Copyright:	2001
Publisher:	Digital Press

Kerberos preauthentication data
Preauthentication is a feature introduced in Kerberos version 5. With pre-authentication data, a client can prove the knowledge of its password to the KDC before the TGT is issued. In Kerberos version 4 anyone, including a hacker, can send an authentication request to the KDC; the KDC doesn’t care. It doesn’t even care about authenticating the client: Authentication is completely based on the client’s ability to decrypt the packet returned from the KDC using its master key.

Preauthentication also lowers the probability for an offline password-guessing attack. Without preauthentication data, it is easy for a hacker to do an offline password-guessing attack on the encrypted packets returned from the KDC. During an offline password-guessing attack a hacker intercepts an encrypted packet, takes it offline, and tries to break it using different passwords. (This is also known as a brute-force attack, where a hacker tries out different keys [in this case passwords] to decrypt a packet until he or she finds the right key that decrypts the packet in cleartext.) To augment his chances, a hacker can even send out a dummy request for authentication; each time he or she will get back another encrypted packet, which means the hacker gets another chance to do a brute-force attack on the encrypted packet and to guess the user’s master key.

In a regular logon session the preauthentication data consist of an encrypted time stamp. When logging on using a smart card, the preauthentication data consist of a signature and the user’s public key certificate. In Windows 2000 preauthentication is the default. An administrator can turn it off using the Don’t require Kerberos preauthentication check box in the account options. This might be required for compatibility with other implementations of the Kerberos protocol. Preauthentication affects the content of a ticket: every ticket contains a special flag to indicate the use or non-use of preauthentication.

Kerberos encryption types
Windows 2000 Kerberos supports the following cryptographic algorithms: RC4-HMAC (see http://www.ietf.org/internet-drafts/draft-brezak-win2k-krb-rc4-hmac-01.txt) DES-CBC-CRC, and DES-CBC-MD5. The default encryption algorithm is RC4-HMAC. There are two reasons why Microsoft did not use DES as the default algorithm:

Ease of upgrading from NT4 to Windows 2000. The key used for RC4-HMAC can also be used with the Windows NT 4 password hash.
Export law restrictions. In the early stages of the Windows 2000 development, 56-bit DES could not be exported outside the U.S. Because Microsoft wanted to use the same Kerberos encryption technology in both the domestic and export versions of the product, they chose the 128-bit RC4-HMAC alternative. RC4-HMAC was already exportable at that point in time.

Kerberos can be forced to use DES by setting the Use DES encryption for this account property on the Windows 2000 account. This may be needed for authentication interoperability with other non — Windows 2000 systems. The algorithm used for a Kerberos ticket can be checked using the klist or kerbtray resource kit utilities.

Table 6.8 shows the algorithms and their supported key lengths. When the Windows 2000 Strong encryption fix has been installed, RC4-HMAC can use 128-bit keys for bulk encryption. A Windows 2000 domain can contain a mix of clients with and without the fix installed. Windows 2000 Kerberos will automatically choose the strongest available encryption algorithm.

TABLE 8: KERBEROS ENCRYPTION TYPES KEY LENGTHS
Algorithm	Authentication	Confidentiality Protection
RC4-HMAC	128	56*
DES-CBC-CRC	56	56
DES-CBC-MD5	56	56
*Upgradeable to 128-bit keys with the Strong encryption fix installed.

Authenticator content
Table 6.9 shows the authenticator fields, their meaning, and whether they are sent in encrypted format across the network.

TABLE 9: KERBEROS AUTHENTICATOR CONTENT
Encrypted?	Name	Meaning
Yes	Authenticator-vno	Version number of the authenticator format. In Kerberos v5 it is 5.
Yes	Crealm	Name of the realm (domain) that issued the corresponding ticket.
Yes	Cname	Name of the server that issued the corresponding ticket (principal name)
Yes	Cksum	(Optional) Checksum of the application data in the KRB_AP_REQ
Yes	Cusec	Microsecond part of the client’s time stamp
Yes	Ctime	Current time on client
Yes	Subkey	(Optional) Client’s choice for an encryption key to be used to protect an application session. If left out, the session keyfrom the ticket is used.
Yes	Seq-number	(Optional) Initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages (protection against replay attacks)

TGT and ticket flags
In this section, we will focus on the TGT and ticket flags. The ticket flags and their meaning are explained in Table 6.10.

TABLE 10: KERBEROS TICKET FLAGS
Flags	Meaning
Forwardable	Indicates to the Ticket-Granting Server that it can issue a new ticket-granting ticket with a different network address based on the presented ticket.
Forwarded	The ticket has either been forwarded or was issued based on authentication involving a forwarded ticket-granting ticket.
Proxiable	Indicates to the Ticket-Granting Server that only non-ticket-granting tickets may be issued with different network addresses.
Proxy	The ticket is a proxy.
May be postdated	Indicates to the Ticket-Granting Server that a postdated ticket may be issued based on this ticket-granting ticket.
Postdated	End service can check the ticket’s authtime field to see when the original authentication occurred.
Invalid	The ticket is invalid.
Renewable	The ticket is renewable. If this flag is set, the time limit for renewing the ticket is set in RenewTime. A renewable ticket can be used to obtain a replacement ticket that expires later.
Initial	The ticket was issued using the AS protocol instead of being based on a ticket-granting ticket.
Preauthenticated	Indicates that, during initial authentication, the client was authenticated by the KDC before a ticket as issued. The strength of the preauthentication method is not indicated but is acceptable to the KDC.
Hardware preauthentication	Indicates that the protocol employed for initial authentication required the use of hardware expected to be possessed solely by the named client. The hardware authentication method is selected by the KDC, and the strength of the method is not indicated.
Target trusted for delegation	This flag means that the target of the ticket is trusted by the directory service for delegation.

Some important notes on the use of the ticket flags in Windows 2000 Kerberos:

By default, every Windows 2000 ticket has the forwardable flag set. This default behavior can be reversed by setting the Account is sensitive and cannot be delegated property on an account object. Windows 2000 Kerberos does not support proxy tickets.
By default, every Windows 2000 ticket has the renewable flag set. "Renewable" means that a ticket can be renewed, it does not always mean that an existing ticket is automatically renewed. In Windows 2000, for example, the operating system will not automatically request a new ticket (a TGT or a service ticket) when it expires. It will, however, get a new ticket when it needs one. As long as a user’s credentials are cached locally this will happen without an additional password prompt.
By default, every Windows 2000 ticket has the preauthenticated flag set.
Every Windows 2000 TGT has the initial flag set.
A Windows 2000 ticket has the Target trusted for delegation flag set if the service or user account to which the ticket belongs has the Account is trusted for delegation property set. Or, in the case of a computer or a service using the local system account, if the computer object has Trust computer for delegation set.

A single ticket can contain multiple flags. The flags are added to a Windows 2000 ticket’s properties as a hexadecimal 8-bit number, of which only the first four bits are significant. One bit can refer to different flags. If flags refer to the same bit position, they are added hexadecimally. This hexadecimal number is displayed when looking at the ticket cache using the resource kit tool klist; the other resource kit tool, kerbtray, automatically converts the number to its appropriate meaning. Table 6.11 shows the bit values and the associated ticket flags.

TABLE 11: KERBEROS TICKET FLAGS AND BIT VALUES
Bit 1	Bit 2	Bit 3	Bit 4
8 N/A	8 Proxy (4)	8 Renewable (8)	8 N/A
4 Forwardable (1)	4 May be postdated (5)	4 Initial (9)	4 Target trusted for delegation (12)
2 Forwarded (2)	2 Postdated (6)	2 Preauthenticated (10)	2 N/A
1 Proxiable (3)	1 Invalid (7)	1 Hardware preauthentication (11)	1 N/A

To facilitate the analysis, Table 6.12 lists the results of adding hexadecimal numbers. Hexadecimal A equals 8 + 2 (decimal 10); hexadecimal D equals 8 + 4 + 1 (decimal 13).

TABLE 12: DECIMAL AND HEXADECIMAL FLAG VALUES
	8	4	2	1
A	*		*
B	*		*	*
C	*	*
D	*	*		*
E	*	*	*
F	*	*	*	*

Some examples of typical ticket flags are as follows:

0x40e00000
4 (Forwardable)
e = 14 = 8 (Renewable) + 4 (AS:Initial ticket ) + 2 (PreAuth)
0x40840000
4 (Forwardable)
8 (Renewable)
4 (Target trusted for delegation)

To illustrate the way the flags are used let’s examine a local logon and a network logon. The domain layout used in these logon sequences consists of one parent domain, corp100.com, and two child domains, eu100.corp100.com and na100.corp100.com (as illustrated in Figure 30). The klist command prompt tool used to look at the content of the ticket cache comes with the Windows 2000 platform SDK; the GUI tool, kerbtray, comes with the Windows 2000 resource kit.

Local logon example A user defined in the na100 domain logs on to the na100 domain from machine dc2-na100, which is also part of the na100 domain. Kerbtray or klist tickets reveal the following local ticket cache content (see Figure 31):

1 TGT for the na100 domain
1 ticket for the local machine: dc2-na100

Network logon example The same user accesses a resource located on machine dc1-eu100 in the eu100 domain. Kerbtray or klist tickets reveal the local ticket cache content (see also Figure 32).

This time the cache contains six tickets, of which four are TGTs. The 4 TGTs reflect the Kerberos referral process: There’s one TGT for corp100, one for eu100, and two for na100. The tickets are for the user’s local machine (dc2-na100) and for the resource machine in the eu100 domain (dc1-eu100).

Let’s take a closer look at the four TGTs.

TGT 1 for na100
Flags: 40e
4 (Forwardable)
e = 14 = 8 (Renewable) + 4 (AS:Initial ticket) + 2 (PreAuth)
TGT 2 for na100
Flags: 60a
6 = 4 (Forwardable) + 2 (Forwarded)
a = 8 (Renewable) + 2 (PreAuth)
TGT 3 for corp100
Flags: 40a
4 (Forwardable)
a = 8 (Renewable) + 2 (PreAuth)
TGT 4 for eu100
Flags: 40a: see TGT3

Kerberized applications
Kerberized applications are applications that use the Kerberos authentication protocol to provide authentication, and maybe, in a later phase, to provide encryption and signing for subsequent messages. Authentication can be related to a user, a machine, or a service (any principal). In its current release, Windows 2000 includes the following Kerberized applications:

LDAP to AD
CIFS/SMB remote file access (CIFS stands for Common Internet File System — more info at http://www.cifs.com)
Secure dynamic DNS update (explained in Chapter 2)
Distributed file system management
Host to host IPsec using ISAKMP
Secure intranet Web services using IIS
Certificate request authentication to Certification Authority (CA)
DCOM RPC security provider

Smart-card logon
Windows 2000 includes extensions to Kerberos version 5 to support public key — based authentication. These extensions are called PKINIT, as defined in draft-ietf-cat-kerberos-pk-init-09.txt. Although Microsoft claims to adhere to this draft, they didn’t implement one of the required algorithms: Diffie-Hellman. PKINIT enables smart-card logon to a Windows 2000 domain. PKINIT allows a client’s master key to be replaced with its public key credentials in the Kerberos authentication request (KRB_AS_REQ) and reply (KRB_AS_REP) messages. This is shown in Table 6.13.

TABLE 13: MAPPING THE STANDARD KERBEROS MASTER KEY TO THE PKINIT PUBLIC-PRIVATE KEY
Standard Kerberos Use of Master Key	PKINIT Replacement
Client-side encryption of the preauthentication data	Private key
KDC-side decryption of the preauthentication data	Public key
KDC-side encryption of session key	Public key
Client-side decryption of session key	Private key

PKINIT introduces a new trust model in which the KDC isn’t the first entity to identify the users (as was the case with the master key concept). Prior to KDC authentication, users are identified by the Certification Authority (CA) in order to obtain a certificate. In this new model the users and the KDC obviously all need to trust the same CA.

Figure 33 and the following list show the way Kerberos smart-card logon works (notice that the cryptic names of the Kerberos messages have changed):

Alice starts the logon process by introducing her smart card and by authenticating to the card using her PIN code. The smart card contains Alice’s public key credentials: her private-public key pair and certificate.
A TGT request is sent to the KDC (AS); this request contains the following (PA-PK-AS-REQ):
Alice’s principal name and a time stamp
The above signed with Alice’s private key
A copy of Alice’s certificate
To validate the request and the digital signature on it, the KDC will first validate Alice’s certificate. The KDC will query the Active Directory for a mapping between the certificate and a Windows 2000 SID; if it finds a mapping, it will issue a TGT for the corresponding SID.
The KDC sends back the TGT to Alice. Alice’s copy of the session is encrypted with her public key (PA-PK-AS-REP).
To retrieve her copy of the session key Alice uses her private key.

KERBEROS CONFIGURATION
Kerberos GPO settings
The Windows 2000 account policies (part of the GPO computer configuration) include a special subfolder for Kerberos-related policy settings. It contains the following GPO entries:

Maximum lifetime for service ticket: in Microsoft terminology, a service ticket is a plain Kerberos ticket; its default lifetime is ten hours.
Maximum lifetime for user ticket: in Microsoft terminology, a user ticket is a Kerberos TGT; its default lifetime is ten hours.
Maximum lifetime for user ticket renewal: by default, the same ticket (service or user ticket [TGT]) can be renewed up until seven days after its issuance. After seven days, a new ticket has to be issued.
Maximum tolerance for computer clock synchronization: this is the maximum time skew that can be tolerated between a Kerberos authenticator’s time stamp and the current time at the KDC or the resource server. Kerberos is using a time stamp to protect against replay attacks. Setting this setting too high creates a bigger risk for replay attacks. The default setting is five minutes.
Enforce user logon restrictions: This setting enforces the KDC to check the validity of a user account every time a ticket request is submitted. If a user doesn’t have the right to log on locally or if the user’s account has been disabled, he or she will not get a ticket. By default, the setting is on.

Another Kerberos-related GPO entry is located in local policies/user rights assignment subcontainer: checking Enable computer and user accounts to be trusted for delegation sets the trusted for delegation property of user and computer objects in a domain, site, or organizational unit.

An important detail is that the Kerberos GPO settings can be defined only once for each AD domain. You cannot define custom Kerberos settings for a particular OU or site.

Kerberos-related account properties
Every Windows 2000 user account has a set of Kerberos-related properties. Most of them are related to Kerberos delegation, one is related to the use of preauthentication, and one is related to the choice of the Kerberos encryption algorithm.

Every user account has the properties Account is trusted for delegation and Account is sensitive and cannot be delegated. Every machine account has the Trust computer for delegation property. These settings can be used to limit Kerberos delegation in space (for a limited set of users or service accounts on a predefined set of machines). The technical details behind delegation were explained earlier in this chapter. By default Account is trusted for delegation and Trust computer for delegation are disabled. An exception are DCs: they are always trusted for delegation. If the check box in a user or machine object’s properties is checked, it means that the user or machine account can forward the credentials of any Kerberos principal. In Kerberos terminology this means that the account can act as a delegate. Setting this property adds the Target trusted for delegation (also called OK_AS_DELEGATE) flag to the account’s tickets. If a user account has the Account is sensitive and cannot be delegated property set, the administrator instructs the KDC not to issue any forwardable tickets to that particular user account.

Do not require Kerberos preauthentication must be set when the account is using a Kerberos implementation that does not support preauthentication. As discussed earlier, Windows 2000 Kerberos supports preauthentication. Use DES encryption for this account must be set for an account using a Kerberos implementation that only supports DES encryption. Windows 2000 Kerberos uses RC4-HMAC for encryption; DES is the encryption algorithm defined in the first version of Kerberos.

Kerberos authentication database security
The credentials (a user’s ID and hashed password) used during the Kerberos authentication sequence are stored in the Active Directory. Anyone with sufficient cryptographic knowledge who can access the authentication database and obtain the user credentials could impersonate any user. Since we’re dealing with a multimaster directory model, the risk for unauthorized access is even bigger.

Accessing the credentials is, however, not that simple, as shown in the following list:

Access to every Active Directory object is validated by the Directory Service Agent (DSA), which is linked to the Local Security Authority (LSA). The LSA and DSA are both part of the Windows 2000 kernel.
To protect against offline attacks (e.g., on a copy of the Active Directory database located on a backup tape) the Active Directory can be encrypted with a special key called the syskey. This feature was also available in NT4 to protect the SAM. If you’re implementing this solution, look for a very safe place to store the symmetric key (the syskey) used for encryption. Also, remember that you cannot use syskey on just one DC. If you use it on one DC, you have to use it on every DC. Futhermore, syskey makes it impossible to do a remote reboot of the DC.
Replication of AD information among Windows 2000 DCs occurs across a secure channel. The secure channel guarantees the confidentiality of the replicated data.

In high-security environments, it can be appropriate to install the KDC service on a DC that is located in a room with sufficient physical security provisions.

Page: 1, 2, 3, 4, 5, 6, 7

ADS BY GOOGLE