The user just needs to have administrative rights over the domain controller server so that you can manage that server's configurations. Since there is no local admins group on a DC the common practice is to place in Domain Admins or map to a Domain Admins account.
There is an administrators built in group. Try that.
Is the administrator's built in group you are referring to the same thing as 'administrator' found in Domain Admins group?
The real objection is mapping to a user in Domain Admins for security reasons. For example, Can Domain users who are not part of Domain Admins push patches to DCs (Power users or other group). Like most client's they want to give the least amount of priveledges.
The user needs to be in the 'BuiltIn\Admins' group directly.
I found that putting the user in 'Domain Admins' or another group that is then in 'BuiltIn\Admins' does not work. I believe this is because on a non-domain server you cannot nest local groups.
now, any group in 'BuiltIn' should work. If there's a Group in the 'BuiltIn' that can push things to domain controllers but no one else, then use that.
that's up to the client to determine - we can't tell them how to configure AD for their environment :)
Thanks for feedback Bill & Frank!
Anybody have an answer for these 2 questions:
Can we map to LocalSystem on the DC since all services on DCs run as LocalSystem?
If there are multiple domains within a forrest and all trusted does the user need to be created in all domains or just one?
As far as I know LocalSystem will not work. LocalSystem is a "special" account and cannot be logged on as a user or impersonated. See http://msdn.microsoft.com/en-us/library/ms684190.aspx for more info.
Even though our service runs as LocalSystem our mapping is looking to impersonate a user, thus logging you on as that user with the appropriate privilege. The purpose of the account you are creating is to simply manage the Domain Controller box. Since a Domain controller does not have "Local" account the only option is to create a Domain account. However, that user will only ever manage the local server. Also, remember that you do not even need to know the password to the account after it is created. As long as the account can administer the local server for compliance, patching, deployment needs you are set.
Also, the account only needs to be in the domain for which that Domain Controller is a member. If they are installing on multiple domains then it would be useful to have the account on other accounts too.
From a security perspective you could always create the account and restrict the servers where it can log on to only the Domain Controllers so that a malicious user could not use it to jump to other systems.
what about using an account in the 'builtin\server operators'?
Just ran into this one again, BuiltIn\Admins is the key setting.