Recently there has been a lot of interest around controlling privileged accounts within an organization. Many customers are rolling out Privileged Identity Management solutions such as password vaults in order to manage their privileged accounts across servers, workstations, databases and applications. One of the first things you need to do to control your privileged accounts is to assess your current environment to see where privileged access has been granted and where the most risk exists.
In this post I wanted to cover three simple ways you can assess privileged access to your Windows Servers by looking into:
Every Windows Server comes with default local groups that are used to grant access to perform various tasks to the server. Many of these groups are intended to give highly privileged rights. Three of the most important groups to monitor include:
For a complete list of these groups and their permissions you can visit this TechNet article https://technet.microsoft.com/en-us/library/cc771990.aspx.
When you look at the membership of these groups there are four different principal types that may appear:
Just by inspecting the memberships of these groups you may begin to find security issues with the way things are set up. Typically you would like to keep domain user accounts out of these groups directly and provision all access through domain security groups. Any domain user accounts that are there should have expiring passwords and account lockout policies. Also there is rarely a need to have security principals nested within these groups such as Authenticated Users. Cleaning up these local groups is a big step towards controlling privileged access.
To secure a Windows server you should also pay close attention to the service accounts being used on the machine. A service account is used to run Windows Services. These services are often required to run applications. For example, Microsoft SharePoint and Microsoft SQL Server each use a variety of services to operate. These accounts often have elevated rights to the systems on which they are applied. Many times these accounts are domain accounts which mean they have rights to authenticate to other systems.
Because service accounts are used to run applications and perform other important tasks, many times they will have passwords that never expire. In many cases, they also will have very lax or no account lockout limitations for bad password attempts. Nobody wants to explain that a critical application broke because a password expired or the account got locked out. This makes these accounts an easy target for anybody trying to hijack a domain account.
Be sure to inventory all service accounts that are running as domain accounts and investigate the password expiration policy, the password age and the lockout policy for that account.
Local Security Policies provide another way to control privileged access on a Windows Server. To view these policies you can use the Local Security Policy management interface which is an Administrative Tool. Some of the most important policies reside under the User Rights Assignment section which is nested beneath the Local Policies section. Typically these policies are managed centrally through Active Directory Group Policies. Nevertheless, it is important to understand what the settings are locally on each server.
Some of the important settings to check for privileged access include:
For a full list of these policies and specifics on what rights they grant you can visit TechNet here: https://technet.microsoft.com/en-us/library/dd349804(v=ws.10).aspx.
These are just a few of the basics to check on a system. There are more areas to explore to ensure a system is locked down properly. To learn more about securing privileged access to your servers and desktops Stealthbits offers free trial downloads to scan and identify vulnerable areas of your servers.
Click here for a free trial of our Local Administrator Assessment Tool!
Learn about how Stealthbits addresses Windows security with StealthAUDIT for Windows.
Jeff Warren is Stealthbits’ General Manager of Products. Jeff has held multiple roles within the Technical Product Management group since joining the organization in 2010, initially building Stealthbits’ SharePoint management offerings before shifting focus to the organization’s Data Access Governance solution portfolio as a whole. Before joining Stealthbits – now part of Netwrix, Jeff was a Software Engineer at Wall Street Network, a solutions provider specializing in GIS software and custom SharePoint development.
With deep knowledge and experience in technology, product and project management, Jeff and his teams are responsible for designing and delivering Stealthbits’ high quality, innovative solutions.
Jeff holds a Bachelor of Science degree in Information Systems from the University of Delaware.
Proper data security begins with a strong foundation. Find out what you're standing on with a free deep-dive into the security of your Structured and Unstructured Data, Active Directory, and Windows infrastructure.
Read more© 2022 Stealthbits Technologies, Inc.
It’s worth mentioning the ‘Replicate Directory Changes’ and ‘Replicate Directory Changes ALL’ privileges. Especially given that some Sharepoint installs seem to request both, even though they only actually use ‘Replicate Directory Changes’. This gives the associated service account the rights to dump all password hashes from the domain.