The company I work for is currently going undertaking a project to remediate (among other things) a pen-test finding that a privileged domain-level account (which was compromised by the pen-testers during the audit) was being used for multiple maintenance and development tasks in production. Currently, we're trying to discourage the use of this account and break its functionality out into separate service accounts. We're getting especially firm push-back from the DBA group on the topic of trying to discourage its use in installing SQL Server patches.

So far, I haven't been able to find any guidance specific to accounts when it comes to "best practices" for installing patches so I was wondering if anyone had any first-hand knowledge or a good starting point on where to look. Thanks

  • possible duplicate of How do I deal with a compromised server? Dec 27, 2014 at 2:09
  • Your system has been compromised. What makes you think about patch installation if you haven't fixed the underlying problem? Dec 27, 2014 at 2:11
  • It's not entirely clear, but it sounds like it was a "white-hat compromise": proof during a security audit that a particular weakness is real.
    – Mark
    Dec 27, 2014 at 2:31
  • Apologies for not making it clearer - @Mark basically summed it correctly, this finding came up during a security audit last year performed by pen testers hired by our company.
    – easleyj
    Dec 29, 2014 at 18:18

1 Answer 1


As you mention a previous pentester compromised the domain-admin account. Once this happens pretty much the entire network is owned by the attacker.

This is part of the reason you should be careful using a domain-admin account to do patch management. If you issue remote commands via PSExec, RunAs, RDP etc then a token is left on that remote system. If that remote system becomes compromised (and the attacker is now a local admin) the attacker will want to elevate his influence on the entire network. If a domain-admin account was used for remote patching then privilege escalation can be accomplished via token-stealing. Metasploit even has a nice and easy module for this. And now the attacker is a domain-admin.

In the SANS reference they recommend

you should enable the checkbox "Account is sensitive and cannot be delegated" within the accounts' properties

They mention that this should have no adverse effects on a domain-admin account.

Finally If you have many people with domain-admin accounts that may indicate some other larger issues at hand. Breaking the domain-admin account into separate service accounts (that are not domain-admin) is probably a good idea as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .