Labs: Mac OS X AD Integration with Centrify Suite 2014

Centrify Suite 2014 Mac Integration Playlist

This playlist (47 minutes total) covers the requirements for the Mac OS Scenario outlined in the previous post.

http://centrifying.blogspot.com/2014/04/enter-mac-extending-2014-evaluation.html

Enjoy!

R.P

Basics: Privilege Management Implemeting (Do) on UNIX/Linux using Centrify and Active Directory

Background

This is the implementation portion of the 4-part series around Privilege Management with Centrify for UNIX/Linux.  Read the previous post to catch up.  The basic knowledge for this post, although focused on UNIX, it's applicable with the exception of rights, applies to Windows too.  The activities required to implement roles with Centrify requires:

1. Create Computer Roles if needed
2. Create and Configure Roles
• Build the PAM access rights if needed
• Build the Commands if needed
3. Assign the role

Creating Computer Roles

Centrify computer roles are groupings of systems that perform a particular role.  I like to call them computer groups.  Systems can be grouped any way it makes sense to you.  The real power of computer roes is that they are based on AD Security groups, this means that you can have computers (just like users) that have multiple roles.   Examples:

• Fragmented (vertical) model:  Web, Database, Utility, Network Services, etc.
• Mixed mode (horizontal/cross funtional)l:  Application X - Dev; Application X - Prod  (Application X has Database, Web and Application servers).

To create a computer role:

1. Create an AD Security Group  (this is the Computer Role container)
2. In Access Manager, Open the Zone, and expand Authorization > Computer Roles
3. Right click Computer Roles and select Create New Computer Role
   
4. Set the name, and browse for the AD group created in step 1.

What happens when you create a Computer Role?

A computer role adds a new scope to assign RBAC and to categorize systems.  The operations associated with Computer Roles are role assignment and member add/moves/changes.

The add/moves/changes for roles are performed within the AD group that grants the role, this makes the Role Assignment a first time/adjustment activity.

Creating Roles

Centrify roles are the building blocks for Role-Based Access Controls.  Roles are defined, then assigned to AD security principals.  In UNIX roles are composed of PAM Access and Commands.

• PAM Access:  Defines the PAM-aware protocols that are allowed in the the role.  Examples:  Secure Shell (ssh), xdm, VNC, and of course, not recommended:  pure telnet & FTP.  The built-in login-all  PAM right allows access on all protocols including the console.
  Note for AIX:  Some AIX platforms are configured for LAM can't provide granular access.
• Commands:  are the privileged (or non-privileged) commands defined for the role.  They can be defined explicitly, or with regular expressions, tied to the Centrify restricted shell, scoped for a particular user, and defined with additional authentication requirements.

To create roles:

You need to know how the role will access the system (e.g. via SSH), what privileged commands it needs (e.g. service control for httpd), any time restrictions and if you have Centrify Enterprise, you

1. In Access Manager open the Zone > Authorization > Role Definitions
2. First, always review your roles to see if a role exists that can be reused.
3. Examine PAM The UNIX Rights definitions node for PAM and Commands and make sure the building blocks exist.
4. Right Click Role definitions and Select Add Role
5. Name the role, use the description field and add any time/day restrictions if needed.
   
6. Go to the System Rights tab.  Define the logon experience. 
• Password login and non-password login (SSO) are allowed:  if  you plan to use both SSO and passwords  (check it)
• Non-Password SSO login allowed:  You would uncheck the one above and only check this if you're in a Smart Card scenario.  (check it)
• Account disabled in AD can be used by sudo, cron, etc:  Only required if you're defining a role for a service account managed from AD.  (leave unchecked)
• Login with a non-Restricted Shell:  This is going to be not selected if using the Centrify Restricted shell (white-list mode).  (check it)
  
  Note the Windows rights, not covered in this posting.
7. If using Enterprise Edition, go to the Audit Tab, and select the appropriate option:
   
   Especially when Auditing roles for Windows, the integration of RBAC and auditing can result in auditing risky actions and less storage usage in the Audit database.
8. Press OK.
   Very important: At this point, the role is defined, but it has no rights assigned to it, this has to be the most common mistake in the area of RBAC along with assigning a role without granting an identity.  
9. Right-click the newly-created role and select Add Rights
   
   Check all the rights (PAM) and commands for the role and press OK.

Now the role is ready to use (be assigned).

Assigning Roles

