Among its many other tasks, the domain controller authenticates users to a network, using security policies and user authentication information stored in the Active Directory service. During an interactive logon, a user logs on to a domain account with a password or smart card. The domain controller confirms the user's identity with the information stored in Active Directory. Once an interactive logon to a domain controller has taken place, network authentication is performed for the user without any further effort on the user's part. The user can access resources on the network without having to reenter a password or smart card personal identification number (PIN). An interactive logon can also authenticate a user to a local computer rather than a domain account. With a local interactive logon, network authentication requires the reentry of a password any time the user needs to access a network resource.
The Kerberos version 5 authentication protocol is used for interactive logon and is also the default protocol for network authentication. Each domain controller includes Kerberos version 5. Both the key distribution center and the ticket-granting service are components of Kerberos and become integral parts of the domain controller. The key distribution center runs as part of Active Directory, which stores passwords and user account information for authentication. A Kerberos client is installed on all Windows 2000 workstations and servers. See Chapter 18 for more information on Kerberos authentication.
Remote access clients, in addition to logging on to the network, must be authenticated by the remote access server before they can access the network. Smart cards and certificates, as well as password-based protocols, are used for dial-up networking. The next section explains how to obtain and use cryptographic tokens for network authentication, as well as how to configure remote clients and servers.
Smart cards combine the security of public-key cryptography with the portability of passwords. Before a smart card can be used for authentication, a logon certificate needs to be programmed onto the card. This is done by an administrator, who requests a smart card certificate from a certificate authority (CA) through an enroll-on-behalf-of station. See Chapter 20 for information on preparing a CA to issue smart card certificates.
More Info
Visit the PC/SC Workgroup Web site at http://www.pcscworkgroup.com for information on emerging smart card technologies and smart card vendors.To request smart card certificates from a CA, the administrator needs a special certificate to sign the request. This certificate, known as an enrollment agent certificate, must be requested by a logged-on domain administrator from the dedicated machine that will be used to program smart cards. An enrollment agent certificate is a software-based certificate and private key that can be requested through the Certificates MMC snap-in. (See the section entitled Requesting Certificates, later in this chapter.) Be sure to use the enrollment agent certificate template, as this is what authorizes the administrator to make smart card certificate requests.
It's possible, although highly inadvisable, to allow users to program their own smart cards by giving them access rights to the enrollment agent certificate template. Administrative programming and distribution of smart cards provides more accountability.
Once the administrator has installed a smart card reader on a system and has obtained the enrollment agent certificate, the system is ready to program smart cards. Smart card installation adds a cryptographic service provider (CSP) to the system that will be selected during the smart card programming process. (See the section Cryptographic Application Programming Interface in Chapter 18 for more information.)
The Web-based request process first generates a public/private key pair on your smart card. Using the public key and the user's name, the certificate authority issues and signs a certificate. Finally the certificate is added to the smart card. To program a smart card, follow these steps:
Table 19-2. Values for fields on the Smart Card Enrollment Station Web page
Field | Value |
---|---|
Certification Template | Smart card login |
Certificate Authority | CA to issue certificate |
Cryptographic Service Provider | The smart card manufacturer's CSP |
Administrator Signing Certificate | The enrollment agent certificate (see the previous section) |
User To Enroll | The name of the end user of the smart card |
Smart card certificates for users requiring different functionality (such as encryption) can be programmed similarly by specifying a different certification template.
Authentication can also be accomplished with private keys and certificates residing on a local computer. See the section entitled Requesting Certificates, later in this chapter, for information on how to obtain a certificate through the Certificates snap-in.
Once a smart card reader has been installed on the target system and the user has obtained a properly programmed smart card from the administrator, the user can use the smart card to log on to the computer. To do so, the user simply inserts the smart card into the reader and enters a PIN when prompted to do so. This process takes the place of pressing Ctrl+Alt+Del and entering a user name and password.
To keep thieves from accessing the system by using a stolen card, the system tallies incorrect logon attempts. After three consecutive failures, the card is locked out of the system.
As mentioned earlier, a user's public-key certificate, used for authentication, can be either programmed onto a smart card or stored locally on the computer. Follow the steps in the next two sections to enable dial-in authentication for each scenario.
Figure 19-6. The Properties dialog box for the dial-up connection.
Figure 19-7. The Advanced Security Settings dialog box.
Figure 19-8. Setting properties for smart card or certificate authentication.
The Advanced Security Settings dialog box is also used to set alternate password authentication protocols for a connection. These protocols, listed under Allow These Protocols, range from the unencrypted Password Authentication Protocol (PAP) to version 2 of the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v2). One or more of these allowable protocols can be selected.
The second option, Use A Different User Name For The Connection, keeps the authentication process from automatically using the certificate subject as the user name. This allows you to specify an alternate name.
Whether you're using smart card-based authentication, password-based authentication, or a mix of the two, ensure that your remote access clients and remote access servers support at least one common authentication method.
In addition to configuring the remote access client, you'll also need to set up the remote access server to allow smart card-based and certificate-based logins. Follow these steps to do so:
If clicking Configure returns an error stating that no certificate could be found, a machine certificate needs to be installed. This can be accomplished by ensuring that your enterprise CA is configured for auto-enrollment, which automatically allocates computer certificates for members of the domain. With this configured, run secedit /refreshpolicy machine_policy from a Windows 2000 command prompt on your remote access server to create a computer certificate.