Introducing StealthAUDIT 11.5! Complete your cloud security puzzle. LEARN MORE
Stealthbits

Identifying Privileged Accounts on Windows Server

Blog >Identifying Privileged Accounts on Windows Server
| Jeff Warren | | 1 Comment

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:

  1. Privileged Group Memberships
  2. Service Accounts
  3. Local Policies

Privileged Groups

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:

  • Administrators: members of this group have full control of the computer
  • Backup Operators: members of this group can access any file on the computer, regardless of the security settings of that file
  • Remote Desktop Users: members of this group can log on to the computer remotely

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:

  • Domain User Accounts – User accounts from Active Directory can be directly nested
  • Domain Group Accounts – Security groups from Active Directory can be nested, granting all of their members the given rights
  • Local User Accounts – Users created locally can be nested within these groups
  • Security Principals – Principals such as NT AUTHORITYAuthenticated Users can be nested within these groups giving membership to large amounts of users

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.

Service Accounts

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

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:

  • Access this computer from the network
  • Allow log on locally
  • Allow log on through Remote Desktop Services
  • Backup files and directories
  • Log on as a batch job
  • Log on as a service

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.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Loading

Featured Asset

Comment

  • 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe

DON’T MISS A POST. SUBSCRIBE TO THE BLOG!


Loading

© 2022 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.

FREE TRIAL