(2014-03-25) An Account With "Trusted For Delegation" – What Are The Risks?

Sometimes when implementing some system/application/appliance that needs a service account, that service account may need to be configured with "Trusted For Delegation". The latter has three flavors as shown in figure 1 below.

Figure 1: The Delegation TAB After Configuring A Service Principal Name

–

As you can see in figure 1, you have 4 options you can configure, being:

1. Trust This User For Delegation To Any Service (Kerberos Only) – A.K.A. "Open Delegation"
2. Trust This User For Delegation To Specified Services Only – Use Kerberos Only – A.K.A. "Constrained Delegation"
3. Trust This User For Delegation To Specified Services Only – Use Any Authenticaton Protocol – A.K.A. "Constrained Delegation"
4. Do Not Trusted This User For Delegation – (this is obvious, isn’t it?!)

–

Now, you may wonder: "what are the risks?". Keep reading!

–

An AD user account or computer account with such powers is worthless on its own. You need to have a system/application/appliance using such an account that is being targeted by end users and that is providing some kind of service.

With regards to the system/application/appliance that has that account configured you are fully trusting the code of the system/application/appliance to act on a user’s behalf for any OR specific services it is performing delegation for. With that in mind you should also think about how likely is it for the system/application/appliance to be "misused" during an attack? As risk mitigations you can think of measures such as physical access controls (secure rooms) and network access controls (firewalls) access controls, but also having the latest patches/hotfixes applied that are recommended by the vendor.
It also comes down to the question if you trust the administrators and/or vendor of the system/application/appliance to not misuse those high privileges. Having trusted administrators with the correct delegation of control supported (pro-active measure) with the correct auditing measures (re-active measure) helps to "secure" the system/application/appliance in a proactive and re-active way.

In addition, if even possible AND after testing, you may be able to configure the following user rights for the service account on different Windows systems to mitigate risks:
(User Rights)

• Deny Access To This Computer From The Network
• Deny Log On As A Batch Job
• Deny Log On As A Service
• Deny Log On Locally
• Deny Log On Through Terminal Services

–

Again in addition, you can configure the account with a very secure password and if needed/possible use the (at least) four-eyes principle to make sure nobody ever knows the complete password but just part of it.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————