Home > Sample chapters

Improving the Security of Authentication in an AD DS Domain

Lesson 4: Managing Service Accounts

Services, like users, must log on. A service is configured with a user name and password of an account with which it logs on. The rights, permissions, and privileges assigned to the account allow the service to access the resources it requires. Because service account credentials are registered in the Service Control Manager (SCM) of a machine on which a service runs, managing and securing service accounts often requires that you make changes not only to Active Directory, but to the SCM of one or more machines as well.

In Lesson 1, you learned to use fine-grained password policies to configure password requirements for service accounts. Windows Server 2008 R2 introduces a new feature, managed service accounts, which reduces the burden of password management for service accounts.

Understanding Managed Accounts

Services require access to resources, so they need rights, permissions, and privileges—at a minimum, the right to log on to a system. To be assigned access, a service must have an account—an identity with a user name and password—with which a system can authenticate the service when the service starts. The service is assigned the account in the SCM, which you manage by using the Services console in the Administrative Tools folder or one of several other tools, including the Sc.exe command and Windows PowerShell.

When a service runs on a single computer, an administrator can configure the service to run as Local Service, Network Service, or Local System. These three accounts are built in to Windows. They are simple to configure and use, but they are typically shared among multiple services and cannot be managed on a domain level.

You can centralize the management of service accounts by creating a domain account. After you create a domain account for a service, you can assign the account to the service on more than one system. For example, an enterprise backup service can be configured to run on multiple servers under a single domain account. You can create a unique account for each service to isolate the privileges for the services.

However, when you need to change the password of a domain service account, you must update the SCM on each computer on which the service is assigned the account. This management burden has led too many organizations to configure service accounts with non-expiring passwords, which is certainly not a security best practice. Other organizations have built or acquired custom scripts or tools to manage service account passwords in the enterprise.

Windows Server 2008 R2 reduces the management burden of service accounts with a new object class—the managed service account. The managed service account is a domain account that is associated with a service on a single computer, and one or more services on that computer can use the managed service account as a logon identity. The computer automatically changes the password of each managed service account on the computer, every 30 days by default.

Another burden associated with service accounts is the management of service principal names (SPNs). SPNs are a critical component of Kerberos authentication. Managed service accounts ensure that if the name of a computer is changed, SPNs associated with services running on the computer are changed in the domain. In addition, SPN management can be delegated to other administrators.

Requirements for Managed Service Accounts

Managed service accounts require minimal changes to your domain. You must prepare your schema for managed service accounts. Run adprep /forestprep at the forest level, and then run adprep /domainprep in each domain where you want to use managed service accounts. For more information about ADPrep, see Chapter 10 and visit http://technet.microsoft.com/en-us/library/cc731728(WS.10).aspx.

You use Windows PowerShell to administer managed service accounts. Therefore, at least one domain controller must support administration of Active Directory with Windows PowerShell by running one of the following:

  • Windows Server 2008 R2

  • Windows Server 2008 with the Active Directory Management Gateway Service

  • Windows Server 2003 R2 with the Active Directory Management Gateway Service

  • Windows Server 2003 with the Active Directory Management Gateway Service

Other domain controllers can be running Windows Server 2003 or later. If the domain functional level is Windows Server 2008 R2, you can take advantage of automatic password management of managed service accounts and simplified SPN management. If the domain functional level is lower than Windows Server 2008 R2, automatic password management of managed service accounts is available, but SPNs must be managed manually.

To create and configure managed accounts in Active Directory, you must use Windows PowerShell on a computer running Windows 7 or Windows Server 2008 R2. In other words, your administrative workstation must be running Windows 7 or Windows Server 2008 R2. You must ensure that the Active Directory Module For Windows PowerShell is installed on the computer. You can install the feature by using the Add Features link in Server Manager if the computer is running Windows Server 2008 R2, or the Turn Windows Features On Or Off link in Control Panel if the computer is running Windows 7. In Remote Server Administration Tools, Role Administration Tools, AD DS And AD LDS Tools group, you will find the Active Directory Module For Windows PowerShell feature.

Finally, each computer that uses a managed account—any computer on which services are associated with managed accounts—must be running Windows Server 2008 R2 or Windows 7 and must have the Active Directory Module For Windows PowerShell installed. Earlier versions of Windows cannot assign a managed account to a service.

Creating and Configuring a Managed Service Account

To create and configure managed service accounts in the domain, you use Windows PowerShell cmdlets. There is no UI support for correctly creating and configuring managed service accounts. The New-ADServiceAccount cmdlet creates a managed service account.

The following example creates a managed service account:

New-ADServiceAccount SRV_APP01 -Enabled $true -Path "CN=Managed Service Accounts,
   DC=contoso,DC=com"

The -Path parameter specifies the Managed Service Accounts container—a new container in Active Directory. You can specify a custom container or OU. You can also use the -ServicePrincipalNames parameter to specify SPNs for the account.

The sAMAccountName attribute of the managed service account is the name specified by the New-ADServiceAccount cmdlet, followed by a dollar sign ($). For example, the sAMAccountName of the managed service account created in the preceding example is SRV_APP01$.

To configure properties of the account, you can use the Set-ADServiceAccount cmdlet or the Attribute Editor tab of the Active Directory Users And Computers snap-in. The Get-ADServiceAccount cmdlet returns an object reference to a managed service account. To delete a managed service account, use the Remove-ADServiceAccount cmdlet.

Installing and Using a Managed Service Account

The Install-ADServiceAccount cmdlet installs the managed service account on a computer so that you can assign the account to one or more services on the computer. For example, the following command installs the managed service account named SRV_APP01 on the local computer:

Install-ADServiceAccount -Identity SRV_APP01

After you have installed the managed service account, you can configure a service to use the account as its logon identity. In the Services console, open the properties of a service and click the Log On tab. Select This Account, then click Browse. Type the name of the managed service account, and then click OK. On the Log On tab, confirm that the name appears with a dollar sign ($). The account will be given the Log On As Service right (SeServiceLogonRight).

If you move a service to another computer and you want to use the same managed service account on the target system, you must first use the Uninstall-ADServiceAccount cmdlet to remove the managed service account from the current computer. Then repeat the same procedures described in the previous example on the target computer: Use the Install-ADServiceAccount cmdlet and then configure the service to use the managed service account.

You must be a local administrator on the computer to install a managed service account and configure the logon identity of a service. You must also have rights to modify the managed service account in Active Directory to install or uninstall a managed service account on a computer.

Managing Delegation and Passwords

You can delegate permissions to configure a managed service account in Active Directory. There is no cmdlet in Windows PowerShell to do so. You must use the DSACLs command, which was introduced in Chapter 2, “Administering Active Directory Domain Services.” The following command delegates to the user named ServiceAdmin the permissions needed to manage a service account named SRV_APP01.

dsacls "CN=SRV_APP01,CN=Managed Service Accounts,DC=contoso,DC=com"
   /G "CONTOSO\ServiceAdmin:SDRCLCRPLOCA" "CONTOSO\ServiceAdmin:WP;Logon Information"
   "CONTOSO\ServiceAdmin:WP;Description" "CONTOSO\ServiceAdmin:WP;DisplayName"
   "CONTOSO\ServiceAdmin:WP;Account Restrictions"
   "CONTOSO\ServiceAdmin:WS;Validated write to DNS host name"
   "CONTOSO\ServiceAdmin:WS;Validated write to service principal name"

A managed service account is a unique object class, msDS-ManagedServiceAccount, that inherits from the computer object class. Managed service accounts, like computers, do not observe domain or fine-grained password policies. Instead, like computers, a managed service account establishes a complex, cryptographically random, 240-character password and changes that password when the computer changes its password—every 30 days by default. A managed service account cannot be locked out and cannot perform interactive logons.

Under normal circumstances, you will not need to worry about changing the password of a managed service account; however, there may be scenarios in which you want to force a reset of the password. You can use the Reset-ADServiceAccountPassword cmdlet to do so.

Limitations of Managed Service Accounts

Managed service accounts are an important new feature of Windows Server 2008 R2, but here are some important restrictions and caveats related to their use:

  • A component must support managed service accounts. Generally speaking, services that you add to a computer, and that are listed in the Services console, can be configured to use a managed service account, as can IIS application pools. You cannot use managed service accounts for identities of applications or non-Windows services. Furthermore, a component must support managed service accounts, and not all services do. For example, Microsoft SQL Server does not support managed service accounts, despite vague and contradictory information in some online resources including Microsoft TechNet. This notable exception is true for versions of SQL Server up to SQL Server 2008 R2. This limitation might be removed in future versions of SQL Server.

  • Each managed service account can be used on only one computer. Services on multiple computers cannot use a single managed service account. Therefore, you cannot use managed service accounts for load balanced and clustered services. For example, you should not use managed service accounts as identities for Microsoft SharePoint Server, because a SharePoint farm can be more than one computer. Similarly, a managed service account cannot be used for a service in a cluster, because a cluster contains more than one computer.

  • A computer can have more than one managed service account. For example, if you have five services running on a computer, those five services can share a single managed service account or can use five separate managed service accounts.

PRACTICE: Managing Service Accounts

In this practice, you create a managed service account for an IIS application pool.

EXERCISE 1 Add the Internet Information Services Role

In this exercise, you add the Internet Information Services (IIS) role and verify that the default website is created.

  1. Log on to SERVER01 as Administrator.

  2. Open Server Manager.

  3. In the Roles Summary section, click Add Roles.

    You might need to scroll down to see the Roles Summary section.

  4. In the Add Roles Wizard, on the Before You Begin page, click Next.

  5. On the Select Server Roles page, select the Web Server (IIS) check box, and then click Next.

  6. On the Web Server (IIS) page, click Next.

  7. On the Select Role Services page, click Next.

  8. On the Confirm Installation Selections page, click Install.

    The Web Server (IIS) role and its default services are installed.

  9. On the Installation Results page, click Close.

  10. Open Internet Explorer.

    If the Set Up Windows Internet Explorer 8 dialog box opens, click Next. On the Turn On Suggested Sites page, click No, Don’t Turn On, and then click Next. On the Choose Your Settings page, click Use Express Settings, and then click Finish.

  11. Browse to http://server01.contoso.com.

    The IIS7 page opens. This is the default page of the default web application that is created when you install IIS. Leave Internet Explorer running.

