Identity consolidation and privileged access management across Windows, Linux, and UNIXEnterprise Edition
Detailed auditing of privileged user sessions on Windows, Linux and UNIXPlatinum Edition
Dynamic segmentation and isolation of cross-platform systemsApplication Edition
Secure, centralized single sign-on to on-premises business applications
Single sign-on and unified management for cloud and mobile apps and devicesMac Edition
Centralized security and management for Macs and mobile devicesPremium Edition
SaaS and Mac Editions combined with mobile security management
Try DirectControl for Yourself
This application note assumes you have used Centrify DirectControl to join your UNIX/Linux systems to Active Directory. To learn more:
Generic accounts are commonly used to enable UNIX administrative staff to log on to a computer system and perform specific operations using the account identity and permissions of the generic account. While using generic accounts is a simple way to manage specific services, they represent a significant risk in terms of both access control and IT auditing. There is no easy way to manage who can access these accounts or to provide an audit trail showing which administrator used the account to take a specific action. This application note uses an example generic account to show how Centrify DirectControl and Active Directory can be used to control both the password of generic accounts and an administrator's access to a specific computer system or group of systems. It shows how administrators can be granted the appropriate permissions to execute the privileged operations normally run by the generic account without requiring generic accounts to exist.
There are several different ways to address the risk that generic accounts represent. This document show two methods:
The password control solution shows how to enable Active Directory to take control of the generic account's password and enforce Active Directory password policy on those generic accounts. This is the simplest solution because it leaves the generic accounts and the administrator's current practices in place while still enabling centralized control over the password for common generic accounts across several systems; it also ensures that password policies are being enforced properly across the enterprise.
The lock-down solution shows how to eliminate the generic account by replacing it with a set of rights that are granted to the administrator based on membership in a group that is managed within Active Directory. In this scenario, the administrator authenticates to the computer system using his account (typically via an SSO connection from a Windows workstation running PuTTY to eliminate the initial login) and then runs the privileged command directly using sudo without having to su to the generic account. This lock-down solution enables organizations to more tightly control which specific administrator has privileges to execute privileged operations on specific computers throughout the enterprise. Additionally, organizations will be able to lock down or remove these generic accounts since the privileges that were previously granted to these generic accounts will now be granted to individual system administrators on an as-needed basis. Further, Centrify DirectAudit can also be used to provide full visibility into the actual session activity of the administrator who is running these privileged commands, including not only what the administrator typed but what he saw as a response on the display as well. This level of detail satisfies an IT auditor's need to know which person accessed specific systems or specific data on those systems.
For the purposes of this document, let's look at a typical example environment in which a common generic account, called hpov, is used to access multiple computer systems. Administrators log in to any of these systems using the hpov account, or they su to the account in order to run one of the following commands:
$ opcacta -- Run opcacta command
$ opcagt -- Run opcagt command
$ opcagtreg -- Run opcagtreg command
$ opcapm -- Run opcapm command
$ opcclustns -- Run opcclustns command
$ opccma -- Run opccma command
$ opcctla -- Run opcctla command
$ opcdista -- Run opcdista command
$ opceca -- Run opceca command
$ opcecaas -- Run opcecaas command
$ opcle -- Run opcle command
$ opcmack -- Run opcmack command
$ opcmon -- Run opcmon command
$ opcmona -- Run opcmona command
$ opcmsg -- Run opcmsg command
$ opcmsgi -- Run opcmsgi command
$ opcskm -- Run opcskm command
$ opcsubagt -- Run opcsubagt command
$ opctemplate -- Run opctemplate command
$ opctrapi -- Run opctrapi command
A sudo policy is used to control the rights granted to this generic account. As you can see in the following screen, the sudoers file grants the generic account hpov the rights to execute a specific set of commands with root privilege.
In this example, a command alias is used to make the management of the sudoers file simpler, which may or may not be used in production.
For an administrator to execute one of these privileged commands, he must log in with the generic account or su to the account; both of these actions require the administrator to know the password to the generic account. Once he has gained proper privileged access to the account, the administrator can run any of the privileged commands by typing sudo followed by the name of the command along with any required parameters. A log entry is written to /var/log/messages for the administrator when he su'd to the generic account, and a log entry is written to /var/log/secure for each command executed using sudo.
This is a typical scenario in many organizations. The use of a generic account represents a security risk in terms of both access control and auditing. From an access control perspective, anyone who knows the generic account's password can execute privileged commands as root on these systems. From an auditing perspective, it is impossible to directly associate a specific command with a specific user.
If the current operating environment requires generic accounts to be defined locally, or if it is not possible to migrate to a role-based authorization method (as described in the next section), then the best alternative is to centrally enforce password policies for these generic accounts using Centrify DirectControl.
Passwords for generic accounts are typically stored and managed within the local file system, and sometimes they are stored in a NIS domain. Most administrators for these systems know the password or it is a common password. This means any administrator can log in or su to the generic account in order to perform specific operations with the security permissions or rights of that generic account. In addition, these accounts are typically immune to any form of password policy or access control policies due to the way in which they are used.
While generic accounts that are stored within a NIS domain can be migrated into Active Directory through DirectControl, the locally defined generic accounts remain on the individual systems, representing a security exposure. In order to secure the password and to ensure that the Active Directory password policy and authentication controls can be enforced on these local generic accounts, DirectControl's account-mapping feature enables a local account to be linked to an Active Directory user account. To set up this mapping, you can either manually add the mapping the local computer's centrifydc.conf file, or you can use the Group Policy Object Editor to add the mapping to a collection of computers. The entry is formed in the config file as
where unix_user is the login name of the local UNIX account and windows_user is the SAMAccount name of the Windows user in Active Directory.
This link between the locally defined generic account and the Active Directory account enables DirectControl to require the user to enter his Active Directory account password when trying to log in to or su to the generic account. In addition, because the password is now managed within Active Directory, the password policy can be enforced for all password change events. Once the local account is linked to an Active Directory account, it is then possible to centrally disable logins to the generic account simply by locking the Active Directory account.
A better alternative is to replace generic accounts with a role-based authorization solution. In this scenario, when an administrator logs in to the system, he is granted a specific set of privileges based on his Active Directory group. This approach may not work in all environments and may need to be combined with the generic account management model described in the previous section. However, it can be a powerful way to manage privileges for the administrative staff.
The first step in migrating the privilege that was previously granted to generic accounts is to create an Active Directory group with a similar name. By adding users to this group, we can then control who will be granted the privileges that were previously granted to these generic accounts.
In following example, we create an Active Directory group called hpov_group and then UNIX-enable it for a Zone, a logical grouping of computers, called Finance.
We also create and UNIX-enable a couple of users, Fred Thomas and Tim Smith.
Now that we have an Active Directory group that corresponds to the administrative role, we need to assign users as members of this group so that they will get any rights that are granted.
Next, we need to grant the hpov_group Active Directory group the same rights that were previously granted to the generic account. To do this, we use DirectControl to define an Active Directory Group Policy to be applied to our UNIX systems. We will grant the members of the Active Directory group hpov_group, known on UNIX as hpov_gro, the same rights to execute the commands contained in the command alias that we had previously defined within the local sudoers file. In this example, we edit the Default Domain Policy so that this sudoers policy applies to members of the hpov_group on all UNIX computers joined to Active Directory within this domain.
Now that the Group Policy has been defined and applied to the group hpov_group, the policy will be applied to the computer at boot and on the next policy refresh as set by the Group Policy periodic interval (typically every 90 minutes).
Now, either of the two users that we defined previously can log in. An additional benefit is that DirectControl eliminates the steps that the administrator previously had to follow in order to gain access to the system. From a Windows computer using a properly Kerberized ssh client (such as the DirectControl-enabled version of PuTTY that Centrify provides free of charge), the administrator can gain single sign-on based on a Kerberos credential validation. When the UNIX administrator who is a member of the hpov_group is logs in to the UNIX system, the sudo policy grants him the right to execute the privileged commands, just as if he had logged in using the generic account or switched to the generic account.
This application note shows how to leverage your centralized Active Directory infrastructure and Group Policy services to centrally manage an administrator's right to run privileged commands on specific UNIX systems. Group Policy makes it easy to centrally manage the rights that are granted to users and administrators without having to touch each computer individually. Additionally, the sudo Group Policy that grants an administrator the appropriate privileged rights enables the elimination of generic accounts. This also enables auditors to know exactly which user accessed a computer and what privileged commands he executed while logged into that system.
Many other possible solutions exist based on the ability of DirectControl to centrally manage accounts on UNIX systems, whether it is a generic account or a specific end-user account.
It is important to note that DirectAudit can also be combined with this solution in order to provide upper management with full visibility into the activities both individual administrators and generic accounts that log into an audited system.