Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
What version of Windows Server are you using ? –  Stephane Jul 16 '13 at 13:29
2008 R2 SP1 at the moment, but if a Windows Server 2012 solves this in a better way we can probably upgrade. –  nitramk Jul 16 '13 at 13:41
2008R2 will do, as long as your DCs are also R2 and so is your domain functionality level. –  Stephane Jul 16 '13 at 13:48

2 Answers 2

up vote -1 down vote accepted

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).

share|improve this answer

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.

share|improve this answer
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
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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