Planning and Implementing an Authentication Solution

An Overview on Authentication

Authentication is the process of identifying authorized valid users from unauthorized users. It is therefore the initial step in defining and implementing a network security strategy because it deals with restricting access to the network. A solid authentication solution prevents unauthorized users such as hackers, and Trojan horses from accessing network resources. Implementing the ideal authentication strategy for your network could be tricky because while too much authentication would keep unauthorized network access under control, it could also prevent authorized network users from legitimately accessing network resources.

Authentication also opens the door to other security strategies and implementations such as authorization and auditing. Authentication is typically performed by the user attempting to access the system, providing a user name and password. A user is authenticated once the authentication strategy implemented within your organization verifies that the user is indeed who he/she claims to be, based on the user name and password combination provided. At this point, the system does not know whether the user is authorized to access the network resource(s) he/she is attempting to access. Authorization is the process that verifies whether a user is permitted to access network resources by checking the ACL of a resource, and by differentiating between standard users, groups, administrators, and guests. From this short discussion, you can see how important the security concepts of authentication and authorization are, and how authentication makes it possible for authorization to be implemented and operational in your network. Auditing on the other hand, deals with monitoring and tracking those actions which were performed on a network resource(s). Auditing is also referred to as Accounting. Planning and Implementing an Authentication Solution

It is evident that a strong security strategy has to focus on authentication, authorization and accounting/auditing. The location of the users that need to access the network, and the client and server operating system (OS) employed within your environment greatly influences which authentication solution you need to implement. Users can be connected through a simple dial-up connection, or through a high-speed network connection.

Implementing a strong authentication solution would most certainly require the combined usage of protocols, mechanisms and strategies. All of these facets should inter-operate to ensure that a user attempting to access the system is in fact the user that he/she is portraying to be.

The following protocols and mechanisms can be used to perform authentication:

Kerberos authentication protocol
NT LAN Manager (NTLM) authentication protocol
Secure Sockets Layer/Transport Security Layer (SSL/TLS)
Digest authentication
Smart cards
Virtual Private Networking (VPN) and Remote Access Services (RAS)

Password authentication is on the whole the more general authentication method implemented. Password authentication is the process whereby a user provides a user name and password to the computer and the computer checks that the credentials provided by the user matches with those credentials stored in the system for the particular user name. When a match occurs, the user is permitted to access the system. One of the factors that affect the success of password authentication is the manner in which the password of the user is transmitted over the network. Authenticating passwords should not be transmitted in a clear text format over the network. Kerberos and NT LAN Manager (NTLM), the later authentication methods, do not transmit the true user password over the network connection. While you can control whether or not passwords are transmitted in clear text format over the network, you have far less control over whether or not users are actually using strong passwords, and whether or not they are revealing their user credentials to other parties. Strategies such as implementing password policies can assist in ensuring that users do indeed use robust intricate passwords.

A few methods of securing user accounts are listed below:

You should control membership to the administrative security groups listed below. Standard network users that do not need to perform any administrative duties should not be included as members of any administrative security groups:
- Domain Admins security group
- Enterprise Admins security group
- Schema Admins security group
You can limit administrator accounts or members of the Domain Admins group to log on only to specific computers within your network
You can also restrict administrators to only using an administrative account when needing to perform administrative functions, and to use a standard account for normal functions such as reading e-mail.
Through the use of smart cards, you can implement an additional level of authentication for administrators, by forcing them to use smart cards to authenticate if they are logging on to the system via an administrative account.

Windows Server 2003 includes support for the Single Sign-on authentication feature. Single Sign-on authentication enables domain users to authenticate only once with any computer within a domain. Because users basically only need to be authenticated once, Administrator does not need to manage multiple user accounts over domains and severs. For Single Sign-on authentication to work, the following has to occur:

The user has to perform an interactive logon: This is the process of a user providing their network credentials to the operating system. The logon name and password can be one of the components listed below:
- A domain user account located on a domain controller within a domain. Domain account information is store within Active Directory, and once authenticated, the user is able to access the domain, and the local workstation.
- A user account stored in the Security Account Manager (SAM) database of the local computer. User accounts in the SAM database are only used to access the local computer. A member server or workstation server holds the SAM account.
Network authentication is the process whereby users are authenticated to access resources that reside in a different location in the network after the user is able to access a physical workstation. Kerberos, NT LAN Manager (NTLM) and Secure Sockets Layer/Transport Security Layer (SSL/TLS) enable network authentication.

Understanding how Password Polices affects Authentication

