Logging on to Windows using Kerberos: Single domain environment

This excerpt from "Windows Server 2003 security infrastructures" looks in detail at both local and network logon features in single and and multiple domain environments.

Windows Server 2003 security infrastructures The following excerpt, courtesy of Elsevier Digital Press, is from Chapter 5 of the book "Windows Server 2003 security infrastructures" written by Jan De Clercq. Click for the complete book excerpt series or purchase the book.

Logging on to Windows using Kerberos:
Single domain environment

Now that we have explained the basic Kerberos protocol, we can discuss some real-world Windows Kerberos logon examples. In this section we will look in detail at both local and network logon features in single and multiple domain environments and in a multiple forest scenario.

Jump ahead for help logging on in multiple domain or multiple forest environments.

Typical examples of logon method in a single domain environment are:

  • Alice is logging on from a machine that is a member of the domain where Alice's user account has been defined (this is a local logon method).

  • Alice accesses a resource located on a machine that is a member of Alice's logon domain (this is a network logon method).

Local logon process

Figure 5.11 shows what happens during a local logon process in a single domain environment.

Everything starts when Alice presses Ctrl+Alt+Del and chooses to log on to the domain.

    1. The client Kerberos package acting on behalf of Alice tries to locate a KDC service for the domain; it does so by querying the DNS service (Windows 2000 and Windows Server 2003 publish two Kerberos-specific SRV records to DNS: _kerberos and _kpasswd. The list of all published SRV records can be found on a domain controller in the "%windir%system32confignetlogon.dns" file. The SRV DNS records are created automatically during the domain controller setup, as part of the dcpromo process). The Kerberos package will retry up to three times to contact a KDC. At first it waits 10 seconds for a reply; on each retry it waits an additional 10 seconds. In most cases a KDC service for the domain is already known. The discovery of a domain controller is also a part of the secure channel setup that occurs before any local logging on.

    2. Once the DC is found, Alice sends a Kerberos authentication request to the DC. This request authenticates Alice to the DC and contains a TGT request (KRB_AS_REQ).

    3. The Authentication Service authenticates Alice, generates a TGT, and sends it back to the client (KRB_AS_REP).

Figure 5.11 Local logon process in a single domain environment.

    4. The local machine where Alice logged on is -- just like any other resource -- a resource for which Alice needs a ticket. Alice sends a ticket request to the DC using her TGT (together with an authenticator) (KRB_TGS_REQ).

    5. The TGS of the DC checks the TGT and the authenticator, generates a ticket for the local machine, and sends it back to Alice (KRB_TGS_REP).

    6. On Alice's machine, the ticket is presented to the Local Security Authority, which will create an access token for Alice. From then on, any process acting on behalf of Alice can access the local machine's resources.

Network logon process

When Alice is already logged onto a domain and wants to access a resource located on a server within the same domain, a network logon process will take place. In this case, the logon sequence is as follows (see Figure 5.12):

    1. Alice sends a server ticket request to the DC using her TGT (together with an authenticator) (KRB_TGS_REQ).
    2. The TGS of the DC checks the authenticator, generates a server ticket, and sends it back to Alice (KRB_TGS_REP).
    3. Alice sends the ticket (together with an authenticator) to the application server (KRB_AP_REQ).
    4. The application verifies the ticket with the authenticator and sends back his or her authenticator to Alice for server authentication (KRB_AP_REP).

Figure 5.12 Network logon process in a single domain environment.

Disabling Kerberos in migration scenarios

In certain migration scenarios it may be necessary to disable the Kerberos authentication protocol on your Windows Server 2003 domain controllers. Remember from Chapter 4 that for Windows 2000 Professional and later clients, the first authentication protocol of choice is always Kerberos -- at least if the client is talking to a Windows 2000 or later DC.

Imagine the following migration scenario: You have migrated all your client platforms to Windows XP and you upgraded one of your Windows NT4.0 DCs to Windows Server 2003 -- all the remaining DCs are still on NT4.0. In this scenario the one and only Windows Server 2003 DC may become overloaded by Kerberos authentication traffic because all Windows XP clients try to authenticate against it. Also, if this DC becomes unavailable, the clients cannot be authenticated anymore. Once a client has been authenticated by a Kerberos KDC it will not fall back to NTLM and NT4 DCs. This is a typical scenario where you may want to temporarily disable the Kerberos authentication protocol on the Windows Server 2003 DC.

To disable Kerberos, Microsoft provides a registry hack (the hack is available from Windows 2000 Service Pack 2 onward). The hack is called NT4Emulator (REG_DWORD) and should be added to the HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Netlogon/ Parameters registry key of the Windows 2000 SP2 or later DC and set to value 1.

The creation of this key on the Windows 2000 SP2 or later DC creates another problem because it will make it impossible to manage the AD using any of the MMC-based AD management tools. To get around this problem, you must make a registry change on the clients from which you want to use the AD management tools. Add the NeutralizeNT4Emulator registry value (REG_DWORD) in the HKEY_LOCAL_MACHINE/System/Current-ControlSet/Services/Netlogon/Parameters registry key and set it to value 1.

The role of SPNs

One of the great features of Kerberos is its support for mutual authentication. The enabling technologies for mutual authentication are the Kerberos protocol itself, User Principal Names (UPNs), and Service Principal Names (SPNs). The UPN and SPN concepts were introduced in Chapter 2. In the following we will look at how SPNs are used during the Kerberos authentication exchanges.

Let's take the example of a network logon process: A user decides to access a file on another server during his or her logon session. In this example the following SPN-related events will occur during the authentication exchanges:

  • 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 that is responsible for the file the user wants to access. This message is sent to the user's domain controller. A Kerberos client can always construct a service's SPN -- how this works was explained in Chapter 2.

  • The KDC queries the AD (In the first place it will query the local domain Naming Context of the user's authentication DC; after that, it will query the global catalog.) to find an account that has a matching SPN (this process is also known as "resolving" the SPN). The service's SPN must be unique in the AD. If more than one account is found with a corresponding SPN, the authentication will fail.

  • Given the service account corresponding to the SPN and the associated master key, the KDC can construct a service ticket and send it back to the client. (This is the "KRB_TGS_REP" message.)

  • In the next step the client sends a "KRB_AP_REQ" message to the file server (including the service ticket and a Kerberos authenticator).
  • Finally, the service will authenticate back to the client (this is the "KRB_AP_REP" message). This is where the real mutual authentication happens.

Click for the next excerpt in this series: Logging on to Windows using Kerberos: Multiple domain environment.

Click for the book excerpt series or visit Elsevier to obtain the complete book.

Read more on Server hardware