Why You Should (Almost) Always Use System- and Task-Specific Service Accounts
In my company, my overall department often takes over environments for business units who have built their own, then found they lack the time/knowledge to manage it effectively. It then falls upon my team to reorganize the Active Directory domain to follow industry/internal security standards and best practices. This article covers one of the most common low-level offenses we encounter: shared service accounts.
Like so many questionable decisions, using a shared service account seems like such a good idea on the surface. You only have to create one account in AD, you only have to record and track one set of credentials, app installers only have to remember one set of credentials, permissions for different processes will likely overlap (meaning you only have to grant the access once), etc. However, I have a personal story that will help highlight why you're playing with fire.
Let's travel back to early 2008. It was the first week of my current job, and I was trying to learn as much as I could about the various environments and services of my new team. One of those services was the internal company portal that was running Microsoft Office SharePoint Server (MOSS) 2007. For those of you lucky enough to never have administered a WSS/MOSS/SharePoint Server instance, there are several roles within the product that are (ideally) done by several different service accounts. The admins who built the system the system for my employer had chosen to use one account, likely because of convenience (it was also a Domain Admin, which is another post).
As part of my discovery process, I was given the credentials for that account and told to review the MOSS configuration. I tried the creds and was rebuffed multiple times. This is the part where the AD admins out there start sweating. I was not familiar with the domain settings yet, so I shrugged and figured I'd get the correct creds from my teammates later. After about five minutes, people started insistently asking why the portal was down. Long story short, I locked out the account and brought down the primary CMS/portal for the entire company (5,000+ users at that time).
This leads to the first (and, in my mind, primary) reason to not use shared service accounts:
If you use separate service accounts for each task/service/process, the effects of a single account incident will be minimized. In the SharePoint example, if the Setup account had been split off on its own (as per best practice) my lockout wouldn't have affected the core functionality of the product. In the MSSQL example, you might lose functionality in one instance instead of half a dozen, reducing the chances something truly important (like an SLA-affecting service) will be affected.
Shared accounts can also annoy customers in more direct ways. If you have a customer classroom lab with a capacity of 30 and each student logs in as the same account (per-room logins), that means every time they have to enter their credentials, you're assuming all 30 will be able to do so successfully before hitting the lockout threshold. If the account does get locked out, the entire class might have to be put on hold while the account is unlocked. If you use per-workstation logins, each user is independent and the rest of the class can keep running while you unlock one account.
Other arguments against shared accounts include:
Things usually grow and grow until domain ownership changes (rare), someone grants the access using a blunt method like membership in a default domain group (Domain Admins, anyone?) or a root group policy setting, or there's an incident bad enough to force the admins to reconsider the design.
Like so many questionable decisions, using a shared service account seems like such a good idea on the surface. You only have to create one account in AD, you only have to record and track one set of credentials, app installers only have to remember one set of credentials, permissions for different processes will likely overlap (meaning you only have to grant the access once), etc. However, I have a personal story that will help highlight why you're playing with fire.
Let's travel back to early 2008. It was the first week of my current job, and I was trying to learn as much as I could about the various environments and services of my new team. One of those services was the internal company portal that was running Microsoft Office SharePoint Server (MOSS) 2007. For those of you lucky enough to never have administered a WSS/MOSS/SharePoint Server instance, there are several roles within the product that are (ideally) done by several different service accounts. The admins who built the system the system for my employer had chosen to use one account, likely because of convenience (it was also a Domain Admin, which is another post).
As part of my discovery process, I was given the credentials for that account and told to review the MOSS configuration. I tried the creds and was rebuffed multiple times. This is the part where the AD admins out there start sweating. I was not familiar with the domain settings yet, so I shrugged and figured I'd get the correct creds from my teammates later. After about five minutes, people started insistently asking why the portal was down. Long story short, I locked out the account and brought down the primary CMS/portal for the entire company (5,000+ users at that time).
This leads to the first (and, in my mind, primary) reason to not use shared service accounts:
A lockout or other account incident will affect multiple processes/systems
In my example, this means every facet of SharePoint was affected because they were all running under the same account. Another fairly common practice is using one account to run multiple MSSQL instances; this means one lockout or accidental disable could take down every MSSQL instance in an environment. Depending on how gracefully your apps deal with abruptly being shut off from their database tier, this could be a pretty big deal.If you use separate service accounts for each task/service/process, the effects of a single account incident will be minimized. In the SharePoint example, if the Setup account had been split off on its own (as per best practice) my lockout wouldn't have affected the core functionality of the product. In the MSSQL example, you might lose functionality in one instance instead of half a dozen, reducing the chances something truly important (like an SLA-affecting service) will be affected.
Shared accounts can also annoy customers in more direct ways. If you have a customer classroom lab with a capacity of 30 and each student logs in as the same account (per-room logins), that means every time they have to enter their credentials, you're assuming all 30 will be able to do so successfully before hitting the lockout threshold. If the account does get locked out, the entire class might have to be put on hold while the account is unlocked. If you use per-workstation logins, each user is independent and the rest of the class can keep running while you unlock one account.
Other arguments against shared accounts include:
Access will aggregate unnecessarily
One of the mantras of every good sysadmin is the principle of least privilege. In layman's terms: everybody should have access to everything they need to their job, but no more. This seems like a pretty common sense thing, but it's amazing how often it is violated in the name of convenience. Using a shared account is doing just that: once you start using one service account for multiple purposes, you're forced to grant it access for those purposes. You could argue the account only has the permissions it needs, but that's an overly simplistic viewpoint:- The systems running under that account are entities in their own rights. They are functionally performing actions under that security context, and they have their own sets of access needs. By using a shared account, each of those systems has more access it needs.
- Unless you're a very small shop, you likely share service account credentials with product installation or maintenance teams. If you use a shared account, that means everyone who has the credentials to that account has all the products' aggregated access as opposed to just what is needed for their product.
Things usually grow and grow until domain ownership changes (rare), someone grants the access using a blunt method like membership in a default domain group (Domain Admins, anyone?) or a root group policy setting, or there's an incident bad enough to force the admins to reconsider the design.
Account decommissions and access audits become much more difficult
Consider this scenario: you're in a shop with a DFS-R namespace that has a couple hundred shares as well as a SharePoint instance. Some of those shares/lists contain data that needs to be read by systems and some are repositories where systems write data. You are using one shared service account for your HCM/HR systems because the installer was only on site for one week and didn't let you know until the third day, meaning the HR department didn't want to wait for you to pump the vendor for the information needed to make process-specific accounts.
Back in the present day, HR comes to you saying they purchased a new product to take over a part of the HCM system. Accordingly, you need to make sure you revoke the access associated with the old system because it accesses very sensitive data.
Had you been able to use process-specific service accounts, this would be as simple as scheduling the decommission of the associated account and maybe cleaning up some ACL entries on some shares/lists after it's deleted (not necessary if you're using representative access groups).
However, you're now stuck. Your best case scenario is the vendor has accurate, up to date, very specific documentation on what access that part of their product needed so you can remove it granularly. If this has happened to you, buy a lottery ticket. For the rest of us, you don't know what you can take away. Even if you know some access was tied to the retired product, it's entirely possible some other part of the HCM system also needs it, especially read permissions. You're likely going to have to rip the access out piece by piece, having the HCM people test to make sure you didn't break something. The fun part? Most HCM systems have reports that only get run once per month, quarter, or even year, so there's a chance you won't know if you broke anything for months.
Of course, presented with this risk, many sysadmins and dependent departments will simply accept the risk of stale access. If nothing changes, the shared service account will have far more access than it needs, and it will only become a larger and larger project to clean up as time goes along and additional changes are made.
This is one of those small things you can do to make the systems in your domain more resilient and get yourself some long-term brownie points with business units. If they're used to shared accounts, they will likely balk at the extra work needed to switch their model, but the first time an account gets locked out/disabled and nothing important goes down, you'll look pretty smart. And, as shown by the last example above, it will allow you to more closely follow the principle of least privilege, lessening the impact should you ever experience a credential breach.
The ideal scenario is something like AD reports that require no elevated directory access but might number in the dozens or hundreds. Of course, if you choose this route, make sure you document all the uses in your internal documentation/knowledge base so you can make informed decisions regarding account decommissions and be ready to provide all the account's uses should an auditor come calling.
Unless...
Of course, there are exceptions to every rule. If there are multiple non-critical tasks or processes that have identical access needs, it might be appropriate to have them configured to use the same account. As the importance/critical rating goes down and the number of tasks/processes go up, the shared account model gets more attractive.The ideal scenario is something like AD reports that require no elevated directory access but might number in the dozens or hundreds. Of course, if you choose this route, make sure you document all the uses in your internal documentation/knowledge base so you can make informed decisions regarding account decommissions and be ready to provide all the account's uses should an auditor come calling.
Comments
Post a Comment