A Better Way to Sudo

Part 2: Representing Sudoers Policy through Centrify's User Interface

Series overview

The goal of this series is to help customers take better advantage of the DirectAuthorize features included with Centrify Server Suite. There are several areas we could explore around managing privileged UNIX rights with the Centrify DirectAuthorize functionality included in Centrify Server Suite. For starters, its important to have a basic understanding of the DirectAuthorize policy model. And if you are familiar working with sudoers, you will be right at home with DirectAuthorize. No problem if you’re not familiar with sudoers… In Part 1 we show you how the pieces logically fit together. At this point, I’ve identified the first three parts to series:

• Part 1 - Using Sudoers to Understand Centrify DirectAuthorize: In Part 1 we discussed the key gaps in “native” sudoers we hear from customers and why you should consider taking advantage of DirectAuthorize. We introduced how how UNIX users interact in the UNIX environment through “dzdo” (Centrify’s enhanced implementation of sudo).  And we used sudoers as a frame-of-reference to introduce the DirectAuthorize policy model.
• Part 2 – Representing Sudoers Policy through Centrify's User Interface: This installment picks up where Part 1 leaves off. Using the sudoers example file discussed in Part 1, you’ll see how these policies are represented in Active Directory and the Centrify DirectManage Access Manager user interface. DirectManage Access Manager is the Centrify RBAC policy administration user interface for UNIX and Windows operating systems (yes, we deliver privilege elevation to Windows too). The scope of this post focuses on UNIX specific policies.
• Part 3 – Sudoers to DirectAuthorize migration tooling: We introduce the out-of-the-box technical tooling to assist in your transition from your current sudoers file based implementation to DirectAuthorize. To set expectations, the purpose of showing Centrify's out-of-the-box suoders migration wizard is to further illustrate the similarities between Centrify's UNIX RBAC model and native sudoers. That said, if you are considering a migration, it might be worthwhile to enlist experienced guidance from Centrify's Professional Services team.

Some things to keep in mind before diving in to the second installment of this series:

• I suggest keeping Part 1 handy in a separate browser window as we’ll reference back to its sample sudoers file entries over the course of this post.
• The audience is intended for both security professionals, UNIX admins, and Active Directory admins.

Centrify Computer Role

Consider a sudoers "User Specification" entry is comprised of a Cmnd_Alias assigned to a User_Alias which in turn is applied to a Host_Alias. Similarly, a Centrify “Computer Role” and "Role Assignment" are both analogous to a sudoers “User Specification” (compare Figure 1 below with Part 1 – Figure 10).  A Computer Role is comprised of three elements: 1) a Centrify Role which is associated to; 2)  an Active Directory Group of Users which in turn this policy combination of Role(s) and User(s) is then scoped to; and 3)  an Active Directory Group of Computers. The computers within the AD Group of Computers represent a subset of the machines within a particular Centrify Zone. As another option, you can use the "Role Assignment" node if you want to apply a policy combination of Centrify Roles and Active Directory users to all computers within a Centrify Zone. 

Figure 1: Illustrates the Role Assignment portion of a Centrify Computer Role and their respective counterparts in a sudoers file

Figure 2: Members is where you can scope your Role Assignment to an AD Group of Computers

Figure 3: Under Role Definitions, you’ll see the Cmnd_Alias/Centrify Role along the corresponding UNIX commands / Centrify UNIX Rights

Centrify Roles - beyond native sudoers Cmnd_Alias

Right-clicking a Role and selecting properties shows some interesting options not available in native sudoers.

Time restricting roles - Consider the requirement we've hear from several customers where sensitive operational/maintenance are scheduled only during specific times. In particular, these tasks entail privileged commands that are only ever used during these periods. And possessing these rights outside these time periods essentially violates least privilege and could result in audit findings, security vulnerabilities, etc. This requirement cannot be solved purely through native sudoers. However, as shown in figure 4 below, Centrify solves this problem through time-boxing when the UNIX Rights within a particular can be exercised.

Figure 4: Right-click a role and select properties. From there, select "Avaiable Times".

