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