The effect of short-cut trusts on multiple-domain logon traffic
A typical scenario when you would create a short-cut trust is a Windows 2000 domain tree, where a massive amount of authentication traffic occurs between two domains logically linked together using a transitive trust. The short-cut trust example illustrated in Figure 20 shows how the number of referrals is reduced and how the trust path used during authentication is shortened; note that the KDC in NA.compaq.com can detect the existence of the short-cut trust when querying AD. It has enough intelligence to refer Alice directly to the KDC in Europe.compaq.com.
In the example in Figure 19 the creation of a short-cut trust between NA and Europe would affect the authentication steps as follows:
- Step 1: Alice uses her TGT to obtain a ticket from a KDC in the NA domain for the resource server in the Europe domain. The KDC in the NA domain isn’t the authoritative KDC for the resource server’s Europe domain, so the KDC in the NA domain refers Alice to the domain closest to the target domain the NA domain has a real trust relationship with. This domain is Europe.
- Step 2: A KDC in the resource server’s Europe domain, authoritative for that domain, generates a ticket for Alice.
- Step 3: Alice uses the ticket to access the resource server.
Multiple-domain logon: behind the scenes
In this section, we’ll explain some of the concepts behind multiple-domain logon: referral tickets, interrealm keys, Authentication service, and Ticket-Granting Service. To fully understand multiple-domain logon, we will also introduce two special Kerberos principals: the domain trust account and the krbtgt principal. We will also explain what we mean by a "real" trust relationship.
Domain trust accounts To enable interdomain authentication every domain trusted by domain A is registered in domain A’s AD domain NC as a special Kerberos principal, also known as a domain trust account. Inter-domain authentication traffic (the referral tickets mentioned previously) are secured using the master key and the session key of these domain trust account principals (see also LSA trusteddomain object discussion in the previous chapter). The domain trust account’s keys are also referred to as inter-realm keys. As for any other account, the domain trust account’s master key is the account’s password. Also, as for any other account, the password of a domain trust account is changed on a regular schedule.
The master key of the domain trust account also explains the "real" trust relationship concept we referred to in the previous sections. A real trust relationship is nothing else than a shared secret (a key) between the DCs of two different domains, as follows:
- If only domain A is registered as a domain trust account in domain B, we have a one-way trust going from B to A (domain B trusts domain A). In this scenario the master key of the domain trust account of domain A is the shared secret behind the one-way trust.
- If only domain B is registered as a domain trust account in domain A, we have a one-way trust going from A to B (domain A trusts domain B). In this scenario the master key of the domain trust account of domain B is the shared secret behind the one-way trust.
- If both are registered as domain trust accounts, we have a two-way trust. In this scenario the master key of the domain trust account of both domains is the shared secret used for the two-way trust relationship.
The creation of the domain trust accounts and their master keys (the interrealm keys) happens automatically during the DCPROMO process when a domain joins an existing domain tree. More details on the types of trust relationships are provided later on in this chapter.
Now it should also be clear why the Kerberos authentication traffic follows real trust relationships — also known as the trust path (based on domain trust accounts) — and not transitive trust links. A transitive link is not secured; there’s no shared secret between two domains linked using a transitive trust. The reason for this is pretty obvious: there are no domain trust accounts defined between two domains linked using a transitive trust. If you don’t have a secret you cannot use the trust link to send authentication traffic. This is also why a transitive trust is just a logical concept.
The krbtgt account To explain the use of the KRBTGT account we must first explain why the Kerberos KDC is made up of two subservices: the Authentication Service (AS) and the Ticket-Granting Service (TGS). The services offered by a KDC can be split into two service categories; each sub-service has a set of different tasks, as follows:
- The Authentication Service authenticates accounts defined in the domain where the AS is running and issues TGTs for these accounts.
- The Ticket-Granting Service issues tickets for resources defined in the domain where the TGS is running.
Splitting up the KDC into two subservices offers the flexibility to run the two subservices on two different servers; unfortunately, this is not supported in Windows 2000.
The AS and TGS services share a secret that is derived from the password of the krbtgt principal. The krbtgt principal is the security principal used by the KDC; its master key will be used to encrypt the TGTs that are issued by the KDC. The krbtgt account is created automatically when a Windows 2000 domain is created. It cannot be deleted and renamed. As with any other account, its password is changed regularly. In the Windows 2000 users and computers snap-in this account is always shown as disabled.
Multiple-domain logon revisited Now that we’ve explained interrealm key, krbtgt, domain trust account, and what’s behind a real trust relationship, let’s look once more at how multiple-domain logon works. A basic rule in Kerberos is that to access a resource a user needs a ticket. How can Alice get a ticket for a resource contained in a domain different from Alice’s definition domain? Remember that a ticket for a resource can only be issued by an authoritative DC. Let’s once again use the example of Alice defined and logged on in domain NA.compaq.com, who decides to access a resource in Europe.compaq.com (as illustrated in Figure 21).
To resolve this issue Kerberos uses referral tickets, domain trust accounts and interrealm keys. In this scenario, the KDC of NA.compaq.com would issue a referral ticket to Alice to access compaq.com. What is a referral ticket? A referral ticket is a TGT, which Alice can use in domain compaq.com to get a ticket for a resource in that domain. The KDC of NA.compaq.com can issue such a TGT because compaq.com is a principal (remember the domain trust account) in its domain. How can the KDC of compaq.com trust a TGT that was issued not by itself, but by the KDC of NA.compaq.com? The KDC of compaq.com will decrypt the TGT with the interrealm key of its domain trust account in NA.compaq.com. If the decryption comes out valid, the KDC will consider the TGT trustworthy. The same things will happen when compaq.com issues a referral ticket for Alice to request a service ticket to a KDC in the Europe.compaq.com domain.
The referral process we just explained relies heavily on AD and the Global Catalog (GC). First, it uses the GC to find out, given the Service Principal name (SPN) in which domain the resource is located and thus which DC can issue a ticket to access the resource. The service that’s responsible for a resource is always registered in the GC. SPNs (and UPNs) are unique identifiers for users and services that want to authenticate using Kerberos. SPNs (and UPNs) are explained in detail in Section 6.6.1. Then it uses AD to find out the domain closest to the target domain to which Alice should be referred. Since GCs are not shared between forests, referrals and Kerberos authentication will not work between forests.
Kerberos in the Windows 2000 startup and logon sequence
So far, we’ve explained the Kerberos authentication sequence in all its possible flavors. In the following text, we will look at where the Kerberos authentication sequence fits into the Windows 2000 machine startup and user logon sequence. We will see that the Kerberos authentication sequence is executed more than once during machine startup and that machine startup and user logon includes much more than just user and machine authentication.
Machine startup
Figure 22 shows the different processes that take place during a regular Windows 2000 client machine startup. The different processes are as follows:
- The client starts up. The network interface is initialized. If the machine is not configured with static IP configuration information, it will run through the DHCP configuration process to obtain its IP configuration.
- Once the client’s network interface has been configured and the network protocol stack has been initialized, the machine will launch a DNS query for an LDAP service (Windows 2000 DC) to one of its configured DNS servers. The DNS query will look for an _ldap._tcp.default-first-site-name._sites.dc._msdcs.<domain name> SRV record. (The site name depends on the one registered on the machine, by default it is default-first-site-name).
- When an LDAP service (Windows 2000 DC) has been located, the client will launch an LDAP query for a DC of the machine’s definition domain to the LDAP server ("definition domain" means the domain containing the machine account).
- The client will then negotiate an SMB dialect with the DC. The Server Message Block protocol (SMB) is an important file sharing protocol in both NT4 and Windows 2000. It is used to provide remote file services in a distributed client/server environment. Later on in the startup, it will be used by the client to download configuration information (including GPO settings) from the DC.
- Next, the client will set up a secure channel with the DC. To do this it will connect to the DC’s netlogon service. The secure channel is needed to send confidential information, such as authentication data, from the client to the DC in a secure way. Secure channels were explained in detail in Chapter 5.
- Once the secure channel has been set up, the client will launch another DNS query to its DNS server to find an authentication server (in Windows 2000, a DC running a KDC service). The DNS query will look for a _kerberos._tcp.default-first-site-name._sites.dc._msdcs.<domain name> SRV record. The site name depends on the one registered on the machine; by default it is default-first-site-name.
- The machine Kerberos authentication phase takes place.
- The Kerberos authentication takes place for every service that is not running using the local system account.
- The client will then connect to the IPC$ share on the DC and start the Distributed File System (DFS) referral process. The DFS referral process downloads DFS configuration information from the DC to the client (downloading happens using the SMB protocol).
- The client launches an RPC call to the DC to convert its name into a Distinguished name (DN).
- Using the DN the client can then perform an LDAP query against its DC to find out the group policies applied to it. The group policy information is downloaded using the SMB protocol.
- The client then launches another LDAP query to the DC to find out PKI configuration information (e.g., What are the Enterprise CAs?).
- If NetBIOS is enabled on the client, it will start a browser election.
- The client performs time synchronization with its DC.
- Finally, the client launches a DNS query for the start of authority of its DNS domain; the client then performs a dynamic update of its DNS records on the DNS server returned from the previous query.
- The client startup will be completed by closing down the connections with the DC.
User logon
Once a machine has been started up, a user can log on to it interactively. Figure 23 shows the different processes that take place during a regular Windows 2000 user logon. As we will see, the user logon process is much shorter than the machine startup process. The different processes are as follows:
- After the machine has started up successfully, a CTRL-ALT-DEL screen will be displayed on the screen, permitting the user to start an interactive logon session by pushing CTRL-ALT-DEL.
- The user presses CTRL-ALT-DEL, fills in a set of credentials, and presses OK or Enter.
- The user Kerberos authentication sequence takes place.
- The machine launches an RPC call to the DC to convert the user name to a Distinguished name (DN).
- Using the DN the client can then perform an LDAP query against its DC to find out the group policies applied to the user. The user group policy information is downloaded using the SMB protocol. At the same time DFS referral information linked to the user will be down-loaded.
- The user logon will be completed by closing down the connections with the DC.
ADVANCED KERBEROS TOPICS
In this section we’ll focus on some advanced Kerberos topics: Kerberos principal identifiers, the link between authentication and authorization, the content of Kerberos tickets and authenticators, the details behind smart-card logon, Kerberos transport protocol and port usage.
Principal identifiers
One of the great features of Kerberos is its support for mutual authentication. The enabling technologies for mutual authentication are Kerberos itself, User Principal names (UPNs), and Service Principal names (SPNs). In this section, we’ll explore UPNs and SPNs.
User principal names
Windows 2000 users can log on to a Windows 2000 domain using an NT4-like account name or using a User Principal Name (UPN). A Windows 2000 account also has other identifiers associated with it: the X.500 DN (Distinguished Name), the GUID, and the SID. In this section we focus on names that can be used to log on to Windows 2000.
The concept of a UPN is an extension to the standard Kerberos protocol. A UPN must be unique in the forest. Every user also keeps his or her down-level NT4-like logon name: <domain Name>\<SAM Name>. Contrary to the UPN, the NT4-like logon Name must only be unique in the domain. The UPN is stored in the userprincipalname property of a Windows 2000 account. It is validated at logon time first by searching the local Active Directory domain NC, and then the GC.
A UPN consists of a principal’s name, an @ symbol, and a DNS domain name. (UPNs are defined in RFC 822.) There’s no need for the DNS domain Name to correspond to the domain containing the user account. It needs to correspond to a domain that has a trust relationship with the principal’s domain or to an alternate domain name listed in the UPNsuffixes property of the Partitions container (part of the configuration naming con-text). UPNsuffixes can be set from the Windows 2000 GUI: Use the properties of the active directory domains and trusts container in the Active Directory Domains and Trusts MMC snap-in (as illustrated in Figure 24).
The UPN stays the same independently of what happens with the user principal after its creation. The following administrative actions do not affect the UPN: moving a user principal to another domain and renaming a user principal’s NT4-like name.
From a user’s point of view, Windows 2000 UPNs enable the user to log on with his or her e-mail address. This can be risky from a security point of view: A hacker sniffing SMTP traffic can immediately catch half of the user’s credentials.
Service Principal Names
A Service Principal Name (SPN) is a service identifier. Once you can identify a service, you can also authenticate it and that’s what we want in Kerberos mutual authentication. As with UPN, an SPN must be unique in the Windows 2000 forest. It is associated with a service’s logon account; associated means that the SPN is stored in the service logon account’s AD object ServicePrincipalName attribute. An SPN can only be associated with one account. To look at the SPNs associated with a machine account use the support tools tool, adsiedit, or use the resource kit tool, setspn. Typing set-spn — l <machinename> at the command prompt will list all the SPNs linked to <machinename> (as illustrated in Figure 25).
To enable a user to construct the SPN without knowing the service’s logon account, SPNs have a fixed format and do not contain any reference to the service account. This format is ServiceClass/Host:[Port]/[Service-name], where:
- ServiceClass is a string identifying the service. Examples are www for a Web service, and ldap for a directory service.
- Host is the name of the computer on which the service is running. This can be NetBIOS or a DNS Name. Since a NetBIOS name is not necessarily unique in the forest, it’s advisable to use DNS Names.
- Port is an optional parameter for the service port number. It enables the user to differentiate between multiple instances of the same service running on the same machine.
- ServiceName is an optional parameter used to identify the data or services provided by a replicable service or to identify the domain served by a replicable service. A replicable service is a service running on different machines and whose data are replicated among different machines.
Let’s look at how SPNs fit into the Kerberos authentication. We will take the example of a user who decides to access a file on another server during his or her logon session. The steps are as follows:
- The Kerberos software on the client side constructs a Kerberos KRB_TGS_REQ message, containing the user’s TGT and the SPN of the service responsible for the file the user wants to access. Notice that the client can construct the SPN even though he or she doesn’t know the service account. The Kerberos software sends this message to the user’s authentication DC.
- The KDC will query the AD (in the first place the local domain NC, afterwards the GC) to find an account that has a matching SPN (this process is also known as resolving the SPN). If more than one account is found, the authentication will fail.
- Given the service account and its master key (which is also stored in AD), the KDC will construct a service ticket, and send it back to the client. (This is the KRB_TGS_REP message.)
- Next step is the client sending a KRB_AP_REQ message to the file server (including the service ticket and a Kerberos authenticator).
- In the last step, the service will authenticate back to the client (KRB_AP_REP message). This is where the real mutual authentication happens.
One more remark on step 1. In most cases the Kerberos software may not get the SPN from the user, but just an LDAP or HTPP URL. Windows 2000 includes a special OS function called DsCrackNames, which can make conversions between different naming formats. This function can, for example, transform an LDAP URL to an SPN.
To end our discussion about SPNs let’s take a look at the conditions that should be met in order for mutual authentication to work. They are as follows:
- Both the user’s and the service’s account must be defined in a mixed-or native-mode Windows 2000 domain.
- Both accounts must be defined in domains that are part of the same Windows 2000 forest. Remember that the KDC queries the GC to locate the service account associated with an SPN. In Windows 2000, GCs do not span forests.
- The user must be authenticating from a Windows 2000 machine and the service must be running on a Windows 2000 machine. The reason for this is that an SSP is needed that supports mutual authentication; so far only the Kerberos and the Negotiate SSP support mutual authentication.
- The SPN must include the full DNS name of the server on which the service is running.
|
Page:
1,
2,
3,
4,
5,
6,
7
|
next page  |
|
|
|
|
Windows IT Pro
Register
