6

I'm working in a team with 10 developers. We have servers set up which performs backup, automated build of software, automated deployment and more. Some of these servers contains sensentive material, such as login details to production systems (which is required for automated deployment).

We want to limit who has access to these machines to reduce the risk of passwords leaking out accidentally. To do this, we created a group in Active Directory containing 4 persons who are allowed to access the servers containing the sensitive material and made sure that only these 4 users could log on.

Some of these servers run scheduled tasks and Windows services to perform backup/deployment. These tasks/services run under a specific "shared" user account, let's call it "buildacc". The reason for this is that the tasks require access to shared resources in the network to be able to perform build/deployment. So we gave this user access to the servers as well.

To be able to modify the scheduled tasks in Windows, all 4 developers needs to have access to this "buildacc" account, which means that they all have to know the shared password and inform eachother when it's changed which we don't like the idea of.

We've considered using personal accounts to run scheduled tasks such as the script for building. The downside we see is that any member in the team can change the build script and make it do new things under the user account who configured the actual scheduled task.

Is there any best practices on how to handle this situation?

shodanshok
  • 47,711
  • 7
  • 111
  • 180
nitramk
  • 203
  • 1
  • 3
  • 6

3 Answers3

3

Overall what you've done up front is fine. A dedicated "service" style account that is setup with the permissions it needs and is used to run the scheduled tasks.

At this point, all you really need to do is:

  1. Change the password to buildacc
  2. Don't let the 4 developers know the password
  3. Assign someone the task of changing the scripts/tasks going forward (ie. Change Control policies) after the developers change their code.

It's really just an internal policy issue at this point. You should setup the scheduled tasks so that they don't really change. Meaning if it is running "test.exe" then have the developers modify that exe file but not the scheduled task itself. If all 4 of the developers truly need access to change the scheduled tasks then you are simply stuck where you are...

EDIT: I'd also caution you on being too liberal with your buildacc account across services and servers. Better to keep it strictly for "builds" and have backups and other services run under their own dedicated accounts.

TheCleaner
  • 32,627
  • 26
  • 132
  • 191
  • Considering people need vacation, get sick and so on, at least 2 persons needs the login details for the buildacc account. If we have three such "shared" accounts, that means that every person will need to remember 2-3 shared passwords and to coordinate with eachother when it changes. I don't feel this is really a great solution. – nitramk Jul 16 '13 at 13:39
  • 3
    Dedicated "service" accounts typically don't get "logged into" and scheduled tasks typically don't change frequently. If the 4 devs are using this account for their daily work then you can't really prevent "they all have to know the shared password and inform each other when it's changed which we don't like the idea of." What type of solution were you hoping to achieve? – TheCleaner Jul 16 '13 at 13:48
  • Something better. Please see Stephane's answer which seems to be better. – nitramk Jul 16 '13 at 13:49
  • An MSA doesn't prevent "The downside we see is that any member in the team can change the build script and make it do new things under the user account who configured the actual scheduled task.". You also stated that the `buildacc` account is used on multiple computers. MSA's exist only on a single computer. – TheCleaner Jul 16 '13 at 13:52
  • @TheCleaner That is correct, but a different problem alltogether. Basically, if the users need to change the script you run, there are only two ways around it: don't run the script in a context that has more access than the user himself or force an audit good enough to trace. In this situation, the typical solution is to place the build script under source control and have the build server automatically pull the latest version from SVN before running it: you have a proper audit trail. – Stephane Jul 17 '13 at 12:02
3

Assuming you are using a Windows 2008R2 system and a 2008R2 AD, you can use a managed service account for this.

This technet blog entry has a pretty good summary of how to use managed service accounts but, here are the basic principles:

A managed service account is an AD account that is strongly tied to a computer and that has an automatically managed password. You don't create the password and nobody needs to know about it but since it's an AD account, you can use it for network ACLs which makes it perfect for your scenario.

Using a MSA for a scheduled task will, however, require you to use the command-line to create your tasks (see this and this thread for more details).

Stephane
  • 6,432
  • 3
  • 26
  • 47
1

I see several answers mentioning MSA as a solution for the account used to run a scheduled task but as mentioned by the author of this post, they use Windows Server 2008 R2 and according to my research, MSA on this OS can't be used to run scheduled tasks.

However, with Windows Server 2012, a gMSA (Group Managed Service Account) can be used to run scheduled tasks as explained in this article.

CuiZinieR
  • 11
  • 1
  • 2
    Welcome to ServerFault. While the content of the article you linked may well be helpful, it's generally recommended on this site to include the relevant content from linked articles in your answer such that your answer doesn't explicitly rely on the links to be useful. Could you update your answer with the relevant info from the article please? – BE77Y May 21 '15 at 08:21
  • Here in 2020 - article does no longer exist under the given URL. – surfmuggle Oct 30 '20 at 09:31
  • This is most likely the article being referenced: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/windows-server-2012-group-managed-service-accounts/ba-p/255910 – Nathan Lutterman Apr 27 '21 at 19:28