Now, assuming that this is not a domain admin, the ability to logon to a domain controller is defined in the Default Domain Controllers Group Policy. You can view this by right clicking on the Domain Controllers OU in Active Directory Users and Computers and selecting "Properties". Click on the "Group Policy" tab, select the policy and click "Edit". Navigate using the Group Policy Object Editor to the following branch:
Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment
In the right hand window, look for either "Log on locally" or "Allow Logon Locally" (it differs depending on which version of Windows you are using). Double click on the policy and add/remove users from that list accordingly and check the box next to "Define these policy settings:" to define who will be allowed to logon locally. By default, the following accounts/groups can logon locally to domain controllers:
- Account Operators
- Backup Operators
- Print Operators
- Server Operators
- Corresponding Internet Users (IUSR_
As always, rather than directly editing the Default Domain Controllers Group Policy, you should create a new group policy object with the settings you want. Also, be advised that changing the default settings can cause unexpected and potentially damaging results to your systems.
View questions and answers from all of our Windows security experts here.
I'm curious. How come you didn't tell the admin you were advising that its better not to make a person a domain admin, rather it is better to use the "Delegation of Authority" feature to give that user the abilities they need rather than give them the keys to the safe and make them a domain admin?I was first introduced to this feature at http://mcpmag.com/columns/article.asp?editorialsid=1198#post and have given my user the ability to do several tasks including working in ADU&C, (creating, adding, removing users and computers to the domain) all without being a domain admin. I can run most of the needed tools from adminpak.msi on my local XP client with my normal user, and don't need to be a full fledged domain admin.
This is actually a very good point. At the time, I was answering the question that was asked, and frankly I didn't think about alternative approaches. My response was predicated on the fact that the users were Domain Admins. With that said, a far, far more effective overall approach that would indirectly solve the original problem is to do exactly what you mention. By Delegating Authority to the objects and resources that an admin needs to manage you can grant them all the necessary rights and privileges that they need, without making them Domain Admins. A good example of this is an environment that I work in which uses delegation and permissions in Active Directory to grant users rights to specific Organizational Units (OUs). This allows "normal" users to be able to perform the functions they need in a given OU (such as adding/deleting computers, users or groups) without ever making them a Domain Admin (and in fact in my example they are just normal Domain Users).
Additionally, there are some third party applications such as NetIQ Directory and Resource Administrator, NetIQ Change Administrator or Quest ActiveRoles that allow you to configure management schemes that allow unprivileged users to be able to perform required privileged tasks while still ensuring regulatory compliance, logging and accountability for all changes.
This was first published in February 2006