Denying Log On Locally to doman admin but allow runas

[colly72]

As part of our security review, I'm trying to get to where our domain admin accounts are blocked to Log On Locally but can still be used for elevation/runas admin.

 

Is there a way to achieve this in Group Policy or should I be looking to secure by using a different method?

[PotNoodleTech]

On PCs? If so deny DA completely via GPO and create a separate PC elevation account that is added to the local administrators group on all the PCs via GPO which you can use for the daily stuff.

 

That way your not using DA accounts for the daily stuff.

 

I've done the same thing on servers too - a separate server elevation account that is a local admin on just the servers, can be used to do general stuff on all the servers without being a DA.

[free780]

You can use runas /netonly to do this. Ideally you shouldn’t need to. Microsoft recommend you do not remove domain admins from local administrators which would seem logical.

[colly72]

On PCs? If so deny DA completely via GPO and create a separate PC elevation account that is added to the local administrators group on all the PCs via GPO which you can use for the daily stuff.

 

That way your not using DA accounts for the daily stuff.

 

I've done the same thing on servers too - a separate server elevation account that is a local admin on just the servers, can be used to do general stuff on all the servers without being a DA.

 

Yeah, we have separate elevation accounts already but denying them the log on locally right on PCs stops them from being used when runas administrator is attempted. I guess I'm missing the bit that requires us to add them as a local admin.....

[colly72]

Yeah, we have separate elevation accounts already but denying them the log on locally right on PCs stops them from being used when runas administrator is attempted. I guess I'm missing the bit that requires us to add them as a local admin.....

 

Scrap that, my elevated admin account is in the local administrator group (its a domain admin) but as soon as I deny access to logging on locally, I can't use it as an elevated account

[Rob_D]

What about using LAPS and elevating using the built in local admin for elevation?

[colly72]

What about using LAPS and elevating using the built in local admin for elevation?

 

Good idea but that's hugely painful, assuming you can get in to ADUC in the first place to obtain the password (without being asked for elevated permissions), then requires writing down the password and manually typing it in (pasting the password is not allowed).

[psydii]

Gpo that adds the group sec_%computername%_admin to the local administrator group.

 

Give each techie a ladminUserName account. These user accounts should by default be a member of Domain Users and Protected Users only.

 

When a techie needs admin on a local

Machine, add them to the sec_ %computername%_admin group for that machine.

 

If the machine is broken and can’t/can’t be connected to get line of site to the DC, it’s a wash, wipe it and start again.

[colly72]

Gpo that adds the group sec_%computername%_admin to the local administrator group.

 

Give each techie a ladminUserName account. These user accounts should by default be a member of Domain Users and Protected Users only.

 

When a techie needs admin on a local

Machine, add them to the sec_ %computername%_admin group for that machine.

 

If the machine is broken and can’t/can’t be connected to get line of site to the DC, it’s a wash, wipe it and start again.

 

Adding a non domain admin account to the local administrator group doesn't allow running things like ADUC, Hyper-V Manager, DNS, DHCP etc, with admin privileges as far as I can tell, which is what I am looking for.

[PotNoodleTech]

Adding a non domain admin account to the local administrator group doesn't allow running things like ADUC, Hyper-V Manager, DNS, DHCP etc, with admin privileges as far as I can tell, which is what I am looking for.

 

Ah I get you. We don't allow access of those tasks on normal workstations or servers out in the wild.

 

We use a separate privileged admin workstation (virtual server) and a separate DA account for each member of staff that needs ad/dns/dhcp etc

[altecsole]

We use a separate privileged admin workstation (virtual server) and a separate DA account for each member of staff that needs ad/dns/dhcp etc

 

This.

 

Also, if you can, restrict Internet access for the DA accounts.

[psydii]

Adding a non domain admin account to the local administrator group doesn't allow running things like ADUC, Hyper-V Manager, DNS, DHCP etc, with admin privileges as far as I can tell, which is what I am looking for.

Ah gotcha. A privileged workstation is one way you could go - but that might not be much of a boundary if you rdp into the system. The device you RDP from is still a potential vector for privilege escalation.

 

Mind you, DA isn't actually necessary for any of the tools you listed.

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups

 

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/delegating-administration-by-using-ou-objects (make sure that the service admin groups are out of scope, otherwise you've just re-introduced the privilege escalation path!)

 

https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-hyper-v-security-in-windows-server

 

Of course with a bit of work an attacker with DNS Admin (or DHCP admin) could set up MITM or auth downgrade attacks, but if you use a Just-In-Time privilege model (similar to the one for local admins described above) your accounts only have access to the services while you need them to, minimizing the risks of credential theft.

[Rob_D]

Ah gotcha. A privileged workstation is one way you could go - but that might not be much of a boundary if you rdp into the system. The device you RDP from is still a potential vector for privilege escalation.

 

That's where using a browse-down model can help. You log in to your admin PC first and then "browse" (rdp) into your daily driver.

https://www.ncsc.gov.uk/whitepaper/security-architecture-anti-patterns#section_3

[PotNoodleTech]

That's where using a browse-down model can help. You log in to your admin PC first and then "browse" (rdp) into your daily driver.

https://www.ncsc.gov.uk/whitepaper/security-architecture-anti-patterns#section_3

 

Hmm! That's an interesting idea!

[colly72]

Ah I get you. We don't allow access of those tasks on normal workstations or servers out in the wild.

 

We use a separate privileged admin workstation (virtual server) and a separate DA account for each member of staff that needs ad/dns/dhcp etc

 

Thanks for this, it sounds like this is the best way forwards. The more I'm reading up on a PAW solution, the more complicated it gets. As a school we have limited budget and resources, so it's interesting to see how much others invested in a PAW solution and what is a reasonable solution that provides us with appropriate security, without over-complicating our system. Any input on how others have implemented this and how far into it they have got would be greatly received.

[jthompson]

I found this list really helpful when rebuilding our domain a few years ago. The first 6 items in the list are relevant here (although the info about LAPS is now out of date as there's a newer, more built-in implementation of it).

 

https://activedirectorypro.com/active-directory-security-best-practices/#limit-domain-admins

 

"domain admin" privileges should only be in play once in a blue moon, for things like promoting or demoting a domain controller. For day-to-day admin stuff like using ADUC, DHCP and Hyper-V consoles, you should be able to not actually need your account to have domain admin privileges.

 

The browse-down model mentioned earlier is interesting, but how well does that fit with wanting/needing access to admin tools when away from your desk or offsite?

[PotNoodleTech]

Thanks for this, it sounds like this is the best way forwards. The more I'm reading up on a PAW solution, the more complicated it gets. As a school we have limited budget and resources, so it's interesting to see how much others invested in a PAW solution and what is a reasonable solution that provides us with appropriate security, without over-complicating our system. Any input on how others have implemented this and how far into it they have got would be greatly received.

 

Well by the look of some of the other posts even what I am doing is not right / not the best :S (not using domain admins at all is a good call, the browse-down model looks superior too).

 

If you have a virtual server infrastructure, then leverage that. My PAWS VM's are literally super basic - 2 vcpu 2-4gb ram variable and 100gb HDD space.

 

If you don't have virtual servers it is going to be more difficult, you could compromise by using an old server or decent spec PC in your office and just use that with a separate domain admin account for managing active directory etc stuff.