Using Active Directory to Manage Local Administrators or How To Easily Give Out root Accounts In A Few Simple Steps…
When something needs to be done on a Windows Server, it typically needs to be done with privilege. The user account has to be authorized with the right privileges to do whatever needs to be done: restart a service, install an application, or change a Windows Firewall configuration, for example.
You’re a part of the IT team chartered with enforcing your organization’s policy for user privilege management. You get a request from someone – an application administrator, a contractor, anyone who needs to do something on a Windows Server – and you need to grant them the privilege to do that something.
What usually happens next is that you make the user a Local Administrator on the target machine.
There are different ways to do this, but they all boil down to making the user account a member of the local built-in/Administrator security group on the target Windows Server. This is not an Active Directory security group. It’s a group local to the target Windows Server. That means, in a vanilla environment, you have to login to the Windows Server in question, launch the Local Users and Groups MMC snap-in, and add the Active Directory account to the local security group.
Voila – your user is now a Local Administrator and can do whatever they need to do on the machine. In fact, as Local Administrator, they can do anything on the machine. (And that’s a topic for the next post in this blog — as Local Administrator, they can do whatever they want.)
But for a variety of reasons, organizations we’ve spoken with may use a more sophisticated method to achieve the same end: making the user a member of the built-in/Administrator group on the target Windows Server without having to do a remote login to each individual Windows Server, every time, by leveraging Active Directory security groups.
Here’s how they do it. See if this looks familiar to you.
It starts with the initial provisioning of a new Windows Server for your data center. It can be a physical or virtual machine; for our purposes, they’re effectively the same.
After the shiny new Windows Server is running, given a unique Windows computer name and joined to the Active Directory domain (let’s call it MyAD), you can do the little bit of magic that gives you centralized control for moving your users in and out of the Local Administrator role on this particular machine.
First, create a new Active Directory security group. Give it a name that enables you to quickly correlate the security group with this particular machine, and the purpose of the security group.
Let’s say the computer’s name is SRVX. In that case, you might name the Active Directory security group SRVX-Remote-LAdmin. Regardless of the specific naming convention an organization chooses, they’ll use the same convention for each Active Directory security group they create for each server.
Second, login to your new Windows Server. It could be a console (interactive) or remote (RDP) login. It doesn’t matter. Once you’ve logged in, launch the Local Users and Groups MMC snap-in on the server.
And last (this is the cool part), you add your new Active Directory security group to the built-in/Administrator group on the target Windows Server.
- You have a new Windows Server named SRVX with a built-in, local security group SRVX/Administrators.
- You have a new security group named SRVX-Remote-LAdmin in the Active Directory domain MyAD.
- The local security group SRVX/Administrators has a new member: MyAD/SRVX-Remote-LAdmin.
From this point on, you can manage the movement of your users in and out of the Local Administrator role (that is, membership in the built-in/Administrator group) on the target Windows Server centrally. You simply use the Active Directory Users and Computers MMC snap-in to move a user in or out of the Active Directory security group MyAD/SRVX-Remote-LAdmin. Anyone in that security group will inherit the Local Administrator role on the target Windows Server.
The diagram below illustrates the method we’ve established.
- email@example.com is a member of the SRVX-Remote-LAdmin Active Directory security group
- The Active Directory security group SRVX-Remote-LAdmin is a member of the local security group
- firstname.lastname@example.org is a Local Administrator on the Windows Server named SRVX
Based on what our customers tell us – and we talk to our customers a lot – this is an approach many organizations use to manage Local Administrator membership and its root-equivalent privileges across their Windows Servers.
Root-equivalent. That’s an interesting phrase. On UNIX and Linux machines, we hardly ever give people root accounts; in fact, “break glass” may be the only time we do that. It’s a security policy violation and audit finding if we grant rootprivilege to someone who only needs to configure a firewall, for example.
But if a Local Administrator on Windows is effectively the same account as root on UNIX, then what we’ve just talked about is, in essence, a method to make it easier for us to grant root accounts across our entire Windows Server environment…accounts with too much privilege…
And that sounds like an excellent topic for my next blog post.