Basics: Managing UNIX groups from Active Directory with Centrify

Background

With Centrify, UNIX group membership can be managed from AD Security groups.  There's basically a 1:1 mapping between the AD group and the UNIX group.
Note:  In version 2016 of Server Suite, Centrify has added the ability to manage local UNIX groups. Here's a post on how to test the feature: http://centrifying.blogspot.com/2016/01/labs-testing-local-account-management.html

Planning

UNIX groups may be used for different purposes, may contain different members and can mean different things for different administrative groups.  The most important goal is standardization in management, therefore the system administrators have to get together to answer these questions:

• What is this group used for? Why?
• Is this group still relevant?
• Will this group be deprecated by any of the authorization components?
  This is very important, for example, Netgroups are not needed anymore with Centrify zones and Computer Roles.  The other important note is that Role Assignments eliminate the need to maintain UNIX groups for the purpose of sudo usage.
• How many groups are uniquely identified?
• Are there any groups that are defined differently in other systems?
• Are the group memberships uniform?  Are there groups that have network and local users?
• Is this a primary group for all  or a set of users?
• What is the impact of changing the definition?
• What is the impact of the unavailability of the group?
• Is the group in AD going to be managed manually or with a tool?
• Are there any workflow and approvals required?
• Is the group subject to any attestation exercises?
• What will be the naming convention for the AD group that corresponds to the UNIX group?
• What is the scope of the AD group (Domain Local, Domain Global, Universal)?

All these questions need to be answered with a catalog of groups, definitions, members, etc. in a serious table-top exercise.  Because groups are units of identity management, the decisions made here can affect zone design.  

A common issue seen in the field is that a group is part of a legacy infrastructure not understood by the current management team, therefore they decide to keep the status-quo and not compromise on governance, naming or GID to be assigned, this adds complexity rather than understanding the real impact of the group.

For example:

UNIX Group:  db2-dba

UID: 1001

Group Membership:  Includes local account db2inst.
Note: This means that the agent has to be configured to merge NSS group memberships.

Purpose: Used to identify the db2 Database Admins.

Any different definitions:  No

Managed:  Manually

Attestation:  Yes

AD Standards:
                        AD Group Scope:  Domain Local
                        AD Container: UNIX Groups,
                        AD Naming Convention: UNIX-<Zone Name>-Unix Name.   UNIX-HQ-DB2 DBA

Creating the Group Mapping (Do)

Creating the UNIX Group

1. In Access Manager, go to the Zone/UNIX Data and right click Groups and select Create UNIX Group
2. In the Find window, find the corresponding UNIX group (e.g. UNIX-HQ-Wheel), select it and press OK
3. Set the UNIX name (preferable  8 characters depending on platform(s) to be supported) and set the GID.
   
   
   

Populating the Group

1. From ADUC, find and open the group, go to the members tab, click add and add any user principal that has been UNIX-enabled.
2. From Access Manager, right click the UNIX group, select AD properties and follow the steps outlined above.
3. From UNIX using adedit:
   a) Log in to UNIX/Linux with an account that can modify the group (or use kinit) and open adedit.
   b) bind to the domain
   >bind corp.contoso.com
   c) add the ade_lib library
   >package require ade_lib
   c) use the add_user_to_group function
   >add_user_to_group "jessie.matthews@corp.contoso.com" "UNIX-HQ-DB2 DBAs@corp.contoso.com"

Note:  Remember that you can use an Identity Management tool, a script (VB, PS) to populate an AD Group.

Process Reuse:  Now your organization can reuse the existing process and tools to manage the memberships to UNIX systems.

Verifying the Membership (Check)

You can always get a snapshot of the Members tab of the AD Group, however, here are some alternatives.

On UNIX with the getent command

1. Log on to a system in the zone that the UNIX group was created.
2. Use the getent command.  E.g. (for db2dba)
   $ getent group db2dba
   db2dba:x:1001:jessie.matthews

On UNIX with the adquery command
This report is great because it can mix the AD and local users if the agent was configured to merge them.

1. Log on to a system in the zone that the UNIX group was created.
2. Use the adquery group command.  E.g. (for db2dba)
   $ adquery group db2dba
   db2dba:x:1001:jessie.matthews

On UNIX with adedit
Log on to a system in the domain.

1. Log in to UNIX/Linux with an account that can modify the group (or use kinit) and open adedit.
2. bind to the domain
   >bind corp.contoso.com
3. Set the object distinguished name
   >set obj_dn [principal_to_dn "UNIX-HQ-DB2 DBAs@corp.contoso.com"]
4. select the object just retrieved
   >select_object $obj_dn
5. Query the group members
   >get_object_field member{CN=Jessie Matthews,OU=Staff,DC=corp,DC=contoso,DC=com}

On Windows from the Command Line

1. On a computer with the AD DS tools installed, open the command prompt
2. Run the dsget command  (eg. for the UNIX-HQ-DB2 DBAs group)
   dsget group "CN=UNIX-HQ-DB2 DBAs,OU=UNIX Groups,OU=UNIX,DC=corp,DC=contoso,DC=com" -members
   CN=Jessie Matthews,OU=Staff,DC=corp,DC=contoso,DC=com"

On Windows with Access Manager Reporting

1. On a computer with Access Manager installed, go to the Reports node.
2. Create your own report or reuse the Groups Report (pre-created)
   

