What are best practices for giving users administrative access in Windows AD domain? – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about windows, active-directory, delegation, , .
The title may be slightly misleading but I’m interested in best practices for delegating administrative access for two different scenarios:
- giving developers local administrative access to certain development servers
Initially I would just add the dev’s AD account to the local Administrators group but this strategy quickly becomes difficult to manage. My second thought was to create a security group, add all developers to it and assign that group under the local Administrators group on the few development servers which they need access to. Please point out any problems with this strategy or if there is a better/easier/more standardized method.
And the second:
- currently I am the only one who holds domain admin privledges. I am planning on locking away an envelope with passwords so that the company is not dead in the water if I get hit by a car (or some such accident occurs). My immediate concern however is my ability to take a vacation and delegate control to my boss for the duration of my absense.
Always create groups and assign rights to the groups, never people. Then assign/remove people from the groups. This is a Best Practice that will make your life much easier down the road.
As your business grows in size you can delegate control of a group to a manager through built-in tools in Windows to allow the manager to add/remove people. You keep the access restricted and remove some of the work you have to do.
The second part of your question should actually be a question by itself because the answers are different. I create secondary administrative accounts for selected people who are my backup )if necessary). This is not a day-to-day use account (no email, etc) but it does have elevated rights in the domain. if I am going to be out of town or otherwise out of the office for an extended period of time I can activate these admin accounts and let my backup handle things.
You can also delegate control of rights such as “reset password” to manager/team leads so people do not have to contact you directly for that.
On your first point: I agree with your second thought (I’m seconding Top_Hat’s recommendation). Create a developer group, add the developer user accounts to the group, and add this group to the Local Administrators group on the relevant servers/workstations via Group Policy Restricted Groups or Group Policy Preferences.
As to your second point: That’s a tricky situation. If you’re the only one with the skills to manage the environment then it makes it tough for you to take vacation, sick days, etc. I’m in the same situation. You can use delegation of control to give a user (or users) limited access to AD for tasks like resetting passwords, unlocking user accounts, etc. How much control you delegate is up to you in terms of how comfortable you are with their skill set and understanding, and how much they’ll need to do while you’re away. You can create a group for these users and add this group to the Local Administrators group on selected servers/workstations if they’ll need administrative access to those servers/workstations while you’re gone.
I’ve had to manage access to every component in our environment to allow junior level staff access to a limited set of functions and access in order to back me up… without giving them access to the level of functions and access that a Domain Admin would have. It’s an arduous process and needs to be documented. I’ve had to delegate control to a limited scope of AD, set RDP restrictions, give limited access to the file system on our servers, grant limited access to Exchange server, DNS, etc., etc.