EXERCISE 2 Create a Managed Service Account

In this exercise, you create a managed service account.

  1. Open the Active Directory Users And Computers snap-in. Click the View menu and ensure that the Advanced Features option is selected.

  2. Expand contoso.com and click the Managed Service Accounts OU. Note that the OU is currently empty.

  3. Open Active Directory Module For Windows PowerShell from the Administrative Tools program group.

  4. Type the following command:

    New-ADServiceAccount SRV_APP01 -Enabled $true -Path "CN=Managed Service Accounts,
       DC=contoso,DC=com"
  5. Type the following command:

    Get-ADServiceAccount -Identity SRV_APP01
  6. Type the following command:

    Set-ADServiceAccount -Identity SRV_APP01 -Description "Application Pool 01
       on SERVER01"

    Question: What is the value of the sAMAccountName attribute for this account?

    Answer: SRV_APP01$

  7. Switch to Active Directory Users And Computers.

  8. Click the Managed Service Accounts container and confirm that the SRV_APP01 account exists.

    You might have to refresh the view.

    Question: What is displayed in the Type column for the account?

    Answer: msDS-ManagedServiceAccount

  9. Right-click SRV_APP01 and choose Properties.

  10. Observe the limited number of tabs in the Properties dialog box, and then close it.

EXERCISE 3 Configure a Service to Use a Managed Service Account

In this exercise, you configure the default application pool of IIS to use the managed service account.

  1. Switch to Active Directory Module For Windows PowerShell.

  2. Type the following command:

    Install-ADServiceAccount -Identity SRV_APP01
  3. Switch to Server Manager.

  4. In the console tree, expand Roles, expand Web Server (IIS), and then click Internet Information Services (IIS) Manager.

  5. In the Connections panel, expand SERVER01, and then click Application Pools.

  6. In the Application Pools panel, right-click DefaultAppPool and choose Advanced Settings.

  7. In the Advanced Settings dialog box, in the Process Model section, click Identity, and then click the browse button.

    The browse button is the button that appears next to the current identity. The button’s label is an ellipsis (...).

  8. In the Application Pool Identity dialog box, select Custom Account.

  9. Click Set.

  10. In the Set Credentials dialog box, type CONTOSO\SRV_APP01$.

  11. Leave the Password and Confirm Password boxes blank.

  12. Click OK to close each of the three open dialog boxes.

  13. Right-click DefaultAppPool and choose Stop.

  14. Switch to Internet Explorer and refresh the page, or browse back to http://server01.contoso.com.

    The Service Unavailable page appears. IIS cannot serve the page to the browser, because the application pool that hosts the web server process for the site is stopped.

  15. Switch to Server Manager.

  16. Right-click DefaultAppPool and choose Start.

  17. Switch to Internet Explorer and refresh the page.

    The default IIS 7 page appears.

  18. Open Task Manager.

  19. On the Processes tab, click the User Name column to sort by the identity used by each process.

  20. Locate the process that is running with the SRV_APP01$ identity.

    W3WP.exe is the worker process thread that is supporting the IIS site.

Lesson Summary

  • You can create a managed service account in Active Directory, install the account on a computer, and then configure a service running on the computer to use the managed service account as the logon identity for the service.

  • You use Windows PowerShell to create, install, and configure managed service accounts.

  • A computer automatically changes the password of managed service accounts installed on the computer.

  • If the domain functional level is Windows Server 2008 R2, SPNs associated with the managed service account are automatically changed if the name of the computer is changed.

Lesson Review

You can use the following questions to test your knowledge of the information in Lesson 4, “Managing Service Accounts.” The questions are also available on the companion CD if you prefer to review them in electronic form.

  1. You have been asked to create a new managed account and configure a service on SERVER02 to use the account. What tools must you use? (Choose all that apply. Each correct answer is part of the solution.)

    1. Active Directory Users And Computers

    2. Windows PowerShell

    3. Regedit

    4. Services.msc

  2. You have been asked to create the first managed account in your domain and configure a service on SERVER02 to use the account. SERVER02 is a member server running Windows Server 2003. The domain has a mix of Windows Server 2003 and Windows Server 2008 domain controllers. Which of the following statements are true? (Choose all that apply.)

    1. You must upgrade SERVER02 to Windows Server 2008 R2.

    2. You must raise the domain functional level to Windows Server 2008 R2.

    3. You must upgrade the forest functional level to Windows Server 2008 R2.

    4. You must run adprep /forestprep.

    5. You must run adprep /domainprep.