Migrating And Managing Service Accounts

After you have migrated accounts for the users who log on to the UNIX computers in your organization, the next step in the deployment is to decide how you want to manage the service accounts for applications in your environment. This section describes the options available and why you should consider migrating local service accounts to Active Directory.

Why Migrate Service Accounts?

A service account is typically a local user and group account dedicated to a specific application or to performing specific operations. In many cases, the service account has escalated permissions that allow it to run privileged operations on behalf of the application it supports. In addition, service accounts often have no password or a password that is wellknown to multiple users. Service accounts without a password typically require a local sudoers policy to control access. Service accounts with a shared passwords present a security risk because users can avoid an audit trail and, if passwords are managed locally, they may not conform to the password policies that are enforced for normal user accounts.

Therefore, the primary reason for migrating service accounts to Active Directory is to provide better security for accounts that can execute privileged commands, start and stop processes, or run specialized jobs on computers in your network.

Note that not all organizations choose to migrate and manage service accounts in Active Directory. There is no technical requirement that you do so. However, Server Suite provides you with several options for improving the security for service accounts. You should consider the options available, then decide which, if any, are most applicable for your environment.

Identifying Service Accounts to Migrate Tto Active Directory

Every UNIX platform has its own set of standard service accounts that are installed by default. For example, most UNIX platforms include services accounts for common applications, such as gopher, mail, ftp, and uucp. For most of these standard service accounts, there’s no business reason to map them to accounts in Active Directory, unless you are trying to eliminate all local accounts on your UNIX computers.

In most cases, you can skip migration for the standard service accounts included by default when you installed the operating system as described in Eliminate default system accounts.

However, service accounts that run or manage applications or own an application’s files are typically good candidates for mapping to Active Directory users. For example, an Oracle database instance has an oracle service account that owns the database server and the related processes that run in the background. Although usually linked to an application, a service account can also be account created to run scheduled jobs and own the files related to those jobs.

Service accounts that are good candidates for mapping to Active Directory users are ones that perform business operations without a password, rely on a shared password known to multiple users, or use shared SSH keys.

Service Accounts Without a Password

Most UNIX service accounts do not use passwords because UNIX services don’t require an interactive log on to own files or run jobs. The most common way for users to access the service account is through the configuration of the sudoers file. The sudoers file provides rules that allow a subset of users to run the su command and change to the service account user. Mapping this type of service account to an Active Directory user eliminates the need for managing access through local sudoers policies and enables you to enforce the same password complexity rules for service accounts as normal user accounts.

Service Accounts with a Shared Password

The second most common way for users to access service accounts is with a shared account password. In this scenario, multiple users know the password for the service account and may be able to log on directly as that account. With shared accounts, there is no authoritative way to identify who is logging in to use the account. If you have any service accounts that rely on a shared password, you should consider migrating those accounts to Active Directory to eliminate the shared password.

Service Accounts that Use SSH Keys

Another common attribute of service accounts is that they often have a set of SSH keys that are available on multiple computers. The SSH keys allow the service account to transfer information from one UNIX computer to another without a password. In this scenario, a specific or the default SSH key for the service account exists in the authorized keys file on each of the computers to which the service account must connect.

Mapping a Service Account to an Active Directory User

After you identify one or more service accounts as candidates for mapping to an Active Directory user principal, you should identify an appropriate Active Directory user principal for the service account to map to. In most cases, there won’t be an appropriate user already defined in Active Directory, so you will need to create one or more new users.

Create a New Active Directory User Account

You can use Active Directory Users and Computers or another tool to create a new user principal for each service account you are migrating to Active Directory.

In most cases, you submit a request for a new account to be created using the procedure defined for your organization. For example, you might submit a request by filling out a service desk ticket and have the request serviced by a member of the account fulfillment team. The steps in this section only apply if you have permission to create new Active Directory user accounts. If you are not responsible for creating new Active Directory user principals, you can skip the following procedure.

To create a new Active Directory user for a service account:

Start Active Directory Users and Computers.
Expand the forest domain and the top-level UNIX organizational unit you created in Selecting a location for the top-level OU.
Select Service Accounts, right-click, then select New > User.
Type a name and account login information for the service account, then click Next.
Type and confirm the password to use for the service account in Active Directory, select the User cannot change password and Password never expires options, then click Next.

