11 April,19 at 11:50 AM
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 2: Representing Sudoers Policy through Centrify's User Interface
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:
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
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 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
As shown in Figure 7, Centrify UNIX Rights Definitions are organized by:
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.
Not pictured in Figure 9:
Figure 9: UNIX Rights Definitions - Commands - General
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.