Configuring Authentication Service on Microsoft Windows Vista
John R. Vacca
This appendix describes the configuration of Windows Vista® authentication service features that are relevant to IT professionals. The authentication service features included with Windows Vista extend to a strong set of platform-based authentication features to help provide better security, manageability, and user experience. The features include the following:
• Backup and Restore of Stored Usernames and Passwords
• Credential Security Service Provider and SSO for Terminal Services Logon
• TLS/SSL Cryptographic Enhancements
• Smart Card Authentication Changes
• Previous Logon Information1
1. Backup and Restore of Stored Usernames and Passwords
In some environments, the stored usernames and passwords feature significantly affects user efficiency and productivity because it can store dozens of credentials for using network resources per user. Unfortunately, this same usefulness can lead to frustration if a user suddenly loses his or her stored usernames and passwords because of a hardware or software failure on the client computer she regularly uses.1
To resolve this potential source of user frustration (or to help organizations support this feature), Windows Vista includes a Backup and Restore Wizard that allows users to back up usernames and passwords they have requested that Windows remember for them. This new functionality allows users to restore the usernames and passwords on any computer running Windows Vista. Restoring a backup file on a different computer allows users to effectively roam or move their saved usernames and passwords.1
To access this feature, open Control Panel, double-click User Accounts, and then click Manage your network passwords. If you have previously saved any credentials, the Back up button is enabled.1
Automation and Scripting
For security reasons, this feature cannot be automated, nor can the backup process be initiated by an application that runs under standard user credentials. This feature requires Windows Vista.1
Security Considerations
The backup file is encrypted by using Advanced Encryp-tion Standard (AES) and a password supplied by the user at the time the backup is performed. The password should be a strong password to avoid the possibility of the backup being compromised if the password is lost.1
2. Credential Security Service Provider and SSO for Terminal Services Logon
Authentication protocols are implemented in Windows by security service providers. Windows Vista introduces a new authentication package called the Credential Security Service Provider, or CredSSP, that provides a single sign-on (SSO) user experience when starting new Terminal Services sessions. CredSSP enables applications to delegate users’ credentials from the client computer (by using the client-side security service provider) to the target server (through the server-side security service provider) based on client policies. CredSSP policies are configured via Group Policy, and delegation of credentials is turned off by default.1
Like the Kerberos authentication protocol, CredSSP can delegate credentials from the client to the server, but it does so by using a completely different mechanism and with different usability and security characteristics. With CredSSP, when policy specifies that credentials should be delegated, users will be prompted for credentials (unlike Kerberos delegation) which means the user has some control over whether the delegation should occur and (more importantly) what credentials should be used. With Kerberos delegation, only the user’s Active Directory® credentials can be delegated.1
Unlike the experience in Windows Server® 2003 Terminal Server, the credential prompt is on the client computer and not the server. Most importantly, the client credential prompt is on the secure desktop. Therefore, not even the Terminal Services client can see the credentials, which is an important Common Criteria requirement. Furthermore, the credentials obtained from the prompt will not be delegated until the server identity is authenticated (subject to policy configuration). Finally, the terminal server will not establish a session for the user (which consumes a significant amount of memory and CPU processing time on the server) before authenticating the client, which decreases the chances of successful denial-of-service attacks on the server.1
Requirements
This feature requires the Terminal Services client to run on Windows Vista or Windows Server 2008. It also requires that Terminal Services be hosted on a server that runs Windows Server 2008.1
Configuration
CredSSP policies, and by extension the SSO functionality they provide to Terminal Services, are configured via Group Policy. Use the Local Group Policy Editor to navigate to Local Computer Policy | Computer Configuration | Administrative Templates | System | Credentials Delegation, and enable one or more of the policy options.1
Security Considerations
When credential delegation is enabled, the terminal server will receive the user credentials in plaintext form, which can introduce risk to the network environment if the servers are not well secured. An organization that wants to achieve this functionality should plan carefully for its deployment and ensure that an effective security program for the servers is in place beforehand.1
In addition, a few of the policy settings might increase or decrease the risk. For example, the Allow Default Credentials with NTLM-only Server Authentication and Allow Fresh Credentials with NTLM-only Server Authentication policy settings remove the restriction to require the Kerberos authentication protocol for authentication between the client and server. If a computer requires NTLM and either of these settings is selected, then NTLM will be used and will allow communication to occur successfully but at a higher security risk. The Kerberos protocol provides significant additional security in this scenario because it provides mutual authentication—that is, positive authentication of the server to the client. This functionality is important, because users should be protected from delegating their plaintext credentials to an attacker who might have taken control of a network session. Before enabling the NTLM-only policies, network administrators should first ensure that NTLM authentication is necessary in the scenario that they need to support.1
3. TLS/SSL Cryptographic Enhancements
Microsoft has added new TLS extensions that enable the support of both AES and new elliptic curve cryptography (ECC) cipher suites. In addition, custom cryptographic mechanisms can now be implemented and used with Schannel as custom cipher suites. Schannel is the Windows security package that implements TLS and SSL.1
AES Cipher Suites
The support for AES (which is not available in Microsoft Windows® 2000 Server or Windows Server 2003) is important, because AES has become a National Institute of Standards and Technology (NIST) standard. To ease the process of bulk encryption, cipher suites that support AES have been added. The following list is the subset of TLS AES cipher suites defined in Request for Comments (RFC) 3268, Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) (http://go.microsoft.com/fwlink/?LinkId=105879), that are available in Windows Vista:
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA1
Requirements
To negotiate these new cipher suites, the client and server computers must be running either Windows Vista or Windows Server 2008.1
Configure AES
For information about the registry entries used to configure TLS/SSL ciphers in previous versions of Windows, see TLS/SSL Tools and Settings (http://go.microsoft.com/fwlink/?LinkId=105880). These settings are only available for cipher suites included with Windows operating systems earlier than Windows Vista and are not supported for AES. Cipher preferences are configured in Windows Vista by enabling the SSL Cipher Suite Order policy setting in Administrative Templates | Network | SSL Configuration Settings.1
ECC Cipher Suites
ECC is a key-generation technique that is based on elliptic curve theory and is used to create more efficient and smaller cryptographic keys. ECC key generation differs from the traditional method that uses the product of very large prime numbers to create keys. Instead, ECC uses an elliptic curve equation to create keys. ECC keys are approximately six times smaller than the equivalent strength traditional keys, which significantly reduces the computations that are needed during the TLS handshake to establish a secure connection.1
In Windows Vista, the Schannel security service provider includes new cipher suites that support ECC cryptography. ECC cipher suites can now be negotiated as part of the standard TLS handshake. The subset of ECC cipher suites defined in RFC 4492, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) (http://go.microsoft.com/fwlink/?LinkId=105881), that are available in Windows Vista is shown in the following list:
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P5211
The ECC cipher suites use three NIST curves: P-256 (secp256r1), P-384 (secp384r1), and P-521 (secp521r1).1
Requirements
To use the ECDHE_ECDSA cipher suites, ECC certificates must be used. Rivest-Shamir-Adleman (RSA) certificates can be used to negotiate the ECDHE_RSA cipher suites. Additionally, the client and server computers must be running either Windows Vista or Windows Server 2008.1
Configure ECC Cipher Suites
Cipher preferences are configured in Windows Vista by using the SSL Cipher Suite Order policy setting in Administrative Templates | Network | SSL Configuration Settings.1
Schannel CNG Provider Model
Microsoft introduced a new implementation of the cryptographic libraries with Windows Vista that is referred to as Cryptography Next Generation, or CNG. CNG allows for an extensible provider model for cryptographic algorithms.1
Schannel, which is Microsoft’s implementation of TLS/SSL for Windows Server 2008 and Windows Vista, uses CNG so that any underlying cryptographic mechanisms can be used. This allows organizations to create new cipher suites or reuse existing ones when used with Schannel. The new cipher suites included with Windows Server 2008 and Windows Vista are only available to applications running in user mode.1
Requirements
Because both the client and server computers must be able to negotiate the same TLS/SSL cipher, the Schannel CNG feature requires Windows Server 2008 and Windows Vista to use the same custom cipher configured for use on both the client and server computers. In addition, the custom cipher must be prioritized above other ciphers that could be negotiated.1
Configure Custom Cipher Suites
Cipher preferences, including preferences for custom cipher suites, are configured in Windows Vista by using the SSL Cipher Suite Order policy setting in Administrative Templates | Network | SSL Configuration Settings.1
Default Cipher Suite Preference
Windows Vista prioritizes the complete list of TLS and SSL cipher suites as shown in Table A.1.1 The cipher suite negotiated will be the highest-listed cipher suite that is supported by both the client and the server computers.1
Table A.1
Prioritized List of TLS and SSL Cipher Suites
| Number | Cipher Suites |
| 1. | TLS_RSA_WITH_AES_128_CBC_SHA |
| 2. | TLS_RSA_WITH_AES_256_CBC_SHA |
| 3. | TLS_RSA_WITH_RC4_128_SHA |
| 4. | TLS_RSA_WITH_3DES_EDE_CBC_SHA |
| 5. | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256 |
| 6. | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384 |
| 7. | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521 |
| 8. | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256 |
| 9. | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384 |
| 10. | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521 |
| 11. | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 |
| 12. | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 |
| 13. | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 |
| 14. | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 |
| 15. | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 |
| 16. | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 |
| 17. | TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
| 18. | TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
| 19. | TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA |
| 20. | TLS_RSA_WITH_RC4_128_MD5 |
| 21. | SSL_CK_RC4_128_WITH_MD5 |
| 22. | SSL_CK_DES_192_EDE3_CBC_WITH_MD5 |
| 23. | TLS_RSA_WITH_NULL_MD5 |
| 24. | TLS_RSA_WITH_NULL_SHA |
Previous Cipher Suites
The Microsoft Schannel provider supports the cipher suites listed in Table A.2.1 However, the cipher suites are not enabled by default. To enable any of these cipher suites, use the SSL Cipher Suite Order policy setting in Administrative Templates | Network | SSL Configuration Settings.
Table A.2
Previous Cipher Suites
| Number | Cipher Suites |
| 1. | RSA_EXPORT_RC4_40_MD5 |
| 2. | RSA_EXPORT1024_RC4_56_SHA |
| 3. | RSA_EXPORT1024_DES_CBC_SHA |
| 4. | SSL_CK_RC4_128_EXPORT40_MD5 |
| 5. | SSL_CK_DES_64_CBC_WITH_MD5 |
| 6. | RSA_DES_CBC_SHA |
| 7. | RSA_RC4_128_MD5 |
| 8. | RSA_RC4_128_SHA |
| 9. | RSA_3DES_EDE_CBC_SHA |
| 10. | RSA_NULL_MD5 |
| 11. | RSA_NULL_SHA |
| 12. | DHE_DSS_EXPORT1024_DES_SHA |
| 13. | DHE_DSS_DES_CBC_SHA |
| 14. | DHE_DSS_3DES_EDE_CBC_SHA |
4. Kerberos Enhancements
Microsoft’s implementation of the Kerberos authentication protocol is significantly improved in Windows Vista with the following features:
• Improved security for Kerberos Key Distribution Centers (KDCs) located on branch office domain controllers1
AES
This Windows Vista security enhancement enables the use of AES encryption with the Kerberos authentication protocol. This enhancement includes the following changes from Windows XP:
• AES support for the base Kerberos authentication protocol. The base Kerberos protocol in Windows Vista supports AES for encryption of ticket-granting tickets (TGTs), service tickets, and session keys.
• AES support for the Generic Security Service (GSS)-Kerberos mechanism. In addition to enabling AES for the base protocol, GSS messages (which conduct client/server communications in Windows Vista) are protected with AES.1
Requirements
All Kerberos authentication requests involve three different parties: the client requesting a connection, the server that will provide the requested data, and the Kerberos KDC that provides the keys that are used to protect the various messages This discussion focuses on how AES can be used to protect these Kerberos authentication protocol messages and data structures that are exchanged among the three parties. Typically, when the parties are operating systems running Windows Vista or Windows Server 2008, the exchange will use AES. However, if one of the parties is an operating system running Windows 2000 Professional, Windows 2000 Server, Windows XP, or Windows Server 2003, the exchange will not use AES. The specific exchanges are:
• TGT. The TGT is created by the KDC and sent to the client if authentication to the KDC succeeds.
• Service ticket. A service ticket is the data created by the KDC, which is provided to the client and then sent by the client to the server to establish authentication of the client.
• AS-REQ/REP. The authentication service request/response (AS-REQ/REP) exchange is the Kerberos TGT request and reply messages sent to the KDC from the client. If the exchange is successful, the client is provided with a TGT.
• TGS-REQ/REP. The ticket-granting service request/response (TGS-REQ/REP) exchange is the Kerberos service ticket request and reply messages that are sent to the KDC from the client when it is instructed to obtain a service ticket for a server.
• GSS. The Generic Security Service application programming interface (GSS-API) and the Generic Security Service Negotiate Support Provider (GSS-SPNEGO) mechanisms negotiate a secure context for sending and receiving messages between the client and server by using key material derived from the previous ticket exchanges.1
Table A.3 shows whether AES is used in each exchange for different combinations of Windows operating systems.1
Table A.3
Usage of AES with Various Windows Operating Systems
Read-Only Domain Controller and Kerberos Authentication
Windows Vista includes new Kerberos authentication protocol features to further protect a Windows Server 2008 domain controller that is physically located in a branch office. With the read-only domain controller (RODC), the KDC issues TGTs to branch users only and forwards other requests to the hub domain controller.1
In the Windows implementation, the keys used to create TGTs are derived from the password of the krbtgt account. This account and its password are typically replicated to every domain controller in the domain. In the branch office scenario, the risk of theft or unauthorized access to the local domain controller (and therefore the security of the krbtgt account) is typically greater. To mitigate this risk, the RODC has a unique krbtgt account that does not have all of the capabilities of a standard krbtgt account on a standard domain controller. If the RODC is compromised, the scope of the breach in regards to the krbtgt account information is limited to that RODC, not the other KDCs.1
5. Smart Card Authentication Changes
Although Windows Server 2003 includes support for smart cards, the types of certificates that smart cards can contain are limited by strict requirements. Each certificate needs to be associated with a user principal name (UPN) and needs to contain the smart card logon object identifier (also known as OID) in the Enhanced Key Usage field. In addition, each certificate requires that signing be used in conjunction with encryption.1
To better support smart card deployments, Windows Vista enables support for a range of certificates. Customers now have the ability to deploy smart cards with certificates that are not limited by the previous requirements. Specific certificate requirements that were changed are itemized in the following list:
• For smart card logon, the Enhanced Key Usage (no need for smart card logon object identifier) and Subject Alternative Name (need not contain email ID) fields are not required. If an enhanced key usage is present, it must contain the Smart Card Logon enhanced key usage.
• You can enable any certificate to be visible for the smart card credential provider.
• Smart card logon certificates do not require a Key Exchange (AT_KEYEXCHANGE) field.
• Certificate Revocation List (CRL) is no longer a required field.1
Because the restrictions found in previous versions of Windows are still considered best practices for certificate deployment, the listed changes are not enabled by default except for multiple certificates support (some certificates are excluded). Administrators need to configure the registry keys on client computers to enable the functionality. Group Policy can be used to accomplish this configuration. In addition to these changes to the smart card requirements, the following functional changes have been made for smart card logon:
• When a smart card is inserted into a smart card reader, the logon process does not start automatically. Typically, users are now required to press Ctrl +Alt+Delete to start the logon process.
• All valid smart card logon certificates are enumerated and presented to users. The smart card must be inserted before users can enter a personal identification number (PIN).
• Keys are no longer restricted to being in the default container, and certificates in different smart cards can be chosen.
• Multiple Terminal Services sessions are supported in a single process. Because Windows Vista is closely integrated with Terminal Services to provide fast user switching, this functionality is an important improvement.1
Additional Changes to Common Smart Card Logon Scenarios
The following part of this appendix, describes the changes in Windows Vista for common smart card authentication and logon scenarios.1
Smart Card Logon of a Single User with One Certificate into Multiple Accounts
In Windows Vista, a single user certificate can be mapped to multiple accounts. For example, a user can log on to his or her user account or can log on as domain administrator.1
Smart Card Logon of Multiple Users into a Single Account
Windows Vista supports the ability for multiple users with unique smart card certificates to log on to a single account, such as an administrator’s account.1
Smart Card Logon Across Forests
In some situations, such as logon across forests, there might not be enough information in the smart card certificate to reliably route the logon request. Windows Vista allows users to enter a “hint” in the form domainuser username or a fully qualified UPN such as [email protected] that allows reliable authentication routing. For the Hint field to appear during smart card logon, the X509HintsNeeded registry key must be set on the client computer.1
OCSP Support for PKINIT
The Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) protocol is the smart card authentication mechanism for the Kerberos authentication protocol. Online Certificate Status Protocol (OCSP), defined in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP (http://go.microsoft.com/fwlink/?LinkID=67082), enables applications to obtain timely information regarding the revocation status of a certificate.1
Because the Windows KDC is a high-volume transactional service, it benefits greatly by using OCSP instead of relying on CRLs. Windows Server 2008 KDCs will always attempt to use OCSP to verify certificate validity.1
Certificate Revocation Support
Table A.4 describes the registry key values you can use to disable CRL checking.1
Table A.4
Registry Key Values to Disable CRL Checking
| Key | Value |
| HKLMSYSTEMCCSServicesKdcUseCachedCRLOnlyAndIgnore RevocationUnknownErrors | Type= DWORD Value=1 |
| HKLMSYSTEMCCSControlLSAKerberosParametersUseCachedCRL OnlyAndIgnoreRevocationUnknownErrors | Type=DWORD Value=1 |
Smart Card Root Certificate Requirements for Use When Joining a Domain
When using a smart card to join a domain, the smart card certificate must comply with one of the following conditions:
• The smart card certificate must contain a Subject field that contains the DNS domain name within the distinguished name. If it does not contain this field, resolution to the appropriate domain will fail, causing the domain join with smart card to fail.
• The smart card certificate must contain a UPN in which the domain part of the UPN must resolve to the actual domain. For example, the UPN [email protected]would work, but [email protected] would not work because the Kerberos client would not be able to find the appropriate domain.1
The solution for both of the listed conditions is to supply a hint (enabled via the X509HintsNeeded registry setting) in the credentials prompt when joining a domain. If the client computer is not joined to a domain, then the client will only be able to resolve the server domain by viewing the distinguished name on the certificate (as opposed to the UPN). For this scenario to work, the Subject field for the certificate must include “DC =” for domain name resolution. To deploy root certificates on smart cards for the currently joined domain, the following command can be used:1
Terminal Server Redirection
In terminal server scenarios, remote servers are used to run services. However, the smart card is local to the computers from which the connections are established. In smart card logon scenarios, the Smart Card service on the remote servers will appropriately redirect to the smart card readers that are connected to the remote computers from which users are trying to log on.1
Terminal Server Sign-On Experience
As a part of Common Criteria compliance requirements, the Terminal Services client must be able to be configured to use Stored User Names and Passwords to acquire and save users’ passwords and smart card PINs. Common Criteria requires that applications must not have direct access to users’ passwords or PINs.1
Specifically, the Common Criteria requirement is that passwords and PINs never leave the highly trusted Local Security Authority (LSA) unencrypted. When this requirement is applied to a distributed scenario, it should allow passwords and PINs to travel between one trusted LSA and another if they are encrypted during transit.1
In Windows Vista, smart card users will need to log on for every new Terminal Services session. However, users are not prompted for their PINs more than once to establish a Terminal Services session. For example, after a user double-clicks a Microsoft Word document icon that resides on a remote computer, the user will be prompted to enter his or her PIN. This PIN will be passed via a secure channel established by CredSSP. The PIN is routed to the Terminal Services client over the secure channel, where it is used to access the keys on the smart card. Users are not prompted again for their PINs unless a PIN is incorrect or if a smart card fails due to problems with the card or reader.1
Terminal Services and Smart Card Logon
This feature enables users to log on with smart cards by entering a PIN on the Terminal Services client, which securely relays this information to the server in a manner similar to authentication that uses a user name and password. Smart card logon with Terminal Server was first introduced in Windows XP. It is not available in any earlier versions of the Windows operating system. In Windows XP, users can use only one certificate from the default container to log on. To enable smart card logon to a terminal server, the KDC certificate must be present on the local Terminal Services client computer.1
Terminal Services and Smart Card Logon across Domains
With Windows Vista, it is now possible to use smart cards to log on across domains or from computers that were not joined to domains trusted by the users’ account domains. Common scenarios where this functionality is required include:
• Using Routing and Remote Access to access an organization’s network resources across the Internet.
• Using Terminal Services across domains that are not trusted or computers that are not joined to a domain.1
To enable this functionality, the root certificate for the user’s account domain must be provisioned on the smart card. To provision the domain root certificate while using a computer that is a member of the domain, type the following at a command prompt:1
In addition, for Terminal Services access across trusting domains, the KDC certificate of the domain of the Terminal Services computer needs to be present in the NTAuth store of the client computer. The following command can be used to provision this certificate onto the client computer:1
Replace certfile with the root certificate of the KDC certificate issuer.1
To log on to a terminal server by using a smart card from a client computer that is not a member of the domain, the smart card needs to be provisioned with the root certificate of the terminal server’s domain controller. Furthermore, cross-domain terminal server logon will only work if the UPN attribute of the certificate is in the form username@domain_dns_name. If it is impossible or impractical to deploy certificates with the UPN attribute in this form, enabling domain hints with Group Policy is a potential solution.1
Terminal Services and Smart Card Logon Registry Settings
If smart card logon is the only form of logon that is supported, enable the following registry setting:1
AllowFreshCredentials
If the user also has a corresponding password-enabled account, enabling the following setting would also be useful:1
AllowFreshCredentialsWhenNTLMOnly
Delegation of default and saved credentials are not supported for Terminal Services with smart card logon. The following Group Policy settings are ignored:
• HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsCredentialsDelegation
• AllowDefCredentialsWhenNTLMOnly
• AllowSavedCredentialsWhenNTLMOnly1
6. Previous Logon Information
This setting enables users to determine whether their accounts were used (or were attempted to be used) without their knowledge. When this policy is enabled and the Windows Vista–based computer is joined to a Windows Server 2008 functional-level domain, the following information is displayed after a successful interactive logon:
1. Date and time of the last successful logon by that user
2. Date and time of the last unsuccessful logon attempt with the same user name
3. The number of failed logon attempts since the last successful logon with the same username1
Configuration
To enable this feature, use the Local Group Policy Editor to navigate to Local Computer Policy | Computer Configuration | Administrative Templates | Windows Components | Windows Logon Options, and enable Display Information about previous logons during user logon. Additional information is available on the Explain Text tab for this setting.1
Security Considerations
User training that accompanies the deployment of Windows Vista should include information about how to use this information and what to do if the information does not represent the user’s actions.1
1“Windows Vista Authentication Features,” Microsoft TechNet, © 2008 Microsoft Corporation; all rights reserved; Microsoft Corporation, One Microsoft Way, Redmond, WA 98052-6399, 2008.