Microsoft defines a strategy called an extensive defense model for implementing a security solution. An extensive defense model is the implementation of numerous security mechanisms and practices; so that when one security mechanism is compromised, other security mechanisms are already set up to assist in blocking any further unauthorized access attempts.

A few main elements in the extensive defense model are summarized below:

You can use the system key utility feature on your mission critical network machines. The system key utility feature encrypts passwords that are stored in the local SAM database.
Educate your users on the importance of security within your network environment. For instance, educate users on factors such as locking unattended workstations, and keeping their passwords safe. Users should also be educated on not saving their passwords on a local workstation.
The password should be immediately changed on any user account that has been compromised.
You should implement a password policy and a password lockout policy that suites the security needs of the organization.
When you have applications within your network tat use service accounts to access the operating system, ensure that each service account has a unique password. Using the same password for a set of service accounts could result in many applications being vulnerable when the password is compromised.

Passwords are probably the component that presents the most vulnerability in an authentication implementation. Passwords that are weak can easily be identified, even when password encryption is used. Password encryption is the process whereby the password of the user is encrypted. What this means is that the password is not transmitted over the network in clear text. When users actually use strong complicated passwords, an unauthorized individual attempting to access the system should not easily be able to interpret or decipher the password. Regularly having users change their passwords also ensures that even when a strong password is deciphered by an unauthorized user, the password would probably be invalid.

What is a weak password? A weak password is a password that contains one of, or a segment of the following information:

The name of the user
The name of the organization
The login ID of the user
The word ‘password'
Blank passwords

What is a strong password? A strong password typically contains none of the above mentioned segments of information. Strong passwords have the following characteristics:

The password is intricate so that it cannot be deciphered by unauthorized network users, but can also be remembered by the user. The user should not need to document the password because he/she cannot remember it.
The password should be at least seven characters in length.
The password should include characters from three of the following groups:
- Uppercase characters: Letters A through to Z
- Lowercase characters: Letters a through to z
- Non-alphabetic characters such as: $, #, %
- Numeric digits such as 0 through to 9

Implementing Password Polices

You can implement a strong password policy by using the following security policy settings located in the Password Policy node in Account Policies:

Maximum password age: This security policy setting determines the duration after which a user is forced to change a password.
Enforce password history: This security policy setting prevents users from re-specifying or reusing previously used passwords.
Minimum password age: This security policy setting determines the length of time that a user has to keep a password before he/she can modify the password.
Minimum password length: This security policy setting stipulates the minimum length that a password can have.

Account lockout policies should be implemented if your environment is particularly vulnerable to threats arising from passwords which are being guessed. Implementing an account lockout policy basically ensures that the account of a user is locked after an individual has unsuccessfully tried for several times to provide the correct password. The important factor to remember when defining an account lockout policy is that you should implement a policy that permits some degree of user error, but that also prevents unauthorized usage of your user accounts.

The following password and account lockout settings are located in the Account Lockout Policy area in Account Policies:

Account lockout threshold: This setting controls the number of times after which an incorrect password attempt results in the account being locked out of the system.
Account lockout duration: This setting controls the duration that an account which is locked, remains locked. A setting of 0 means that an administrator has to manually unlock the locked account.
Reset account lockout counter after: This setting determines the time duration that must pass subsequent to an invalid logon attempt occurring prior to the reset account lockout counter being reset.

How to implement a domain password policy

Open the Active Directory Users and Computers console under the Administrative Tools Menu.
In the console tree, locate and right-click the domain for which you want to implement a password policy, and then select Properties from the shortcut menu.
When the Properties dialog box for the domain opens, select the Group Policy tab. From this tab, you can create a new password policy for the domain, or you can change the default domain policy. To create a new policy, click New; or alternatively click Edit to change the default policy.
Click Edit to change the default policy.
Click Computer Configuration, expand Windows Settings, Security Settings, Account Policies, and then expand Password Policy.
Right-click the password policy that you want to implement and then select Properties from the shortcut menu. You can configure the following password policies from here:
- Enforce password history, Maximum password age, Minimum password age, Minimum password length, Password must meet complexity requirements, Store passwords using reversible encryption.

How to implement an account lockout policy

Open the Active Directory Users and Computers console under the Administrative Tools Menu.
In the console tree, locate and right-click the domain that you want to work with, and then select Properties from the shortcut menu.
Select Default Domain Policy, and then click Edit.
Click Computer Configuration, expand Windows Settings, Security Settings, Account Policies, and then expand Account Lockout Policy.
Right-click the account lockout policy that you want to implement and then select Properties from the shortcut menu. You can configure the following password policies from here:
- Account lockout duration, Account lockout threshold, Reset account lockout counter after.

How to reset a local user account

