Server Authentication
Authentication is the act of confirming the identity of a user or system and is an essential part used in authorization when the user or system tries to access a server or network resource. Because authentication is such a key component in security, you need to choose the appropriate authentication method. Two types of authentication that Windows supports are NT LAN Manager (NTLM) and Kerberos.
Although Kerberos is the default authentication protocol for today's domain computers, NTLM is the default authentication protocol for Windows NT, standalone computers that are not part of a domain, and situations in which you authenticate to a server using an IP address. NTLM also acts as a fallback authentication protocol if Kerberos authentication cannot be completed, such as when it is blocked by a firewall.
Understanding NTLM Authentication
NT LAN Manager (NTLM) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. NTLM is an integrated single sign-on mechanism, which is probably best recognized as part of Integrated Windows Authentication for HTTP authentication. It provides maximum compatibility with different versions of Windows and compared to Kerberos, it is the easiest to implement.
NTLM uses a challenge-response mechanism for authentication in which clients are able to prove their identities without sending a password to the server. After a random 8-byte challenge message is sent to the client from the server, the client uses the user's password as a key to generate a response back to the server using an MD4/MD5 hashing algorithm (one-way mathematical calculation) and DES encryption (a commonly used encryption algorithm that encrypted and decrypted data with the same key).
Managing Kerberos
Kerberos is a computer network authentication protocol, which allows hosts to prove their identity over a non-secure network in a secure manner. It can also provide mutual authentication so that both the user and server verify each other's identity. For security reasons, Kerberos protocol messages are protected against eavesdropping and replay attacks.
The Kerberos protocol is a secure protocol that supports ticketing authentication. With Kerberos, security and authentication are based on secret key technology, and every host on the network has its own secret key. The Key Distribution Center maintains a database of these secret keys. Although Kerberos is more secure than NTLM, it is more complicated than NTLM, which requires additional configuration (such as requiring a service principal name (SPN) for the domain account).
When a user logs in to a network resource using Kerberos, the client transmits the username to the authentication server, along with the identity of the service the user wants to connect to (for example, a file server or a SharePoint server). The authentication server constructs a ticket, which contains a randomly generated session key, which is encrypted with the file server's secret key. The ticket is then sent to the client as part of its credentials, which includes the session key encrypted with the client's key/password. If the user types the right password, the client can decrypt the session key, present the ticket to the file or SharePoint server, and give the user the shared secret session key to communicate between them. Tickets are time stamped and typically expire after only a few hours.
For all of this to work and to ensure security, the domain controllers and clients must have the same time. Windows operating systems include the Time Service tool (W32Time service). Kerberos authentication will work if the time interval between the relevant computers is within the maximum enabled time parameters. The default is five minutes. You can also turn off the Time Service tool and install a third-party time service. Of course, if you have problems authenticating, you should make sure that the time is correct for the domain controllers and the client that is experiencing the problem.
Kerberos offers several benefits. When the client connects to a server or service, Kerberos uses the current client ticket proving that the client is authenticated. As a result, the service does not have to perform authentication to a domain controller. In addition, Kerberos can perform a double-hop authentication, which forwards Kerberos tickets from one service to a supporting service. Both of these Kerberos benefits improve authentication performance.
To secure the double-hop authentication, you can configure Kerberos constrained delegation. Constrained delegation restricts which services are allowed to delegate user credentials by specifying, for each application pool or service, the services to which a Kerberos ticket can be forwarded.
Kerberos settings are configured with Group Policies, specifically \Computer Configuration\ Policies\Windows\Settings\Security Settings\Account Policies\Kerberos Policy. It contains the following GPO entries:
Enforce user logon restrictions:
Enforces the Key Distribution Center (KDC) to check the validity of a user account every time a ticket request is submitted. If a user does not have the right to log on locally or if his or her account has been disabled, he or she will not get a ticket. By default, the setting is on.Maximum lifetime for service ticket:
Defines the maximum lifetime of a service ticket (Kerberos ticket). The default lifetime is 10 hours.Maximum lifetime for user ticket:
Defines the maximum lifetime ticket for a Kerberos TGT ticket (user ticket). The default lifetime is 10 hours.Maximum lifetime for user ticket renewal:
Defines how long a service or user ticket can be renewed. By default, it can be renewed up to 7 days.Maximum tolerance for computer clock synchronization:
Defines the maximum time skew that can be tolerated between a ticket's timestamp and the current time at the KDC. Kerberos uses a timestamp to protect against replay attacks. The default setting is 5 minutes.
Managing Service Principal Names
A service or application that is secured by Kerberos must have an identity (a user account or computer account) within the realm (in this case, the domain) that the system exists on. Although Active Directory can identify an account using a simple username, the Kerberos standard includes information such as the service class, host name, and port that the account can use.
A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. The client locates the service based on the SPN, which consists of three components:
The service class, such as HTTP (which includes both the HTTP and HTTPS protocols) or SQLService.
The host name
The port (if port 80 is not being used)
To establish an SPN for https://portal.contoso.com on port 443, you use HTTP/portal. contoso.com:443. Kerberos authentication service then uses the SPN to authenticate a service. When a domain controller's KDC receives the service ticket request from a client, it looks up the requested SPN. The KDC then creates a session key for the service and encrypts the session key with the password of the account with which the SPN is associated. The KDC issues a service ticket, containing the session key, to the client. The client presents the service ticket to the service. The service, which knows its own password, decrypts the session key and authentication is complete.
If a client submits a service ticket request for an SPN that does not exist in the identity store, no service ticket can be established and the client throws an access denied error. For this reason, each component of a SharePoint infrastructure that uses Kerberos authentication requires at least one SPN. For example, the intranet web application app pool account must have an SPN of HTTP/intranet.contoso.com.
The SPN is associated with the application pool, not the server. In addition, for each web application, you should assign two SPNs, one with the fully qualified domain name for the service and one with the NetBIOS name of the service.
You can use ADSI Edit to add SPNs to an account. To configure an SPN for a service or application pool account, you must have domain administrative permissions or a delegation to modify the ServicePrincipalName property. In addition, you must run ADSI Edit from a domain controller or load the Windows Server 2012 Remote Server Administration Tools feature.
CONFIGURE AN SPN FOR A SERVICE OR APPLICATION POOL ACCOUNT GET READY
To configure an SPN for a Service or Application Pool Account, perform the following steps:
Open Server Manager.
Click Tools → ADSI Edit. The ADSI Edit console opens.
Right-click ADSI Edit in the console tree, and then click Connect To.
When the Connection Settings dialog appears, click OK.
Expand Default Naming Context in the console tree, expand the domain, and then expand the nodes representing the OUs in which the account exists. Click the OU in which the account exists.
In the Details pane, right-click the service account and then click Properties.
In the Attributes list, double-click servicePrincipalName to display the Multi-valued String Editor dialog box.
In the Value to add fi eld, type the SPN and then click Add.
Click OK twice.
Alternatively, you can use the setspn.exe to add SPNs to an account. The syntax is as follows:
setspn <domain\user> -s <SPN>
whereby:
<domain\user>identifies the security principal to which you want to add an SPN.<SPN>is the service principal name that you want to add.
For example, to add SPNs for the intranet web application to the app pool account used in SharePoint, type the following commands:
setspn CONTOSO\SP_WebApps -s HTTP/portal.contoso.com setspn CONTOSO\SP_WebApps -s HTTP/portal
You must perform separate commands for each SPN.
Configuring Kerberos Delegation
Kerberos delegation allows a Kerberos ticket to be created for another service on the originating user's behalf. This can be done with full delegation or with constrained delegation. Constrained delegation is when you specify that the Kerberos delegation can be executed only against a limited set of services.
To configure Kerberos delegation, you simply open Active Directory Users and Computers, go to the account that has an SPN, open the account's properties, and click Delegation.
To allow full delegation, select the Trust this user for delegation to any service (Kerberos only). To allow for constrained delegation, select the Trust this user for delegation to specified services only. You can then select to use only for Kerberos, or you can specify Use any authentication protocol, and then click the Add button, to specify which services to be delegated for a user or computer and specify the user or computer.