[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 980
  • Last Modified:

Granting local access do a specific Windows 2008 domain controller


I don't know if anyone tried this Windows 2008 R2 but I am trying to see if I could grant access to log on locally for one specific user (non admin) on a specific Windows 2008 R2 controller to act as a sort of "server operator".

I mainly want this user to be able to reboot the server if there is some problem with it and also copy a few files between folders as well as checking if the backup performed well.

However, this user should not have access to see the directory tree (because I do not want him to view other usernames from other business units in the same AD domain.

I was thinking about trying for a start to grant him a local "allow to log on locally" right directly on the DC in question but even with the domain administrator account, this setting is grayed out.

Any clue on how I could achieve that? I absolutely can't grant this user administrators rights.


2 Solutions
Justin OwensITIL Problem ManagerCommented:
I know for a fact you cannot grant "Log on locally" to a domain controller.

I am fairly certain that you cannot accomplish your goals as you set them forth in this Question.

benjilafouineAuthor Commented:
That's my feeling too but I am hoping some answer will show up. My other option is to leave the server as a Domain Member but since it is at the other end of a VPN, there could be performance issues.
Justin OwensITIL Problem ManagerCommented:
That is the conundrum of remote administration.
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Mike KlineCommented:
You can give someone the right to logon locally on a DC  
..but that doesn't give them any of the rights, they can just logon.   For example take a look at the screenshot of the user I setup in my lab to logon locally and you can see I can't shutdown or reboot.
There are builtin groups like backup operators or server operators but that will give people rights across your domain.  The only real way to be an admin on a DC is to be an administrator/DA.

Justin OwensITIL Problem ManagerCommented:
I should have been more specific when I said you can't grand log on locally rights... I meant in a usable way.  My apologies.
Darius GhassemCommented:
That is true you don't have the ability to customize a DÇ local logon like you would be able to with a member server.

Also, by giving access to a DC you are giving certain abilities and accesses to the DC that you don't want non-Domain admins to have. Even though they can't access AD Users and Computers they still have access to the DB and other services that can access AD to corrupt.
You certainly can grant any user right to logon to a DC.
Just a few more comments before you doing it:
1) by default as mike has indicated, Administrators, server operators, account/print/backup operators can logon locally. These users can also shutdown/restart servers and DCs with the exception of Account operators.
2) With 1 above, if you do not want the user to be able to do the above on all servers and DC then you should create a security group and make the user a member of then follow the steps provide from Mike's link to add the group. In addition to logon locally, you may want them to shutdown/restart system as one of your needs, same procedure.
3) If you do the above, you may want your user to also be able to logon to the DC remotely via RDP, then same procedure but look for "Allow log on through Terminal Services" and add the group you have created.

Finally, regarding viewing the domain trees, any domain user or authenticated users can view the domain trees as long as they have the AD tools installed. If you have a specific OU or OUs that you want to prevent specific group to read etc, you need to do delgation of those OUs. You can right click on the OU and select Delgation Control to deny or allow the group you have created above.
benjilafouineAuthor Commented:
Thanks for all the answers.

First, I believe that it would be easier if the server was not a DC. Since it will serve only 5 users (only one power user), I may take the chance to set the server as a member server only. I have done that for another client (3 users) and the site-to-site VPN tunnel between the two locations seems to be fast and solid enough to handle kerberos and DNS operations. That way, letting the user logon to the server would become more easier (like being a local admin user only as in PCs).

If I run into some latency with the requests, I will promote the server to a DC and then I will follow recommendations from Americom and Mike and make sure this only gives the user the rights I want him to have.

Note: I have started "hosting" very small companies directly in my own Windows domain for data replication purposes, web site hosting and also providing Exchange email addresses (my server manages seveval Internet domains) so they don't even have a network admin onsite (I am the part time admin). However, I like to have someone at the client who can at least reboot the server if I am unavailable but there is some stuff they should not be allowed to see (hiding an OU with a delegation is also a good suggestion).

benjilafouineAuthor Commented:
I will still have some testing to do but I assume it will work.

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now