Access the workstation using a Domain Admins account, or the local Administrator account.
Click Start, All Programs, Administrative Tools and then click Computer Management.
This action opens the Computer Management console.
In the left console tree, click Computer Management, click System Tools, click Local Users and Groups, and then click Users.
Right-click the user account that you want to reset the password of, and select Set Password from the shortcut menu.
When a message dialog appears, warning that the user could possibly lose data as a result of the password reset process, click the Proceed button.
Set the new password for the user.
Click OK.
The system next informs you that the password of the local user account was successfully reset. Click OK.
In the Computer Management console, right-click the user account that you just reset the password for, and then select Properties from the shortcut menu.
Enable the User Must Change Password at Next Logon option
Click OK.

How to create a password reset disk

When a user forgot his/her password, an Administrator had to manually reset the password of the particular user, in previous versions of Windows such as Windows 2000. With the introduction of Windows XP, and Windows Server 2003, the feature exists whereby a user can create a password reset disk for his/her local user account. Creating password reset disks prevents users from losing any encrypted files or Internet passwords that were saved on his/her local computer. This sort of data loss typically occurs when passwords are manually reset by administrators.

The following sequence of events occurs when a password reset disk is created:

The system creates a public key and private key pair.
The public key encrypts the password of the local account of the user.
The private key is stored within the password reset disk.
The private key is accessed when a user forgets his/her password. This key decrypts the existing password of the user.
The user has to immediately change any local user account password which was obtained from a password reset disk.

Use the steps below to create a password reset disk,

Hold down the Ctrl+Alt+Del key combination, and click the Change Password option.
Enter the logon information for the account that you want to create a password reset disk for in the User Name box.
Local Computer Name should be set in the Log On box.
Click the Backup button.
This action launches the Forgotten Password wizard.
On the initial Welcome screen of the Forgotten Password wizard, click Next.
When prompted, insert a blank diskette into the A: drive.
Click Next to create the actual password reset disk.

How to create a system key

The System Key utility feature encrypts password information stored in the SAM database. To create a system key, use the steps summarized below.

After accessing a Windows Server 2003 server desktop, click Start, Run, enter syskey in the Run dialog box, and then click OK.
Click the Encryption Enabled option, and click the Update button.
Select one of the following options:
- Password Startup option: Although this option encrypts password information on the local computer, you have to specify a password that protects the actual system key. You have to then provide this particular password when you reboot the computer.
- System Generated Password option: After selecting this option, you have to select one of the following options:
  - Store Startup Key on Floppy Disk: This option stores the system key on a diskette. This diskette has to be inserted when the system starts up.
  - Store Startup Key Locally: This option stores the key used for encrypting password information on the local computer. Store Startup Key Locally is the option that offers the least security.
Click OK.

Windows Server 2003 Authentication Protocols

Windows Server 2003 supports the following authentication protocols:

NT LAN Manager (NTLM) authentication protocol: The NTLM authentication protocol employs the challenge-response authentication strategy (the user is challenged to supply unique confidential information) to authenticate the following types of users and computers:
- Users/computers running the Windows Me OS, and prior OSs.
- Computers running Windows 2000 or later which are not members of a domain.

The following types of challenge- response authentication methods are supported in Windows Server 2003:

- LAN Manager (LM): This is the least secure challenge-response authentication method, and was initially developed for Workgroups, Windows 95, Windows 98, and Windows Me. With LM authentication, servers performing authentication have to store user credentials in LMHash.
- NTLMv1: With NTLMv1 authentication, the server stores user credentials in NTHash. NTLMv1 utilizes 56-bit encryption for security, and is a more secure challenge-response authentication method than the LM challenge-response authentication method. It is used to connect to servers running Windows NT with SP3 or prior.
- NTLMv2: NTLMv1 utilizes 128-bit encryption for security, and s typically used to connect to servers running Windows 2000, Windows XP and Windows NT with SP4 or above.
Kerberos authentication protocol: The Kerberos authentication protocol is the default authentication protocol used for Windows 2000, Windows XP Professional, and Windows Server 2003. Kerberos authentication offers improved security over the NTLM authentication protocol, including the following:
- Delegated authentication enables services to pose as clients when accessing network resources.
- Mutual authentication makes it possible for the server to be authenticated to the client.
- A server can authenticate a client with no need of contacting a domain controller.
- Transitive trust can be used between domains within the same forest, and for domains which are connected with a forest trust relationship.

Authentication Methods for Earlier Operating Systems (OSs)

