Role-Based Access Control for Linux, Unix and Mac

Authentication, Group Policy, Audit and Reporting

---

Manage User Roles and Sudo Files from Active Directory

Role-based access control, or RBAC, is the holy grail of security, especially when it is coupled with separation of duties. Proponents of RBAC, such as security auditors, seek to separate users from privileges with an abstraction: the role of the user. Rather than thinking, “Jane needs to be able to restart the network,” RBAC proponents want us to think: “network administrators need to be able to restart the network. Jane is a network administrator.” In other words, an organization practicing RBAC should be able to define a set of roles and a set of privileges needed by those roles.

To help comply with such regulations as Sarbanes-Oxley and the Payment Card Industry Data Security Standard, individuals should be assigned to the role or roles that they need to perform their job functions. Ideally, assignment is automatic based on job description, department, and other business rules. As individuals join or leave the organization or simply change jobs, the RBAC system should dynamically adjust their associated roles.

Likewise Enterprise does not provide a mechanism to design roles, but it is easy to see how Active Directory groups coupled with sudo can be used to enforce them. A role can be mapped to a group name and the group name can be used in a sudoers configuration file to allow designated privileges. Then, a Likewise sudo Group Policy can be used to automatically distribute sudoers to Linux, Unix, and Mac computers participating in RBAC. Role membership can be easily controlled through AD-based group membership.

Different Roles on Different Systems

In an RBAC system, however, there is one remaining challenge: not all users have the same roles on all systems. A software developer, for example, might be considered a network administrator on all the computers in Research and in Staging but not in Production. Let us consider two different ways of dealing with this challenge.

First, rather than having a role called network administrator, we could have three roles: Research network administrator, Staging network administrator and Production network administrator. These would have 3 different AD groups associated with them and we could employ a different sudoers file for each of Research, Staging and Production. Likewise Enterprise’s Group Policy features would be able to help with the deployment of the appropriate sudoers file.

The second approach is a variation of the first. The Likewise Enterprise cell feature allows us to define aliases for groups. Different cells, containing different Linux computers, can have different aliases. To solve our problem, we could create three cells (Research, Staging and Production) and different group aliases in each. In the Research cell, for example, we could set an alias that said:

netadmins = CORP\ResearchNetAdmins

In the Production alias, however, we would say:

netadmins = CORP\ProductionNetAdmins

The benefit of this approach is that the same sudoers file can be used on all Unix computers. A single Likewise Enterprise Group Policy setting can distribute the same sudoers file to the Unix computers. Roles could be defined in the abstract, without concern for which users have those roles on which computers.

Summary

The Enterprise version of Likewise, with its cell technology and AD sudo group policy, can provide a powerful tool for enforcing role-based access control for Unix, Linux, and Mac OS X computers.

See more information about Likewise group policies.

See more information about the access-control and authorization features of Likewise Enterprise.

Next > > Workgroup Manager Overview