(Adjust)ing the Group 

Some of the events that may require an adjustment are:

• Merging local users in the result:   This is needed in situations in which a local group (existing in the /etc/group) that contains a local user needs to be merged with the AD-managed group.   This is documented in the centrifydc.conf file:
  adclient.local.group.merge  (by default false) - use with caution.
• Adjusting the GID:  This may be required if redefining the group's unique identifier. It can be facilitated by tools like adfixid.

Basics: Centrify Roles 101 - UNIX Role Creation and Assignment

Centrify Roles

The Centrify Suite allows for the implementation of role-based access controls leveraging Active Directory.  In UNIX, these roles are implemented using AD, Authorization Manager, the base agent (dc or adclient) , the authorization client (dz or directauthorize) and Centrify-enhanced sudo.  In Windows (although out of scope for the initial blog postings) it uses the Centrify Agent.

PDCA method and Roles

The Plan-Do-Check-Adjust methodology is a perfect way to implement Centrify roles.  Use this framework to implement and maintain your roles.  Remember:  Access Controls is a CAPABILITY meaning that it's not a "set it and forget it" activity.  The attestation process is a great opportunity to review roles and see what can be done to tweak them.

Business Problem # 1 has a very basic set of roles.  They just need System Administrators and regular users.  You will see that as we implement more problems, we will tweak roles accordingly.

When (plan)ning for a role, ask yourself these questions:

Ask yourself	Comments	Examples
1. What is the role supposed to allowed do?	This is the functionality that you want to enable.  Use cases are great tools to view this.	Contractor DBAs should be able to run the sqlplus command as the oracle account, all their work will be within SQL plus.
2. What is their UNIX experience? (controlled or flexible)	This question will define what kind of shell is provided to them (a white list or just regular commands plus their privilege commands)	Contractor DBAs are regular unix users with one privileged command.
3. What is the role NOT supposed be allowed to do or know?	These are the controls or rules that are required by policy, security, regulation, methodology, etc.	Users should not know the oracle account password
4. Are there any time/day restrictions to this role?	This is the days/times that the role is available.	Contractor DBAs shall not log in over the weekends.
5. How is the role supposed to access the UNIX system?	These are the access protocols allowed.	DBAs should only have access via ssh.
6. Are there any particular platform implications?	These are exceptions based on the UNIX/Linux platform used.	Oracle databases are used on Solaris systems.  The SSH daemon is a fork called sshd-kbinit
7. Are any additional controls required when privileges are used?	Depending on the action or the nature of the role, you may require simple or complex authentication mechanisms to elevate.	Authentication is required to elevate.
8. Is this assignment temporary or permanent?	Is this role effective for a particular length of time?	Contactor DBAs will work from 3 months starting on Jan 1st 2014
9. What is the scope of this assignment?	This is a key question.  You need to determine if this role is applicable to all systems (zone), some systems (computer group), or a single system (system override).	Only Oracle systems.
10. Will this role be audited?	This is to turn capture/replay if required (A topic for Enterprise Edition)	Yes.
11. Will we have a group of people or a single individual have this role?	Ideally you will always leverage AD Groups for role assignments because it just makes life much easier to manage, but there are instances in which performing a user assignment may be needed.	There is a group of 5 contractors, it is expected that this work may go beyond the original contract.

Creating (do) the Role 

1. In ADUC.  Request or create an AD Security group
   In our example, the UNIX administrator has delegated rights and there is a Roles container for those groups.  It's important to have a good naming convention to understand the purpose of the group.  This is a temporary group that will be assigned at the computer role level, so something like:  UNIX Contractor DBAs is very descriptive.  Notice the UNIX in front of the name.  This is because you could have roles for Windows.
2. In Access Manager/Zone/Authorization/UNIX System Rights review the PAM access rights.
   Centrify ships with some ssh PAM access roles, but based in our example, the Oracle ssh daemon is not listed.  This needs to be created.
   
3. In Access Manager/Zone/Authorization/UNIX Commands create the command(s) required for the role.
   In our example, there's only one privileged command, the sqlplus command running as oracle with authentication required.
    
    
   
4. In Access Manager/Zone/Authorization/Role Definitions, right-click Add and Configure the role.
   In our example, the contractors only work during weekdays and have a regular user experience.  Here you need to keep a good naming convention too.  UNIX-ContractorDBAs is a good name.
    
   
5. In Access Manager/Zone/Authorization/Role Definitions, right-click the newly created role and select add rights. 
   Select the SSH PAM access rights and the newly created sqlplus-as-oracle command.
   
6. In Access Manager/Zone/Authorization/Computer Roles.
   Assuming you have the corresponding computer role (in our example: Database servers), expand the group and right click Role-Assignment.
   

 Testing and verifying (Check) the Role

1. Add a test user to the UNIX Contractor DBAs group.
2. Attempt to access the system(s), verify that SSH access is allowed, but not any others.
3. Verify the role by testing the account with dzinfo and dzdo.
   
4. Verify the role by using the reports or User Effective rights facilities in Access Manager 
   

 (Adjust)ing the role

1. Based on review or circumstances:
   E.g "Contractors now shall work on weekends"
2. Change the role accordingly.
3. Review your roles at least twice a year.

 From this point on, the RBAC is managed via AD group memberships, and the role can be tweaked based on the business needs.