Considerations when using a domain-based service account with AD LDS

When creating an AD LDS instance you are prompted to specify an account to use as the service account. At this point you can specify either the Network Service account or another account. Unless you have a particular need, you should choose the built-in Network Service account. If you opt for a domain-based service account you have to jump through a whole lot of hoops to get things working. Also, you typically end up giving your domain-based service account more permissions than are strictly necessary (as described later in this article). The Network Service account on the other hand provides an easy set up option and is a good choice from a security perspective given that the account has limited access to the local computer.

So why bother to use a domain-based service account at all? Well, if you have a number of services on your server all running under the context of the Network Service account there is potential for security compromise. In this scenario you may want to consider isolating the services from each other using dedicated service accounts.

What follows is a discussion of the steps required to configure AD LDS to use a domain-based service account.

1. Create a user account in AD.

The account doesn't require any specific group memberships. As a service account, you may want to give some thought to the "Password Never Expires" setting, as well as password complexity.

2. Permission to create serviceConnectionPoint objects.

The account you have created requires the ability to create Service Connection Point objects in AD. These objects are typically created automatically as child objects of the AD LDS computer object when the service is started.

The simplest method is to set the permission using DSACLS. You could alternatively use the security editor from within dsa.msc or adsiedit.msc, but you would first need to edit the %systemroot%\system32\dssec.dat file to expose the serviceConnectionPoint object. Here's the syntax using DSACLS:

C:\>dsacls /G :CC;"serviceConnectionPoint"

e.g.

C:\>dsacls "CN=ADLDS1,OU=Servers,DC=Widget,DC=com" /G MyDom\ADLDS_SVC:CC;"serviceConnectionPoint"

The setting should appear similar to that shown in the screenshot below.

3. Permission to create servicePrincipalName objects.

Your service account also needs permissions to create Service Principal Name (SPN). The SPNs are generated automatically as attributes of the service account itself in AD when the service is first started. Note that this is different from the behaviour when running the service under the Network Service account. When using Network Service, the SPNs are created as attributes of the AD LDS server's computer object.

To set the permissions, assign the SELF account Read/Write servicePrincipalName. The permissions are applied onto This object only on the service account object. Here's an example using DSACLS.

C:\>dsacls /G SELF:RPWP;"servicePrincipalName"

e.g.

C:\>dsacls "CN=ADLDS_SVC,OU=Service Account,DC=Widget,DC=com" /G SELF:RPWP;"servicePrincipalName"

The screenshot below shows how the permissions should appear.

4. Grant "Log on as a service" user rights

The service account requires Log on as service user rights on the server running the AD LDS instance. You don't normally have to assign this right in advance because you will be prompted when creating the instance using the setup wizard.

If you have to set this right manually, use the Group Policy Editor to edit the local policy, or alternatively use the GPMC to edit an appropriate domain policy. The location of the setting is:

Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.

The screenshot below shows the setting.

5. Membership of the local Administrators group.

At the time of writing, the AD LDS product documentation indicates that the service account is not required to be a member of the local Administrators group on server running the AD LDS instance. However, my experience is that without this, the following error is generated in the event log corresponding to the instance each time the service is re-started.

Log Name: ADAM (instance1)
Source: ADAM [instance1] General
Date: 6/04/2009 11:22:08 a.m.
Event ID: 1168
Task Category: Internal Processing
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: ADLDS1.widget.com
Description:
Internal error: An Active Directory Lightweight Directory Services error has occurred.

Additional Data
Error value (decimal):
-1073741790
Error value (hex):
c0000022
Internal ID:
3000715

The fact that the service account requires membership of the local Administrators group makes the choice to use Network Service even more compelling. The Network Service account has a lower level of privilege on the local machine than that of members of the Administrators group. This implies the potential for compromise is lower when using Network Service.

Conclusion

As you can see, using domain-based service accounts for your AD LDS instances requires a fair amount of extra work during setup. I recommend that you use Network Service unless your circumstances require you to use a domain account.