Scenario 2: A client application authenticates
with a middle-tier application and the
middle-tier application then serves data from
one or more back-end applications. In this case,
the client application is a Web browser or Office
application, the middle-tier application is the
MOSS portal, and the back-end application
can be a point solution (i.e., Project Server) or
an integration services layer that accesses the
back-end system.
Scenario 3: A service account accesses
resources on behalf of a user. This process is
referred to as the trusted sub-system model.
The sub-system (or back-end application) trusts
the middle-tier application service account so
that the service account can retrieve data for
a user by using the service account’s identity
and hand that data to the user. This scenario
scales well, but should only be used to retrieve
data that doesn’t have to be secured by the user
account or that requires per-user auditing.
So where is delegation necessary? The first
scenario, in which a single application accesses
a file share, doesn’t involve delegation. The
user logs on to the system and there is no
service running on another computer acting
on behalf of the user to authenticate to a file
share containing the Word document. In the
second scenario, delegation is essential for supporting
a single sign-on (SSO) experience and
for authenticating to remote resources as the
logged-on user. In the third scenario, the trusted
sub-system model, delegation isn’t necessary
because, by design, the service account isn’t
impersonating users.
How to Configure Kerberos
Delegation
Configuring delegation to a user account
assigned as an application pool identity for
a SharePoint Web application is relatively
straightforward. The simplest way to enable
this delegation is to navigate to the properties
of a user account in the Active Directory Users
and Computers snap-in.
Once there, take one of two paths depending
on your domain functional level. If you’re
running a Win2K domain or your Windows
2003 domain is running in Win2K domain functional
level, click the Account tab and under
Account Options select the Account is trusted for delegation check box. If you’re running in
Windows 2003 domain functional level, select
the Delegation tab in the user properties dialog
box, which Figure 3 shows. (If the Delegation
tab isn’t present and the domain is set to a
Windows 2003 functional level, you need to go
back and set an SPN on the service account.) In
the Delegation tab, select one of the following
three options:
Do not trust this user for delegation. This
option is the default selection and doesn’t let
the user account impersonate another user to
any back-end system.
Trust this user for delegation to any service
(Kerberos only). This option lets the user
account impersonate another user to any backend
system that supports Kerberos authentication.
It’s time constrained because a Kerberos
session key’s default expiration lifetime is 10
hours. However, it’s not constrained to a specific
target. The application pool account will
attempt to access any Kerberos-enabled backend
target as an impersonated user.
Trust this user for delegation to specified
services only. This option constrains the
application pool account to a specific target
or targets. As Keith Brown describes in The
.NET Developer’s Guide to Windows Security (Addison Wesley, 2005), this option constrains
delegation not only in time, but also in space.
We specifically say “target” and not “back-end
system” because the only valid target for constrained
delegation is an SPN. The two typical
targets are either SPN-enabled computers or
user accounts. If your goal is to limit delegation
to a back-end system that uses an application
pool user account, you have two choices: You
can either register an SPN for a target user
account, as we described earlier in this article,
or you can choose one of the existing SPNs
assigned to the target back-end computer.
Typically, using an existing SPN assigned
to the computer is adequate. Some reasons
why you might want to register additional SPNs
include the following:
• Users access the back-end system by a custom
FQDN.
• You want to further constrain delegation by
designating a specific port to which the backend
service listens.
• The back-end service uses a custom service
name (SPN class field) that isn't registered in
the default set of SPNs on a target system.
• You choose to constrain delegation to specific
user accounts rather than to specific
target computers.
Figure 3 shows constrained delegation (i.e.,
the check box Trust this user for delegation
to specified services only is
selected) to a back-end system with
a custom FQDN of BackEnd01.
Server.Sys, two ports designated for
two SPNs, one service on usahsvulm268
that’s listening on port 4000,
and another service on BackEnd01
.Server.Sys that’s listening on port
45000.
When and How to Configure
Protocol Transition
When one or more users accessing
your portal Web applications can’t use
Kerberos from their client computers
or when your front-end Web servers
don’t provide Windows Integrated
Authentication, you can use the Kerberos
Protocol Transition feature. The
former case is relatively rare. However,
in the latter case, some routers or
firewalls won’t let you negotiate to Kerberos
or even NTLM authentication. In these
situations, configuring IIS to use Basic authentication
over SSL is the best you can do. After IIS
authenticates a user by using Basic authentication,
the Kerberos Protocol Transition feature
lets the front-end Web servers negotiate up to
Kerberos authentication on behalf of the user.
Continued on Page 5
SCG December 18, 2007 (Article Rating: