Share via

New Authentication Functionality in Windows Vista

  • Article

 

GINAs Replaced with New Credential Providers

In previous releases, the customization of interactive user logon was done by creating a custom GINA. Despite the name, GINAs were responsible for more than simply gathering authentication information and rendering the UI to collect it. Because of this, custom GINAs were complex to create and usually required Microsoft® Product Support Services (PSS) support for successful implementation. Often, using a custom GINA resulted in unintended side effects such as preventing fast user switching (FUS) and smartcard login. In Windows Vista GINAs are replaced with a new modular Credential Provider model that is easier to program to.

 

New Credential Security Service Provider, CredSSP

Credential Security Service Provider (CredSSP) is a new security service provider available via the Security Support Provider Interface (SSPI) in Windows. CredSSP enables an application to delegate the user’s credentials from the client (by using the client-side SSP) to the target server (via the server-side SSP). CredSSP is used by Terminal Services to provide SSO.

Stored User Names and Passwords Backup and Restore Wizard

Stored User Names and Passwords in Windows Vista includes a Backup and Restore Wizard, which allows users to back up user names and passwords they have requested Windows to remember for them. This new functionality allows users to restore the user names and passwords on any Windows Vista system. Restoring user names and passwords from a backup file will replace any existing saved user names and passwords the user has on the system.

 

SSL/TLS Enhancements

Microsoft has added new SSL and TLS extensions, which enable the support of both AES and new ECC cipher suites. The support for AES—not available in Microsoft Windows 2000 or Windows Server 2003—is important as AES has become a National Institute of Standards and Technology (NIST) standard. In order to ease the process of bulk encryption, several cipher suites have been added that support AES.

 

Schannel ECC Cipher Suite Support

Elliptical curve cryptography, known as ECC is an encryption technique that uses a public key. ECC is based on elliptic curve theory and is used to create more efficient and smaller cryptographic keys. ECC differs from other forms that use the product of very large prime numbers to create keys; ECC instead makes use of an elliptic curve equation to create keys.

In Windows Vista, the Schannel SSP includes new cipher suites that support ECC cryptography. Now, ECC cipher suites can be negotiated as part of the standard TLS handshake.

               

Schannel Crypto Agility

Windows Vista offers an Open Cryptographic Interface (OCI) and crypto agile capabilities for Schannel. By providing crypto agnostic capability, Microsoft enables government organizations to substitute a higher level of functionality, including advanced combinations of cipher suites. Organizations can now create new cipher suites and then plug them into Schannel.

 

Kerberos support for AES

This Windows Vista security enhancement will enable the use of AES encryption with Kerberos. This enhancement includes the following changes from Windows XP:

• AES support for the base Kerberos protocol: The base Kerberos protocol in Windows Vista will support AES for encryption of TGTs, Service tickets, and session keys.

• AES support for Generic Security Services (GSS)-Kerberos mechanism: In addition to enabling AES for the base protocol, GSS messages—which make up client/server communications in Windows Vista are protected with AES.

               

Authentication Support for Branch Domain Controllers

Windows Server code name “Longhorn” includes new authentication feature changes to support the branch office DC feature in Longhorn.

               

Flexible Smartcard Authentication Support

Although Microsoft Windows Server 2003 included support for smartcards as well, the types of certificates that smartcards could contain were limited by strict requirements. First of all, each certificate needed to have a user principal name (UPN) it was associated with and needed to contain the smartcard logon OID in the extended key usage (EKU) field. In addition, each certificate required that signing was used in conjunction with encryption.

To better support smartcard deployments, Microsoft has made changes to the Windows operating system to enable support for a range of certificates. Now, customers can deploy smartcards with certificates that are not limited by the previous requirements.

                               

Last Login Time

This feature displays the time of the last successful interactive logon, and the number of failed logon attempts since the last successful logon, during a successful interactive logon. This will enable a user to determine if the account was used without his or her knowledge.

 

- The Windows Authentication Team

