Kerberos Tickets: The Keys to Trusted Access

With Kerberos, authentication is a done deal as long as the information between the parties can be decrypted, or as long as one party can prove that it is the real thing by being in possession of the decrypting key in the first place, like our cyber-lovers discussed earlier. Now, what if someone on the network steals the key, or manages to bug previous authentication sessions and somehow builds a key? Kerberos takes care of this problem because it assumes that someone will be nasty enough to try and hack in.

The Kerberos authentication process kicks into gear as soon as a user or service tries to gain access to a domain (or Keberos realm, to be more precise). At this stage of the authentication, Keberos assumes that the network is not secure and that it is possible for anybody to infiltrate the communication between the client and the server.

When Kerberos receives an authentication request from the Windows security services, it performs the following steps before any access to the network is permitted:

1. It looks the user up in a directory, in our case Active Directory, and retrieves the encryption/decryption key it shares with the user to decrypt the user’s authentication message.

2. Next it looks at the information in the message. The first item it checks is the time field, which is the time on the clock of the user’s workstation or machine from which the user attempted to log in. If the time on the sender’s clock is out of sync by five minutes, Kerberos will reject the message (Kerberos can compensate for the different time zones, and daylight saving time). However, if the time is within the allowable offset of five minutes, Kerberos accepts the message. But wait, there is more.

3. Kerberos now checks to see if the time is identical or older than previous authenticators received from the partner. If the time stamp is not later than and not the same as previous authenticators, Kerberos allows the user to authenticate to the domain.

However, it is also important to know that the authentication is mutual. Kerberos will send back a message demonstrating that it was able to decrypt the user’s message. This means that the partner server or device is able to verify that it, too, is not masquerading. This is something that NTLM, the legacy Windows authentication service, could never do. Kerberos sends back only select information, the most important being the time stamp that it obtained from the original authentication from the client. If that time stamp matches the client’s information, then the client is sure that Kerberos and not some imposter decrypted the message.

Key Distribution

So authenticating to Kerberos works well for authentication to the domain, but what about accessing resources once the client has logged in? After all, the whole idea of logging in is to connect to SQL Server and to start working. So how is the connection to SQL Server trusted in the way described earlier? Remember, NTLM and Windows/Active Directory security services cannot vouch to SQL Server that, just because the client logged in okay, he or she is touched by an angel. To put it differently, “How trusted is trusted access?” On the old Windows NT 4.0 domain, I would have balked at the idea of “trusted access” because NT was as outmoded in a digital nervous system as a Model-T on Mars. SQL Server trusting a user on an NT network is like you or me trusting a used car salesperson, just because he or she is dressed well. But you can safely implement trusted access on Windows Server 2003, Active Directory because with a PKI in the picture or even just native Active Directory security you can distribute keys.

Essentially, Kerberos has the capability to forward a “letter of credit” for every client it can vouch for to the server. This letter of credit is a session key, which tells SQL Server “this guy’s for real.” In other words, it acts as a broker. This in fact is where the name Kerberos, the protocol, comes from. You may recall from Greek mythology that Kerberos (or Cerberos) was a three-headed dog that stood guard over the gates of Hades. Kerberos, the protocol, also has three heads: the client, the server, and a mediator or proxy. The proxy is known as the Key Distribution Center (KDC)-it doles out session keys that it fabricates when the client authenticates. In Windows Server 2003, the Key Distribution Center is installed on the Active Directory Domain Controller.

If you have not studied Kerberos extensively, the authentication process just described might sound too complex and bandwidth-intensive to be of use on a modern network. If decrypting the messages and checking time stamps has to be repeated between clients and servers all the time, and if the KDC has to keep sending all the network resources copies of every user’s session key all the time, it would seem to be a tremendous drain on resources. Every server would have to store session keys from thousands of users. But this is not the case-what in fact takes place is ingenious, is simple, and has no impact on the network.

Session Tickets

Instead of following the logical option and sending the “letter of credit” to every server and every client at one time, the KDC sends two copies of the session key (one belonging to the server) to the client and then attends to other connections. The client thus holds the SQL Server host’s copy of the key until it is ready to contact the server, usually within a few milliseconds. This process is illustrated in Figure 5–7.