As described, Role assignment is the granting of a UNIX (or Windows) role to an AD Security Principal in the correct scope.  Roles can be assigned at:

• Zone Level:  This role will apply to all systems in the zone.  (Limited Use)
• Child Zone:  This role will apply to the child zone (Depends on your design)
• Computer Role:  This role will apply just to the set of systems in the role (Optimal usage)
• Computer:  This is a local override or exception  (If you find yourself doing this a lot, you have a governance problem)

Time-bounding Role Assignments

Permanent vs. Temporary Role assignments:  Time-bounding of role assignments is a powerful feature of Centrify, this allows for scenarios like this:

• Change-control windows:  You can have your population be regular users all the time, and only get a role with privileges when a change control has been granted.  The access/rights expire automatically at the time specified.
• Contractor scenarios:  A set of external users may need access to systems in a specified period of time.

With the AD Group, scope and time, all the information is ready for do do an assignment.

1. In Access Manager, go to Zone > Authorization
2. At this point, it's time to pick the scope:
• To assign at the zone/child zone level, select the Role Assignments node right under authorization.
• To assign at the Computer Role level, expand Computer Roles, find the correct system group, and expand to expose Role assignments
• Exception:  At the system level, go to the Computers node, find the computer, expand it and find Role Assignments.
3. Right click Role Assignments and select Assign Role, then pick the role you are going to assign.
   
4. In the Assign Role box, time-bound based on your information (scope or permanent), then use the Add AD Account button and find the Group (or user -not recommended- promotes exceptions) that you will grant the role to and press OK.
   

Process Reuse: The biggest benefit of assigning the role to a group is that this makes the integration with other tools and process reuse much easier.

In the next post we will talk about the Check (Verify the implementation) portion of Privilege Management.

Basics: Privilege Management Planning on UNIX/Linux using Centrify and Active Directory

Background

Privilege Management (or Privilege Access Management):  is the capability to control and limit users activities in accordance with the least privilege principle, some key goals:

• Limit access to systems based on business need-to-know
• Limit privileges or actions to those required to perform the job function
• Provide timely information for the purposes of attestation or auditing
• Enforce separation of duties.

In the context of UNIX and Linux systems, Centrify provides capabilities to establish a Privilege Management model that satisfies all these goals (since version 2013, these benefits extend to Windows systems too).

To perform a Plan-Do-Check-Adjust exercise on Privilege management, we will break down the activities in Access, Privileges, Governance and Reporting.  To keep the posts a short read, we'll focus on planning.

Planning Privilege Management with Centrify for UNIX/Linux

Governance

Governance is related to separation of duties and ideally, the people who define the access, rights and privileges (Security Analysts, compliance, etc.) are different than the people who access the systems (System Admins, DBAs, etc);  however, in the real world the expertise and organizational history required to establish a governance model is in the hands of the most senior administrators.  

Delegation of Centrify objects is performed in two places:

• In Active Directory (this is another topic)
• At the zone level, Centrify breaks the actions to be performed as follows:

Rights	Category	Description
Change zone properties	Operational	Changing zone properties may imply changing the UID/GID defaults, renaming the zone or how the zone is provisioned.  These actions should be change-controlled.
Add users	Operational	Adding users is basically UNIX-enabled AD users.  This is delegated to the ZPA service account in an automatically provisioning scenario.  In a manual zone, this is just day-to day activities.
Add groups	Operational	Same as above, but with groups; however, this is a one-time setting, the real operations are Add/Removes from the mapped AD group.
Join computers to the zone	Operational	This is the equivalent to joining computers to the domain, the Windows process can be reused here.  UNIX operations are typically granted this role.
Remove zones	Operational	Deleting zones (in production) should be a change-controlled activity.
Remove users	Operational	See “Add users”
Remove groups	Operational	See “Add groups”
Remove computers from the zone	Operational	See “Join computers to the zone”
Modify user profiles	Operational	See “Add users”
Modify group profiles	Operational	See “Add groups”
Allow computers to respond to NIS client requests	Operational	With Centrify, NIS maps can be reused securely in a clientless scenario, Operations may need to configure computers to act as NIS proxies for appliances, legacy systems, etc.
Import users and groups to the zone	Operational	See “Add groups”
Manage roles and rights	Governance	Roles and rights are the building blocks of RBAC.  See below.  This activity should be reserved for Security or Compliance, although in an initial implementation may be granted to UNIX administrators.
Manage role assignments	Governance	Role assignments entitle AD user or group principals to access or privileges based on a role.  The guidance is the same as “Manage roles and rights.”
Modify computer roles	Governance	Computer Roles are the groupings of systems.  They define the types of systems and the scope of access. The guidance is the same as “Manage roles and rights.”
Add or remove NIS map entries	Operational	With Centrify, NIS maps can be reused securely in a client scenario, Operations may need to add/remove/change those maps.
Modify NIS map entries	Operational	See “Add/Remove NIS map entries”
Remove NIS maps	Operational	See “Add/Remove NIS map entries”

