How Kerberos Authentication Works

[Previous] [Next]

Kerberos authentication uses a notion of tickets. A ticket is nothing more than a packet of information specific to Kerberos to aid in authentication. A ticket contains the client's identity, a session key, a timestamp, and other information. Sensitive parts of the ticket are encrypted with the server's key. However, before we dive into Kerberos ticket flow, let's take a moment to explain some of the acronyms used in Kerberos.

Some Kerberos Acronyms

You'll encounter many new abbreviations and acronyms when using Kerberos. This section of the chapter discusses each in detail.

Key Distribution Center (KDC)

The Key Distribution Center is at the heart of Kerberos. The KDC's job is to set up protected communication between client and server by assisting in the secure distribution of cryptographic keys that can then be used by the client and the server to protect their conversation.

In Windows 2000, the KDC resides in the Local Security Authority (LSA) process Lsass.exe on domain controllers. To an administrator, the KDC is implemented as a Windows service that is enabled on a Windows 2000 domain controller. It resides on a domain controller because Kerberos in Windows 2000 uses Active Directory as its account database.

The KDC is a mediator of sorts; all requests for all tickets come through the KDC. The KDC is a trusted third party; it knows about all the principals (users and computers) in the system and knows their passwords. (Yes, Windows 2000-based computers have passwords!)

The KDC is logically broken in two components, the authentication service and the ticket granting service, which are covered in the next two sections.

Authentication service (AS)

The authentication service's role is to authenticate principals and to grant tickets known as ticket granting tickets, described in a moment, which allow the principal to obtain further tickets from the ticket granting service, described next.

Ticket granting service (TGS)

The ticket granting service issues service tickets that are used by a principal to authenticate itself to another principal such as a server. Note that the TGS can issue ticket granting tickets also. Often these tickets are used when accessing other Kerberos realms (analogous to Windows 2000 domains); however, Windows 2000 also uses the TGS to get delegable ticket granting tickets. More on this a little later.

Ticket granting ticket (TGT)

A ticket granting ticket is a ticket issued by the AS to access the KDC itself. It is opaque to all principals other than the KDC. The reason TGTs exist is to reduce the number of times a user must present credentials to the operating system. So long as the TGT is valid and has not expired, it can be used to authenticate the user without having the user enter her username and password. The default lifetime for a TGT is 10 hours. TGTs form the basis of delegation; we'll discuss TGTs and delegation shortly.

Service ticket (ST)

Service tickets, also known as sessions tickets, are issued by the TGS. STs are used when a principal wants to authenticate itself to another principal. Figure 14-2 shows the layout of the KDC and the flow of STs and TGTs in Windows 2000.

click to view at full size.

Figure 14-2. The architecture of the KDC, and the flow of data in and out of the AS and TGS in Windows 2000.

Service principal name (SPN)

A service principal name is the name by which services are identified. SPNs are used to support mutual authentication between a client application and a service. Remember that we mentioned that NTLM authenticates the client only? Using SPNs allows server services to be named, and hence they can also be identified and authenticated. The format of an SPN is

<service type>/<instance name>:<port number>/<service name>

Table 14-1 describes what each part of the SPN means.

Table 14-1. Elements of an SPN.

ElementComments
Service type Type of service. For example, HTTP for Internet Information Services (IIS), MSSQLSVC for the Microsoft SQL Server service, SMTPSVC for the Simple Mail Transfer Protocol (SMTP) Server service, or LDAP for the Lightweight Directory Access Protocol (LDAP) service.
Instance name The name of the server on which the service resides. Often the DNS name of the server.
Port number (optional) Port number used by the service if it's different from the default for the service type. For example, if IIS is listening on another port other than port 80, this will need to be set.
Service name (optional) Name of the service, if applicable. This option is used to locate replicated services.

If the service name is the same as the instance name, which is common, and the port number is the default for the service, the SPN can be abbreviated to

<service type>/<instance name>

Table 14-2 describes some example SPNs.

Table 14-2. Example SPNs.

Example SPNComments
HTTP/WEBSERVER HTTP/webserver.explorationair.com Two SPNs registered by the Web server services. One is an SPN for the NetBIOS name of the server, and the other is the DNS name of the server.
MSSQLSERVER/dbserver.explorationair.com:1433 An SPN for SQL Server. Note that we are interested in supporting mutual authentication only if the client accesses this server using DNS rather than NetBIOS. We have explicitly set the port number to which SQL Server is listening. This is important in the case of SQL Server 2000 because the technology allows multiple instances of SQL Server to run on a server, each listening on a different port.

Why Register Two SPNs?

If a client accesses a remote computer, he can access the computer by using either its NetBIOS name or its DNS name. Actually, he could use the IP address too, but IP addresses are not a secure way to authenticate a server. Because the two SPNs are registered, the client software can authenticate the service regardless of the name used to access the server.

Note that not all services need to be registered. Many service types will map to a default service type called HOST. Examples include HTTP, W3SVC, WWW, RPC, CIFS (file access), WINS, and UPS (uninterruptible power supply). For example, if your client software performs an HTTP connection to the Web server on the middleware.explorationair.com server by using an SPN of HTTP/middleware.explorationair.com, but this SPN is not registered on the server, the Windows 2000 domain controller will automatically map it to HOST/middleware.explorationair.com. This mapping applies only if the Web service is running as LocalSystem.

Before we discuss the ticket flow in Kerberos, let's look at three tools that help an administrator using Kerberos.



Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
ISBN: N/A
EAN: N/A
Year: 1999
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net