Figure 5–7: Key distribution and mutual authentication

The KDC invents a session key whenever the client contacts it to access a SQL Server host (A). The KDC sends the session key to the client, and embedded in the session key is the session ticket (B). Embedded in the session ticket, which really belongs to the SQL Server host, is the host server’s session key for the client.

As soon as the client receives the session communication from the KDC, it opens the ticket and extracts its copy of the session key. Both items are then stored in volatile memory. When the client is ready to contact SQL Server (C), it will send the server a packet that contains the ticket still encrypted with the server’s secret key and the time authenticator encrypted with the session key.

If everything checks out, the SQL Server host grants access to the client (D) because the server knows that a trusted authority, the KDC, issued the credentials. After the connection is allowed, the Net-Libraries can do their thing and begin login to SQL Server; credentials can then be passed into the instance and teamed up with the SQL Server login. As soon as the client is done using the server, the server can get rid of the session key that the client was using to communicate with the server. The client will instead hold the session key and represent it to the server each time it needs to access it. But no other client can try to connect to SQL Server under the guise of a user that just disconnected or might still be using the system.

Session tickets can also be reused, and as a safeguard against ticket theft, the tickets come with expiration times. The time-to-live for a ticket is specified in the domain security policy, which is discussed later in this chapter in the section “The SQL Server Security Plan.” Typical ticket life is usually about eight hours, the average login time. When the user logs out, the ticket cache is flushed and all session tickets and keys are discarded.

Kerberos, Trusts, and Login Delegation

Kerberos provides the technology that allows Windows Server 2003 domains to interoperate as bidirectional, transitive trusts, as long as the domains are part of a contiguous namespace (such as an Active Directory tree). Domains in separate domain trees or in separate forests can, however, share an interdomain key, and one KDC becomes the proxy for the other and vice versa. This makes for a secure environment that can safely allow a user in a foreign domain to connect to SQL Server.

Once an interdomain key has been established, the ticket granting service in each domain is registered as a security principal with the other domain’s KDC, allowing it to issue ticket referrals. Clients in their own domains still need to contact their local KDCs for access to a foreign resource. The process is as follows:

1. The local KDC checks to see if the resource needed by the client resides in another domain.

2. If it does, it sends the client a referral ticket for the resource in the other domain.

3. The client then contacts the other domain’s KDC and sends it the referral ticket. The remote KDC authenticates the user or begins a session ticket exchange to allow the client to connect to resources in the remote domain. The domain-to-domain trust model is illustrated in Figure 5–8.

Figure 5–8: The domain-to-domain trust model under Kerberos

What takes place on a Windows Server 2003 network is as follows: The client delegates authentication to a server by telling the KDC that the server is authorized to represent the client. In lay terms, that is like telling the KDC that the SQL Server machine you are authenticated to has power of attorney to deal with the second SQL Server machine. This is similar in process to the concept of the access token, another f orm of attorney, agency, proxy, or what Microsoft calls “impersonation”-an unfortunate word.

Delegation can be done as follows:

1. The client can obtain a ticket from the KDC for the referred server. Upon connection to the login server, the client must hand this ticket to the server. Such a ticket is called a proxy ticket. Difficulty arises in this scenario because the client needs advance knowledge of the other server, which becomes a management cost in both the client and server tiers.

2. The better option is to allow the client to issue the login server a ticket granting ticket (TGT), which can be set up upon initial presentation to the SQL Server login server, which can then use this TGT to obtain a ticket for the referred server, as needed. Such a ticket is also known as a forwarded TGT.

The forwarded tickets are managed in Kerberos policy in Active Directory. Kerberos policy is managed in the Default Domain Group Policy object and is something you need to set up outside of SQL Server at your domain controller. You or your network administrator will need to manage the policy object in Active Directory, by a process you’ll find described in Windows Server 2003 help or a good book on Windows Server 2003 security.

