• RSS
  • Twitter
  • FaceBook

How New Delegation of Authentication Options Improve Security

Delegation is the act of giving power, responsibility or authority to someone (or something). When we talk about delegation in the context of administering our Windows Server 2003 computers and networks, we can be talking about either the Delegation of administrative authority (also called delegation of control); or the Delegation of authentication (allowing a service to use a user or computer account for access to resources). It is this second type of delegation that we will discuss in this article. Windows Server 2003 has provided some enhancements to this feature that will make your administrative life a little easier.
Deb Shinder photo

Understanding Delegation of authentication

When we discuss authentication, or the process of verifying identity in order to grant access, we usually think about users and computers needing to be authenticated. However, when services (programs that provide functionality to support other programs) need to access network resources to do their jobs, they also must be authenticated. If they didn’t, this would create a huge security hole that could be exploited.

Service can impersonate user or computer accounts to gain the access they need; when they are allowed to do so, they’re said to be trusted for delegation. Then that service can use other network services by impersonating a user. 

Only administrators who have the privilege Enable computer and user accounts to be trusted for delegation can set up delegation. Domain admins and Enterprise admins have this privilege. The procedure for allowing a user to be trusted for delegation depends on the functionality level of the domain. In either a Windows 2000 native or Windows Server 2003 functional level, you do this in Active Directory Users and Computers (ADUC) tool by selecting the Users container, right clicking the user account you want to trust for delegation, and clicking Properties. The difference lies in the tab that is used: in a Windows Server 2003 domain, it is the Delegation tab; in a Windows 2000 native domain, it is the Account tab. In either case, you simply check the Account is trusted for delegation checkbox.

Where’s the Delegation tab?

In the case of Windows Server 2003 functional level, you won’t see a Delegation tab if there is no Service Principal Name (SPN) registered for the account. Normally, SPNs are only registered for service accounts. Regular user accounts don’t have an SPN by default, but you can register one using the Setspn tool that is included in the Support Tools on the Windows Server 2003 installation CD.

To do this, you’ll need to first install the Support Tools if you haven’t already done so. Then open a command prompt and type setspn. This will show you the syntax and switches for the command.

You’ll need to use the –A switch to add an arbitrary SPN, and select a name for the SPN to be registered, and then type the account name, as in this example:

Setspn –A http/bobjones bob

In this example, “http/bobjones” is the SPN and bob is the user’s account name in Active Directory.

The output of this command is shown in Figure A.


FIGURE A

Trusting the Account for Delegation

advertisement

You can trust the account for delegation to any service, or to one or more specific services, as shown in Figure B. If you trust the account for delegation to a specific service, you can specify that only Kerberos authentication be used, or you can allow any authentication protocol to be used.


FIGURE B

If you choose to trust to specific services, you’ll need to add the service(s) by clicking the Add button. Then select the computer name of the computer on which the service is running, and select the service(s) to which you want to delegate from the list, as shown in Figure C.


FIGURE C

So what part of this is new in Windows Server 2003? In Windows 2000, delegation of authentication could only use the Kerberos authentication protocol. Now this restriction no longer applies. Because of a new feature called protocol transition, a client can authenticate to the server using other authentication protocols (if you have selected to allow any protocol to be used; the default is still to use Kerberos only). When you select to allow any authentication protocol, the protocol that was used for the initial client-to-server authentication is used. This can be NTLM, SSL certificate mapping or Digest authentication. 

Another feature that’s new is constrained delegation. This is what allows administrators to trust an account for delegation without allowing it to delegate to any and every service. The ability to specify which particular SPNs the account can delegate to was not present in Windows 2000. Instead, all services under the local system account on the computer were trusted for delegation. Being able to specify only specific services for delegation adds immeasurably to the security of your accounts and thus, the network as a whole. 

Also different is what goes on under the hood when you’re using Kerberos authentication. In Windows 2000, a service ticket was needed for delegation. The user’s ticket granting ticket (TGT) was embedded inside the service ticket. The TGT was used by the account that was trusted to request service tickets to other services. Now, with Windows Server 2003, no TGT is necessary. This is another feature of protocol transition.

NOTE: Protocol transition allows for more flexibility in authentication. It is used to allow clients to use a variety of authentication methods to connect to front end web servers.

Summary

Windows Server 2003 has improved and enhanced security in many ways – both those that are visible to the user and administrator and those that take place “under the hood.” Delegation of authentication has been made much more flexible by the new protocol transition feature that permits you to use protocols other than Kerberos, and by the new ability to constrain or restrict delegation so that you control the services to which an account can delegate. 

Delegation is an important part of your network’s authentication strategy, so these features are welcomed by Windows administrators.

About Deb Shinder

Deb Shinder photo DEBRA LITTLEJOHN SHINDER, MCSE, MVP (Security) is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security. She is also a tech editor, developmental editor and contributor to over 20 additional books. Her articles are regularly published on TechRepublic’s TechProGuild Web site and Windowsecurity.com, and have appeared in print magazines such as Windows IT Pro (formerly Windows & .NET) Magazine. She has authored training material, corporate whitepapers, marketing material, and product documentation for Microsoft Corporation, Hewlett-Packard, DigitalThink, GFI Software, Sunbelt Software, CNET and other technology companies. Deb lives and works in the Dallas-Ft Worth area and can be contacted at deb@shinder.net or via the website at www.shinder.net

Click here for Deb Shinder's section.

Receive all the latest articles by email!

Get all articles delivered directly to your mailbox as and when they are released on WindowSecurity.com! Choose between receiving instant updates with the Real-Time Article Update, or a monthly summary with the Monthly Article Update. Sign up to the WindowSecurity.com Monthly Newsletter, written by George Chetcuti, BSc in Computing & IS (Honors), containing news, the hottest tips, security links of the month and much more. Subscribe today and don't miss a thing!



Receive all the latest articles by email!

Receive Real-Time & Monthly WindowSecurity.com article updates in your mailbox. Enter your email below!
Click for Real-Time sample & Monthly sample

Become a WindowSecurity.com member!

Discuss your security issues with thousands of other network security experts. Click here to join!

Community Area

Log in | Register

Readers' Choice

Which is your preferred Event Log Monitoring solution?