During the implementation phase, the trusted administrators that are implementing Centrify may have full control, but as the implementation matures, as part of the adjust phase, the governance rights can be split from operations.  The key questions are:

• Who are the individuals that have operational responsibility for your UNIX/Linux systems?
• Who are the individuals that have governance responsibility for your UNIX/Linux systems?
• Is there a geographical o divisional breakdown that we should be aware of?
  The answer to this final question is very important.  It may trigger the need to have parallel or child zones.  Try to do as much as you can to keep things as flat as possible.

Privileges

Planning for privileges is one of the hardest activities;  and this is because the people using the system may not be used to thinking about Roles-Based Access Controls.  A good starting point may be a sudoers file (Centrify can import them); but even that may carry legacy information;  the worst case scenario is the implementation of a centralized mess.  Here are some base questions for a table-top exercise:

Questions	Typical answers	Comments
1.      What are the user populations that access UNIX/Linux systems?	DBAs, Developers, System Administrators, etc.	The goal of this question should be to identify user populations.  Moderating the scope of this answer is critical. Also, try to find out if users are within an AD domain, across domains, etc.  This has an effect on the type of Security groups used for role assignment.
2.      What are the groups of systems they access today?	Oracle servers, Apache servers, Dev Servers, Filers, etc.	The goal of this question is to identify how systems should be grouped.  This question is the key to establish the governance model because it will produce the Computer Roles.  An advantage of Centrify is that a system can have multiple roles.  It can be a Database System and a Web System at the same time.
3.      What are the groups of systems they should have access to?	The answer varies	It’s possible that this may be the hardest question to answer; this is because other than Netgroups, organizations may not have a mature way to group systems and grant access.
4.      How do these users access the systems today?	SSH, console, VNC, FTP, NFS, Samba, etc	This is key, because Centrify can control how PAM access is granted.
5.      How do these users should access these systems?	This varies too	With Virtualization, console access is rare; also, unless there are HPUX, Solaris or AIX systems, console access is limited to a trusted set of administrators; there will be a bias towards SSH, but even that can be controlled granularity with Centrify.
6.      How do people use privileges today?	The answer to this question may vary.	The best way to explain this is with an example.  How do DBAs use the oracle account? Answer: “they access with their account, and sudo as oracle or su to oracle” Upon verification, turns out those DBAs were logging in directly with the Oracle account.
7.      What are the privileges that they have today?	Everyone is can be root, sudo access, etc.	The answer to this question depends on the maturity level of the organization.
8.      What are the privileges that they should have?	The answer varies	Just like the answer to question 3, since the possibilities are unknown, it may be hard to get.

Again, the hardest part of this planning exercise is to get people that know enough about what's possible with Centrify (see implementation below), and that privilege management has its own roadmap. 

Access

Access involves planning the types of systems available in the enterprise.  Grouping systems based on type,  or environment allows the scoping of roles to be tied to groups of servers, effectively enforcing both access and privileges.  For example, a group of systems may be defined for Application A, that has web, application and database servers; it's possible to group these systems together and have a different access/privilege model for DEV, QA and Prod.

The Output of the Planning Session

In Business Problem # 1, the access model was well defined;  and in Business Problem #2, the privigeles are going to be expanded:

User Populations	Access / Protocols	Privileges
System Administrators	All Systems via any protocol	Run any command as root
DBAs	Database Systems via SSH	Elevate to db2inst Run db2 commands as db2inst DB2 instance service control
Web Admins	Web Systems via SSH	HTTP daemon service control (as root) Edit http daemon configuration file (as root)
Developers	Database and Web Systems via SSH	Run application X, service control
All UNIX-enabled users	Listed on Filers	No access, no privileges.

Stay tuned, in the next post we'll talk about Implementation and Verification.