Trust this computer for delegation to any service (kerberos only)

To use delegated authentication, the user account, as well as the service or computer account acting on the user's behalf, must be configured to support delegated authentication.

Configuring the Delegated User Account

For the user account, you must ensure that the account option Account Is Sensitive And Cannot Be Delegated is not selected, which by default it isn't. If you want to check this option, use Active Directory Users And Computers, as shown in the following screen. Double-click the user's account entry in Active Directory Users And Computers, and then select the Account tab. You'll find the Account Is Sensitive And Cannot Be Delegated option under Account Options. Scroll through the list until you find it.

CO CO

Configuring the Delegated Service or Computer Account

For the service acting on the user's behalf, you must first determine if the service is running under a normal user account or under a special identity, such as LocalSystem. If the service runs under a normal user account, check the account in Active Directory Users And Computers and ensure that the Account Is Sensitive And Cannot Be Delegated option is not selected. If the service runs under a special identity, you need to configure delegation for the computer account of the front-end server.

When the domain is operating in Windows 2000 Mixed or Windows 2000 Native functional level, you have limited options for configuring a computer for delegation. In Active Directory Users and Computers, double-click the computer account. On the General tab, select the Trust This Computer For Delegation option to allow delegation. This option sets the Windows 2000 level of authentication, which allows the service to make requests for any network resources on the client's behalf.

In Active Directory Users And Computers, double-click the computer account to display its Properties dialog box, and then select the Delegation tab, as shown in the following screen:

CQPR5ERVER08 Properties

General Operating System Member Of

Delegation | Location | Managed By ] Dial-in

