Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have experience with Linux server administration, however when it comes to Windows I'm pretty much a newbie.

I have a lot third-parties applications that use an AD admin account to perform its authentication against the enterprise Active Directory. In total I found more than 40 admin accounts, which from a compliance regulatory perspective is a red flag!

I'm sure there is a way to overcome this situation. My intention is to have a AD ready only account capable to query the AD Forrest and return to the application if the username/password is valid or not. This account must not have any write.

What is your recommendation for this kind of situations?

share|improve this question
up vote 3 down vote accepted

First, when you say 40 admin level accounts I'm going to assume you mean Domain Admin. 40 of these type of accounts is dangerous for so many reasons that I'm sure you can already guess. What I would recommend as the first thing to do would be to open the Domain Admin, Enterprise Admin, and Schema Admin groups in Active Directory. Opening these groups up will let you select a tab called Members to truly see how many people are in each group. The three I named (domain admin, enterprise admin, and schema admin) are the most important and allow the most control over your domain/forest so you want to make sure that only you as a sysadmin and maybe a select FEW others that are either admins themselves or that you trust have these rights. I'd say only you, but I know sometimes there are circumstances where you have to have others that get these rights; rarely, but it does happen. Here is a screenshot of the Domain Admin properties for reference:

enter image description here

The next thing you'll want to do since you need an account, or accounts, for these 3rd party apps to communicate/authenticate through AD with would be to create an MSA, or managed service account. I have used these accounts and I can say that I think when it comes down to it that they are superior to just using a regular user account in AD. Avoid giving any non admin user/account admin rights at all costs.

What I like to do, and have done, is create a new OU in ADUC for these service accounts so they are easily managed and can have certain things like GPOs (Group Policy Objects if you're not aware are ways to manage mass number of computers/users) applied to them much easier if needed.

You can create and manage these MSAs through Windows PowerShell but make sure you're on at least version 2 of PowerShell. The command for creating one of these accounts is simply Add-ADComputerServiceAccount. Whatever other options you want to create this user with can be found here.

Another good thing about MSAs is that you can create what are called Service Administrators (effectively people in AD with permissions to manage these MSA accounts) who can have delegate control over these accounts. This could be good for you as this person doesn't need to have domain admin rights and in the long run could save you time as they are able to manage the MSA accounts which leaves you more time for more important sysadmin stuff.

For a list of best practices for the MSA see this post directly from the MS Directory Services Team.

share|improve this answer

Just create a user account that is member of the Domain users group. That account won´t have any write permissions on the other objects of the directory except for itself.

If you need some more advance service accounts, Windows 2008 R2 has something called Managed Service Accounts. I have never used them but it won´t hurt to have a look at them:

Hope it helps ;)

share|improve this answer

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.