Abstract
This chapter looks at the most important operating system security service and how it is implemented in Windows 2000: authentication. We will look at the Windows 2000 authentication architecture and at the nuts and bolts of the Kerberos authentication protocol: how it compares to NTLM, how it can be used as a single sign-on solution between different operating systems, and so on.
INTRODUCTION
Before an entity is given access to a resource on a Windows 2000 system, the operating system must validate the entity’s identity and check whether it can access that particular resource. The latter process is known as access control; it was discussed in the previous chapter. The first process is known as authentication, and it will be discussed extensively in this chapter. The primary purpose of authentication is to prove and validate an entity’s identity. It answers the question of who or what is the system talking to?
In a Windows environment, you bootstrap the authentication process by pressing CTRL+ALT+DEL (known as the Secure Attention Sequence [SAS]) to log on to a machine or a domain (this is called an interactive logon). A valid interactive logon results in a local logon session. If you want to access a resource located on another machine during your logon session, another authentication process will be started (this is called a noninteractive logon). A valid noninteractive logon results in a network logon session.
Every entity that authenticates to a Windows 2000 system is called a principal. A principal is identified by its Security Identifier (SID); to prove its identity during an authentication process, a principal uses credentials. Credentials allow principals to be distinguished from one another and to identify them. Examples of credentials are a principal’s account name and its password. Don’t confuse principal and account. An account is a record in an authentication authority’s database; a principal is an entity that can be identified by a Windows 2000 system. If the operating system accepts this type of credential for authentication, the fact that the principal knows its account name and password is regarded by the operating system as a proof of its identity. Remember from the previous chapter that the OS may well accept other credentials. In Windows 2000, for example, you may use a smart card and a PIN code or a fingerprint.
The component that handles authentication on the operating system side is known as the authentication authority. The authentication authority differs depending on what you’re logging on to. If you log on locally to a machine, it is the Local Security Authority (LSA) on the machine itself; but if you log on to a domain, authentication is performed against the LSA of a DC. To be able to validate a principal’s identity the authentication authority needs a copy of a principal’s credentials; they are stored in the authentication database.
A Windows 2000 authentication process can use different authentication protocols: NTLM (NT LAN Manager), Kerberos, SSL (TLS), Distributed Password Authentication (DPA), and so on. The manner in which these protocols are embedded in the Windows 2000 authentication architecture is explained in the next section.
WINDOWS 2000 AUTHENTICATION ARCHITECTURE
Since its early days, one of the most important design principles of NT has been modularity. NT’s authentication architecture is an excellent example of a modular architecture built upon different abstraction layers. In Windows 2000 this architecture is basically the same as the one used in NT4. Ninety percent of the changes that Microsoft incorporated can be described as the plugging in of supplementary security modules.
Windows 2000 is built upon four basic logon types: local (or interactive) logon, network (or noninteractive) logon, batch, and service logon. Batch logon is used by task schedulers (e.g., the "at" or "WINat" service); service logon is used by services. All of them have slightly different architectures. In the following text, we will focus on local and network logon.
Architecture for interactive authentication
The architecture for interactive authentication is illustrated in Figure 1. An interactive authentication starts whenever a user initiates an SAS sequence. This makes the Winlogon service call the GINA module. (GINA stands for Graphical Identification and Authentication.) Winlogon is the OS component that provides interactive authentication. GINA is the component responsible for displaying the logon interface, extracting the user’s credentials, and passing them to the Local Security Authority (LSA).
The Local Security Authority is the OS kernel component that acts as authentication authority: It interacts with the local security database and the authentication packages and handles user authentication. To decide if a user is permitted to log on the LSA relies on both authentication packages and security databases.
Authentication packages are software packages that implement different authentication protocols. In NT4 the only available authentication package was MSV1_0. MSV1_0 was the package that performed a passthrough authentication if there wasn’t a credential store (a SAM database) available locally to validate the user’s credentials. Software vendors can implement their own authentication package to provide other authentication protocols.
Windows 2000 comes with two authentication packages: MSV1_0 and Kerberos. You can find out which authentication package DLLs are available at your machine by looking into the HKEY_LOCAL_MACHINES\System\CurrentControlSet\Control\Lsa\AuthenticationPackages registry location. The Kerberos authentication package cannot handle local logon requests on workstations or member servers. Kerberos requires the presence of a Key Distribution Center (KDC) service, which is only available on a Windows 2000 DC.
The authentication database stores the credentials needed during the authentication process. In this context "authentication database" refers to the same concept as security database. NT4 machines, Windows 2000 workstations, and member servers store credentials in the SAM database (which is part of the system registry). A Windows 2000 DC stores credentials in the Active Directory. In the first case, the credentials contain local accounts; in the second, domain accounts.
Architecture for noninteractive authentication
Figure 2 provides a simplified overview of the noninteractive authentication architecture used in a distributed application consisting of a client and a server component. A good example of a distributed application is an Outlook client accessing an Exchange mailbox. This architecture introduces two new important concepts: the Security Support Provider Interface (SSPI) and Security Support Providers (SSPs).
Communication between the client and the server component happens via communication protocols. These protocols can be typical LAN communication protocols such as SMB and RPC, or typical Internet-oriented communication protocols such as HTTP, POP3, NNTP, and LDAP.
The SSPI is an Application Programming Interface (API), sitting between the communication protocols and the security protocols; it has two important functions, as follows:
- Its primary function is to abstract the commonalities of different authentication protocols and to hide their specific implementation details. For example, Kerberos and NTLM both use the concept of a master key; NTLM, however, uses a challenge-response mechanism, while Kerberos relies on a ticketing system.
- Abstract communication protocols from security protocols. Any security protocol should be available to any communication protocol; or, in other words, the implementation of a security protocol should not contain any communication protocol — specific code.
A Security Support Provider (SSP) is a software module that implements a security protocol. SSPs can be plugged into the SSPI. Out-of-the box Windows 2000 supports the following SSPs: NTLM, Kerberos, SChannel (SSL and TLS), and Distributed Password Authentication (DPA). The NTLM SSP supports LAN Manager authentication, NTLM version 1, and NTLM version 2. NTLM is the default authentication protocol of NT4. DPA is a challenge response — based authentication protocol introduced in the Microsoft Commercial Internet System (MCIS). Software vendors can also implement their own SSP to provide other security models. In the next release of Windows 2000 (Windows.net, codenamed "Whistler"), Microsoft will provide a "Digest authentication" SSP.
Notice in Figure 2 that SSPs access authentication packages via the LSA. It also shows the LSA communicating with the authentication database: remember from the previous section that the LSA validates credentials by comparing them with the entries in its authentication database. One concept not shown in Figure 2 is that most SSPs rely on Cryptographic Service Providers (CSPs). CSPs are modules that provide basic cryptographic functions. For example, encryption using the Data Encryption Standard (DES), signing using RSA, or hashing using Message Digest 4 (MD4). SSPs can call on different CSPs thanks to another abstraction layer introduced in NT4: the CryptoAPI (or CAPI). The Crypto API will explained in Chapter 8.
Because the model shown in Figure 2 contains multiple authentication protocols (SSPs), there has to be some kind of negotiation between the client and the server before the actual authentication can take place. To enable the negotiation Microsoft included a special SSP called Negotiate; it is illustrated in Figure 3. This package is based on the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), as defined in Internet draft RFC 2478: The Simple and Protected GSS-API Negotiation Mechanism. In order to negotiate an authentication protocol the Negotiate package has to know how to communicate with the corresponding authentication pack-age. So far the Negotiate SSP can only deal with the Kerberos and NTLM package.
So how does this negotiation work? The first SSP that is called by the SSPI when a call for authentication comes in is the Negotiate SSP. The client Negotiate package then sends a list of available SSPs to the server. Finally, the server Negotiate package picks an SSP based on its locally available SSPs and communicates it to the client. Although this negotiation clearly adds some communication overhead, it offers much more flexibility.
In Windows 2000 the Negotiate SSP’s first choice for authentication is Kerberos. It will fall back to NTLM if the following conditions are present:
- No KDC service (read Windows 2000 domain controller) is available in the domain.
- A service’s Service Principal name (SPN) is not registered (SPNs will be explained in Section 6.6.1). For example, when a user tries to access a file share on a server of which the host SPN is not registered, the user will be authenticated using NTLM.
Also, if the use of Kerberos is not feasible, the Negotiate SSP will first try NTLM version 2, then NTLM version 1, and then LAN Manager authentication. The supported NTLM SSP protocols can be configured using the LMCompatibilityLevel registry key; for more information, take a look at Microsoft Knowledge Base article Q147706, "How to Disable LM Authentication on Windows NT."
An excellent tool to get a deeper understanding of how the SSPI really works is the SSPI workbench. It is written by Keith Brown from Develop-Mentor and can be downloaded from the Microsoft MSDN Web site http://www.microsoft.com/msdn.
Authentication architecture overview
The most important updates to the Windows 2000 authentication architecture are as follows:
- Kerberos, the new default authentication protocol, has been implemented as both an authentication package and a Security Support Provider (SSP). The rest of this chapter will focus on the Kerberos authentication protocol.
- Windows 2000 includes another new SSP: the Negotiate package.
- On a DC the authentication credentials are stored in the Active Directory.
Table 6.1 gives an overview of the different authentication types, the authentication packages, and SSPs available in NT4 and Windows 2000.
INTRODUCING KERBEROS
In Greek mythology Kerberos is a three-headed dog who guards the entrance to the underworld. In the context of this book Kerberos refers to the authentication protocol developed as part of the MIT Athena project.
|
TABLE 1: OVERVIEW OF WINDOWS 2000 AUTHENTICATION TYPES, PACKAGES, AND SSPs |
|
Authentication Type | Machine-Domain Logon | Logon From | Authentication Package | Security Support
Provider (SSP) |
| Interactive authentication | Machine logon | Non-DC | | | | |
| | | | NT4 | MSV1_0 | NT4 | NA |
| | | | Win2K | MSV1_0 | Win2K | NA |
| | | DC | NT4 | MSV1_0 | NT4 | NA |
| | | | Win2K | Kerberos | Win2K | NA |
| | Domain logon | Any Machine | NT4 | MSV1_0 | NT4 | NA |
| | | DC | Win2K | Kerberos | Win2K | NA |
| Noninteractive authentication | NA | Any Machine | NT4 | MSV1_0 | NT4 | NTLM |
| | | | Win2K | Kerberos | Win2K | Negotiate
Kerberos
NTLM
Secure
Channel |
Kerberos is embedded in Windows 2000 as the new default authentication protocol. Every Windows 2000 workstation and server includes a client Kerberos authentication provider. Windows 2000 does not include Kerberos support for other Microsoft platforms. If you want your NT4, Windows 95, or 98 clients to authenticate using Kerberos, you’ll need to upgrade your workstation to Windows 2000 Professional. In the early days of Windows 2000 Microsoft promised to include Kerberos support for Windows 95 and 98 in the Directory Service Client, an add-on for Windows 95 and 98, which can be found on the Windows 2000 Server CD. The same is true for the NT4 Directory Service Client, which Microsoft released in September 2000. You can download it from the Microsoft Web site.
A little more about the dog’s three heads: they stand for authentication, access control, and auditing. The basic Kerberos protocol (version 5, as defined in RFC 1510) only deals with authentication. Microsoft’s implementation of the protocol also includes extensions for access control. So far no Kerberos implementation covers auditing. But there’s more than the three As: Later in this chapter we’ll explain how one of the secret keys exchanged during the Kerberos authentication sequence can be used for packet authentication, integrity, and confidentiality services.
Another way to look at the dog’s three heads is as the basic entities the protocol is dealing with. There are always three: two entities that want to authenticate to one another (e.g., a user and a resource server) and an entity that mediates between the two–a trusted third party, or in Kerberos terminology, the Key Distribution Center (KDC).
Kerberos positioning
Figure 4 positions NTLM, Kerberos, and SSL-TLS together with the main cryptographic technology they rely upon. (SSL stands for Secure Sockets Layer; TLS for Transport Layer Security; TLS is SSL version 3.1.) NTLM relies on symmetric key cryptography. SSL-TLS uses asymmetric key cryptography. Windows 2000 Kerberos comes in two flavors: standard Kerberos (as defined in RFC 1510) is based on symmetric key cryptography; Kerberos PKINIT uses asymmetric key cryptography.
Authentication protocols purely based on asymmetric cryptography scale better than protocols based on symmetric cryptography. In asymmetric solutions, the trusted third party doesn’t need to be online all the time. Of the two symmetric solutions, Kerberos and NTLM, Kerberos scales better than NTLM. This is mainly due to the Kerberos ticketing system. Still, Kerberos cannot scale to environments such as the Internet. For Internet authentication the best available solution remains SSL-TLS.
Compared with their symmetric-key counterparts asymmetric crypto-based authentication protocols are more complex to administer. Asymmetric cryptography is also a relatively new technology. This is one of the main reasons why Microsoft didn’t choose a full asymmetric crypto — based solution and instead incorporated Kerberos as the new default authentication protocol of Windows 2000.
Kerberos Advantages
In this section, we will explain the key differences between NTLM and Kerberos and the advantages Kerberos brings to the Windows 2000 operating system and its users. This section is just an introduction; in later sections, we will look at the technical details.
Faster authentication
The core of the Kerberos protocol uses a unique ticketing system, providing faster authentication, as follows:
- Every authenticated domain entity can request tickets from its KDC to access other domain resources.
- The tickets are considered access permits by the resource servers.
- The ticket can be used more than once and can be cached on the client side.
When a resource server or the KDC gets a Kerberos ticket and a Kerberos authenticator from the client, the server has enough information to authenticate the client. If the resource server is not a DC, NTLM requires the server to contact a DC to validate a user’s authentication request (this process is known as pass-through authentication). Thanks to its ticketing system, Kerberos does not need pass-through authentication. This is why Kerberos accelerates the authentication process. A downside to the ticketing system is that it puts a greater workload on the client.
Mutual authentication
Kerberos supports mutual authentication. This means that the client authenticates to the service that’s responsible for the resource and that the service authenticates to the client. This is a big difference from NTLM. The NTLM challenge/response provides only client authentication: The server challenges the client, the client calculates a response, and the server validates that response. Using NTLM users might provide their credentials to a bogus server.
Transitive trust
As in NT 4.0, a trust between two Windows 2000 domains facilitates cross-domain resource access and creates cross-domain account visibility. In Windows 2000 Microsoft simplified trust creation and management by letting you create trusts automatically as part of the domain hierarchy building process (DCPROMO) and by allowing transitive trust. Although they are created automatically, so far there’s no simple way to turn trust relationships off.
Transitive trust means that if both europe.compaq.com and us.compaq.com trust compaq.com, then europe.compaq.com implicitly trusts us.compaq.com. In the current version of Windows 2000, however, this is only true if both the europe and the us domain are in the same Windows 2000 forest. So far, trust relationships between forests are always nontransitive. Transitive trust reduces the number of trusts needed for authentication. In Figure 5, only four trusts are needed (between each parent and child domain) to obtain authentication interoperability between all three domains. NT4 would have needed six trust relationships to do the same thing.
Transitive trust is only a logical concept–no shared secret exists between the DCs of the domains that share a transitive trust. This means that for authentication to occur between entities on opposite ends of a transitive trust, the authentication process will not flow across the transitive trust but through the trust path. This is illustrated in Figure 5. It shows the message flow needed to authenticate a user defined in europe and logging on to a machine in the us domain. The flow follows the trust path, not the transitive trust.
Kerberos is an open standard
Microsoft based its Kerberos implementation on the standard defined in RFC 1510 (this is Kerberos V5). This is why Kerberos can provide single sign-on between Windows 2000 and other OSs supporting an RFC1510 based Kerberos implementation. Over the past years, Microsoft has been actively involved in the Kerberos standardization process. Microsoft software engineers participated in the creation of the standards and standard drafts listed in Table 6.2.
Support for delegation
Delegation can be looked at as a next step after impersonation. Thanks to impersonation a service can access local resources on behalf of a user; thanks to delegation a service can even access remote resources on behalf of a user. What delegation really means is that user A can give rights to intermediary machine B to authenticate to an application server C as if machine B were user A. This means that application server C will base access control decisions on user A’s identity rather than on machine B’s account. Delegation is also known as authentication forwarding. In Kerberos terminology this means that user A forwards a ticket to intermediary machine B, and machine B then uses user A’s ticket to authenticate to application server C.
You can use delegation for authentication in multitier applications; an example of such an application is database access using a web front end, where the browser, the web server, and the database server are all running on a different machine. In a multitier application authentication happens on different tiers; preferably every authentication process can use the same credentials. In such an application setup it is impossible to use NTLM for authentication on every link, simply because NTLM does not support delegation.
Support for smart-card logon
Through the Kerberos PKINIT extension Windows 2000 includes support for smart-card logon. Smart-card logon provides much stronger authentication than password logon does, because it relies on two-factor authentication: To log on, a user needs a smart card and its PIN code. Smart-card logon also offers stronger security in general: it blocks Trojan Horse attacks that attempt to grab a user’s password from the system memory.
|
TABLE 2: KERBEROS IETF STANDARDS AND DRAFTS |
|
Standard or Draft Name | Available From |
| The Kerberos Network Authentication Service (V5) | http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-revisions-04.txt |
| Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) | http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-10.txt |
| The Simple and Protected GSS-API Negotiation Mechanism (RFC 2478) | http://www.ietf.org/rfc/rfc2478.txt |
| Generating KDC Referrals to Locate Kerberos Realms | http://www.ietf.org/internet-drafts/draft-swift-win2k-krb-referrals-00.txt |
| The Windows 2000 RC4-HMAC Kerberos Encryption Type | http://www.ietf.org/internet-drafts/draft-brezak-win2k-krb-rc4-hmac-01.txt |
| User to User Kerberos Authentication Using GSS-API | http://www.ietf.org/internet-drafts/draft-swift-win2k-krb-user2user-00.txt |
| Extension to Kerberos V5 for Additional Initial Encryption | http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-extra-tgt-02.txt |
| Extending Change Password for Setting Kerberos Passwords | http://www.ietf.org/internet-drafts/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt
|
Comparing Kerberos with NTLM
Table 6.3 compares Kerberos, the default authentication protocol of Windows 2000, to NTLM, the default authentication protocol of NT4. It also lists the main features of both protocols introduced in the previous sections.
|
TABLE 3: KERBEROS — NTLM COMPARISON |
| |
NTLM | Kerberos |
| Cryptographic Technology | Symmetric Cryptography | Basic Kerberos:
Symmetric Cryptography
Kerberos PKINIT:
Symmetric and Asymmetric Cryptography |
| Trusted Third Party | DC | Basic Kerberos:
DC with KDC service
Kerberos PKINIT:
DC with KDC service and Enterprise CA |
| Microsoft-Supported Platforms | Windows 95, Windows 98, NT4, Windows 2000 | Windows 2000 |
| Features | Slower authentication because of passthrough authentication | Faster authentication because of unique ticketing system |
| |
No mutual authentication Mutual authentication |
| | No support for delegation of authentication | Support for delegation of authentication |
| | No support for transitive trust if the authenticating DC is an NT4 DC.
Support for transitive trust if the authenticating DC is a Windows 2000 DC. | Support for transitive trust |
| | No support for smart-card logon | Support for smart-card logon |
| | Proprietary Microsoft standard, poorly documented | Open standard, fully documented |
| | No protection for access control data carried in NTLM messages* | Cryptographic protection for access control data carried in Kerberos tickets |
| *This was the case for NTLM version 1; this problem has been resolved in NTLM version 2.
|
|
Page:
1,
2,
3,
4,
5,
6,
7
|
next page  |
|
|
|
|
Windows IT Pro
Register
