Domain Admin Group Level Access

tbs_mnp
tbs_mnp used Ask the Experts™
on
Domain Admin Group. As of now we have four actual people in the domain admin security group, the administrator account and then a handful of service accounts that primarily read AD...example a C# program logs in using windows credentials but uses the service account to authenticate with AD, another example is using service accounts to run services on specific servers.

My question. the four people only need access to this group for access to servers  and network shares (I can get rid of this).
Administrator account of course has to stay.

This leaves my service accounts, whats the best way to go about removing these accounts from domain admin group while still allowing them permission to run the actions they run?
is it through group policy or local server access?

Looking for how we can minimize risk, also curious- how you treat your domain administrator account password? We have it pretty much limited to only access servers from a login standpoint, but who has access to this password, what do you guys use it for if anything?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Darrell PorterEnterprise Business Process Architect

Commented:
I would first begin by reviewing what permissions are required to perform the functions needed by your scripts.
To enumerate objects in AD, one (normally) merely needs to be a member of Domain Users and certainly not Domain Admins.  The service account may need to be granted the "Run As A Service" permission on the server it runs on.  You could create a group, Domain Service Accounts, and create a group policy to allow this group to run as a service on all servers, but this opens up (probably) far more access than is needed.
Also, ensure you document everything you find and everything you do so that, should you need to change something 6 months from now, you don't have to go on the great trek of discovery again.

Author

Commented:
yes good point. im going to narrow down what the service accounts are doing. I think I should be able to clean up most of whats in the domain admin group..

whats your opinion or experience on logging into a server NOT as the domain admin account or a local administrator. would power user suffice? ive been feeling unsure about logging into the servers as domain administrator account lately.
Shaun VermaakTechnical Specialist
Awarded 2017
Distinguished Expert 2018

Commented:
My question. the four people only need access to this group for access to servers  and network shares (I can get rid of this).

This leaves my service accounts, whats the best way to go about removing these accounts from domain admin group while still allowing them permission to run the actions they run?
You can configure global admins
https://www.experts-exchange.com/articles/29596/Securing-Active-Directory-Administrators-Groups.html

I have never found a service account that cannot function without DA rights, even when the vendor claims so.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Mike TLeading Engineer

Commented:
Hi,

First I would point you to read the MS Best Practise documentation here: http://aka.ms/bpsad.

Microsoft have realised, after years of people logging into laptops as domain admins, to surf, read phishing emails and "help" remoting onto other laptops that none of those behaviours are good. Worse, it's become habit so many IT staff do not know any better, partly because MS haven't explained.

I've made a point of reading up and educating myself and found the following:

1) Domain Admins (and Enterprise Admins and a few others) are solely meant for occasional or rare use, in emergencies. They are "break glass accounts": i.e. only for using for emergency situations, for a limited time.
2) The above accounts are privileged accounts. Privileged accounts are not normal accounts and behave differently and the OS protects them with specific engineering.
3) Domain Admins are meant for one thing: making changes to domain controllers.
4) Domain Admins are meant to only logon from a secure admin server or workstation to make those changes to the DC. Ideally, never logon directly to your DC.

There's a long PDF from MS here:
https://www.microsoft.com/en-us/download/confirmation.aspx?id=38815

From MS
DAs are all-powerful within their domains, while EAs have forest-wide privilege. In a properly designed and implemented delegation model, DA membership should be required only in "break glass" scenarios, which are situations in which an account with high levels of privilege on every computer in the domain is needed, or when certain domain wide changes must be made.

https://docs.microsoft.com/en-gb/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b--privileged-accounts-and-groups-in-active-directory

https://activedirectorypro.com/active-directory-security-best-practices/
https://blogs.msmvps.com/richardsiddaway/2016/09/14/how-many-domain-admins-do-you-need/ : (Richard Siddaway is a PowerShell author & MVP but writes on security too)
https://www.csoonline.com/article/2627737/authentication/how-many-enterprise-admins-is-too-many-.html?page=2 (second paragraph) (Roger Grimes is a leading security consultant).

Your Environment
we have four actual people in the domain admin security group,
Remove 3, leaving the most trusted person in

the administrator account
Fine :)

handful of service accounts that primarily read AD...
Remove them ALL

