Identifying service accounts to migrate to 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.