5

I use domain accounts for SQL Server service accounts. Sometimes, when I have multiple servers that are logically or thematically related, I'll use the same set of domain accounts for the service accounts on all of them. The user account permissions on each server may be different, but there's usually a lot of overlap.

The gist of my question is this: can a user with access to one instance, but not the other, exploit the shared service accounts to gain access to the other server?

Here's the specific situation I'm trying to address:

  • I have two servers with default SQL instances, call them org-sql-1 and org-sql-2.
  • I use a domain account for each service, so I'd have mydomain\orgDBService, mydomain\orgAgentService, etc. (although I'm not sure that's strictly relevant -- I think I'd have the same question if I used a single account for all services).
  • But I reuse these domain accounts on both servers, so the database service on both org-sql-1 and org-sql-2 runs under mydomain\orgDBService, for example.

To date, I've never particularly questioned the security implications, since these servers have a common purpose and user base, even if the specific user permissions may differ.

Now, we're about to add a third instance, let's call it org-sql-rpt. This one is a good thematic fit with the others, but there's one key difference: we're going to allow an external partner (i.e. not an employee of our org) access to this server, like so:

  • Their credentials will own (belong to db_owner) a couple databases.
  • But they won't belong to any Server Roles (other than public, of course).
  • They may have admin access to the OS desktop for a limited time, prior to making this server live.
  • They won't know the passwords for the service accounts.

Given that, should I worry about reusing the domain accounts as service accounts for this new instance? Is there any risk that this person could use their legitimate credentials on org-sql-rpt to gain access to either org-sql-1 or org-sql-2? (i.e. any risk that could be mitigated by using different service account credentials?)

Or is this just a generally bad idea for other reasons?

EDIT

The new instance will be hosting Database, Integration, and Reporting services (for now, at least). No Analysis services.

The external user will have elevated database privileges, but no explicit instance permissions. They won't be able to create logins, jobs, or reports, for example.

  • I would say securing databases by using restricted logins with limited privileges is better way. Like if both SQL server have same service account and if logins are completely different its not possible unless a hacking is done. – Shanky Jul 31 '14 at 15:49
  • One issue that I think about when configuring multiple servers to run under the same service account is account lockouts. If the service account gets locked out, now all your servers might be affected. If you have one account per service, at most one service can be affected by a lockout. – Max Vernon Jul 31 '14 at 15:58
  • It may depend on the level of permissions you give the service accounts within the instance. If the SSA service account for example has sysadmin rights and a user has rights to create an SSA job to run under the service account context (like on a Dev instance), you could have a job created that either creates a linked server or OPENQUERY call to access data on the other server. Granted, it's contingent on both the user and service account in question having the required permissions. – MattyZDBA Jul 31 '14 at 17:03
  • @Max If account gets locked out I dont think SQL Server sevices will stop immediately ? I guess if SQL Server services are restarted then it would affect – Shanky Jul 31 '14 at 17:27
  • @MattyZDBA, no Analysis services or atypical service account privileges. But that does seem like an example of the kind of thing I'm trying to discover, i.e. cases where a legitimate user account can piggy back on service account credentials to access another server using the same service account. – Matt Jul 31 '14 at 17:33
6

Risk mitigation would indicate creating a separate account for each service on each machine. The level of work required to create the accounts necessary is extremely minimal, but the unknown risks that accompany not doing so are quite high, according to Microsoft's own recommendations.

Microsoft Best Practices recommend using separate service accounts for all services.

See http://msdn.microsoft.com/en-us/library/ms144228.aspx#isolated_services for details.

The salient points being:

Isolate Services

Isolating services reduces the risk that one compromised service could be used to compromise others. To isolate services, consider the following guidelines:

Run separate SQL Server services under separate Windows accounts. Whenever possible, use separate, low-rights Windows or Local user accounts for each SQL Server service. For more information, see Configure Windows Service Accounts and Permissions.

There is also a KB talking about securing SQL Server that mentions how to configure service accounts properly:

http://support.microsoft.com/kb/2160720

When choosing service accounts, consider the principle of least privilege. The service account should have exactly the privileges that it needs to do its job and no more privileges. You also need to consider account isolation; the service accounts should not only be different from one another, they should not be used by any other service on the same server. Do not grant additional permissions to the SQL Server service account or the service groups. Permissions will be granted through group membership or granted directly to a service SID, where a service SID is supported. For more details please refer to Books Online Topic Setting Up Windows Service Accounts.

Technet has an article, titled Configure Windows Service Accounts and Permissions at http://technet.microsoft.com/en-us/library/ms143504.aspx that has this to say:

Security Note: Always run SQL Server services by using the lowest possible user rights. Use a MSA or virtual account when possible. When MSA and virtual accounts are not possible, use a specific low-privilege user account or domain account instead of a shared account for SQL Server services. Use separate accounts for different SQL Server services. Do not grant additional permissions to the SQL Server service account or the service groups. Permissions will be granted through group membership or granted directly to a service SID, where a service SID is supported.

"MSA" in the above paragraph refers to "Managed Service Accounts" which is the default for installations on Windows 7 or Windows Server 2008 R2 and above. Managed Service Accounts are defacto unique to each machine.

  • 2
    I've read most of that before, but a refresher never hurts. I am using a separate account for each service, and they're all lowest-of-the-low-privilege domain accounts, I'm just not clear what the risks are of reusing a domain account for the same service on two different servers. Managed Service Accounts look interesting, though, so I definitely have some more reading to do there. – Matt Aug 1 '14 at 18:06
  • @Matt, did you ever figure out the answer for using Same domain Service Account on two different servers?...I am stuck at this very same question now!! – Santhoshkumar KB Jan 2 '18 at 13:45
5

we're going to allow an external partner (i.e. not an employee of our org) access to this server, like so:

Their credentials will own (belong to db_owner) a couple databases.

A concern along with the service account being the same on multiple instances is that an outside entity can escalate their permissions quite easily. Given that outside entity is in dbo, a risk is being opened up that they could hack and elevate to sysadmin. DBO Escalation

Next concern, you have a user that may have local admin access (duration doesn't matter here), they can easily add themselves (without already having a login to SQL server) as a sysadmin or change the sa password and the threat continues from there. Here is an article on how to do that.

Add Sysadmin

And another Example to add a sysadmin - 2012

Based on these exploits, I would use a different service account and password for each instance. Make it as difficult for that outside entity to move from one server to the next.

  • yeah, I knew the local admin access was not good; they'll be supervised for the duration (connecting via webex), but still... Do you happen to have any links handy on how dbo escalation works? Wolter says "It is then a piece of cake to gain system level permissions once you are for example in the db_owner database group" but he doesn't say how, and I'd have a better argument for restricting access if I could demonstrate the vulnerability. – Matt Aug 1 '14 at 17:33
  • One method to do get the dbo escalated to sa is via the trustworthy bit. If trustworthy is set on, then permissions can be escalated. Once you get to sa, then the doors are wide open. – SQLRNNR Aug 1 '14 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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