Most Microsoft applications use service
accounts, and Lync Server is no exception. Although some applications
use service accounts running as System or Network Service, many IT
groups prefer to use named accounts for services. This often results in
simplified management of permissions because accounts can use
descriptive names and it makes it easier to apply local policies to
these service accounts. It also enables you to create a single
domain-based service account to use across multiple servers. This also
makes it easier to ensure that rights are consistent across multiple
servers in the same deployment. Regardless of the methodology used, it
is worthwhile to put some effort toward securing the service accounts.
Caution
In too many environments, service accounts are given
high-level rights to avoid taking the time to determine granular rights.
Often in these situations, multiple members of IT are familiar with the
logon name and password of these service accounts because they might be
used for configuring certain applications. This results in multiple
people having access to a high privilege account with no accountability
because there is no way to know which person used the account. This is
generally considered a bad idea for security.
Configuring Service Accounts with Least Privilege
As
a general rule, when creating service accounts to work with
applications, special care should be taken to ensure that the services
have only the rights they need to do their jobs. Rather than simply
making a service account a local administrator on a given server, take
the time to determine what rights it actually needs and grant them
through the Local Security Policy editor.
1. | Click Start, Administrative Tools, and Local Security Policy.
|
2. | Expand Local Policies.
|
3. | Click User Rights Assignment, as shown in Figure 1.
|
4. | Choose a right that needs to be granted from the right pane and double-click it.
|
5. | On the Local Security Setting tab, click Add User or Group.
|
6. | Add the service account into the available window, and click Check Names. Click OK.
|
7. | Click OK again to grant the right.
|
Some local rights that are typically granted for applications include
Access this computer from the network
Allow log on locally
Back up files and directories
Generate security audits
Load and unload device drivers
Log on as a service
These types of granular rights can easily replace the
need to make a service account a local administrator on a server.
Coupling limited rights with a Managed Service Account can greatly
reduce the possibility of a high privilege account from becoming
comprimised and used to take control of a system.
Utilizing Managed Service Accounts for Lync Server
Active Directory 2008 R2 introduced a new type of
service account known as a managed service account. Managed service
accounts work like computer accounts in Active Directory. That is to
say, they automatically rotate their passwords every 30 days, and they
cannot be used by a person to interactively log in to a computer system.
Managed service accounts are exceptionally useful for applications that
require named accounts and have a need for heightened security.
To create a managed service account in Active Directory, you must use PowerShell:
1. | Click Start, Administrative Tools, and Active Directory Module for Windows PowerShell.
|
2. | Type New-ADServiceAccount MSAName–enabled $true.
|
This creates an MSA in the Managed Service Accounts OU called MSAName, as shown in Figure 2.
To use this MSA on a server, perform the following steps:
1. | Log on to the server that will use the MSA.
|
2. | Click Start, Administrative Tools, and Services.
|
3. | When prompted for permissions, click Continue.
|
4. | Right-click the service that will use the MSA and click Properties.
|
5. | Click Log On tab, click This Account, and type the name of the MSA in the format of domain\MSAname. Click OK.
|
6. | Select the service and click Start the Service. Verify that the MSA name appears in the Log On As column.
|
From this point forward, the service account updates
its own password every 30 days, as a computer account does in Active
Directory. This results in a secure password that isn’t known by any
administrator on the network.
Note that only one computer can use a
particular Managed Service Account, so if you have a need for multiple
computers to use a Managed Service Account, configure one MSA per system
that needs to use one.
