Account is sensitive and cannot be delegated

  • Last Post 09 June 2016
barkills posted this 06 June 2016

AD supports a per-user flag that prevents the ability to perform Kerberos delegation (constrained or unconstrained) with that account. I’m wondering about other’s practices related to this setting.   What isn’t particularly well-documented is that that there are two effects to this setting: 1.      other accounts can not obtain a forwardable TGT for the account marked sensitive 2.      this account can not obtain forwardable TGTs for any other account, even if that other account is not sensitive   We had to learn #2 the hard way, so I’m including that as helpful information for someone else. But that’s all background.   We have a practice of marking all accounts that are not personal as sensitive (so service accounts + admin accounts + “shared” accounts are all sensitive), because as a rule they tend to have a higher level of privilege and sensitivity to them.   We’ve recently discovered that HyperV leverages Kerberos delegation when performing a VM migration between clusters. This means some set of our admin accounts will need to not be sensitive, so that they can perform VM migrations. I’ve never heard anyone mention this issue, despite the ubiquity of HyperV. This has made us wonder if there are other features/services that our practice has left broken which we haven’t yet discovered.

  And in thinking more broadly about his, we are left wondering how many others use the Kerberos sensitivity setting-- I don’t think I’ve ever heard anyone talk about this topic other than in very general statements.   So what practices do others have around Kerberos delegation sensitivity? Do you use it at all? If you use it, which accounts are marked sensitive? What problems have you found with using it?   Brian Arkills

Order By: Standard | Newest | Votes
joe posted this 06 June 2016

We use it but much more narrowly than you do (for domain admins only). We don't use a lot of HyperV and our domain admins would typically not be using those accounts for VM migrations anyway so I'm pretty confident we've never seen that.
We never really put any thought into applying this more broadly to other account types (especially service accounts) so other than making me jot this down on my list of things to think about, I have not much else to offer you.
Since this is not implemented by default on any account in AD (that I'm aware of) and the feature is poorly understood, my guess is that you'll see very little actual usage of this. However, the activedir crowd tends to be a lot "deeper" than most so this is one of the best places I can think of to discover others using it. :)
Joe K.


SmitaCarneiro posted this 06 June 2016

Like Joe, we only use it for Domain Admins. Using it for service accounts may be a good idea too, and I’ll certainly start looking at this.





chaselton posted this 09 June 2016

FYI, Configuring this setting also came back to bite us. 


Turns out that forwardable tickets are needed in order to use the Get-AdGroupMember cmdlet on remote machines (by “remote” I mean “any machine that is not a

domain controller”).  I’ve not had a chance to dig too deeply into the why, so I’m not sure if this applies strictly to multiple-domain forests or not, but I thought I’d reply as this is something we looked into recently.