The password must conform to your existing password policies for Active Directory users.

If you are creating a new user to replace a shared account, type the password currently in use if it is acceptable within your site’s Active Directory rules for password complexity. If you use the shared password, you should change the password after migration. If the current password is not complex enough, you should type a new password that complies or contact the Active Directory Enterprise Administrator for alternatives.
Click Finish to complete the creation of the new user principal.

Map the Unix Service Account to the Active Directory User

After you create a new Active Directory user principal for the service account, the next step is to map the UNIX account to the Active Directory user.

In preparation for this step, you should notify the user community that the service account will be unavailable for a brief period of time, so that you can make the change and verify that everything works as expected. You should then stop the service and any jobs associated with the service account.

By notifying users and making the service account unavailable for a period of time, you can prevent the change from affecting people who depend on the service to do their jobs. You can then use Access Manager to select the service account and map it to an Active Directory user.

To map the service account to an Active Directory user with Access Manager:

Start Access Manager.
Navigate to the UNIX user account
Navigate to the service account under a specific computer’s Users node or under the Local Account Users node.
Select the service account, right-click, then click Map to AD User.
Type all or part of the Active Directory user name, click Find Now, then select the account in the results and click OK.

Clicking OK updates the configuration on the remote host. You could accomplish the same thing by manually editing the configuration file (centrifydc.conf) or with a group policy.
Verify the service starts and executes operations as expected by switching to the root user or the service account and attempting to start the service.
Check for messages in the log files that the service account writes to. The entries should be regular service startup messages. You should verify that there are no errors or authentication failure messages.

After you verify that the service starts as expected and that any jobs it owns start successfully, you can notify users that the service is available or do additional testing. Depending on your organization and the service account you have mapped to Active Directory, developers, database owners, application owners, and others may want to do full regression testing or execute specific test cases.

How the Mapped User Changes Your Environment

The Active Directory user you create for a service account must be enabled for authentication to work. However, enabling this new user account does present some potential risks to your environment. For example, on UNIX computers, creating the new user may have added a password for a service account that did not previously have one. If the new password is known to more than one person, the account may be considered a shared account and result in an audit finding.

Also, because the new account is a valid Active Directory user principal, anyone with the password can potentially log on to any Windows computer in the forest. By giving the service account a valid password and enabling the account, you have granted access to the Windows network for an account that previously had no access to Windows computers.

If you disable the account, you prevent that account from accessing all Windows and UNIX computers, running jobs, or executing required tasks. If you leave the account enabled and the password is compromised, both Windows and UNIX computers are vulnerable to attack. Even if the password is not compromised, failed password attempts could trigger an account lockout policy, rendering the service unusable.

Mapping service accounts to Active Directory users is a simple technique for managing access and password complexity for service accounts. If you have strong passwords and carefully control access to the account and its password, you can mitigate the risks. This strategy is also best suited to service accounts that already use a password. However, if granting the service account access to the Windows network presents too great of a risk, you should consider alternatives.

Creating a Service Account Role in a Zone

As discussed in How the mapped user changes your environment, mapping a service account to a Windows user makes the account vulnerable to attack. If the attack results in a guessed password, the attacker would be able to log on as the service account, and, potentially, impersonate the service account on multiple computers on the network using SSH keys. Because the mapped user is also a valid Windows account, a successful dictionary attack might also grant access to Windows computers on the network. If the attack did not result in a guessed password, the failed password attempts could lock out the service account, making it unusable.

For service accounts that do not have a password, this vulnerability to a password-guessing attack would be a new security risk that did not previously exist. Therefore, simple account mapping is typically not the best solution for service accounts that are secured using sudoers policies or SSH keys instead of an account password.

If simple account mapping is not the appropriate solution for the service accounts in your organization, you may want to consider creating one or more service account roles. Roles enable you to securely manage the privileges of UNIX service accounts through Active Directory.

Create an Active Directory User Account for the Service

Because roles are tightly integrated with Active Directory user and group definitions, linking a service account to a role requires that you have an Active Directory user object to work with. In most cases, you should use your existing procedures to request a new user account. If you are responsible for creating new Active Directory user principals, see Create a new Active Directory user account.

Define a New Role with System Rights