Comments

  • Anonymous
    January 01, 2003
    Is TLS enabled on the server app? What errorerrcode do you get on failure? Which version of OpenSSL? Could you use IIS instead for testing to eliminate the possibility of an error in the sample?

  • Anonymous
    January 01, 2003
    We run a full interop test spectrum with OpenSSL and the implementations have been interoperable for a while now. Could you report the specifics of the failure you are experiencing? The SDK sample should be current as no changes were needed to calling applications to take advantage of AES on VistaLH.

  • Anonymous
    January 01, 2003
    It was easy to setup. I used nmake to compile the SDK sample, the one in  the "SamplesSecuritySSPISSLWebServer". My environment is visual studio .net 2003. I ran it in verbose mode and TLS 1.0. I am using the windows wget at the link http://users.ugent.be/~bpuype/wget/ as the client. This one uses openssl library. I created a self-signed certificate and let the SDK WebServer uses this certificate. wget can successfully finish the handshake with WebServer, but the HTTP request it sent to WebServer can not be decrypted. It is something to do with cipher AES. It will have no problem if using IE as client or uses openssl but not uses AES cipher. I had tried other openssl client and got the same result. I ran Vista Business in the virtual machine. But I tried both VMWare and Virtual PC 2007 and they both had the same result. I had also tried the latest Windows 2008 beta and got the same result. I suspect it has something to do with SDK example, but many programs using CryptoAPI followed this SDK example.

  • Anonymous
    January 01, 2003
    Yes, the SDK WebServer sample has an option to use TLS 1.0. I had tried using the latest version of openssl. I had tried to use the new IIS beta in Windows 2008. IIS beta works with openssl AES cipher without this problem. That's the reason that I suspected the SDK sample program probably won't work with AES cipher in Vista.

  • Anonymous
    January 01, 2003
    Hi, I would like to create new cipher suite and then plug it into Schannel. But I Couldn't find the way how to do it. Could you tell me where I can get it or how to do it? thanks, Hyun

  • Anonymous
    January 01, 2003
    This seems to be happened in TLS also. I had tried to use SDK sample web server from: C:Program FilesMicrosoft Platform SDKSamplesSecuritySSPISSLWebServer If I connected it with AES128-SHA from client using Microsoft CryptoAPI, it works without any problem. But if I connected it with cipher AES128-SHA from client using openssl, TLS negotiation can success. The WebServer using Microsoft CryptoAPI can not decrypt message from openssl client. However, openssl client can decrypt message from CryptoAPI WebServer. Is the SDK example outdated with Windows Vista?

  • Anonymous
    January 01, 2003
    cxu123 let's move this discussion to the MSDN forum. We are not making good use of the comments section here :) I've started a thread here: http://forums.microsoft.com/technet/showpost.aspx?postid=1833975&siteid=17

  • Anonymous
    January 01, 2003
    Interestingly enough - this is an interop issue that we have seen previously. The problem is occurs only in the following scenario: TLS Enabled Client --> SSL3.0 only server The SSL3.0 server responds to a TLS client hello with a SSL3.0 server hello trying to negotiate an AES cipher. Unfortunately AES ciphers were not even defined for SSL3.0 and obviously the client closes the connection. The server in this case is misconfigured to negotiate AES over SSL3.0 This will be a bigger problem if not fixed when TLS 1.2 is implemented and SSL3.0 servers try to negotiate new TLS1.2 ciphersuites like TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.

  • Anonymous
    January 01, 2003
    Unfortunately the new AES encryption for SSL/TLS is not compatible with OpenSSL library! Many people experience this problem. http://www.mail-archive.com/openssl-users@openssl.org/msg48968.html

  • Anonymous
    January 01, 2003
    GordT, Sorry for the confusion. This was authored a while back before we knew Vista was just client. We have updated the text to avoid future confusion.

  • The Windows Authentication Team

  • Anonymous
    January 01, 2003
    Furthermore, I'd like to use new cipher suite at windows xp. If you know the way to plug the new cipher suite into XP, please let me know.

  • Anonymous
    January 01, 2003
    "Windows Vista includes new authentication feature changes to support the branch office DC feature in Longhorn." Are there more details on this? I thought it would be possible to use the Branch Office DC features with WinXP as well - is this not to be?

  • Anonymous
    March 20, 2006
    Interesting.  From an IT management / user point of view - does allow further development of the RunAs (secondary logon) theme to allow task based authorisation within windows generally?

    The push towards least privileged user accounts is great but it's not easily supported in the OS for day to day users.  For example, if they need to install a new application (and it's not been deployed via GP) it would be great if the OS would prompt them to elevate their privileges temporarily; or, if they needed to change their IP address - rather than simply saying "please contact your system administrator".

    Dare I say this: the users' experience of "least privilege" in OSX is good - they get prompted to confirm or enter credentials when they try to perform an "elevated" task in the OS which means that they can actually get on with life without "contacting your system administrator".  I believe this should at least be an option in a Windows environment as it would encourage organisations who currently don't implement a decent security policy for their desktop PCs (running as local admins for example is very common) to make some steps in the right direction.

  • Anonymous
    March 20, 2006
    Indeed we are working in Vista to improve the Least privilege user experience. Please take a look at the UAC blog for more details
    http://blogs.msdn.com/uac