The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.
Domain Admin Group Level Access
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?
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?
Asked:
Who is Participating?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
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.
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.
My question. the four people only need access to this group for access to servers and network shares (I can get rid of this).You can configure global admins
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?
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.
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
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
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.
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.
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:
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
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:
- Create shares
- Create folders
- 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
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trialIt's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory
From novice to tech pro — start learning today.
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get this solution by purchasing an Individual license!
Start your 7-day free trial.
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.