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 computer‑to‑computer 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 time‑consuming 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 Centrify-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 computer‑to‑computer 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.
For information about using the setspn.exe program, see the Microsoft documentation for that program. For information about using Centrify command line programs, see the corresponding man page.