One of the most common tasks frequently carried out by network or systems administrators, not only during deployment but also in the day-to-day management of Windows Server operating systems (OS) and applications that run on them, is to create and manage user accounts.
In Windows Active Directory (AD), a range of different user account types can be set up with the necessary permissions, access, and roles. An important part of these user account types is the service accounts.
In this article, we’ll explain AD service accounts, how to create them in PowerShell, and the best tools for managing AD service accounts. Hopefully, this will help you gain a better understanding of how to effectively use and manage AD service accounts for better security.
What is a Service Account?
A service account is a user account that is created explicitly to run a particular service or application on the Windows operating system. If you create service accounts when installing applications that request them, they usually grant the appropriate rights and security permissions when the accounts are created. This is done following the principle of least privilege, which grants users only the minimum rights and permissions they require.
For example, if a service account is created for backup service it does not require rights to change systems settings. A service account that is created to run the SQL Server service does not require access to execute applications. Following the principle of least privilege, a user account with just the right amount of access is created as a service account. You may often be tempted to use an administrator account for a service account since usually they already have the necessary rights and permissions. But don’t fall for it. The advantage of the service account is that if the user account used for the service was to become compromised, the damage that could be done using that service account is minimized.
To understand a bit better why a service account is required, let’s look at what happens when a service account is not used. When you install applications such as SQL Server, Internet Information Services (IIS), or SharePoint Services on Windows server OS like Windows Server 2012 R2, it is not uncommon for the application to ask for a username and password that will be used to run it. In order to get the application to work, a lot of administrators will simply enter a user account that has domain administrator access. There are a number of problems with this approach.
Firstly, If you use the same user account for a different number of applications, and the user account fails due to one reason or the other, all the applications using that service account would also be affected. Secondly, if the account becomes compromised, this service account could be used to gain access to resources on the network. The more access the service account has the more potential damage that it could do. Thirdly, the service account could prevent applications and services using it from running by simply changing the password of the account.
When the password for a service account is changed, the password must be updated in all locations that use the service account. Otherwise, the old password will still be used and this will prevent the application from running. If all of your essential services are using the same service account and the password is changed, this will cause all the services relying on that service account to stop working, thereby resulting in a denial of service. Although service account passwords are usually configured not to expire; however, the implication is that when you have an account password that doesn’t expire, the password becomes much more vulnerable over time.
Managed Service Accounts
After considering all those challenges, Microsoft introduced Managed Service Accounts (MSA) with Windows Server 2008 R2 to automate the management of service accounts. Using managed service accounts means that the password cannot be locked out or used for interactive login. Instead, the service account will be automatically changed periodically without any intervention from the system administrator. The MSA is bound to one computer and thus cannot be shared among multiple computers, or a computer that it was not designed to work with. This provides additional security. The MSA can be categorized into the following groups:
- Standalone Managed Service Account (sMSA): sMSA is a managed domain account that provides automatic password management, simplified Service Principal Name (SPN) management, and the ability to delegate it to other administrators. The sMSA was introduced in Windows Server 2008 R2 to automatically manage (change) passwords of service accounts. With sMSA, system admins can mitigate the risk of system accounts running system services being compromised. However, one major issue with sMSA is that the usage of such service accounts is restricted to only one computer. This means that sMSA cannot work with cluster or Network Load Balancing services, which operate simultaneously on multiple servers or server farms and use the same account and password.
- Group Managed Service Account (gMSA): To fix issues associated with the sMSA, Microsoft introduced the Group Managed Service Accounts (gMSA) to Windows Server 2012. gMSA provides the same functionality within the domain but also extends that functionality over multiple servers. When a gMSA is used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.
How to Create Service Account in PowerShell
Windows PowerShell is a command-line shell and scripting language built on the .NET Framework to enable system administrators to automate task and configuration management on Windows OS and applications that run on the Windows Server environment. In PowerShell, administrative tasks are generally performed by cmdlets (pronounced command-lets), which are specialized .NET classes that implement specific functions.
In Windows Server 2012, the PowerShell cmdlets default to managing the group MSAs rather than the original standalone MSAs. To create a group Managed Service Accounts (gMSA), follow the steps given below:
Step 1: Create key distribution services (KDS) Root Key.
This is used by the KDS service on the domain controller (DC) to generate passwords. To create the root key, open the PowerShell terminal from the Active Directory PowerShell module and run the following cmdlet:
Add-KDSRootKey -EffectiveTime ((Get-Date).AddHours(-8))
The 8 hours specified above imply that the Active Directory distribution service replication has within that time frame to replicate the changes to other domain controllers. You can use the following code if you’re in a test environment:
You confirm if the key was successfully created by running the following PowerShell command:
Step 2: Create and configure gMSA.
To do this, open the PowerShell terminal and type the following commands:
New-ADServiceAccount –Name gserviceaccount1–DNSHostname DC1.comptech.com –PrincipalsAllowedToRetrieveManagedPassword "gserviceaccount1Group"
From the above command,
- The gserviceaccount1 represents the name of the gMSA account to be created
- The DC1.comptech.com is the DNS server name
- The gserviceaccount1Group is the Active Directory group which includes all systems that have to be used. This group should be created before in the Groups.
To confirm that the account has been created, go to Server Manager >> Tools >> Active Directory Users and Computers >> Managed Service Accounts.
Step 3: Install the MSA on a host computer in the domain, and make the MSA available for use by services on the host computer.
To install gMSA on a computer, open PowerShell terminal and type in the following commands:
Install−ADServiceAccount −Identity gserviceaccount1
To confirm that the installation of the gMSA was successful, run the following command:
If the installation was successful, the result should return “True” after running the command as shown in the screenshot below.
Step 4: Configure a service to use the account as its logon identity.
To do this, follow the steps below:
- Open Server Manager.
- Click Tools >> Services, to open the Services console
- Double-click the service to open the services Properties dialog box
- Click the Log On tab
- Select “This Account”, and then click Browse
- Enter the name of the MSA on the text box, and then click OK to save changes
- On the Log On tab, confirm that the MSA name ends with a dollar ($) sign
- When it states that the new logon name will not take effect until you stop and restart the service, click OK.
The account will be given the “Log On as a Service” and the password will be retrieved automatically. If you move a service to another computer and you want to use the same MSA on the target system, you must first use the Uninstall-ADServiceAccount cmdlet to remove the MSA from the current computer and then use the Install- ADServiceAccount cmdlet on the new computer.
Figure 1.0 Screenshot showing Application Identity Properties settings box
Tools for Managing AD Service Accounts
1. SolarWinds Permissions Analyzer FREE TOOL: One of the common challenges with the Microsoft Active Directory program is that it offers poor permissions management. This is where SolarWinds Permissions Analyzer stands out. SolarWinds Permissions Analyzer enables network admins to gain better visibility into user and group permissions, check permissions assigned on Active Directory objects, browse permissions by a group or user, or analyze user permissions based on group membership and permissions even in multi-domain Active Directory Forest. Some of the key features and capabilities include:
- Identify how a user’s permissions are inherited
- Browse permissions by group or individual user
- Analyze user permissions based on group membership and permissions
Figure 3.0 Screenshot showing SolarWinds Permissions Analyzer interface
Imagine a scenario where a service account with rights and permissions beyond what it requires is hijacked by a malicious actor and suddenly begins to carry out malicious activities from the inside. You observe that this service account has access to all sorts of key company groups, shared network folders, and files; but no one is certain exactly what and how much. This could be a major security issue for your organization, so you need to get to the root of what’s going on quickly. One way to investigate this is to use PowerShell if you have the skill and experience to do it, but the reality is that not everyone does. That’s where SolarWinds Permissions Analyzer comes into play. With this tool, network admins can easily identify which service accounts have excessive access privileges to key company resources.
Most of all, SolarWinds Permissions Analyzer is available for download free of charge.
2. ManageEngine MSA Management: Creating and managing an MSA can be a daunting task for most system admins, especially because it demands a good hands-on knowledge of PowerShell scripting language. Even if you are skilled in PowerShell scripting, it’s not as easy as using a GUI-based tool. This is where the MSA Management tool from ManageEngine comes to the rescue.
Figure 2.0 Screenshot showing service accounts on the Service Account Management tool
ManageEngine MSA Management is a free GUI-based tool designed to simplify the process of managing service accounts. With just a few clicks, network admins can easily create, edit, and delete MSAs without the knowledge of PowerShell. Some of the features and capabilities include:
- Create managed service accounts
- Delete managed service accounts
- Edit information like name, sAMAccountName, and description of an MSA
- Bulk enable managed service accounts
- Bulk disable managed service accounts
- Get a complete list of all MSAs in a domain
The tool also enables network admins to gain insights into the service accounts present in each computer in an Active Directory domain. Some of the reports that can be generated include:
- A list of all computers in the domain
- A report of all service accounts present in each computer
- A report of all services associated with the service accounts
These reports can be fine-tuned using available filters and can be exported as a CSV file. The ManageEngine MSA Management tool can be downloaded as part of the ManageEngine’s Free Active Directory tools.
3. SolarWinds Access Rights Manager (ARM) FREE TRIAL: SolarWinds ARM is designed to assist IT and security administrators in managing and regulating user and service account access rights and permissions to systems and data across domains, which is an important step in protecting the organizations from cyber risks. Its auditing and permissions management capabilities make it easy to analyze user authorizations, access permissions and Group Policy to give you a better visualization of who has access to what, and how and when they accessed it.
Figure 4.0 Screenshot showing SolarWinds ARM dashboard
The custom report generation features allow for the quick creation of a variety of AD reports, from simpler reports for management to more technical and detailed reports appropriate for auditors.
SolarWinds ARM enables network admins to perform the following access rights management activities:
- Permission Analysis: This feature helps admins to define which users or service account have access to which data. Some of the key activities that can be performed include: view permission settings, track access paths, understand nested group permissions, among others.
- User Provisioning: User provisioning helps admins to create and manage user or service accounts and groups.
- Security Monitoring: Security monitoring empowers network admins to leverage logs from across Active Directory, file servers, and other systems and tools to generate reports, alerts, and track key activities.
- Role and Process Optimization: This feature enables network admins to automate the process of determining data owners across business units and departments. Data owners play a key role in determining and defining user access rights and permissions, including service accounts.
4. ManageEngine ADAudit Plus: ADAudit Plus by ManageEngine is an AD auditing tool that allows network admins to audit active directories, login and logoff records, file, and Windows server data, and generate real-time user activity reports. Key AD auditing features include:
- Active Directory auditing
- Windows file server auditing
- NAS device file auditing
- Windows server auditing
- Workstation auditing
- Azure AD auditing
Figure 5.0 Screenshot showing ADAudit Plus dashboard
With this tool, you can keep track of which employees or service accounts did what, when they did it, and how they did it on Windows servers and installed applications. You can get reports on domain controllers and file servers and export the reports to CSV, PDF, XLSX, and HTML formats. Network admins will be able to block or prevent legitimate users from abusing their access privileges. One of the key benefits of this solution is its inherent support for industry-specific regulatory compliance. It is bundled with pre-configured standards compliance reports, which follow the SOX, HIPAA, GLBA, PCI-DSS, and FISMA standards. So, you won’t need to customize the system or set up your own reports in order to demonstrate compliance.
ADAudit Plus is available in three editions: Free, Standard, and Professional. A 30-day free trial and an online demo which includes all features of Professional Edition are all available. Overall, ADAudit Plus’ great dashboard and analytics makes it a powerful tool to gain insights and visibility into your AD environment.
5. Quest Recovery Manager for Active Directory: Human error, hardware, and software crashes do occur. AD objects including service accounts can often be mistakenly modified or even deleted; and faulty scripts can overwrite attributes. This can result in a corrupt Active Directory or Group Policy data, unplanned system downtime.
Figure 6.0 Screenshot showing Quest Recovery Manager for Active Directory interface
Recovery for Active Directory is a third-party AD tool that enables network admins to pinpoint changes to their AD environment at the object and attribute level, and quickly recover entire sections of the directory (both on-premise AD and Azure AD), selected objects, or individual attributes without taking the AD controller offline. Most times, when an object such as a user or service account is lost in Active Directory, you have to restart the Domain Controller to recover it. Recovery Manager for Active Directory eliminates this inconvenience by allowing you to recover objects without going offline.
You can restore objects such as users, service accounts, computers, attributes, configurations, sites, subnets, group policy objects, and organizational units. Some of the key features include:
- Online restore—Restore directory objects without taking the domain controller offline
- Comprehensive recovery options—Restore any object in AD, including users, service accounts, groups, computers, organizational units (OUs), sites, subnets, and Group Policy Objects (GPOs)
- Attribute-level restore—Restore only the required attributes without affecting other attributes
- Schedule of AD—Schedule backups and centrally manage system state backups for domain controllers
The main issue with Recovery Manager for Active Directory is that it comes at a relatively high price. It is therefore most suitable for organizations running multiple AD domain controllers across multiple locations. A free 30-day trial is available.
Active Directory Service Account FAQs
What is a service account in Active Directory?
A service account is a special user account that is created for the sole purpose of running a particular service or application on the Windows operating system. Services use the service accounts to log on and interact with the operating system.
How can I create a service account in Active Directory?
A Service account can be either the traditional service account or managed service accounts (MSA). The traditional service accounts can be created by following the steps below:
- Go to Tools >> Active Directory Users and Computers >> Create a new user.
- Enter a password for the account and check the box for “Password never expires” (This is necessary because, with service accounts, there is no interactive login).
Managed service accounts can be created via PowerShell as described in the section on How to Create Service Account in PowerShell
How can I give permissions to run as a service in Active Directory?
To configure a user account to have ‘logon as a service’ permissions, follow the steps below:
- Logon to your Window server as an administrator
- Click Start >> Control Panel >> Administrative Tools >> Local Security Policy
- Select Local Policies >> User Rights Assignment >> Log on as a service
- Right-click ‘Log on as a service’ and select Properties.
- Click on Add User or Group, and then add the account to the list of accounts that possess the Log on as service permission you desire.