Authentication for Administrative Authority
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Microsoft Solutions Framework
Best Practices for Enterprise Security
Note: This white paper is one of a series. Best Practices for Enterprise Security ( http://www.microsoft.com/technet/archive/security/bestprac/bpent/bpentsec.mspx ) contains a complete list of all the articles in this series. See also the Security Entities Building Block Architecture ( http://www.microsoft.com/technet/archive/security/bestprac/bpent/sec2/secentbb.mspx ).
On This Page
The Focus of This Paper
Logon and Authentication
Management of Kerberos
Interoperating with a UNIX (MIT Kerberos V5) Environment
NTLM in Windows 2000
The Windows 2000 Domain Model and Security
Kerberos Capacity Planning
The Focus of This Paper
Authentication for the administrative authority. What does this mean? The "administrative authority" for most systems is the system administrator. So then, what does "authentication" mean? Technically, "authentication" is the process a system uses to determine exactly who is talking to the system. The question that authentication asks is, "How can I be sure you are who you say you are?" But many people equate authentication with "logon." For a system running Microsoft Windows, the logon sequence involves much more than just authentication.
This document uses the terms "authentication" and "logon" by their precise meanings, and it focuses on authentication.
This paper provides information about authentication for system administrators who have some experience with Microsoft Windows NT 4.0 and recently have upgraded or are considering an upgrade to Windows 2000.
In essence, this document answers the question, "What do I think I would want to know about authentication in Windows 2000?"
This document includes information on:
Management aspects of Kerberos authentication.
Interoperating with the Massachusetts Institute of Technology Kerberos V5 implementations.
Higher-level aspects of Kerberos authentication.
It also includes a section documenting a series of tests conducted by a Microsoft team to determine how many logon requests a server can handle. The intent was to give system administrators some numbers to use to plan for their particular environment.
Although each environment will have its own issues and limitations, and these results could not be considered "rigorous," the results should give system designers an idea about the level of computer that their organization will require, as well as a better understanding of how much resource the logon process will require.
Logon and Authentication
The Logon Process
The logon process has several steps. On a Windows 2000 client, when a user presses CTRL+ALT+DELETE and types in a user name and password, the computer already has authenticated itself to the domain controller, performed several Lightweight Directory Access Protocol (LDAP) and Domain Name System (DNS) queries, and has received the various policies that apply to that computer. The user logon process includes LDAP queries, required protocol negotiations, and the gathering of user-specific policies.
The Authentication Process
When the logon process performs the actual authentication steps, Windows 2000 uses the Kerberos authentication protocol. Kerberos V5 protocol is the default authentication protocol in Windows 2000. Kerberos protocol originated as part of Project Athena at Massachusetts Institute of Technology (MIT) in the late 1980s. Version 5 of the Kerberos protocol is the second production version (the first three versions were internal development versions), and is described in the IETF RFC 1510. (See http://www.ietf.org/rfc/rfc1510.txt for more details.)
Kerberos V5 protocol is an authentication protocol. It only allows a computer to verify that a user or another computer is really who the user claims to be. This is the basis of all security systems. Unless a server can verify the user's identity, it cannot reliably control access to its resources. Once the server receives positive identification of the user, it can determine whether the user is authorized to access the resource.
The Kerberos protocol, per se, does not authorize the user to access any resource. The Microsoft implementation of the Kerberos V5 protocol does allow secure delivery of user credentials. User and group security identifiers (SIDs) are packaged in a ticket called a Privilege Attribute Certificate (PAC). The PAC is not a public key certificate and is not issued by a certificate authority. The PAC contains the SIDs that the server computer will use to determine if the user has access to the resource the user requested. The specification of the PAC can be found at http://go.microsoft.com/fwlink/?LinkId=23186.
Why Kerberos Protocol?
The following are some of the reasons why Kerberos is a good choice for an authentication protocol.
Any security scheme should be secure, reliable, transparent to the user, and scalable. These are the exact design criteria used for developing the Kerberos protocol.
To meet the secure criterion, the Kerberos protocol uses what is considered today to be state-of-the-art encryption protocols.
To be reliable, Kerberos has been critiqued and found to be cryptographically sound.
Because the Kerberos protocol caches tickets and can forward tickets, the protocol appears transparent to the user.
In part due to the caching and in part due to the smaller number of messages compared to NTLM, the Kerberos protocol should scale to much larger environments than NTLM does.
Coming from the academic world, the Kerberos protocol has been reviewed and analyzed by many. It has no obvious mistakes such as unencrypted passwords that travel across the network. The technical weaknesses of version 4 were corrected in version 5, which is considered to be an "industrial strength," general-purpose authentication protocol.
The Kerberos protocol has some potential weak links. (For instance, see "Limitations of the Kerberos Protocol" by S.M. Bellovin and M. Merritt in the Winter 1991 USENIX Conference Proceedings. Their issues with replay attacks and password attacks apply to Kerberos V5 protocol, although their paper was an analysis of version 4.) But these limitations apply to virtually all distributed computing environments (DCEs). Many authors have noted that the Kerberos protocol is vulnerable to a password attack. What this means to network administrators is that they should log authentication failures and lock out accounts that have multiple failures in a short time span.
One of the fields in version 5 of the protocol is an encryption type identifier so that any encryption method can be used. Also, the encryption keys are associated with a type and length. RFC 1510 defines the minimum set of encryption methods that must be supported, but as encryption methods improve, implementers will be able to keep up with the state of the art without applications having to change the protocol.
Proxy and forward.
One of the limitations of Windows NT 4.0 and earlier was that NTLM could not support multihop impersonation. If a user passed his or her credentials to a middle-tier object, that object could not forward the user's credentials to gain access to say, a Microsoft SQL Server™ database.
Kerberos V5 protocol allows both proxy and forwarding. Proxy is where a user can give a service the user's session ticket for some other resource. The service can use the session ticket to access the resource. A print server, for instance, could access a file to be printed using the user's session ticket with the file server.
Proxy requires only the client's session ticket and a session key for the target server. This is a limited sort of impersonation. The more general case, forwarding, or delegation, is where an application must pass on all of the client's credentials in order to fully impersonate the client. To do this, the application must use the client's ticket-granting ticket (TGT) to request session tickets on the target server. COM+ applications will be able to make full use of forwarding. From a low-level point of view, forwardable means that a ticket can have one Internet Protocol (IP) address for the source computer and a different IP address for the requesting computer.
Efficient—tickets are cached (transparent to the user).
The Kerberos protocol client on each computer keeps the tickets it receives in memory. The authentication sequence must happen only once per logon session. The TGT and service tickets can be kept and used as many times as the client requires without going through the entire set of steps. All of this caching is transparent to the user. When tickets expire, the client renews them automatically. This is transparent to the user also.
IETF standard—interoperability with non-Windows systems.
The IETF RFC 1510 defines how the Kerberos protocol should work. The Microsoft implementation of the Kerberos protocol fully supports this RFC. This will allow a basic level of interoperability between Microsoft Kerberos clients and servers and MIT Kerberos clients and servers. (See the section later discussing this interoperability.)
Speed and scaling.
The use of tickets allows clients to "carry around" their credentials and present them to a server as many times as needed. There is no need to reauthenticate the user each time the user requests access to a service or resource. Because of the caching, a client will not have to get a new ticket during the lifetime of the ticket. Both these things should allow the Kerberos protocol to be faster than NTLM and it will certainly scale better.
Short Overview of the Six Kerberos Messages
Any discussion of the Kerberos protocol should describe the six primary Kerberos messages. The six messages are really three types of actions, each of which has a request from a client and a response from the Kerberos Key Distribution Center (KDC).
The first action occurs when the client types in a password. The Kerberos protocol client on the workstation sends an "AS" request to the Authentication Service on the KDC asking the Authentication Service to return a ticket to validate that the user is whomever he or she claims to be. The Authentication Service verifies the client's credentials and sends back the authentication response.
The second action is when the client requests access to a service or a resource by sending the authentication response to the Ticket-Granting Service on the KDC. The Ticket-Granting Service returns a set of tickets that the client can submit to whatever server holds the service or resource the clients wants.
The third action is when the Kerberos client actually submits the service ticket to the server and requests access to the service or resource. These are the application (AP) messages. The access security identifiers (SIDs) are contained in the PAC that is part of the ticket sent to the server.
This third action need not have a response by the server unless the client has specifically asked for mutual authentication. If the client has marked this exchange for mutual authentication, the server returns a message to the client that includes an authenticator timestamp. For a typical domain logon, all three of these actions occur before the user is allowed access to the workstation.
Management of Kerberos
Working in the Background
Remember, the Kerberos protocol is just the authentication component that will be used during the logon process. As noted earlier, the logon process is vastly more complicated than just authentication. Computer policies, group policies, and potentially the sIDHistory must all pass from the domain controller to the client. These items could add up to a significant amount of network traffic. So, it is probably more useful to expand your view when considering how and where to set up domain controllers.
For example, the logon process requires the client to query information from the global catalog. If the link between the client and the server with the global catalog is unreliable or slow, major logon issues will occur. It is probably safe to say that the Kerberos traffic and Kerberos work will be small compared to the total amount of traffic and work that occurs for the other parts of the system such as logons, Active Directory replication, and so on.
The Kerberos protocol does not require, nor even allow, much "administration." It is the default authentication package, and like NTLM, it works in the background without intervention. When you set up a Windows 2000 domain controller, an account with the name krbtgt is created. This account is the security principal used by the Kerberos service per RFC 1510. This account cannot be deleted nor can the account name be changed. The account is disabled and cannot be enabled, since krbtgt cannot be used to log on.
When the account is created, a random password is assigned, and that password is changed by the system on a regular basis. The password to the krbtgt account is used by the Kerberos client on the domain controller to create the secret key for encrypting and decrypting all the ticket-granting tickets for the KDC. So, when you see the krbtgt account in your list of users, leave it as is.
Microsoft-Provided Management Tools
KerbTray. This is a utility that comes in the Windows 2000 Server Resource Kit. You will find it in the Network Management Tools folder, not in the Security Tools folder. When you run KerbTray.exe, it shows up in the tray on the Windows taskbar. KerbTray shows a graphical view of the tickets in the cache on that computer. Below are examples of each of the tabs on the KerbTray screen.
NetDom. Network Domains is a command line utility that allows the network administrator to verify servers and trusts as well as to reset trusts.
NetMon. Network Monitor did not have a Kerberos parser as of the Windows 2000 release date. A NetMon trace would show the traffic to and from port 88, the Kerberos IP port, and would show the unencrypted data that is in some of the messages. This data might be enough to determine some basic problems but it is not likely that NetMon will be used as a day-to-day evaluation tool.
Errors and Troubleshooting
Kerberos errors are logged to the Event Log. Network administrators should review this log on a regular basis, or better yet, create or buy an application that watches the Event Log for particular items and warns you in some proactive way. RFC 1510 defines many errors that are not possible in a Windows 2000 domain. One such error is Requested Protocol Version Number Is not Supported. Because all Windows 2000 Kerberos clients are version 5, this error could happen only in an environment where MIT Kerberos version 4 clients were trying to authenticate using the Windows 2000 domain controller.
Here are some errors you might see, what they mean, and what to look for:
Error 0x6: Client's name not found (principal unknown) or Error 0x7: Server's name not found (principal unknown).
This error happens if the domain controller cannot find the name in the Active Directory on that domain controller. If you encounter this error, you should check to see if the name is in the Active Directory. If it is, check to see if the account has expired. It is possible for a user to be in the middle of a session and suddenly be locked out. This can happen if "Enforce user logon restrictions" is set to true—the default setting—and the account expiration date passes.
"Enforce user logon restrictions" forces the domain controller to check the user's account each time a TGT is presented. If the principal name is not in the local Active Directory, but you know the account should exist, you should check whether the Active Directory synchronization is up to date. It could be that the user has just been added to the domain and the updates have not yet reached the domain controller that is acting as the KDC for that user.
Error 0x17: Password has expired. Change password to reset.
If a TGT is cached and the user's password expires and is changed, there could be conflicting credentials. The user's secret key is based on the password, so the key kept in the cached TGT will not match the key the KDC has for that user. The user will need to log off and log on again in order for the credentials to match.
Error 0x1A: Requested server and ticket do not match.
A server received a ticket meant for another server. The place to start looking for a problem is DNS or whatever you are using for name resolution. It is likely that the client received the wrong address for the server it was looking for.
Error 0x1F: Integrity check on decrypted field failed and Error 0x29: Message stream modified.
These errors indicate that the hash included with the message did not match the hash that was computed at the destination. This modification of the message could be the result of an attack or it could be due to network noise. This would be one of the messages you would like proactive notice about.
Error 0x20: Ticket has expired.
The smaller the value for "Maximum lifetime for user ticket," the more you will see this error. Ticket renewal is automatic, so you should not have to do anything if you see this message.
Error 0x22: Session request is a replay.
This error indicates that a specific authenticator showed up twice. The cause could be an attacker trying to replay a session or it could just be a bad network card. Either way, this is an error you would like to know about as soon as it happens.
Error 0x25: Clock skew too great.
If a client computer sends a timestamp that is different from the server's timestamp by more than the number of minutes found in the "Maximum tolerance for computer clock synchronization" policy, this error is logged. This could be quite common, especially as the number of laptops—that is, disconnected computers—increases.
Although this error may show up in the logs, it will not stop a user from being authenticated. When this error is returned, the domain controller also supplies the correct time on the domain controller. The Kerberos client uses the correct domain controller time to attempt the authentication request a second time. Presuming that the user's credentials are valid, the user will be authenticated on the second try.
How to Configure Kerberos in Windows 2000
The primary thing to remember about configuring Kerberos is that the default is good. Only about a half dozen items can be changed in Kerberos on Windows 2000. Unless there is some specific reason to change one of the parameters, you should leave the parameters alone. One reason customers have increased the Kerberos ticket lifetimes is to reduce their reliance on wide area network (WAN) links between clients and domain controllers.
If you choose to change the Kerberos parameters, go to Start/Programs/Administrative Tools/Domain Security Policy. Open Security Settings, open Account Policies, and then open Kerberos Policy. As you will see, the Kerberos policy is set at the domain level and is stored in the Active Directory.
This means two things: One is that you must be a member of the Domain Administrators group to change the Kerberos policy. The other is that changes made on one domain controller will be replicated to the other domain controllers along with the normal Active Directory replication.
The five policy items are:
Enforce user logon restrictions. This setting, normally set to "Yes," forces the domain controller to check the validity of the account every time a TGT is submitted. This will cause increased overhead, but it will give the nervous network administrator more comfort.
Maximum lifetime for service ticket. Session tickets must be renewed after this number of minutes. It usually is set to 60.
Maximum lifetime for user ticket. This setting defines the amount of time a TGT can live before it must be renewed. It usually is set to 10 hours.
Maximum lifetime for user ticker renewal. Usually set to seven days, this value defines the total maximum time a ticket of any sort can live. After this amount of time, a ticket may not be renewed. The client must obtain a new ticket. This is not usually a problem, since the client will attempt to obtain a new ticket automatically.
Maximum tolerance for computer clock synchronization. This is the amount of time that the client timestamp and the domain controller time can differ by and still have the domain controller think that the timestamps are the same. If the timestamps differ by more than this number, no ticket will be issued to the client. As mentioned earlier, a "Clock skew too great" error will be logged if the domain controller encounters this situation.
The system administrator can also change the user and computer properties. Although tickets are marked as "Forwardable," by default neither computers nor user accounts are trusted for delegation, which means that forwarding is turned off. In order to turn on forwarding, the network administrator does not have to set the user account being used as the security context to "Account is trusted for delegation." Only the computers or services which run as user accounts in the forwarding chain need to have the "Trust computer for delegation" setting. There is no reason to do this unless you have a particular application that requires forwarding.
To change the user account properties, open AD Users and Computers and then open the Users folder. Double-click on the appropriate user to bring up the Properties dialog box. Choose the Account tab and look in the Account Options list. If you want this account to be able to forward tickets, select the Account is trusted for delegation box. If you want to be sure that account is never used for forwarding, select the Account is sensitive and cannot be delegated box. The following graphic shows the User Properties dialog box.
To change the computer properties, open AD Users and Computers and open the Computers (or Domain Controllers) folder. Double-click on the appropriate computer to bring up the Properties dialog box. Click on the General tab and select the Trust computer for delegation box. The following graphic shows an example of the dialog box for the computer properties.
Interoperating with a UNIX (MIT Kerberos V5) Environment
How to Make It Work
Generally, Windows 2000 Kerberos clients interoperate with MIT Kerberos V5 KDCs, and MIT Kerberos clients interoperate with Windows 2000 domain controllers. In this case, "interoperate" means that either KDC can produce ticket-granting tickets and session tickets for either type of client.
A few items must be set up for this to work. Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability describes the items that are required for both the Windows 2000 side and the UNIX side. There are a variety of registry entries that must be set and there are a few command line tools to help with this task, including KSETUP and KTPASS. If a Windows 2000 client is going to authenticate to an MIT Kerberos V5 KDC, the Windows 2000 user must log on using e-mail-style names (User Principle Names) such as email@example.com, because MIT KDCs do not support Microsoft-style names, such as someone by itself.
On the Windows 2000 side, you must map UNIX clients to Windows 2000 user accounts. You can set a single user, for instance UnixUser, on the Windows 2000 domain and map all UNIX clients to that one Windows 2000 account. Or, you can map the UNIX users to Windows 2000 users on a one-to-one basis. You must create registry entries for the UNIX user to Windows 2000 user mappings.
The Microsoft implementation of Kerberos V5 supports all the Kerberos name and encryption types, so it is possible to have a Windows 2000 domain trust an MIT realm. The command line utility, NetDom, can be used to establish this sort of trust. There are two things to watch out for. The first is that Windows 2000 uses a single password for both "directions" of the trust. MIT realms use separate passwords for each direction. So, in order for the trust to work, you must use the same password for both directions in the MIT realm. The second thing to ensure is that the version of Windows 2000 is a North American version because of the various export limitations.
The KDC knows if the request is coming from an MIT realm by examining the flags in the ticket. If the request is from an MIT realm, the KDC checks to see if a Windows 2000 PAC is in the ticket. If there is no PAC, the KDC will attempt to find the Windows 2000 account that the MIT user is mapped to. If there is no mapping for this MIT/UNIX user, then no PAC information is added to the ticket. This ensures that the ticket will be a small enough size to fit the User Datagram Protocol (UDP) packet size that the MIT Kerberos V5 implementations are expecting.
NTLM in Windows 2000
A Different Role
NTLM authentication does not go away in Windows 2000. In Windows NT 4.0, NTLM is the default authentication protocol. As noted, the Kerberos protocol is the default authentication protocol in Windows 2000, but NTLM is supported. For both local logon and non-Windows 2000 clients or servers, NTLM is still used to authenticate users.
When you log on to a computer, Windows attempts to use the Kerberos protocol as the primary source of user authentication. If the KDC is not found for Kerberos authentication, then Windows uses NTLM security to authenticate users in the local Security Accounts Manager (SAM) database.
The way this works is the Graphical Identification and Authentication (GINA) collects the user's logon information and passes it to the Local Security Authority (LSA) for authentication. The LSA passes the information on to the Security Support Provider Interface (SSPI). SSPI does not know or care if the user is logging on locally or through a domain account and has an interface to both Kerberos and NTLM.
Because the Kerberos protocol is the default authentication provider, the authentication request is first passed to the Kerberos Security Support Provider (SSP). The Kerberos protocol checks to see if the logon target name is the same as the local computer name. If so, the Kerberos protocol returns an error message to the SSPI that no logon servers are available, just as if it had checked the network for a KDC and found none. The SSPI starts the process over from the beginning and eventually sends the request to the next security provider, NTLM. The authentication process used by NTLM is identical to previous versions of Microsoft Windows NT. The following graphic describes this process.
The authentication protocol is determined by the capability of client and server. If the client cannot use the Kerberos protocol, Windows 2000 servers can use NTLM. And if the Windows 2000 client tries to authenticate to a Windows NT 4.0 domain controller, the Windows 2000 client can use NTLM. So, client computers running previous versions of Windows NT or Windows 9x will have no problem authenticating to a Windows 2000 domain controller.
Note also that if you have transitive trusts set up between multiple domains, the downlevel clients will be trusted throughout the forest if the target domain contains Windows 2000 domain controllers.
Going the other way around, a Windows 2000 computer can authenticate to a Windows NT 4.0 domain controller using NTLM.
In order to use the Kerberos protocol, the following four conditions must be true:
The user who is logging on must be part of a Windows 2000 domain.
The computer being logged on to must be running Windows 2000.
The computer being logged on to must be part of a Windows 2000 domain.
The user account and the computer account must be in the same forest of domains.
A mixed-mode domain is one with both Windows 2000 domain controllers and Windows NT 4.0 domain controllers. Windows 2000 domain controllers can emulate the services and capabilities of Windows NT 4.0 domain controllers and so both types of domain controller can cohabitate in a single domain without problem.
Although the servers can cohabitate without problems, testers have uncovered one potentially surprising requirement for clients in a mixed-mode domain. Windows 2000 clients require a Windows 2000 domain controller in order to log on. Without at least one Windows 2000 domain controller available, a Windows 2000 client will be able to perform only a local logon to that computer. A domain logon for a Windows 2000 client will not be possible if only Windows NT 4.0 backup domain controllers (BDCs) are available. This makes sense if you remember that Windows 2000 clients require the Kerberos protocol for a domain logon, and Windows NT 4.0 BDCs obviously cannot service such requests. Workarounds for this scenario are described in Summary of "Piling On" Scenarios in Active Directory Domains and How to Prevent Overloading on the First Domain Controller During Domain Upgrade.
The Windows 2000 Domain Model and Security
A Collection of Objects
A Windows 2000 domain is just the collection of objects that share the same Active Directory database. These objects can be computers, users, groups, policies, and so on. A set of Windows 2000 domains can be related in a parent-child manner. This relationship is determined when the domain is created. When two domains are connected this way, a transitive, two-way trust is established between the domains.
The Windows 2000 model differs from the Windows NT model. In that model, any trust between domains had to be explicitly built.
Security Implications of the Win2K Domain Model
Every domain controller is a KDC. The KDC keeps everyone's private key. Therefore, every domain controller has a copy of every secret key. This means the network administrator needs to keep the passwords and the computers as secure as possible.
To protect user passwords, the Kerberos client transforms them into 64-bit keys that are used to encrypt the tickets passed between the client computer and the domain controller.
Three password policies should be set to ensure that users choose harder-to-guess passwords. To do this, go to Start/Programs/Administrative Tools/Domain Controller Security Policy. Open Security Settings, open Account Policies, and then open Password Policy.
Here you will find Enforce password history, which should be set to at least 10 passwords.
Maximum password age should be set to however many days your security policy requires a password change. The suggested number is 56 days.
Minimum password length should be set to at least six characters; eight characters is better. (Note that with a six-character password, the last 8 bits of the 64-bit key used by the Kerberos client would be all zeros. You need at least seven characters to "fill" the key with random data.)
Finally, you should enable Passwords must meet complexity requirements so that passwords must contain punctuation and uppercase and lowercase letters.
You may want to set the Minimum password age policy to not allow passwords to be changed in rapid succession. This prevents a user from changing the password 11 times to get around the password history limitations.
Physical security is critical. Physical security on the domain controllers has always been crucial, but in Windows 2000 it is even more important. Remember, every KDC keeps every secret key in the domain. If an attacker could obtain your system backups or even "borrow" your system disk for an hour, the attacker will likely be able to break into your system because the attacker has more time than anything else.
Another way an attacker might put a few of these items together and potentially gain access to your system would be by changing the time on the domain controller. A replay attack combined with tickets being forwardable might allow access by an attacker not currently on site.
Configuring Trusts in Windows 2000
When a domain is added as a child domain, a domain controller from each domain negotiates a secret key to be used for secure exchanges. The domain controllers use this secret key as the basis for encrypting the various tickets that would be required for users in one domain to access resources in the other domain. Because the domain controllers in each domain share a secret key, there is a two-way trust between the domains. Establishing the two-way trust is only a matter of having the domain controllers negotiate a secret key. The secret key is automatically changed on a regular basis as part of the normal interdomain communication. In order to reset a broken trust, you can use the NetDom command line utility.
Security Implications of Transitive Trusts
Everyone trusts everyone. Remember high school math? Transitivity was defined as if a = b and b= c then a = c. Or in other terms, the friend of my friend is my friend. The authentication credentials of a user from another domain are just as valid as the authentication credentials of user in my own domain.
When the trust is established, a secret key is established and shared between the domains. This allows a KDC in one domain to give out a ticket-granting ticket for another domain. By traversing through the domain structure, a Kerberos client can eventually obtain a session ticket for any resource in any domain that is connected to the user's home domain.
An authenticated user in one domain is an authenticated user in every domain that is connected to that user's home domain.
Credentials can be forwarded or proxied. Conceptually, this means that a ticket can have one IP address for the source computer and a different IP address for the requesting computer.
Another good rule to follow is to keep the number of domains as small as possible, but no smaller. If there are K domains, there must be ((K * (K-1))/2) secure key exchanges to allow each domain to interoperate with the others.
Kerberos Capacity Planning
Determining Computer Size
One of the questions a system designer must answer is how large the domain controller computer must be to support authentication in the organization. The encryption and decryption of the Kerberos tickets take some amount of resource on the domain controller.
The Deployment Competency Center at Microsoft has conducted performance and stress testing to assist with this. You should use these results as a broad guideline. The results should give you some idea about the magnitude of the computer you are likely to require. Be sure to test your intended computer(s) in a controlled lab environment before going into production with your design.
Earlier, this paper mentioned the three primary Kerberos message pairs that the Kerberos protocol uses to authenticate a user. The three messages are the AS, the Ticket-Granting Service, and the AP. The AS and the Ticket-Granting Service are used during the initial user logon sequence between the client computer and the domain controller to establish the user's credentials on the client computer. The Ticket-Granting Service set is used when the client wants to access resources on some computer providing some service or application. The client sends the Ticket-Granting Service request to the KDC with the name of the application server the client wants access to. The KDC responds with a Ticket-Granting Service message that contains a ticket the client can send to the application server. The client sends the last Kerberos message, the AP request, to the application server when the client wants access to that server's resources.
Because the AP messages are sent between a client and an application server, and not sent to the domain controller, the tests documented here ignored the AP messages.
In the lab, two environments were set up, one with a low-budget domain controller that the team considered "small" and one with a high-performance enterprise domain controller that the team considered "large." In both cases, four workstations were used to send messages to the domain controller. All computers had 100-megabit Ethernet cards and were on an isolated network.
The low-budget domain controller was a Dell OptiPlex GXI 500 with 128 megabytes (MB) of RAM and one 500 megahertz (MHz) Pentium, with 32 kilobytes (KB) of level 1 cache and 256 KB of level 2 cache,, running Windows 2000 Server build 2195.
The high-performance enterprise domain controller was a Dell PowerEdge 6300/550 with 4* 550 MHz Pentium, with 32 KB of level 1 cache and 1 MB of level 2 cache, 1 gigabyte (GB) of RAM, running Windows 2000 Advanced Server build 2195.
All of the workstations were Dell OptiPlex GX1p with 128 MB of RAM and one 500 MHz processor, three of which used Windows 2000 Professional build 2195, and one used Windows 2000 Server build 2195.
The test used scripts to populate Active Directory with about 80,000 users and about 160,000 total objects. The users were three organizational unit levels down so that the test might reflect a somewhat complex structure.
These tests used a tool called ADTest. ADTest is a Microsoft internal tool developed by the Windows 2000 performance group. Currently, this tool is not part of the Windows 2000 Resource Kit. Customers who want to conduct performance tests on their hardware platform can contact Microsoft Consulting Services for assistance.
Each domain controller ran a script that would send a batch job to each of the workstations participating in the test. The batch job ran a program that read a script file and performed the actions in the script file. The script file could contain looping constructs, as well as calls to the various LDAP and LSA application programming interface (API). If there are loops, the workstations were set to loop through the process as fast as possible with no lag or sleep time.
On the domain controller, PerfMon measured logons per second, average disk queue length, percentage of processor time (both total and for each processor), and percentage of total processor time for the Local Security Authority Server Service (LSASS) process. (The testers initially recorded available bytes but found it was not a factor in the tests.)
The testers recorded both the maximum values and the average values for each five-minute run of each test. They recorded the total number of loops processed by the workstation and divided that number by the amount of time the test ran. This gave a "loops per second" value that was divided by 10 in order to get it to fit on the graph. The program running on the workstation also kept a count of the operations per second on an average basis. The testers recorded a rounded average of the numbers the workstation showed.
The testers wanted to find the number of logons that would cause maximum load as well as the number of logons that caused about 70 percent load. Other than the testing software, no application was running on the domain controller.
They examined two basic scenarios. The first was the logon sequence. The logon sequence consisted of eight API calls, followed by execution of the user's logon script. For testing purposes, they assumed a minimal logon script and only the default policies for the user logon.
For the logon tests, the script file chose a random user in the range of users in the Active Directory, selected that user, and performed the logon sequence of events. This repeated until the batch file process was killed or the computer was restarted. The testers had a "throttle" on the process that allowed them to control the rate per second that requests were sent from the client to the server. They generally tried to set the throttle high enough that clients never paused between loops. In the charts, the legend term "rate" refers to this throttle. The rate was set to 50 requests per second in order to ensure that the client was not a limiting factor in any test.
The idea was to get numbers for how many logons a server could perform. The testers wanted to simulate the "Monday at 8:00 in the morning" case where perhaps every user in the organization wants to log on within the same few moments.
On the high-performance enterprise domain controller, they tested with one, two, three, and four processors so that they could get a valid comparison about how the number of processors affects the number of possible logons.
The second scenario tested the Kerberos Ticket-Granting Service messages. The thought was that a user will log on once per day, but will access several "application" servers per day. This type of access requires only the Ticket-Granting Service message pair between the client and the domain controller. For this test, they randomly chose a user and called LsaCallAuthenticationPackage with a ProtocolSubmitBuffer of KERB_RETRIEVE_TKT_REQUEST. There were no other steps in the process.
The goal of this test was to find how many Ticket-Granting Service tickets could be produced and sent by a server. The testers used the same process to send messages as with logons, and they measured the same parameters. Also in this test, only the testing software was running on the domain controller.
The following graphic shows the results of the logon tests with the low-budget domain controller. You can see in this chart that changing the throttle value from 20 to 50 operations per second did not affect any of the parameters. The disk utilization also was not affected by increasing any of the parameters. Increasing the number of workstations sending requests increased the logons per second as well as the CPU utilization. You also can see that even a relatively small number of logons, averaging 10 per second, takes more than 50 percent of the CPU time in the low-budget domain controller. In order to keep average CPU utilization at 70 percent or less, the average number of logons per second was about 15 (or about 900 per minute).
The next figure shows the data with the high-performance enterprise domain controller. Here too you can see that the number of logons processed is related directly to the CPU utilization and available CPU cycles. With the number of workstations available, the tests were unable to push the high-performance enterprise domain controller above 70 percent average total CPU utilization when all four processors were operating. With all four processors operating, the testers processed between 2,100 and 2,400 logons per minute. Adding CPUs did improve performance, but not in a linear way. Each additional processor added increasingly fewer logons per second than the previous processor. Disk performance was not a factor in these tests.
The next figure shows the results of the Ticket-Granting Service-only tests. The testers could not get the low-budget domain controller to use more than 8 percent of the CPU even when sending about 1 million requests per minute. The test environment was not large enough to create enough traffic to stress either of the domain controllers. The results for both domain controllers are very similar.
Analysis and Recommendations
The following conclusions are based on the test results:
The Microsoft implementation of Kerberos V5 protocol will support the largest enterprise environments. The low-budget domain controller is effectively the same size as a "power user" workstation. You would think that only the smallest companies would be using this level of server for their actual domain controllers. But at 900 logons per minute, and assuming a five-minute window for the entire organization to log on to the system on Monday morning, the small server would support as many as 4,000–4,500 users. Using the high-performance enterprise domain controller, that five-minute window allows more than 10,000 users to log on.
Adding multiple processors seems to add about 50 percent more capability for the second processor, 25 percent for the third, and another 10 percent to 15 percent for the fourth processor. This would seem typical for CPU bound operations.
To support this level of logon performance, a company should have at least one domain controller that is dedicated to this purpose. If a company expects to use the domain controller for other work, it will have to plan logon performance accordingly.
Because most organizations will have at least two domain controllers, using computers the size of the low-budget domain controller should support organizations of up to about 5,000 users. For organizations of up to about 10,000 users, you should use a computer in the same class as the high-performance enterprise domain controller computer. You also should add a pair of high-performance enterprise domain controller computers for every 10,000 users in the organization.
The Ticket-Granting Service messages are insignificant in terms of domain controller load. Even the low-budget domain controller could handle the maximum testable load with minimal CPU usage.
This testing environment was not the same as any production environment. Many, many factors will influence your actual results. This test environment had a dedicated network and domain controllers doing nothing other than servicing the test requests. This testing process should accurately reflect the actual traffic that occurs in real situations. However, the tests did not actually involve 4,000 users on separate workstations. Your results will vary.
The test did not consider level 2 (L2) cache because it is understood that cache size will impact the results. However, logon testing by Intel Corp. found the following:
512 KB to 1 MB L2: 7 percent to 19 percent throughput increase
1 MB to 2 MB L2: 4 percent to 31 percent throughput increase