You will notice when you set up delegation that each ticket has a time-out period that can be defined in Active Directory. If a connection remains idle for too long, the ticket will expire and all subsequent attempts to execute a distributed query or a remote stored procedure will fail. The user will have to disconnect from the login server and reestablish the connection if your application keeps the connection open. This is an added security benefit, because most well-written applications should not keep connections open indefinitely. In distributed or n-tier scenarios, it is unlikely your client will be maintaining openended connectivity to the server.

Looking at the connection from the viewpoint of the secondary server, when SQL Server instance A connects to SQL Server instance B and executes a distributed query that references tables on instance B, then instance B has access to your login credentials. Instance B can then validate your individual permissions to access the data from the tables referenced.

On a Windows network, you have to specifically define a login on A to connect to B. The login is global and is used regardless of which user executes the distributed query on A. Instance B will not have any knowledge of the actual user executing the query, and you cannot define permissions specific to individual users connecting from A. You will have to define a global set of permissions for the login account used by A. The solution on Windows is also less secure. For example, you cannot audit what the specific users are doing in B.

Configuring Delegation

There are a number of things to consider before you can support delegation. The following checklist highlights the necessary components to manage or configure:

• DNS   You need to install a DNS server as the locator service for Kerberos. The DNS service that ships as part of Windows Server 2003 Server is the best DNS to use because it is tightly integrated with Active Directory and supports dynamic updates. If you already use another brand of DNS, note that the governing RFC (1510) specifies how DNS should resolve KDC hosts to IP addresses. In a Windows Server 2003 domain, the KDC is usually installed on the Active Directory server, the domain controller. They are not connected in terms of application process space and run as separate services. However, since the KDC is always installed on the DC, it is possible to resolve a KDC by looking up the host address of a domain controller. Client computers in a Kerberos realm need to send their messages to the IP address, and if the IP address of the KDC cannot be resolved, it generates an error message to the client indicating that the domain cannot be located.

• Active Directory   You will need to install Active Directory if your primary network is not a Windows Server 2003 network. It is also possible to install Windows Server 2003 servers in non-Windows Server 2003 domains or networks (such as Linux), and they can still participate in Kerberos authentication. You will need to ensure that they resolve to the correct host addresses, which might not be Active Directory domain controllers. The utility called ksetup.exe (in the Windows Server 2003 Resource Kit) is used to configure clients and servers to participate in Kerberos realms that are not Windows Server 2003 domains.

• TCP/IP   All computers participating in SQL Server delegation will need to be running TCP/IP, and you will need to ensure that TCP/IP is the Net-Library being used by all clients and servers.

• Computer Account   Your SQL Server computer should have an account in Active Directory. Find or create the account, open to the General tab of the server Properties dialog box, and ensure that the appropriate Delegation option is checked. This is illustrated in Figure 5–9.

  
  Figure 5–9: Configuring the computer account for delegation

• Service Principal Name (SPN)   A service principal name (SPN) identifies an instance of SQL Server as a security principal. The SPN is defined or set using the setspn utility, which can be found in the Windows Server 2003 Resource Kit. The SPN is typically created by a Windows Server 2003 domain administrator. The syntax to create the SPN is as follows:

   setspn -A MSSQLSvc/Host:port serviceaccount

  The SPN is assigned to the service account of the SQL Server instance on your primary server so that the instance, or rather the service account representing it, is attested as being authenticated, at the particular socket address. For example, to create an SPN for SQL Server, you need to run the following code at a command prompt:

   setspn -A MSSQLSvc/mcsql00.cityhall.genesis.mcity.org:1433 micsql

• User Account   The account of the user (login) must be set up for delegation. Open to the Account tab on the user’s Properties dialog box in Active Directory. Ensure that the appropriate Delegation option is checked. This is illustrated in Figure 5–10.

Figure 5–10: Configure the user account for delegation

The preceding steps are all that is needed to enlist delegation, but there is obviously a lot more to Kerberos and delegation than what we discussed here, and it exceeds the scope of this book. Numerous books have been written that deal exclusively with Kerberos. However, Kerberos security is the de facto pervasive security mechanism that protects Windows Server 2003 domains and their server products, such as SQL Server 2005.

So given that Kerberos security provides a much higher level of trusted access than earlier, it actually makes sense to configure a server for Windows Authentication mode only.