C Do not trust this computer (or delegation C Jrust this computer for delegation to any service (Kerberos only) f* Trust this computer for delegation to specified services only C Use Kerberos only i* Use any authentication protocol

¡s to which this account can present delegated credentials:

When the domain is operating in Windows Server 2003 functional level, you have the following options for configuring a computer for delegation:

• Do Not Trust This Computer For Delegation Select this option if you don't want the computer to be trusted for delegation.

• Trust This Computer For Delegation To Any Service (Kerberos Only) Select this option to use the Windows 2000 level of authentication, which allows the service to make requests for any network resources on the client's behalf.

• Trust This Computer For Delegation To Specified Services Only Select this option to use the Windows Server 2003 level of authentication, which allows the service to make requests only for specified services. You can then specify whether the client must authenticate using Kerberos only or can use any authentication protocol.

When you are using the Windows Server 2003 level of authentication, you must next specify the services to which the front-end server can present a client's delegated credentials. To do this, you need to know the name of the computers running the services and the types of services you are authorizing. Click Add to display the Add Services dialog box shown in the screen on the following page, and then click Users Or Computers to display the Select Users Or Computers dialog box.

In the Select Users Or Computer dialog box, type the name of the computer proving the ser- $ vice, such as CORPSVR02, and then click Check Names. If multiple matches are found, select ®

the name or names you want to use, and then click OK. If no matches are found, you've either ™

entered an incorrect name or you're working with an incorrect location. Modify the name °

and try again or click Locations to select a new location. To add additional computers, type a semicolon (;), and then repeat this process. When you click OK, the Add Services dialog box is updated with a list of available services on the selected computer or computers, as shown in the following screen:

To allow services to be delegated for a user or computer, select the appropriate users or computers, and then click the services.

To select one or more user or computer names, click Users or Computers. Available services:

Users or Computers...

To allow services to be delegated for a user or computer, select the appropriate users or computers, and then click the services.

To select one or more user or computer names, click Users or Computers. Available services:

Users or Computers...

Use the Add Services dialog box to select the services for which you are authorizing delegated authentication. You can use Shift+click or Ctrl+click to select multiple services. Once you've selected the appropriate services, click OK. The selected services are added to the Services To Which This Account Can Present Delegated Credentials list. Click OK to close the computer's Properties dialog box and save the delegation changes.

Continue reading here: Using Locating and Transferring the Schema Master Role

Was this article helpful?

Kerberos unconstrained delegation was introduced in Windows Server 2000. It was designed to let webservers, receiving authentication requests from users, to impersonate those accounts when updating records on backend database servers. Another way to think of unconstrained delegation is as a mechanism where a user sends its credentials to a service and then the service accesses resources on the user’s behalf. When services impersonate user accounts in this way, it is sometimes known as performing a ‘double-hop’.

Unconstrained delegation is enabled by Domain Admins, and users that have the SeEnableDelegationPrivilege right, by checking ‘Trust this computer for delegation to any service (Kerberos only)’ on the Delegation tab of computer accounts in the Active Directory Users and Computers (ADUC) management console.

User accounts, managed service accounts (MSA), and group managed service accounts (gMSA) can also be configured for unconstrained delegation. But the Delegation tab in ADUC is not exposed by default for these object types. User accounts must be assigned a Service Principal Name (SPN) before the Delegation tab appears in the ADUC Properties dialog. Advanced Features must also be checked in the View menu. Delegation attributes for MSAs and gMSAs must be set manually in the Attribute Editor tab in the Properties dialog.

Users with the SeEnableDelegationPrivilege NT right, which is displayed as ‘Enable computer and user accounts to be trusted for delegation’ in security policy, also need write access to account objects to update their msDS-AllowedToDelegateTo, userAccountControl, and/or servicePrincipalName attribute values.

Other types of delegation in Active Directory

Service accounts enabled for unconstrained delegation pose a major security risk because it is possible to collect Kerberos Ticket Granting Tickets (TGT) from users connecting to those computers. Once a hacker has a user’s TGT, it can be used to log in to other systems. Tools like Mimikatz can extract TGTs from memory on systems where unconstrained delegation is enabled if Mimikatz is running with local administrator privileges.

Constrained delegation

Constrained delegation, if delegation must be used, is a much safer alternative as it restricts delegation to specific services. Constrained delegation is configured by selecting ‘Trust this user for delegation to specified services only’ on the Delegation tab in the ADUC Properties dialog and then selecting one or more services.

Resource-based constrained delegation

A third type of delegation, called resource-based constrained delegation (RBCD), is configured using PowerShell. RBCD lets the administrator owning the resource being accessed control delegation. Unlike the other types of delegation, RBCD relies on attributes set on the resource service, opposed to the service that is trusted for delegation.

While RBCD is the most secure type of delegation, it can still be used by hackers to move laterally across a network and elevate privileges if AD security best practices are not followed in your environment. For more information on RBCD, check out Microsoft’s website.

Delegation across Active Directory forest trusts

Services accounts enabled for unconstrained delegation use impersonation to authenticate against any other service in the same AD forest. After applying the July 9th 2019 update for Windows Server, unconstrained delegation is disabled by default across new and existing forest trusts. Changes to the default delegation behavior across forest trusts arrived in a series of updates in 2019.

You can get more information about the updates and how they change default trust delegation settings on Microsoft’s website here.

Find unconstrained delegation in Active Directory

On the same support page, Microsoft has a PowerShell script (Get-RiskyServiceAccountsByTrust.ps1) that you can use to find service accounts and forest trusts configured for unconstrained delegation.

Preventing unconstrained delegation attacks

Using the Get-RiskyServiceAccountsByTrust.ps1 script provided by Microsoft is one way to shine a light on service accounts configured for unconstrained delegation. Furthermore, following a few other security best practices can also help prevent risky configurations in AD:

1. On the Account tab in an account’s Properties dialog in ADUC, check ‘Account is sensitive and connect be delegated’ for accounts with privileged access to AD.
2. If it doesn’t create compatibility issues, add accounts with privileged access in AD to the Protected Users Members of this group cannot be used for constrained or unconstrained delegation. For more information about the Protected Users group, see this article on Petri.
3. Make sure that you restrict who can manage sensitive AD objects. Be careful who can change object attribute values, modify group membership, and reset account passwords.
4. Don’t use privileged AD accounts to manage AD from devices that aren’t specifically secured for that purpose.

1. Delegate privileges so that IT staff can perform everyday AD management tasks without needing privileged access to AD.
2. Remove local administrator rights wherever possible on end-user devices.
3. Use Windows Defender Credential Guard to protect domain accounts.