Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

A Better Way to Sudo – Part 3

11 April,19 at 11:51 AM

Spoiler (Highlight to read)
 Part 3 – Sudoers to DirectAuthorize migration tooling: In this installment, we introduce the out-of-the-box technical tooling to assist in your transition from your current sudoers file based implementation to DirectAuthorize.
 Part 3 – Sudoers to DirectAuthorize migration tooling: In this installment, we introduce the out-of-the-box technical tooling to assist in your transition from your current sudoers file based implementation to DirectAuthorize.

A Better Way to Sudo

Part 3: Sudoers to Centrify DirectAuthorize Migration tooling


Series overview

The goal of this series is to help customers take better advantage of the DirectAuthorize features included with Centrify Server Suite for managing privileged UNIX rights. 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 of the series, we show you how the pieces logically fit together. At this point, I’ve identified the first three parts to series:


  • Part 1 - Use your knowledge of Sudoers to understand 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: Part 2 picks up where Part 1 left off. We used the sudoers file example discussed in Part 1 to illustrate 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: In this installment, 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.

Before diving in:

  • This installment builds off the concepts introduced in Parts 1 and 2. Please give those a read before diving in.
  • 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.


“Optimized” sudoers file

Migrating sudoers over to Centrify provides an opportunity for customers to revisit how UNIX privileged access is currently disseminated. What we typically find when analyzing how privileged UNIX rights are “sliced and diced” across job functions and environments are users with excessive access, stale policy entries, hosts which no longer exist, etc. Certainly this is understandable when you consider that: 1) "Connecting the dot" across the various policy elements in a single sudoers file is difficult to interpret and does not lend itself well to access reporting; and 2) these challenges are all the more daunting when attempting to aggregate a unified access picture across tens, hundreds, or thousands of UNIX (and Windows*) systems. Furthermore, rarely do we see organizations with a formal sudoers file lifecycle management process. For customers that attempt to manage sudoers files on an enterprise scale, they know firsthand how difficult this is to sustain. 


So rather than running your “master” sudoers through our import wizard as is – and potentially perpetuating the same excessive privileged access problems – some business analysis and forethought to structure a sustainable and flexible policy is recommended as a first step. Our professional services consultants are outstanding in guiding customers through this process. At the same time, your master sudoers file(s) does not need to be "perfect" as a precondition to migrate your sudoers implementation to Centrify. Our sudoers migration tooling itself provides you with the visibility you do not have with flat sudoers files. This in turn can help facilitate the long overdue discussion of aligning UNIX RBAC policy with the business. 

Centrify Access Manager Sudoers import example

Using the sample sudoers file introduced in the first installment of this series, we'll walk through the migration of a sudoers file using the Centrify DirectManage Access Manager console. Here you’ll start appreciate how Centrify’s approach is both familiar to Sudoers, and at the same time provides much greater control and flexibility.


Launch the Sudoers Import Wizard

  1. Before we launch the Sudoers Import Wizard, first note in this example we have several Centrify enabled machines joined to the domain and a Centrify Zone. A number of Active Directory users are also assigned to the Centrify Zone under the UNIX Data node (not pictured). 

Figure 1: Computers joined to a Centrify Zone



  1. Next we right click on the zone and select “Import Sudoers File” and browse to the location of a copy of a cleaned-up/optimized master sudoers file. 

Figure 2: Select "Import Sudoers File..."



  1. Next a preview of the sudoers file you’re importing is presented

Figure 3: Sudoers Import Preview



  1. Parsing Summary – The sudoers import wizard attempts to match User_Alias entries with AD Groups, Hosts with AD Computer objects, etc. In this example the parser did not detect any errors or warnings. Errors could be due to, for example, improper syntax of a sudoers file entry. Warnings are often due to the import utility unable to find a corresponding Active Directory object for a given sudoers entry. 

Figure 4: Sudoers files parsing results



  1. At this stage the Sudoers Import Wizard is done and the policies are now staged for your review.  The imported policies are not yet committed.

Figure 5: Finish Sudoers file import wizard



Sudoers Staging Node

  1. After completing the import wizard and clicking the refresh button on the tool bar, you should now see a Sudoers node. This node is essentially a staging area for mapping Sudoers entries to Centrify RBAC policies stored in Active Directory. The next step is to import the sudoers alias definitions followed by the sudoers User Specifications.

Figure 6: Sudoers import staging area



Import User Aliases - AD User Groups

  1. First expand the User Alias node. You’ll see the user aliases on the left. Single click a user alias. On the right you'll see the alias members as defined in the sudoers file. If any of the users from the sudoers file match a Zone enabled user, their POSIX attributes also appear. Click here to see the sudeoers file User_Alias list illustrated in Part 1.

Figure 7: Sudoers staging - User Alias node



  1. Next right-click one of the user aliases on the left pane. Note that you can either create a new AD group or map the user alias to an existing AD group. Through this process you’ll see a few familiar AD user/group admin menus for choosing or defining an AD Group. For this example, we’ll chose the “Map to AD Group…” option. Whether we select Create AD Group or Map to AD Group we can automatically add the User Alias members to the AD group (providing that they are also a member of the Centrify Zone). You’ll also notice the “Remove original AD group membership box. Here you can choose to either append or overwrite the existing AD group membership list.

Figure 8: Mapping User_Alias to AD User Groups



  1. If you take a look at the AD group membership, it now matches the users listed in for this corresponding sudoers Alias.

Figure 9: User_Alias mapped to AD Group members



Import Host Aliases - Centrify Computer Roles

  1. Next expand Host Alias and single click an item on the left. All the hosts assigned to the Host Alias entries in the sudoers file appear on the right. These entries are mapped to the Centrify enabled machines that are joined to this Centrify Zone. If a host name from the sudoers file does not match a computer in the zone, a warning (yellow exclamation mark) appears by the host entry. A Host_Alias enables you to scope privilege assignments to group of computers. Host Aliases naturally lend themselves to Centrify Computer Roles which also assign privileges to groups of computers. 

Figure 10-1: Sudoers staging: Host_Alias node



Right-click an alias object and select “Create Computer Role…”. This process allows you to create an Active Directory Group of Computers populated with the hostnames contained within the given Host_Alias. You’ll be guide through a few screens to specify where in AD to create and manage the AD Computer Group. Choose a naming convention that makes it easy to identify and report on Computer Role objects such as a prefix of “CG”


Figure 10-1: Enter the name of your AD computer group.  

Figure 11-1.png


Figure 10-2: Computer Role name defaults to the host alias. You can accept the default or click edit to change.



Figure 10-3: The end result is a computer role. The Members node of a computer role corresponds to the AD Computer Group created earlier. The Role Assignments node at this stage is empty. We'll assign roles later. 




Command Alias

  1. Next expand the Command Alias node and single click an item on the left pane. You’ll see the Sudoers file command aliases and their corresponding commands listed here. No further import actions within this node. Importing these commands and Command Aliases are managed within the User Specification node discussed next.

Figure 11: Cmnd_Alias node



  1. Next, click User Specifications. Here is another good example of how Centrify’s RBAC model is consistent with Sudoers. The first column lists the User Alias, followed by the Host Alias and the Command Specifications. For reference, See the sample sudoers file User Specification entries here. Back to the Access Manager user interface, if you right click on an item, you can map the User_Alias to an AD group, the Host_Alias to a computer role, as well as import a user specification.


Figure 12: Sudoers staging - User Specification node



  1. In this example we’ll select Import. The import option will take the selected sudoers user specification and create  the following objects in Active Directory:

 13-1Centrify UNIX Rights: The first screen that appears in the User Specification import are the listing of UNIX command rights that will: 1) populate a Centrify Role (next screen shot) and; 2) the UNIX Rights Commands node (not pictured - expand Authorization > UNIX Right Definitions > Commands).

As an aside -- the Command node (example from part-2)  functions as as a "library" of UNIX privileged commands. The list of available commands to support your environment grows as you import more user specifications, create commands by hand, etc. The great thing about this capability is that as your list of available commands grows you can start to "repackage" these privileged command rights into new roles which better align with your organization.


Figure 13-1: Import User Specification Commands



  13-2) Centrify Roles: Clicking next displays the Centrify Role to be created along with the corresponding Unix Commands that were enumerated in the previous screen. The generic role name “Role_1” that’s shown here can be renamed;


Figure 13-2: Map Cmnd_Alias to Centrify Role



 13-3) Centrify Computer Roles – Clicking next brings you to the Preview Role Assignments screen. Like a sudoers Command Specification, you associate a Centrify Role to an AD User Group which in turn is scoped to an AD Group of Computers.

  • The “Trustee” column refers to the AD user groups entrusted with Rights associated with the given Role;
  • The “Scope” column refers to the AD computers groups covered by this policy.

Figure 13-3: Preview Computer Role Definition



After you click next, the users, hosts, and commands are imported and linked to the corresponding Active Directory objects.


Stay tuned… in our next installment, we apply Centrify's privilege elevation RBAC model to Windows operating systems. Here’s a quick preview:

*All Windows Administrators are NOT created equal… Yet we entitle them as if they were. Administrators for the Domain, SQL Server, IIS, and so on perform unique tasks which require windows local administrator rights. But – and this is a big BUT – these administrators do not need ALL the rights afforded to them by Windows local administrator. We discussed how solve the problem disseminating privileged access in the UNIX world. Now we’ll discuss how to solve this challenge for Windows.


Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.