Service Publication in Active Directory
Service Publication in Active Directory |
|
Services can execute in one of two security contexts:
The security context under which the service runs affects the access rights that the service has on the computer and on the network.
A service can run in the context of the LocalSystem account or in a specific service account. LocalSystem is a special, predefined local account available only to system processes. This account does not have a password.
On computers running Windows NT 4.0 and earlier, a service that runs in the context of LocalSystem inherits the security context of the Service Control Manager. The service is not associated with any logged-on user account and does not have credentials (domain name, user name, and password) to be used for verification. The service has limited access to network resources, such as shares and pipes, because it has no credentials and must connect using a null session.
On computers running Windows 2000, a service that runs in the context of the LocalSystem account uses the credentials of the computer when accessing resources over the network and has full access to local resources. A service that runs in the context of LocalSystem on a domain controller has full access to the directory, because the domain controller hosts a directory replica and LocalSystem has complete access to local resources.
In general, a service needs to run under a separate service account on any system, regardless of role, and under a separate service account on domain controllers. Create the service account as part of the service setup and configure ACLs appropriately to give the rights to the service account.
Do not run a service under LocalSystem on a domain controller. Doing so gives your service too much access to Active Directory, because LocalSystem on a domain controller has complete control of Active Directory. Most security-conscious customers will not accept applications that require this context because of its potential to cause serious damage to directory information.
For services that access Active Directory, the LocalSystem context is constraining. When a service runs under the LocalSystem account on a system that is a domain member, such as Microsoft® Windows® 2000 Server running as a member server and Microsoft® Windows® 2000 Professional, that service runs under the context of the computer account when accessing domain resources, such as Active Directory. Computer accounts typically have very few privileges and do not belong to groups. Adding machine accounts to groups is not recommended; the accounts are subject to deletion and re-creation if the computer leaves and then rejoins the domain. The default configuration of an ACL for Active Directory permits minimal access for computer accounts. Services running as LocalSystem, therefore, have only minimal access to Active Directory.
Installing a service with a domain account and password allows the service to have the access that the domain account offers. The domain account can be a member of multiple security groups and is not subject to deletion and re-creation if the machine leaves and rejoins the domain. Group memberships can be easily used to grant access to the desired areas of Active Directory for use by the services that use service accounts. However, running a service in the context of a service account has these disadvantages:
Important
If your service runs under the LocalSystem account, you must test your service on a member server to ensure that your service has sufficient rights to read/write to Active Directory. A domain controller must not be the only Windows 2000–based computer on which you test your service. Remember that a service running under LocalSystem on a Windows 2000 domain controller has complete access to Active Directory, while a member server runs in the context of the computer account, which has substantially fewer rights than a domain controller.