Roles and authentication requirements - Another requirement we hear often is the ability to only permit junior and/or outsourced operational personnel's rights to execute a specific set of commands and nothing else for a given system. For example, someone responsible for restarting the production Apache Web Server after hours in the event it fails. You don't want these users doing anything else on the server - not even running seemlingly benign commands "ls" or "pwd". As shown in figure 5, under the System Rights tab for a role's properties, you'll see that you can configure if users are permitted to authenticate to a given system via password, kerberos, multi-factor, etc. You can configure is users are permitted to login with a "restricted" or standard UNIX login shell when accessing a particular system. If a role is configured for Restricted shell, the user can only execute the specific commands assigned to the Centrify Role. 

Figure 5: Role properties, System Rights tab

Role policy-based session audit trigger - We hear from customers that they don't want to audit everything. Rather than gathering and sifting through noise in their audit logs and session recordings, they only want to capture sensitive and/or compliance related activity. Again, this requirement is not achieveable through native sudoers policy configuration. However, as shown in Figure 6, under the Audit tab of a Centrify Role its simply a matter of selecting a radial button for given role to enable or disable audit/session recording for UNIX and Windows systems.

Figure 6: Role properties, Audit Tab

Centrify UNIX Rights - Beyond native sudoers UNIX commands

Centrify UNIX Rights are analgous to commands within a sudoers file. In short, a Right represents a specific operation users are allowed to perform. However, the flexibility and control provided by Centrify certainly exceed what's afforded by native sudoers commands. At a high-level, UNIX Rights control

• what Centrify enabled UNIX systems users can access;
• what PAM enabled applications users are permitted on specific systems (e.g. SSHD; FTP, VNC, custom PAM applications);
• what commands users can perform on a given system;
• what security/authentication is required for command execution; and 
• more...

As shown in Figure 7, Centrify UNIX Rights Definitions are organized by:

• PAM Access  
• Commands; and
• SSH Rights

Figure 7: Centrify UNIX Rights Definitions are located under the Authorization node within a given Centrify Zone

UNIX PAM Access Rights - Consider scenarios where you only want to restrict users access to specific applications which rely on OS authentication (e.g. SFTP, custom app leveraging OS authentication, etc). These users do not need access to the UNIX shell. Centrify PAM Access rights are designed to address this requirement. For example, PAM Access rights control if users can login via SSH, SCP, VNC, custom PAM enabled apps, etc.  Referring back to Figure 3, you'll see that users with the UNIX Apache Admin role can access the OS via SSH or SSHD. Figure 8 below provides another example for configured PAM Access Rights the VNC. To define new PAM Access right, just specify the PAM application name. You can use wild cards if the names vary slightly across different systems. Once your new PAM Access Right is defined, you can assign it to a Centrify Role. 

 Figure 8: UNIX Right Definitions - PAM Access

UNIX Command Rights: Figure 9 below illustrates some of the configuration options available for managing UNIX Commands. When looking at an individual UNIX Command, note that the configuration options and syntax are essentially the same as native sudoers with some notable improvements.

• Re-authenticate with Multi-factor: In terms of improvements, under the Attributes tab in Figure 9, you can require a multi-factor authentication challenge to execute the command. This particularly useful for mitigating against APT attacks that rely on stolen passwords. 
• Command Syntax: In terms of familiarity to native sudoers, the command syntax, wild cards, and command path are the same. 
• "Command Library"... the Commands node itself essentially represents a "library" of individual UNIX Commands that enabling you craft Centrify Roles into whatever combination of individual UNIX commands you can think of. And, you can import an existing sudoers file to build out your UNIX command library so you don't to define all your UNIX commands from scratch. We'll talk about import in the next post.

Not pictured in Figure 9:

• Restricted Shell tab is particularly useful when you want to strictly control which commands users can execute. In a restricted shell environment, users can only execute the specific commands and command-line options that are explicitly allowed. Users assigned to a Role with restricted commands are not even allowed to run informational commands like "ls" or "whoami" unless explicitly included;  
• Run As tab allows you to define which target OS user the command will elevate to upon execution; and
• Environment tab enables you to set any environmental variables when executing the command.  

 Figure 9: UNIX Rights Definitions - Commands - General

Stay tune for Part 3

If I've done my job in Parts 1 and 2, you'll have at least a basic sense of how the Sudoers and the Centrify DirectAuthorize RBAC policy models correspond to each other.  In Part 1 we dissected a sudoers file and illustrated how entries within a sudoers file map back to their Active Directory counterparts. Here in Part 2, we step through the Centrify Access Manager user interface and show its familiarity and improvements to native sudoers. Next, in Part 3 we'll discuss the Sudoers import tools available through the Centrify Access user interface.