Active Directory GPO - Restricted Groups

as you all know, workstations that need to be joined to a domain need administrative privilege. after joining to a domain, i would like to COMPLETELY disable ALL local administrators. however, we, here, nobody knows how to write a script....i know..i know.....it sux..right. this is why i m looking into GPO solution.

In the GPO, there is a section called Restricted Groups. From here, I perform the followings:

Group Name: Administrators
Member of this group: TESTINC\testing123
this group is a member of : TESTINC\Domain Users
&
"Account: Administrator account status" to disable

I configured above setting in a separate template, then create an OU, create a GPO, then import the template.

In my test, after the workstation joined to specific OU, it's pushed with the above GPO. The builtin administrator is disabled, and all others local administrators membership are completely removed. They show blank in membership. and I m able to use testing123 domain user account as a local administrator.

Should I push this setting in the domain level than OU level? Is there any alternative that i can look into?

thanks

takho

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

royal

It depends on several factors.

My second most preferred method is to modify the default domain policy if you are going to be affecting the entire domain. I then use GPMC to back up the policy so even if I ever have to use DCGPOFIX I still have a copy of the policies that had all the changes. This helps logon performance as your systems don't have as many GPOs to check. See the thing is, even though you create a new GPO and most stuff is set to "Not Configured," the system still has to check to see if those specific policies are set to Allow, Deny, or Not Configured. This is why keeping the amount of GPOs created to a minimum is best.

My most preferred method is not to modify the default domain policy at all. Instead, it is to have a root OU. This way, you can modify the root OU to affect your entire infrastructure without having to modify your Default Domain Policy.

Now if you needed your settings to be a little different across different systems (perhaps servers vs client workstations) you could do a few things. Modify the Root OU, then create a new GPO on the servers OU to override what the Root OU has defined. Or your could apply one GPO to the clients OU and the other GPO to the servers OU. This really depends on how your OU structure is designed.

These different administrative needs are the exact reason Microsoft recommends to design your OU/GPO structure based on administrative/policy needs of your organization rather than the physical structure of your organization.

Hope this helps.

sprkymrk

I agree 100% with Royal. I also would use seperate OU's rather than the Default Domain Policy. The reason being that some workstations (developers for example) need a user to be an admin, but only on that workstation and not "all" domain workstations. Same thing goes for servers. I have a HelpDesk domain group that have admin rights on all workstations, but not on the servers. The last oddball group is mobile users. Many times the owner/user on a laptop might need admin rights when he is at another site and needs to load printer drivers or perform administrative tasks for trouble shooting his laptop when a regular support staff person is 1000 miles away.

So in the above example, you would apply the Restricted Group Policy only to the standard workstations OU, and presumably the developers computers, laptops and servers would each be grouped in their respective OU's without the Restricted Group Policy.

bighornsheep

taktsoi wrote:

as you all know, workstations that need to be joined to a domain need administrative privilege. after joining to a domain, i would like to COMPLETELY disable ALL local administrators.

If you add the computer object in AD prior to joining the workstation to the domain, you dont need the domain administrator account.

For disabling the local administrators, you can use "allow logon locally" policy?

sprkymrk

bighornsheep wrote:

taktsoi wrote:

as you all know, workstations that need to be joined to a domain need administrative privilege. after joining to a domain, i would like to COMPLETELY disable ALL local administrators.

If you add the computer object in AD prior to joining the workstation to the domain, you dont need the domain administrator account.

Additionally, standard users have the right to add up to 10 computers to the domain. The only caveat is that they can only be added to the OU in which the user resides.

theseman

sprkymrk wrote:

Additionally, standard users have the right to add up to 10 computers to the domain. The only caveat is that they can only be added to the OU in which the user resides.

I read this somewhere and was a bit confused. When I first read it, to me it said: "Any authenticated user can add a workstation to a domain (up to 10)." But is this only if a computer account is created beforehand in AD, and the computer account is in the same OU as the user?

Travis

SXRXNRR

Heres how I do it;
At root of domain, I set restricted groups for local admins to Domain Admins, ServerAdmins(a specialty group), and techs(yet another).
At each individual site, I set a local site admin as an administrator on all boxes, along with the others, and have Global Site Admins as well, for certain OUS, and so forth. Like everyone said before, it depends on the structure the admin has in mind, but has to be very carefully thought through. Absolutely, positively, NEVER do ANYTHING just to "get through"..do it right the first time, everytime, even if it means a confrontation with the BOSS...you know, the one that has no clue about what you do...the one that wants to be nice and let you have his old external 14.4 baud modem afterwards....to make him feel like he controlled the situation...:0)
Then, I do not remove or change the local administrator account as this is a technicians, and someytimes admins, nightmare. Simply have the machines change the administrator password randomly upon login. You dont even have to know it. If you are worth your weight in floppy disks, you can "erd it" or something of the like, when needed. Say, a corrupt domain account, for whatever reason has ya down.....sniff...sniff.....well if you cant log onto the domain you just created way more downtime then you needed, and lets face it, at that level its a user service your providing. And you can either change the pw, login, remove, and rejoin, do an ops check..............OR..........boot to some magical mystery cd and transfer dox and settings and then reimage....which one you wanna do???? Hmm?
Change the pwords with your login script....simply create some batch scripts that do that, use EXESCRIPT to compile them, then reference either in your image or in your login scripting....done dealio...keep the passwords so large and random YOU cant even remember them...never tell any of your techs...safe as a baby bird in a titanium birdhouse...well....close enough...
I think looking for the "paranoid" setting on everything creates more issues than it solves for the admin, at least it has in my 160 server, 9700 workstation domain...