1

I was researching a kerberoasting attack on the Active Directory domain. To create the stand, I used a Domain Controller on Windows Server 2016 and one client machine on Windows 10. SQL Server was installed on the Domain Controller which was launched from a sqladministrator account with Domain Administrator rights. The sqladministrator was given a simple password that can be easily attacked by brute force. But by default, the installer of MSSQL Server 2014 offers to create special accounts that cannot be attacked by kerberoasting.

Why do administrators continue to create such vulnerable passwords, even if the default installation of the SQL server avoids it?

4
  • Did you really mean "configuration" or did you mean "password"? It looks like you just mean "password". – schroeder Jan 2 at 8:44
  • 4
    If your question is simply "why do admins create poor passwords?" that might not be answerable other than to simply say that simpler passwords are easier to remember and to enter... – schroeder Jan 2 at 8:45
  • @schroeder. I can reformulate the question as follows. What is the motivation for administrators to launch services with SPN from domain user accounts? Is this really the only possible option, and using the standard service accounts that are offered by default is not possible? Without considering the presence of weak passwords and extremely high privileges for these accounts. – Dmitry Jan 2 at 12:17
  • Then, that really doesn't seem like a security question, but a DBA question with security implications. – schroeder Jan 2 at 12:41
1

What is the motivation for administrators to launch services with SPN from domain user accounts?

There are five ways you can set these things up:

  1. Local service on a workgroup machine
  2. Local user on a workgroup machine
  3. Local service on a domain joined machine
  4. Domain user on a domain joined machine
  5. (g)MSA on a domain joined machine

There is a collective belief that running things as local service accounts (SYSTEM, NETWORK SERVICE, etc.) are bad security practices. This is misguided in some ways and accurate in others. It forces the service to operate as the machine account on the network and rightfully gives the service full control over the machine. If it's a single-use machine then having it operate as SYSTEM is actually more secure because you only have to worry about the machine identity on the network, not machine plus service account. Incidentally machine accounts tend to de facto have fewer permissions on a network because no one every really thinks to grant special privileges to machines.

Conversely if it's a multi-use machine then running it as SYSTEM puts you in a tricky spot because attacking the one thing can cause an attacker to take full control and then easily take over the other things running on the system. Multi-use machines used to be quite normal back in the day, and still are in smaller environments.

This is applicable in both workgroup and domain scenarios but obviously the machine doesn't have an identity on the network in workgroup so that's one less thing (at the loss of manageability).

Given the above belief people tend to just say screw it and make a dedicated service account. Someone makes a claim about SYSTEM, someone else believes them, yet another someone else writes it down, one more takes it as gospel and the cycle viciously repeats itself. See Monkeys, bananas, ladder, spray as a fake and contrived, but convincing, example of how this works in life.

As for why people then give weak passwords for these things? Because they a) don't know any better, or b) don't care, or c) both. Getting people to use good passwords is hard. Like really really really hard.

And for why people don't use managed accounts: because they're poorly documented, people don't understand how they work, only a handful of things support them natively, and most of all people just don't know they even exist.

Not the answer you're looking for? Browse other questions tagged or ask your own question.