Because authentication protocols typically progress as time passes, the authentication methods used in earlier OSs are in fact less secure than those used in later OSs. To provide backward compatibility with the earlier operating systems, Windows Server 2003 can support quite a few authentication protocols. This includes support for authentication protocols such as Kerberos, LM, and NTLMv2. It is strongly recommended to use the more secure authentication protocols such as NTLMv2 and Kerberos if you do not need to cater for compatibility with any earlier operating systems. The Network Security LAN Manager Authentication Level policy determines and stipulates which authentication protocols a computer can transmit, and receive or accept. The Network Security LAN Manager Authentication Level policy is located under Local Policies in the Security Options security policy node. As you increase the security of this particular policy, the less the compatibility which exists between your system and those earlier OSs.

The LM Authentication Levels that can be selected are listed below, and are ordered from the least secure option to the most secure option.

Send LM & NTLM responses: When enabled, domain controllers accept LM, NTLM, and NTLMv2 authentication. This ensures that clients can authenticate with servers running OSs prior to Windows NT 4.0 Service Pack 4. Clients on the other hand only use LM and NTLM authentication.
Send LM & NTLM responsesuse NTLMv2 session security if negotiated: Clients use LM and NTLM authentication, but can also use NTLMv2 authentication if the server supports the protocol. Domain controllers also accept LM, NTLM, and NTLMv2 authentication.
Send NTLM response only: When this security policy setting is enabled, clients can use NTLM authentication, and can only use NTLMv2 if the server supports the protocol. LM authentication is not used. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response only: When this security policy setting is selected, clients use NTLMv2 authentication only. Domain controllers accept LM, NTLM, and NTLMv2 authentication.
Send NTLMv2 response onlyrefuse LM: When selected, clients use NTLMv2 authentication. Domain controllers only accept NTLM and NTLMv2 authentication.
Send NTLMv2 response onlyrefuse LM & NTLM: If selected, clients use NTLMv2 authentication. Domain controllers only accept NTLMv2 authentication.

Anonymous authentication is an authentication method that actually allows a user and network client to be authenticated with the user/client furnishing no user credentials. However, if you are running Windows Server 2003, the user will not be authorized to access network resources. With the earlier Windows operating systems, this was not the case. Anonymous authentication is typically used to supply backward compatibility with systems earlier to Windows 2000, for the folowing scenarios.

Windows NT 4.0 could possibly use anonymous access to obtain information from domain controllers.
Remote Access Server (RAS) servers on Windows NT 4.0 utilizes anonymous access for ascertaining dial-in permissions
Older OSs could also use anonymous access to change passwords (Pre-Windows 2000-compatible access group) in Active Directory.

To enable anonymous authentication, activate one of the following security policy settings:

Network Access: Share That Can Be Accessed Anonymously: Use this security policy setting to define specific shares which can be accessed.
Network Access: Let Everyone Permissions Apply To Anonymous Users: When enabled, anonymous users are added to the Everyone group.

A better method of enabling anonymous access is to include the Anonymous Logon security principal in the access control list (ACL) that needs access.

How to configure domain controllers to only accept only NTLM authentication and to refuse LM authentication

After accessing the domain controller, click Start, Administrative Tools, and then click Domain Controller Security Policy.
Open Local Policies, and then click Security Options.
Double-click Network Security: LAN Manager Authentication Level
This opens the Network Security: LAN Manager Authentication Level Properties dialog box.
Enable the Define This Policy Setting checkbox.
Choose the Send NTLMv2 Response OnlyRefuse LM option from the list of available options.
Click OK
You can force the policy to be immediately implemented for the domain controller by clicking Start, clicking Run, entering gpupdate.exe in the Run dialog box, and the clicking OK.

What is Multifactor Authentication?

A key authentication feature of Windows Server 2003 is its support for multifactor authentication. Multifactor authentication increases authentication security because smart cards are supported, as well a number of other authentication mechanisms using non-Microsoft hardware or software. Because of the costs element associated with implementing smart cards, they are typically only used for specific user accounts such as administrator accounts. Before implementing or requiring smart cards for authentication, ensure first that your existing applications are able to operate together with smart cards. Applications that have the Certified for Windows Server 2003 marking have been tested for meeting the security standards for Windows Server 2003.

Applications that have the Certified for Windows Server 2003 marking have the following characteristics:

These applications include support for smart card logons, and should be able to operate together with smart card authentication.
An application can use Kerberos, NTLM, and the Secure Sockets Layer (SSL) protocol.
The applications use secure network connections, and do not use protocols with known vulnerabilities. The applications therefore do not use NTLM. They use strong authentication methods and account policies.

The Authentication Methods used with Active Directory Trusts in Windows Server 2003

Trust is the terminology used to describe a relationship between domains or forests in Active Directory that allows users in one domain to be authenticated by a different or remote domain. This makes it possible for users, computers, or groups from one domain to be authenticated by domain controllers located in different domains. Configuring trust relationships between domains or forests does not however enable users to access resources in domains other than the domain in which they are located. Configuring domain and forest trust relationships is however a key component for the process of permitting users to access resources in other domains.

The different types of trusts that can be configured if you are running Windows Server 2003 Active Directory are listed below. The authentication protocols used with each trust type are noted alongside each trust type.

Parent/child trust is the default trust type that exists between each domain in a forest. The Kerberos authentication protocol and the NTLM authentication protocol are used with this trust type.
Tree/root trust is the default trust type that exists between each domain tree in a forest. The Kerberos and NTLM authentication protocols are used with tree/root trust.
External trust has to be explicitly configured between domains that are not located in the same forest. The NTLM authentication protocol is used with external trust.
Realm trust has to be explicitly configured between a non-Windows domain such as a Kerberos realm, and a Windows Server 2003 domain. The Kerberos authentication protocol is used with realm trust.
Shortcut trust is typically configured to reduce logon times between domains in a forest. The Kerberos authentication protocol and NTLM authentication protocol is used with shortcut trust.
Forest trust is explicitly configured between forests raised to the Windows Server 2003 domain forest level. The Kerberos authentication protocol and NTLM authentication protocol is used with forest trust.

The actual operating system used for a domain or forest determines the authentication protocol which you can use. For instance, the earlier OSs could only use the LM authentication protocol. Because of this, the OS used actually dictates which of type of trust you can configure between domains and forests.

Kerberos authentication can only be used between Windows Server 2003 forests. Because Windows 2000 forests cannot locate the Kerberos Key Distribution Centers (KDCs) in different domains, Kerberos trust cannot be formed between Windows Server 2003 and Windows 2000 forests. You would need to configure external trust relationships between Windows Server 2003 and Windows 2000 forests. The same type of configuration is necessary to create a trust relationship between a Windows Server 2003 forest and a Windows NT 4.0 forest. With Windows Server 2003 Active Directory, you can create trusts between Windows Server 2003 domains, and domains using Unix or some other OS which includes support for MIT-compliant Kerberos.

The Active Directory Domains And Trusts console is the Active Directory management tool which you need to use to configure trusts between domains within the same forest, or to configure trusts between forests. DNS name resolution should be operational between any two forests for which you are planning to configure a trust relationship. The functional level of each forest in the trust relationship should be raised to the Windows Server 2003 forest functional level before you can create the actual trust relationship.

Implementing an Authentication Strategy for Web Users

The LM, NTLM and Kerberos authentication protocols cannot be used by a Web browser to authenticate users to a Web server. This is because Web servers use the Hypertext Transfer Protocol (HTTP) to communicate. What this means is that for a user to be authenticated to a Web server, the Web browser has to actually use an authentication protocol located in HTTP.

The following authentication methods can be implemented so that a Web browser can authenticate users to a Web server:

Basic Authentication: Even though basic authentication is the least secure authentication method to implement, it is supported by a number of Web browsers. With basic authentication, the password of the user is basically transmitted in a format which is the same as the clear text format.
Digest Authentication For Windows Domain Servers: This authentication method uses a Message Digest 5 hash to submit the password of the user.
Integrated Windows Authentication: This authentication method is supported by only a few Web browsers, of which Microsoft Internet Explorer is one. When this authentication method is enabled, Kerberos version 5 authentication and NTLM authentication is enabled within the Web request.
.NET Passport Authentication: This authentication method is usually enabled if the .NET Passport service is used for authentication.

The majority of public Web sites on the Internet permit anonymous access for a segment of the Web site. What this means is that a user does not need to provide user credentials to access certain information on the Web site. Internet Information Services (IIS) accesses the network resources on behalf of anonymous users, and uses a particular user account to access these resources. The IUSR_computername user name account is the default account used by IIS for this purpose. This account is automatically created when IIS is installed. You can however specify that IIS should use a different user account.

To specify a user account that IIS should use to access network resources on behalf of anonymous users, use the steps listed below:

Using administrative rights, log on to the computer.
Click Start, Administrative Tools, and then click Internet Information Services Manager.
Open the computer node, expand Web Sites, right-click the node that contains the Web site which you want to work with, and then click Properties from the shortcut menu.
Select the Directory Security tab.
Click Edit in the Authentication And Access Control portion of the tab.
When the Authentication Methods dialog box opens, enter the name of the user account in the User Name box, and then enter the password for the account in the Password box.
Click OK.