Microsoft Dynamic CRM 4.0 : Authentication (part 2)

11/26/2011 5:33:42 PM

Kerberos Authentication

In the Windows environment, authentication delegation is possible only with the Kerberos protocol. Therefore, all systems involved in delegation scenarios must use the Kerberos protocol. There are two main delegation scenarios:

Basic Kerberos delegation
Kerberos authentication using constrained delegation

Basic Kerberos Delegation

As illustrated in Figure 4 , when using the basic Kerberos authentication, the user authenticates to the front-end server; the server requests data from the back-end server using the user’s account.

Figure 4. Basic Kerberos delegation.

Delegation enables the user’s credentials to be passed from one server to another and preserves the user identity. This will allow you to have multiple front-end servers. This enables you to scale the middle tier for growth.

Pro
- Security controlled at the data layer, so there is no way security can be compromised.
Con
- Big security management overhead because all security is managed on the back-end systems.
- The middle tier is allowed to access any back-end data source based on the user credentials.

Note

Kerberos authentication passes a Kerberos token provided by the Kerberos Ticket Granting service only after the initial authentication. At no point are the user’s credentials passed within the server farms.

Kerberos Authentication Using Constrained Delegation

This can allow you to enforce a limit that applies to which network resources an account trusted for delegation can access. This feature is supported in Windows 2003 domain functional level and up. Figure 5 shows Kerberos authentication using constrained delegation.

Figure 5. Kerberos authentication constrained to a service.

To limit the resources that services can access on behalf of a user, you can configure constrained delegation by listing services to which account can present delegated credentials. This list is in the form of SPNs (service principle names). Impersonating to any nontrusted back end will fail authentication.

This is the most common deployment of Kerberos authentication.

Setting Up Kerberos

To use Kerberos completely, you must configure a number of things, including the following:

Client settings
Front-end tier, typically an IIS server
Back end
Active Directory

Figure 6 shows the Kerberos flow.

Figure 6. Kerberos flow.

Client Configuration

Before setting up or debugging Kerberos, client settings need to be verified.

Note

To ensure consistency with the client settings, it is recommended to use Group Policy (GPO) to enforce the settings on client machines.

The following steps ensure that integrated authentication is enabled on the client:

In Internet Explorer, click Tools, Internet Options, Advanced, and scroll to Security.

Figure 7. Enable integrated Windows authentication.
Ensure Automatic Logon is enabled in the appropriate zone on the client. (In Internet Explorer, click Tools, Internet Options, Security.)

Figure 8. Enable the Automatic Logon Only in the Intranet Zone option.

Note

Client needs to be a member of a trusted domain.
Ensure the URL is part of the client’s local intranet sites.
The domain user must have the Account Is Sensitive and Cannot Be Delegated option unselected in Active Directory.