Options
Control of local Administrator rights on member servers
We were having a conversation a couple of days ago between my manager, my peer and myself about our "wild west" scenario of our IT department basically having full control in AD and on all the member servers... something that was put into placed years ago by a Sr. IT official that had no clue what he was doing. Anyway, while we were talking about how pull back the reins and selectively grant non-domain admins elevated rights to servers where it was required, my peer, whose word is always taken for gospel, said the way this typically handled is to do the following:
1. Create one security group in AD for every server in the domain for each security role (Administrators, RD rights, etc).
2. Go to every server and add the groups the respective local security groups.
Has anyone actually seen this method used in an environment with hundreds of servers to manage? Or at all, for that matter? This seems like an overly cumbersome way to manage this problem with nothing to gain compared to the way I have always done it and seen it done in the past:
1. Use restricted groups GPO to ensure your server admins are always members of Local Administrators (broken down by site/OU location if distinct admin roles exist)
2. For groups of servers serving the same role (SharePoint for example), either group them in the same OU and use Restricted Groups GPO to add the required service accounts and application administrators, or add their service accounts/admins to a security group for that role and manually add that group to local Administrators on those servers
3. For better security, use restricted groups GPO to enforce only the accounts specified in the GPO may be members of Administrators, and define an AD group that contains computer accounts that are exceptions to the rule (i.e., can have manual additions to the Administrators group).
The method that was asserted as the "best practice" by my peer, as far as I can tell, offers no security benefits at all, because there is no way to enforce the membership of the local groups; anyone who is given the local administrator access can just add other accounts at will. Also, it adds 1000 groups in AD that I would have to manage.
How do you guys usually handle this?
1. Create one security group in AD for every server in the domain for each security role (Administrators, RD rights, etc).
2. Go to every server and add the groups the respective local security groups.
Has anyone actually seen this method used in an environment with hundreds of servers to manage? Or at all, for that matter? This seems like an overly cumbersome way to manage this problem with nothing to gain compared to the way I have always done it and seen it done in the past:
1. Use restricted groups GPO to ensure your server admins are always members of Local Administrators (broken down by site/OU location if distinct admin roles exist)
2. For groups of servers serving the same role (SharePoint for example), either group them in the same OU and use Restricted Groups GPO to add the required service accounts and application administrators, or add their service accounts/admins to a security group for that role and manually add that group to local Administrators on those servers
3. For better security, use restricted groups GPO to enforce only the accounts specified in the GPO may be members of Administrators, and define an AD group that contains computer accounts that are exceptions to the rule (i.e., can have manual additions to the Administrators group).
The method that was asserted as the "best practice" by my peer, as far as I can tell, offers no security benefits at all, because there is no way to enforce the membership of the local groups; anyone who is given the local administrator access can just add other accounts at will. Also, it adds 1000 groups in AD that I would have to manage.
How do you guys usually handle this?
IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
Comments
-
Options
dave330i
Member Posts: 2,091 ■■■■■■■■■■
Isn't this the same place that had N * 2 server capacity for VMware?
Maybe look for some technet articles involving GPOs & least privilege?2018 Certification Goals: Maybe VMware Sales Cert
"Simplify, then add lightness" -Colin Chapman -
Options
blargoe
Member Posts: 4,174 ■■■■■■■■■□
Yes, same place... I'm almost at a point where I'm going to have to publicly shame people into practicing common sense. I'm gaining credibility, but my peer has been entrenched in his position for years and is content to just cruise along and collect a paycheck for mediocre work that people haven't really noticed is mediocre. So often he is looked to first for advice/guidance, and sometimes that guidance is less than optimal... and by the time I get involved, a decision may have already been made to do something a certain way, based on history, or (lack of) understanding, or being afraid to rock the boat, and I just have to live with it. I'm not used to that. I'm used to being the man. I'm getting better at forcing my way into these conversations though
It is getting better. IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
Options
Zartanasaurus
Member Posts: 2,008 ■■■■■■■■■□
We use restricted groups on a per business group basis. There's a couple different ways to use the restricted groups. One is additive, and one basically wipes everything then applies the policy. Going to each server individually to add groups to admins is silly and archaic. This isn't 1983. Divide the servers up per business group/function in OUs and apply a restricted group policy to each OU. Anytime someone new comes on or a consultant that needs admin rights, you add their user to that group. 10 seconds of admin effort.Currently reading:
IPSec VPN Design 44%
Mastering VMWare vSphere 5 42.8% -
Options
AlexNguyen
Member Posts: 358 ■■■■□□□□□□
Zartanasaurus wrote: »This isn't 1983.
Right. There was no Windows server in 1983. Windows NT 3.1 was introduced ten years later.Knowledge has no value if it is not shared.
Knowledge can cure ignorance, but intelligence cannot cure stupidity. -
Optionsblargoe
Member Posts: 4,174 ■■■■■■■■■□
So we're all in agreement that creating a handful of groups for each of 200-300 servers in AD for the purpose of managing admin rights is not only not a best practice, but just absurd? Can anyone give me an argument FOR doing it that way? This guy usually gets the benefit of the doubt, and since all the managers are Unix or Oracle guys, he's used to not being questioned until things break. I've never seen it done this way and for the life of me, can't see why anyone would think it's a good solution.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
OptionsZartanasaurus
Member Posts: 2,008 ■■■■■■■■■□
"We've always done it this way".Currently reading:
IPSec VPN Design 44%
Mastering VMWare vSphere 5 42.8% -
Optionsdave330i
Member Posts: 2,091 ■■■■■■■■■■
Can anyone give me an argument FOR doing it that way?
"Don't know how to use GPO."
"Because it takes more time & I get paid by the hour."2018 Certification Goals: Maybe VMware Sales Cert
"Simplify, then add lightness" -Colin Chapman
