Authentication, a most crucial aspect of deployment,
is often overlooked, but it is a necessary overhead task that requires
an advanced understanding of your network configuration. This is one of
the most important aspects of a deployment and should be carefully
considered. Authentication awareness allows architects to design with
the following considerations in mind:
User authentication passed to the back-end system. Users have access to all back-end systems.
Users
authenticate only with the front-end web servers. Then, the front-end
servers use service accounts to authenticate against back-end systems.
Authentication decisions allow a variety of options, as shown in Table 1.
Table 1. Authentication Types
| Authentication Type | Pro | Con |
|---|
| NTLM (Windows NT LAN Manager) | Simple CRM deployment. | Cannot access reports based on user credentials
Cannot connect to a SharePoint infrastructure as the user |
| Hybrid authentication | None really. This is a common deployment we have seen at client locations. | Usually considered a “complex deployment”
Cannot access reports based on user credentials
Cannot connect to a SharePoint infrastructure as the user
Adds a layer of network overhead when the servers process Kerberos authentication, and the web servers accept only NTLM |
| Basic Kerberos authentication | Allows user credentials to access reports (allows data-level security).
Allows user credentials to access the SharePoint document library. | Allows the server to delegate to any back-end system |
| Constrained Kerberos delegation | Allows user credentials to access reports (allows data-level security).
Allows user credentials to access the SharePoint document library.
Data secured at all levels of the application tiers (for administrators for higher security). | Some complexity in deployment |
There
are many different authentication scenarios in Windows operating
systems. The two authentications used are Windows NT LAN Manager (NTLM)
and Kerberos. Kerberos authentication features delegation, which enables
impersonation of user identity across multiple servers. The delegation
feature was introduced in Windows Server 2003. Delegation provides a
different method for authentication than the challenge-response method
provided by NTLM. The following sections examine the differences between
NTLM and Kerberos authentications. We also examine the three different
delegation scenarios involving Kerberos authentication.
What Is Delegation?
Kerberos
provides the fundamental security services required for a distributed
environment: authentication, data integrity, and data privacy. But
there’s more to this technology.
For example,
the user has already authenticated herself to Server A. Server A can now
impersonate the user and attempt to access something on its local
system, such as a file. In this case, the access checking is built in to
the local Windows installation and will grant or deny the access based
on the file’s ACL (access control list).
In a distributed
environment, however, if user authenticates to Server A, and Server A
requires information from Server B on behalf of the user, we need to
delegate the security. Even though Server A is requesting access to
Server B directly, the access requested will be on behalf of the
original user. For this to work correctly, the user needs some way to
pass its identity to Server A, allowing Server A to make further remote
requests on its behalf. Kerberos supports this concept through
delegation.
NTLM Authentication
NTLM (NT LAN Manager) is a popular authentication mechanism and is still widely used. As illustrated in Figure 1,
in the NTLM protocol, the client sends the request with the username to
the server. The server generates and responds with a challenge to the
client. The client encrypts that challenge using the user’s password and
responds to the server. The authentication option varies based on
whether the account is a local or a domain user account:
Local user account: The server will look into its local Security Accounts Manager (SAM) and authenticate the end user.
Domain user account:
The server forwards the challenge, along with the client’s response, to
the domain controller. The domain controller validates the response and
sends it directly to the server.
Authentication to Back-End Servers with NTLM
Typical
deployment requires a service account on the front-end server (servers
that interact with the end users) to authenticate against a back-end
server (in a multi-tiered environment, this is usually the one holding
the data or responsible for certain application roles), as shown in Figure 2.
Note
When
the service account is not specified, the request will be made as a
null userAuthentication to back-end servers with NTLM. This usually
means that the user cannot access the back-end data (reports, document
library, and so on). This is the most common error people get in their
deployments.
Hybrid Authentication
Many organizations use Kerberos authentication for the front-end server and use NTLM authentication for the backend server.
Kerberos authentication
can enhance security because it provides additional features such as
auditing and accountability. With the additional features, you can
potentially add extra load (perhaps authenticating thousands of unique
users). Alternatively, NTLM does not need additional authentication
after the first request.
Having this
hybrid authentication is not recommended. This will increase the load on
the front-end server and will not provide the impersonation to the
back-end server. This is similar to the previous scenario, with
additional load to the front-end servers.
Figure 3 illustrates a typical hybrid authentication deployment.