For pure authentication you only need AD read permissions. Any standard user account will do. However, if you are using 2012R2 then I highly recommend using Group Managed Service Accounts. They provide a "set it and forget it" way to create an account with a password that the OS manages.
In the event one of the apps using a service does not work, go to the vendor's website and check. My favourite bogey man is BMC agents that get service accounts with passwords that never expire and worse, get Domain Admin. If you check BMC, it only needs a few specific permissions. Quite often services do NOT even need logon permissions.

Q: My question. the four people only need access to this group for access to servers  and network shares (I can get rid of this).
A: No, they don't. Really. They need a logon account and maybe a few other limited permissions. You don't need Domain Admin to RDP to servers. You don't need Domain Admin to use SCCM or indeed BMC Patrol either. The most I would go to is local admin, but even that I would limit if possible.

I will end with another link by Orin Thomas;
https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-New-Zealand-2015/M321
It's old but good. The very first point covers service accounts. The first 10 points are most relevant to everything in your question, but if you have the time watch them all. It is quite entertaining.

Finally, with regards policies, it is worth doing two things:

1) set harder passwords for the privileged accounts - 25 minimum length, stronger lockout than normal. Note this is a separate password policy to every other user account.
2) Deny logon to workstations and standard servers to Domain Admins!

The two things will block people from doing things and stop pass-the-hash dead and make your business safer.
I do realise this is both alien and potentially time consuming but the IT world is getting more threats as time goes by. Doing the above will help attackers choose someone else!

Mike

Author

Commented:
thanks. ive gotten all service accounts besides one out of the domain admin group. my last thing.
whats your opinion or experience on logging into a server NOT as the domain admin account or a local administrator. would power user suffice? ive been feeling unsure about logging into the servers as domain administrator account lately.
Leading Engineer
Commented:
Hi,

I seriously advise you to get that last service out of Domain Admins. There is no sensible reason for it to have that much power. Talk to the vendor if you have to.

As I mentioned above, I try to avoid logging in as domain admin on servers. The main stumbling block I've met is that "Remoting" (RDP) tends to be granted to Domain Admins simply to get onto the server. This is also a "no-no" from security point of view. Any user (or group) can belong to RDP, so step 1 - swap out Domain Admins with another Group (Server admins) .
To do admin on a server you need to:

  1. Create shares
  2. Create folders
  3. Interact with an app

Server tools I have to use each have a console that you can install on a workstation or other "admin" server, so I don't have any need to remote onto the real server.
There is never any excuse to login as Domain Admin, unless something catastrophic has happened. It is only intended to 1) create a new domain, 2) repair a domain 3) merge domains.
It is NOT meant for creating shares, users, OUs or admin of mailboxes.

Local admin rights on servers is more reasonable but even then ought to be rare. It depends if file system/OS changes are required.  

From MS
"Use of a domain's Administrator account must be reserved only for initial build activities, and possibly, disaster-recovery scenarios.

To ensure that an Administrator account can be used for repairs (in the event that no other accounts can be used), do not change the default membership of the Administrator account in any domain in the forest. Instead, you should secure the Administrator account in each domain in the forest as described in the following section and detailed in the step-by-step instructions that follow. "


Ref:
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
http://aka.ms/bpsad

It's a lot of reading but contains valid, key steps to follow to secure the business.

RDP
I only read recently that RDP was never meant as a daily admin tool! Thus, I know this is a mind-shift to standard habits, and I have the same conversations with teams at work. RDP is/was only meant as an emergency tool. Administering servers is meant to be achieved through remote tools - RSAT and PowerShell. Use a dedicated admin workstation, install RSAT on it, enable PowerShell remoting and do the work logged on as a normal user, with permissions added on a needs basis.

The clue to RDP not being appropriate is it only having 2 licenses to connect. MS know you might have hundreds or thousands of servers, so why did MS only permit two connections?
I can't find any MS reference to this design but it's their whole principle: Both Server 2012 and nano server have no GUI so RDP is impossible

The threat of RDP is getting worse too: https://www.cso.com.au/article/647430/fbi-rdp-attacks-still-rise/


This whole exercise is not something you can do overnight. It will take time, but the end result is a far more secure, managed environment, with less threats, less mistakes and less digital mess.

Mike

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial