Manage Learn to apply best practices and optimize your operations.

Managed service accounts tighten Windows Server security

When a Windows Server application uses a service account, it can make an organization vulnerable. Admins can switch to managed service accounts to boost Windows Server security.

Organizations open themselves to risk when they use service accounts to run certain Windows Server applications....

With a little effort, administrators can switch to managed service accounts to reduce their exposure to any vulnerabilities.

For a Windows Server application to run, it needs a security context to grant the required permissions. Generally, those permissions come through a service account. In many cases, a service account is just a user account that IT creates solely to grant these authorizations. But service accounts do not have the same security controls as user accounts, which can lead to problems. For example, service accounts do not typically require password changes because expired passwords can prevent applications from running.

Organizations that use a standard user account as a service account to run Windows Server applications create security risks because the service accounts get special permissions, almost never receive password changes and are sometimes easy to exploit. Administrators can switch to managed service accounts to remove that vulnerability.

User accounts are not the only type of Active Directory object to have an associated password; security credentials can be associated with computer accounts. Administrators don't usually have to manage computer account credentials, because Windows handles the process automatically. Managed service accounts are similar to computer accounts because the operating system manages them. In fact, Windows Server links these managed service accounts to a computer account.

Use PowerShell to create managed service accounts

To create a managed service account, open PowerShell and import the Active Directory module with the command:

Import-Module ActiveDirectory

If an error appears, check that the server has the Active Directory Domain Services role installed. Figure 1 shows how to use the Get-WindowsFeature cmdlet to see a list of the installed roles and features.

Get-WindowsFeature PowerShell cmdlet
Figure 1. If the Active Directory module will not install, use the Get-WindowsFeature PowerShell cmdlet to see a list of the installed roles and features.

Next, create a Key Distribution Service (KDS) root key -- which Active Directory uses to manage the service account -- with this command:

Add-KdsRootKey -EffectiveImmediately

Despite the EffectiveImmediately parameter, the new KDS root key is not immediately available for use. Windows mandates a 10-hour wait period to give the domain controllers time to replicate, which prevents password generation from occurring prematurely. To skip the 10-hour wait -- not recommended for production environments -- use this command:

Add-KdsRootKey -EffectiveTime((Get-Date).AddHours(-10))

Create the managed service account

To create the new managed service account, pick a name to associate with it. For the purposes of this article, use ServiceAct as an account name. The syntax for the command to create a managed service account is:

New-ADServiceAccount -Name <service account name> -DNSHostName <DNS Host Name> -Enabled $True

As noted in the syntax, administrators must enable the service account to use it; administrators can use the same syntax to disable the service account. Administrators on Windows Server 2008 R2 should be aware the syntax and the other commands to create managed service accounts in this article are significantly different. See Microsoft's documentation on that operating system at this link.

The command and syntax to create a managed service account named ServiceAct is:

New-ADServiceAccount -Name ServiceAct -DNSHostName ServiceAct.poseydemo.com -Enabled $True

Create managed service account
Figure 2. Use the New-ADServiceAccount to create a managed service account named ServiceAct.

To verify the system created the account, use this command:

Get-ADServiceAccount -Filter *

Connect the managed service account to a computer account

Associate the service account with a computer account. This demonstration associates the managed service account with a computer named Client.PoseyDemo.com. The command is:

Set-ADServiceAccount -Identity <managed service account name> -PrincipalsAllowedToRetrieveManagedPassword <name of server that will use the service account>

Administrators can display the names of the computers in the Active Directory domain with this command:

Get-ADComputer -Filter 'ObjectClass -eq "Computer"' | Select -Expand DNSHostName

Next, link the ServiceAct account to the computer named Client:

Set-ADServiceAccount -Identity ServiceAct -PrincipalsAllowedToRetrieveManagedPassword Client$

Append a dollar sign to the computer name to indicate to Active Directory that Client refers to a computer account.

Managed service account link
Figure 3. Administrators must link the managed service account to a computer account.

Add the computer to the domain

Next, install the managed service account onto the computer where it will be used. The computer must be domain joined and needs the Active Directory Domain Services server role installed. Log in to the computer, open PowerShell and import the Active Directory module with this command:

Import-Module ActiveDirectory

Next, install the service account with this command:

Install-ADServiceAccount -<service account name>

Finally, to see information about the managed service account, use this command:

Get-ADServiceAccount

Installing the managed service account.
Figure 4. Administrators must install the managed service account onto the computer where it will be used.

How to use managed service accounts

The managed service account is now installed on a computer on the network. When specifying a username, enter the username in domain\account format. Be sure to include a dollar sign at the end of the service account name. The password field can be left blank, because Windows manages the account's internal password on the administrator's behalf.

Next Steps

Five ways to lock down Windows Server

Adjust the local security policy for better protection

How well do you know Azure and Windows security?

This was last published in February 2017

Dig Deeper on Windows Server and Network Security

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What threats to Windows Server security do administrators commonly overlook?
Cancel

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close