It is recommended that you create the role definition for a service account in the appropriate child zone. If you want to make the role definition available in all child zones, however, you can create it in the parent zone. The specific selections you make for the role depend on the requirements of the service account for which you are creating the role definition. The steps described here provide general guidelines. Other settings may apply for the role definition in your organization.

To create a new role for a service account:

Start Access Manager.
In the console tree, expand Zones and the top-level parent zone.
Select the specific zone for which you want to define a role, and expand Authorization.
Select Role Definitions, right-click, then click Add Role.
On the General tab, type a name and description for the new role, then click OK.
Click the System Rights tab and select the following options that allow the service account to access UNIX computers using SSH keys or Kerberos, then click OK:
- Non-password (SSO) login is allowed
- Account disabled in AD can be used
- Login with non-restricted shell
  
  In most cases, you should select the Login with non-restricted shell option. This option enables the service account to execute all of its commands in a standard shell. To have the service account run in a restricted shell, you must be able to identify and define rights for all of the commands that the service runs. The service account must also be able to execute all of its commands within the restricted shell (dzsh) environment. For most organizations, this additional security requires significant research and testing before it can be implemented. However, forcing a service account to run in a restricted shell reduces the likelihood that a compromised service account could be used to attack computers on the network.
Select the new role, right-click, then click Add Right.
Select the login-all right for the zone, then click OK.

This predefined right grants access rights for all PAM applications. If you determine that a specific service account should only use a specific PAM application, such as SSH or FTP, you can define a right that only allows that application to be used, then select that right in the role definition to specify that the service account must use the selected PAM application for access.

Create a Unix Profile for the Service Account and Assign the Role

After you define the role for the service account, you can create a UNIX profile for the service account. In most cases, you should define the UNIX profile for service accounts using machine-level overrides, rather than defining them for zones. Defining profiles for service accounts using machine-level overrides has the following advantages:

Profile attributes are not affected the Zone Provisioning Agent. Most service accounts require specific UID and GID values. By specifying these values using a machine-level override, you don’t have to worry about them changing when the Zone Provisioning Agent runs.
You can explicitly identify which computers the service account can run on. If you define the UNIX profile for a service account in a zone, all of the computers in the zone are available to the same service account. If you define the UNIX profile using machinelevel overrides, the service account only runs on computers where it has a profile and the profile attributes for the service account can be different on different computers in the same zone.
You can restrict the scope of the role assignments on a computer-by-computer basis. By defining the UNIX profile using machine-level overrides, you can configure different service account owners for development, testing, and production computers in the same zone.

If the profile attributes are consistent across most of the computers in a zone and the service account should run able to run on all of those computers, you can define all or part of the UNIX profile for the parent or child zone to reduce the management of profile attributes on individual computers. However, if the legacy accounts had different attributes on different computers, it is typically best to use machine-level overrides.

To create the UNIX profile and assign the service account role using machine-level overrides:

Start Access Manager.
In the console tree, expand Zones and the top-level parent zone.
Expand the Child Zones node, select a specific child zone and expand it to display the Computers node.
Select computer for which you want to define machine-level overrides, right-click, then click Add User.
Click Browse to search for and select the Active Directory user account for the service, then click Next.
Select Define user UNIX profile and Assign roles, then click Next.
Select and define the attributes in the UNIX profile for the service account, then click Next.

You can use inherited default values for any of the attributes from the default values specified for the zone or selectively override the default values for any of the attributes. For example if you define user defaults using runtime variables in the zone, you can use the inherited values for the Login name, GECOS field, Home directory, and Shell and explicitly define the UID and primary GID for the service account profile.
Select the default UNIX Login role, click Remove, then click Add.
Click Browse, select the role you created for the service account, then click OK.
Click OK to accept the default start and end times for the role assignment, then click Next.
Review your selections, click Next, then click Finish.

Secure the Active Directory User Account

At this point, you have an enabled Active Directory user mapped to a UNIX profile for the service account. Having an enabled Active Directory user mapped to a service account, however, still presents a potential security risk as discussed in How the mapped user changes your environment. The next step is to decide how to secure the account to reduce the risk that it will be compromised and allow an attacker to gain access to the computers on your network. Depending on your organization’s infrastructure and requirements, there are essentially two options available:

Use SSH public key authentication
Use Kerberos authentication

Each of these options has advantages and disadvantages and require different steps to configure.

Using Ssh Keys for Authentication

