Authentication Types

What is Authentication

Authentication is the process whereby the system identifies legitimate users from unauthorized users. It is the process in which a user identifies his/her self to the system. How effective an authentication process is, is determined by the authentication protocols and mechanisms being used. Windows Server 2003 provides a few different authentication types which can be used to verify the identities of network users, including:

The Kerberos version 5 authentication protocol is the default authentication type for a Windows Server 2003 environment. Kerberos version 5 makes use of a 'ticket' strategy to authenticate valid network users, and provides mutual authentication between users and resources. Windows Server 2003 supports the NTLM authentication protocol to provide compatibility for the earlier operating systems (OSs) such as for Windows NT 4 compatibility. Secure Sockets Layer/Transport Security Layer (SSL/TLS) and digest authentication is typically used for Web applications. SSL/TLS is based on X.509 public-key certificates, and enables mutual authentication between the client and server.

A few authentication features introduced with Windows Server 2003 are outlined below:

The remainder of this Article focuses on the different authentication types which you can implement to enforce an authentication strategy within your environment.

Kerberos Authentication Protocol

The foremost authentication protocol type used within a Windows Server 2003 Active Directory domain is the Kerberos version 5 authentication protocol. The Kerberos authentication protocol provides the following authentication features:

The terminology used to describe the process by which both the identity of users, and the identity of services being accessed are verified, is mutual authentication. The name of the Kerberos authentication protocol is derived from Greek mythology (three headed dog). This is because of the following three components of the protocol:

The Kerberos authentication type does not transmit passwords during the authentication process. Instead, it uses tickets. Tickets are specially formatted data packets that allow a client to access a resource. The ticket contains the identity of the user in an encrypted data format. When decrypted, the data or information verifies the identity of the client. Because the Kerberos authentication type makes use of tickets, it offers more security for the authentication process.

The Kerberos authentication type is dependant on the Key Distribution Center (KDC) to issue tickets. Each network client makes use of DNS to find the closest available KDC to obtain a Kerberos ticket. The ticket usually remains active for about 8 or 10 hours. The Key Distribution Center (KDC) is a service which runs as a component of Active Directory. In fact, each domain controller in a Windows Server 2003 domain operates as a Key Distribution Center (KDC). It is the Key Distribution Center (KDC) which manages the database of security account information for each security principal within a domain. Security principals that form the foundation of the Active Directory security architecture are user accounts, security groups, and computer accounts. Administrators of domains assign permissions to security principals to access network resources, and to perform certain actions on these resources. The KDC holds the cryptographic key which is only known by the particular security principal, and the KDC. This cryptographic key, also called a long term key, is formed from the logon password of the user, and is used when the KDC and security principal interact. Because each domain controller in Windows Server 2003 domains operates as a KDC, fault tolerance is enabled for the domain. When one domain controller is unavailable, any other domain controller in the domain is able to issue tickets.

Kerberos authentication can be used by clients and servers running the following operating systems (OSs):

Windows 2000, Windows XP Professional, and Windows Server 2003 computers which are members of a Windows 2000 or Windows Server 2003 domain use the Kerberos protocol for network authentication for domain resources. This is the default configuration for these domains. When a down level client attempts to access a Kerberos secured resource, NTLM authentication is used; and not Kerberos authentication.

How the Kerberos authentication process work

The steps outlined below describe the Kerberos authentication process.

  1. The user provides his/her user name and password. The computer transmits these details to the KDC.
  2. The KDC creates a session key, and a Ticket Granting Ticket (TGT). A TGT is a ticket that enables a client to receive temporary tickets from the ticket granting service for each authentication, and it includes the following:
    • A copy of the session key
    • The name of the user
    • An expiration time
  3. The TGT is encrypted by the KDC through its master key.
  4. The client computer then receives this information from the KDC. At this point the client computer holds the session key and TGT, and is authenticated to the domain. The session key and TGT is stored in volatile memory because it offers better security than storing the information on the hard disk.
  5. A Kerberos client passes its TGT and a timestamp encrypted with its session key, to the KDC when it needs to access resources hosted on a server which is a member of the same domain. The KDC utilizes its master key to decrypt the TGT, and it utilizes the session key to decrypt the timestamp. Since the user is the only individual that can use the session key, the KDC is able to verify that the request to access resources originated from the particular user.
  6. At this point, the KDC generates a ticket for the client and a ticket for the server hosting the resources which the client wants to access. Each ticket has a new key which the server and client will share between each other, and contains the following information:
    • The name of the user
    • The recipient of the user request
    • A timestamp which indicates the time that the ticket was created.
    • The expiration time of the ticket
  7. The server master key is used by the KDC to encrypt the ticket of the server. The ticket of the server is stored within the ticket of the client. The session key which the KDC shares with the particular user is then used to encrypt the entire set of information. This is then transmitted to the user.
  8. The user decrypts the ticket it receives using the session key. The user encrypts the timestamp through the new key, and then transmits this information and the ticket of the server hosting resources which it wants to access. Next, the server uses the server master key to decrypt the server ticket. The new key is then used to decrypt the timestamp.

NT LAN Manager (NTLM) Authentication Protocol

The NT LAN Manager (NTLM) authentication protocol is the main authentication type used to enable network authentication for versions of Windows earlier than Windows 2000, such as for a Windows NT 4. The authentication protocol is essentially used for authentication between machines running Windows NT and Windows Server 2003 machines.

The NTLM authentication type is typically used in the scenarios listed below:

Windows Server 2003 supports the following forms of challenge- response authentication methods:

NTLM authentication works by encrypting the logon information of the user. This is done by applying a hash to the password of the user. A hash is a mathematical function. The security account database contains the value of the hash which is generated when the password is encrypted by NTLM. The password of the user is not transmitted over the network. What happens is that the client applies the hash to the password of the user, prior to it actually sending the information to the domain controller. The value of the hash is also encrypted.

How the NTLM authentication process works

  1. The client and server negotiate the authentication protocol to use.
  2. The client transmits the name of the user and the name of the domain to the domain controller.
  3. At this point, the domain controller creates a nonce. This is a 16-byte random character string.
  4. The nonce is encrypted by the client using the hash of the user password. The client forwards this to the domain controller.
  5. The domain controller then obtains the hash of the user password from the security account database to encrypt the nonce.
  6. This is then compared to the hash value which the client forwarded.
  7. Authentication occurs when the two values are identical.

Secure Sockets Layer/Transport Layer Security (SSL/TLS)

Secure Socket Layer (SSL) is a Windows Server 2003 security protocols which utilizes a public-key technology to provide a secure channel for applications communicating over a non-secure network such as the Internet. SSL is typically used by Web browsers and Web servers for secure communication channels. The Secure Socket Layer (SSL) protocol functions at the OSI model's network layer to provide encryption for the following protocols:

The SSL protocol provides the following functions:

Before a client and server can partake in secure Internet communication, the client and server have to perform a security handshake. The security handshake is a process that authenticates each entity involved in communication, and also establishes the level of security to use for communication.

The following events occur when a client and server partake in a security handshake:

  1. The client sends a request for a secure channel connection to the server.
  2. The server sends its public-key certificate to the client. The server can also request the certificate of the client for mutual authentication.
  3. The client then verifies the authenticity of the certificate of the server. At this stage, the client sends its certificate to the server if the server requested it in Step 2. The server proceeds to verify the client's certificate.
  4. The client produces a session key, and encrypts the session key with the public key of server.
  5. The server and client now have a secure channel for communication, because information passed between the two are encrypted and decrypted with the session key.

The Transport Layer Security (TLS) protocol, currently being development by the Internet Engineering Task Force (IETF), will replace the SSL protocol as the new protocol for securing Internet traffic.

Digest Authentication

Digest authentication is typically used for authenticating Web applications running Internet Information Services (IIS). Digest authentication utilizes the Digest Access Protocol in the authentication process. The Digest Access Protocol employs a challenge-response mechanism for applications using HTTP or Simple Authentication Security Layer (SASL) communications. Once a client is authenticated, the session key of the client is located on the Web server. When digest authentication transmits user information over the network, it does so using an encrypted hash. This prevents unauthorized users who may be attempting to access network resources, from intercepting the credentials of the user. Any ensuing authentication requests submitted by the same client are dealt with by using this session key. Because of this feature of digest authentication, the client does not need to authenticate with a domain controller each time that it submits an authentication request.

A few conditions have to be met prior to using digest authentication on IIS servers. These are listed below.

Web sites that utilize passport authentication make use of a central Passport server to authenticate users. Passport authentication works with Microsoft Internet Explorer, Netscape Navigator, and even with some UNIX systems and browsers. This is due to the fact that passport authentication is not proprietary. Passport encryption utilizes the following Web technologies:

A few features of passport authentication are listed below:

Smart Cards

Windows Server 2003 supports smart card authentication. Smart cards can be used to secure the following items:

A smart card is a device similar in size to that of a credit card. Smart cards are dependent on the Windows Server 2003 public key infrastructure (PKI). A smart card is used in conjunction with an identification number (PIN) to enable authentication and single sign-on in the enterprise. The smart card actually stores the private key of the user, public key certificate and logon information. The user attaches the smart card into the smart card reader that is attached to the computer. The user next inserts the PIN when prompted for the information.

Smart cards are typically used for interactive user logons to provide further security and encryption for logon credentials. Smart card readers can be installed on servers, so that you can require administrators to use smart card authentication when using an administrator account. You can also require remote access logons to use smart card authentication. This assists in preventing unauthorized users from using VPN or dial-up connections to launch an attack on your network. Through smart cards, you can encrypt confidential files and other confidential user information as well.

The cost associated with implementing and administering a smart card authentication strategy is determined by the following elements:

In addition to the above, with smart card authentication, each computer has to have a smart card reader, and one computer has to be configured as the smart card enrollment station. It s recommend to use only plug and play Personal Computer/Smart Card (PC/SC) compliant smart card readers. The user responsible for the smart card enrollment station has to be issued with an Enrollment Agent certificate. The owner of this certificate can issue smart cards for users.

Internet Authentication Service (IAS)

The Internet Authentication Service (IAS) functions as a remote Authentication Dial-In User Service (RADIUS) server, and can be used to manage the login process of users by providing the following key features:

Internet Authentication Service (IAS) is supported in the following editions of Windows Server 2003:

The default authentication protocols supported by IAS are:

Once IAS has authenticated the user, it can use a few authorization methods to verify that the authenticated user is permitted to access the network resource(s) he/she is requesting to access. This includes the following:

Wireless clients can use certificates, smart cards, and a user name or password to authenticate to an IAS server. Before a wireless client can connect to your corporate network, you need to define the following:

The events which occur when wireless clients requests network access are outlined below.

  1. The Wireless AP requests authentication information from the wireless client.
  2. The wireless client then passes this information to the Wireless AP. The Wireless AP forwards the information to IAS.
  3. When the information IAS receives is valid, it passes an encrypted authentication key to the Wireless AP.
  4. The Wireless AP next utilizes the encrypted authentication key to create a session with the wireless client.

How to install the Internet Authorization Service (IAS) on a domain controller

  1. Click Start, Programs, Control Panel, and then double-click Add/Remove Programs.
  2. Select Add/Remove Windows Components.
  3. This launches the Windows Components Wizard.
  4. Click Networking Services. Click Details.
  5. When the Networking Services dialog box opens, enable the Internet Authentication Service checkbox.
  6. Click OK.
  7. To start the actual installation of IAS, click Next.
  8. When prompted, place the Windows Server 2003 CD into the CD-ROM drive.
  9. Once the installation of IAS is complete, click Finish, and then click Close.
  10. To register the IAS server with Active Directory so that it can obtain user information from Active Directory domains, click Start, Programs, Administrative Tools, and then Internet Authentication Service.
  11. Right-click Internet Authentication Service, and then select Register Server in Active Directory on the shortcut menu.
  12. Click OK.

How to create a remote access policy

  1. Click Start, Programs, Administrative Tools, and then Internet Authentication Service.
  2. Right-click Remote Access Policies and then click New Remote Access Policy on the shortcut menu.
  3. This action starts the New Remote Access Policy Wizard. Click Next on the welcome screen of the wizard.
  4. Click the Use the wizard to set up a typical policy for a common scenario option, and enter a name for the new remote access policy in the Policy name box. Click Next.
  5. When the Access Method screen appears, choose the Dialup access method. The other access method options include:
  6. Click Next.
  7. Select Group and then choose the group to which you want to grant remote access permission. Click Next.
  8. When the Authentication Methods screen appears, choose the one of the following authentication methods for the new remote access policy.
    • Extensible Authentication Protocol (EAP)
    • Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2)
    • Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
  9. Click Next
  10. Specify the encryption level which users should utilize to connect to the IAS server. Click Next.
  11. Click Finish.

If you want to set any further remote access conditions, right-click the particular remote access policy, and click Properties from the shortcut menu.



Top 5 Free Networking Tools

Bookmark Authentication Types

Latest Blog Posts


English English GermanGerman SpanishSpanish FrenchFrench ItalianItalian PortuguesePortuguese RussianRussian DutchDutch
GreekGreek HindiHindi JapaneseJapanese KoreanKorean ChineseChinese Chinese (Simplified)Chinese (Simplified) ArabicArabic

Copyright 2009 Tech-FAQ. All rights reserved. Privacy Policy.