Partager via

Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts

  • Article

There are a number of configuration options we recommend for securing high privileged accounts. One of them, enabling 'Account is sensitive and cannot be delegated' , ensures that an account’s credentials cannot be forwarded to other computers or services on the network by a trusted application. 

 

The feature that allows an application to act on behalf of a user is known as Kerberos Delegation. It has to be explicitly enabled for trusted services on a trusted computer. It can be switched on for a service account running the service or for the computer's Local System account (all services running as Local System). It can be unconstrained, i.e. the application can impersonate the user anywhere else within the forest or across a trust, or it can be constrained, i.e. the application can only impersonate the user to a specific service on a specific computer.

If a trusted computer is compromised, the trusted application could act on behalf of any user that has presented itself to the service to perform malicious activity. If an account has 'Account is sensitive and cannot be delegated' set, then its credentials can not be reused by a trusted service. This limits the scope of attacks that use delegation, e.g. elevation of privilege activities.

How can you check that your high privileged accounts have this setting enabled?

First up, here's how to get a list of users that have this configuration already set: 

Get-ADUser -Filter {AccountNotDelegated -eq $true}

  

You could make use of my Test-ADUserHighPrivilegeGroupMembership function see which of these users is a member of a High Privileged group:

 Get-ADUser -Filter {AccountNotDelegated -eq $true} | Test-ADUserHighPrivilegeGroupMembership

 

Next, you could test a specific high privileged group for non-complaint users like this:

Get-ADGroupMember -Identity "Domain Admins" | ForEach-Object {

Get-ADUser -Identity $_ -Properties AccountNotDelegated |

Where-Object {$_.AccountNotDelegated -eq $false} |

Format-Table DistinguishedName,AccountNotDelegated -AutoSize

}

 

Alternatively, loop through all users protected by AdminSDholder, i.e. high privileged users:

Get-ADUser -Filter {(AdminCount -eq 1) -and (AccountNotDelegated -eq $false)} | Select-Object DistinguishedName

 

Go do it!

Comments

  • Anonymous
    May 07, 2015
    Making the enterprise more secure... increase the security of interactive logons.
  • Anonymous
    September 10, 2015
    not sure if this is related, I tried this on my admin account and I cannot log into Exchange 2013 admin center anymore. So to be secure or to be able to manage exchange, that is the question...