If you already use distributed SSH keys on hosts that run services, you can take advantage of that infrastructure and secure the service account by disabling the Active Directory user object in Active Directory. This is a common configuration that enables computertocomputer communication without a pass-phrase.

To use SSH public key authentication:

Define the role for the service account with the Account disabled in AD can be used by sudo, cron, etc system right enabled. The role should not allow an interactive login.
Ensure that the computers that communicate with each other have the SSH public key in the authorized_keys file.
Select the Active Directory user principal you created for the service account and set the Disable Account option.

After you disable the account, it cannot be used for authentication on Windows or UNIX computers and it is not susceptible to a password-guessing attack. The account can continue to run UNIX services and use PAM-aware applications to communicate to other computers on the network using the SSH public key.

The primary advantage of using SSH authentication is that if you already have SSH public keys distributed to allow computer-to-computer communications, services should continue to work after the Active Directory user principal is disabled. There is very little configuration required to implement this solution.

There are, however, disadvantages to using SSH public keys. For example, you must manage key distribution. To allow a UNIX service account to communicate with other UNIX computers, you must generate the SSH key, and distribute that key to all of the hosts that the service account needs to communicate with. In addition, the most common configuration of SSH authentication allows keys to be used without a pass phrase. If the private key is compromised, an attacker could effectively impersonate the service account across multiple computers on the network and reacting to a compromised key can be timeconsuming because it requires you to remove the public key from every $HOME/.ssh/authorized_keys file distributed across the enterprise.

Using Kerberos Tickets for Authentication

If you are not already using distributed public-private SSH keys for authentication, you may want to consider using Kerberos authentication. Kerberos authentication is more secure than SSH keys and using Kerberos enables you to centrally manage access for service accounts, but it requires additional configuration.

To use Kerberos to secure UNIX service accounts:

Install Kerberos-enabled software. You can use the Server Suite-provided version of OpenSSH or OpenSSH, version 3.9 or later, if it has been compiled with Kerberos support.
Ensure the Active Directory user principal for the service account is enabled. Unlike SSH authentication, Kerberos requires the user account to be enabled to request ticket granting tickets or service tickets for other computers.
Use the setspn.exe program to create at least one new Service Principal Name (SPN) for the UNIX service account.
Run the adkeytab command on every UNIX computer where you want to re-use the Active Directory user principal that you created the new SPN for. This command creates a Kerberos keytab file that is only readable to the service account user. The keytab file allows the service account to request a ticket granting ticket so that it can communicate with other UNIX computers.
Use the kinit command to request a ticket granting ticket from Active Directory for the UNIX service account. The ticket granting ticket (TGT) allows the service account to request additional host tickets for SSH communications to other UNIX computers.
Use the klist command to list the tickets for the UNIX service account.

Testing And Migration

If you decide to use Kerberos for service accounts, you should test the computertocomputer communication. If you are migrating from authentication using SSH public-private keys, you can move ore rename the authorized_keys file for the service account on remote hosts to test authentication. After you test the Kerberos authentication of SSH communications and are certain that it works, you can delete the id_rsa, id_rsa.pub, and authorized_keys files for the service account that you have migrated.

Renewing Ticket Granting Tickets

Using Kerberos gives you consolidated control over UNIX service accounts. If an account is disabled in Active Directory, it cannot be used after any existing tickets expire.

If the service account runs scheduled jobs, you may want to create a crontab entry for the UNIX service account to run the kinit command at a regular interval so that the TGT doesn’t expire. If the ticket expires and the kinit command isn’t embedded in the job the service run, computer-to-computer communication will fail until the next time kinit is executed. For example, you may want to add logic to run klist to check whether there is a valid TGT, then run kinit is no valid TGT is found.

More Information

For information about using the setspn.exe program, see the Microsoft documentation for that program. For information about using Server Suite command line programs, see the corresponding man page.

Remove Local Service Accounts from Remote Computers

After you have migrated service accounts to roles in Active Directory, tested operations, and verified that commands and jobs run as expected, you can remove the local service accounts from remote computers to prevent them from being used.

For most organizations, removing local service accounts is a recommended security practice. However, you should leave the default operating system accounts as local accounts. In most cases, those accounts are not migrated to Active Directory. The default accounts for each platform are listed in the user.ignore file that is installed with the platform-specific Server Suite Agent.