In the past I have blogged about some of the limitations with sudo in UNIX/Linux environments and how DirectAuthorize is a far richer sudo alternative for privilege management. With our recent release of Centrify Suite 2013, we have extended our privilege management capabilities to also include Windows servers and desktops thereby addressing the issue of restricting and protecting high privilege domain accounts as well as restricting and protecting local accounts with administrative privileges. Another major new feature we just recently added is a fairly comprehensive sudo policy migration tool that I want to call out in this blog post.
But first let me define what sudo is and what it does. sudo is a UNIX/Linux command that lets users run programs with the security privileges of another user. sudo will prompt for the user’s password before executing the command with privilege but it can also be configured for no password at all. The file /etc/sudoers contains the rules that users have to follow when typing the sudo command.
sudo is quite popular and is free. But even with this widespread adoption, customers consistently told us that they have three major issues with sudo that they want to resolve with our DirectAuthorize solution:
#1 key privilege management data is stored locally in the /etc/sudoers file on each and every UNIX/Linux systems, as opposed to managed centrally. This may not be a problem with a small number of systems, but can become problematic when servers number in the 100s and you may not be exactly sure what is in each and every sudoers file on each system. In other words, much like IT organizations are moving from user information stored in /etc/passwd to a central directory (e.g. Active Directory Bridging via Centrify), organizations want the same with roles and rights stored centrally.
#2 sudo requires administrators to understand the complexities of the sudoers policy language. As a result, many organizations have used sudo only lightly; for example, they may use sudo to enable a user to switch to a privileged account, but find it too difficult to limit what the user can then do, which results in relatively weak security. By contrast, DirectAuthorize provides a familiar Windows management interface that simplifies the creation of fine-grained, stringent privilege grants.
#3 sudo really only works on UNIX and Linux and does not support/map over well to the other major server platform which is Windows. Hence another reason we built DirectAuthorize for Windows.
At the bottom of this blog post I discuss why DirectAuthorize is a much better alternative than sudo. But how do you migrate from sudo? With our recent release of Centrify Suite 2013, not only have we come out with support for Windows privilege management, but Centrify now also has a “sudo migration wizard” in place to make it easier to move away from local sudoer files and adopt a centralized authorization model that is also integrated with identity and auditing policy. Here are more details (and hat tip to Matt Hur, our Senior Director of Product Management for our server products, for the details):
The DirectAuthorize sudoer import wizard parallels what we did with /etc/passwd to move from local authentication to centralized authentication. The goal of the sudoer import wizard is to enable customers to convert the sudoer file information to the DirectAuthorize roles model, so they can get away from local file management and/or the need for file synchronization. The import wizard will put the sudoer information into a “staging area” that leaves the customer in control to take the following actions:
- Create or leverage existing Active Directory groups that map to the sudoer “user alias”
- Create computer roles to match the scope defined within the sudoer file “host alias”
- Create DirectAuthorize rights
- Create DirectAuthorize privileged commands from the sudoer “command alias”
- Augment the DirectAuthorize privileged commands for the UID to run as based on the sudoer “run as alias”
Here are a few screenshots to show how simple this is from a user interface perspective.
This screenshot shows how a sudoer file may be imported within any Zone within the DirectManage Access Manager console. The sudoer file may have been copied from the UNIX/Linux computer either manually or by using the DirectManage Deployment Manager tool.
After walking through the steps in the sudoer import wizard (steps that provide visibility into the file and file parsing) the end result is a “staging area” that contains the sudoer alias information as shown in this screenshot below.
The last few items I’d like to mention have to do with new features in Centrify Suite 2013 that make it easier to adopt a model of least privilege. Centrify’s unified privilege elevation mechanism on UNIX/Linux is called “dzdo”. Instead of “su and do” (sudo) it’s “DirectAuthorize and do” — cute huh? Well, in Suite 2013, we are enhancing our dzdo support to include support for local users, so you can assign a role for a local user as well as for users defined within Active Directory.
We’ve also made usability enhancements for dzdo to auto-run as a single user (rather than prompt) where the policy defines only one “run as” user. We’ve also enhanced dzdo to support remote command execution on Centrify enabled system — this makes it easy to set up batch jobs, for example.
Lastly, Centrify OpenSSH now enforces DirectAuthorize policy to control user interactive logins independently from file transfer sessions; so for example, a user may be allowed to copy log files from a server but not be allowed to login to that server. The bottom line is that we’re putting icing on the cake to make it easier to employ best practices, assure compliance, and pass audits.
These are just some of the features we’ve added in Centrify Suite 2013 to provide Unified Privilege Management across UNIX/Linux and now Windows environments. You can find more information about Centrify Suite 2013 here.