Securing Generic and Application Accounts on UNIX

Wednesday, February 11, 2009

In a previous blog entry I discussed the critical need for "superuser privilege management," which is a set of processes and technologies for properly managing the people who have the keys (i.e. elevated privileges and access) to your kingdom (i.e. key systems and applications). In today's blog post I will discuss a related topic: how do you manage from a security perspective the generic and application accounts such as "oracle" that are created on your critical UNIX systems? For this blog post I turned to the expertise of Ken Montagna, one of our Consultants in our Professional Services organization, who was kind enough to provide most of the content below.

As a bit of a background, UNIX service accounts, also called "generic accounts" or "application accounts" are commonly used to enable UNIX administrators or applications to log on to a computer system and perform specific operations using the account identity and permissions of the service account. Using service accounts to run applications and to connect to databases and web applications is commonplace in the UNIX world. It is also common that Windows service account policies are different than UNIX policies in the same organization.

However, they represent a significant risk in terms of both access control and IT auditing. In the past there was no easy way to manage who can access these accounts or to provide an audit trail showing which users used the account and what commands they executed. Typically service accounts are handled by a trusted UNIX systems administrator who knows the password or by an application lead developer or database administrator who knows the password.

The obvious risks of having a service account assigned to a human are:

• the user creates and shares a password with someone who needs the password
• the password is typically marked non-expiring
• if the owner or anyone that knows the password leaves, there is no process of removing it
• lack of reporting who actually accessed the account and what they did

A better method for dealing with service accounts is the following:

• prevent anyone from logging into to the account to begin with
• once no one knows the password, only trusted accounts can "su" to this account
• once the user "su"s to the account they can only perform a set of privileged commands
• all the actions of the users using these accounts to be audited

The above points are exactly what the Centrify Suite can help enable!!!

First, you can set up an account so it can't be directly logged into by using /bin/false as the default shell or using DirectAuthorize's PAM Access capability (more about that later). What you want is that only trusted people can "su" to this account and perform a set of privileged commands.

Next, you can utilize DirectControl to set up your service accounts so no one knows the password. Using DirectControl's Kerberos utility "adkeytab" passwords can be generated randomly and Kerberos tickets can be used instead of passwords. Centrify already uses these tools for the management of the machine account in Active Directory. The service accounts can also be defined in Active Directory and service principle names given to them using adkeytab. Centrify's adkeytab provides a mechanism to edit the DirectControl keytab file and synchronize the changes with Active Directory. It has the ability to:

• Create a new service account and keytab file
• Add new service principals to the computer or a service account
• Delete service principals from the computer or a service account
• Change the password for a computer or service account
• Delete and clean up an existing account

You can then use our DirectAuthorize solution to help you define roles with rights and authorization for a given job. DirectAuthorize in effect helps you migrate users from having access to all commands to just using the commands they only need to do their job. In other words, DirectAuthorize enables the service accounts to be restricted as well as the humans having access to the service account.

DirectAuthorize may sound like the UNIX utility "sudo", but DirectAuthorize differs from sudo in that it stores its data centrally in Active Directory vs. sudo storing its authorization information in local text files and it grants privileges to AD Users vs. UNIX accounts providing a higher level of accountability. Other feature differentiation vis a vis sudo includes:

• PAM Application access. PAM Application access restricts access only to the application a user may require defined by PAM. For example, ftp, ssh, login.
• Time boxing. Time boxing restricts the life cycle of an account and what hours they are allowed to access the system. For example, a vendor is going to need permissions to install software on a machine for one week. The vendor can be restricted to the start and end dates and only during normal working hours.
• Restricted Shell. Restricted Shell is a basic shell that has a white list of commands that can be accessed. The default is denying access. If a command is not in the list then the user cannot execute that command. The restriction can be made to disallow an option of a command. For example, a user is allowed to read uncompress tar files, but not create tar files.

A UNIX user will find it easy to use DirectAuthorize as the concept is the same for privileged commands. Instead of entering "sudo" and the command, the UNIX user just enters "dzdo" and the command. Alternatively, to simplify command execution with privileges further for the user, their account could be configured with a DirectAuthorize Restricted Shell which would be configured to execute specific commands automatically with privilege as the service account. This can significantly streamline the usage of these service accounts eliminating both the user's need to know the passwords for these accounts as well as to simply enable them to run commands with the appropriate privileges automatically applied.

From there, Centrify DirectAudit can be used to record the commands that are used. After a period of time, the system administrator can review the user's sessions to define and restrict the set of commands, the time period, and the applications required to perform their job.

In summary, this blog post discusses how you can leverage your centralized Active Directory using Centrify products to centrally manage a service account to run privileged commands on specific UNIX systems. We have showed that is possible to start a service in a secure way to manage service accounts without the use of passwords. And finally, you can provide upper management with full visibility into the activities both individual administrators and service accounts used on the audited system.

Bookmarks:

< Previous Article: DirectControl Named a Top Mac Client Management Solution
> Next Article: "Andritz" Court Decision and Protecting Against Insider Threats