0

I've been tasked with reconfiguring our current local and admin account setup. Currently we have a single domain account we use for mostly any domain admin work we need to do (largely just UAC prompts), with Linux sudo rights, RDP rights, SQL admin rights and so on being delegated in separate security groups that are tied to user domain accounts we use for our day to day. Most of us also have locally defined admin accounts set up at computer generation. We want to clean this up and have determined the following setup:

each user gets two accounts: a general user account for the day to day, and then an admin account specifically used for UAC prompts for both their local machine (this machine is defined in AD), and any of the servers defined in the Windows server OU.

In looking into this I've found two methods that seem to be standard practice

  • defining a local admins domain security group, then create a group policy for a restricted group for local administrators, and add the domain group. any accounts added are local admins.

  • defining local admin security groups for type of machine (one for Windows servers, one for the SQL servers, etc), and when creating the group policy specifying via the local users and groups GPO config which machines (aka targets here) the account is allowed to access.

What would be the more preferred setup here, while minimizing overhead? I've gotten some pushback on the first method as the built in group administrators has domain admins as a member, and these new admin accounts cannot be domain admins. The second method will allow a lot of granularity, but this would in theory require a new GPO created specifying the user is local to their own machine, as well as any security groups required.

8
  • 2
    the built in group administrators has domain admins as a member, and these new admin accounts cannot be domain admins. that doesn't make any sense, and should not matter. Adding a separate Domain group does not affect Domain Admins. Domain Admins is for administering Active Directory, it is not for and should not be generally used on member server and workstation endpoints for generic maintenance. Principle of least privilege. The only reason it does exist in the local Administrators group is for legacy reasons.
    – Greg Askew
    Commented Dec 10, 2023 at 11:31
  • @GregAskew can you expand on this further? I'm not sure what you mean by legacy reasons. But what i was referencing with that is during the GPO creation I outlined in option 1. You're adding the new group you've created as a restricted group in the GPO, and then specifying this new group is a member of administrators. but domain admins is a member of administrators, and was told this was not allowed after review.
    – BigN00b
    Commented Dec 10, 2023 at 15:55
  • this was not allowed what is not allowed? Does your proposed options not preserve the group membership?
    – Greg Askew
    Commented Dec 10, 2023 at 16:10
  • @GregAskew These new accounts need to be local admin accounts, they cannot be domain admins. Every guide I've seen for configuring as such says to use the built in administrators security group, but this also means the accounts are domain admins. This is the aspect that Ive been struggling with- how do I push out local admin accounts across the domain while having them not be domain admins? community.spiceworks.com/how_to/…
    – BigN00b
    Commented Dec 10, 2023 at 16:16
  • New accounts? And how or why would they be added to Domain Admins if you are creating a separate group to use? Missing a sizeable chunk of mystery there.
    – Greg Askew
    Commented Dec 10, 2023 at 16:41

2 Answers 2

1

For the local admins, I would look into LAPS from Microsoft. The "Local Administrator Password Solution" (LAPS) provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset.

For the rest my approach would be:

  • Investigate what kind of "domain admin groups" you need to have. Like Exchange Administrators or office365 admin or Linux admins.
  • You can either let LAPS manage the local admins, when you need local admin access you can retrieve the password from AD or Azure AD, they you need to add domain groups on local computers who have Admin privileges.
  • Or you can create domain group who is has local group which is added to the local administrator group on every device.
0

For an on-premise AD setup the restricted group method works well, and I’ve used it many times over the years for customer installations. It makes for an easy solution to allowing specific AD user accounts to have Admin access to specific machines on the domain (which you can obviously control via the GPO), while for instance not allowing them any admin access to the server.

“I've gotten some pushback on the first method as the built in group administrators has domain admins as a member, and these new admin accounts cannot be domain admins.”

I suspect whoever has been giving you pushback based on that is either confused or doesn’t know what they’re talking about.

If you have groups A and B and you add them as members to group C, then A and B now have access to whatever C has been granted to. But A doesn’t also gain access to whatever B has been granted to as well. That is roughly what they’re suggesting. To make that true you’d also need to add A as a member to B, only then would A gain access to whatever B had access to (as well as C).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .