[Labs] Centrify's SSH Gateway Explored - On Premises, AWS, Azure and GCP

This article illustrates the steps to set-up a lab to test the SSH Gateway capability of Infrastructure Service.  This capability provides secure access to on premises or IaaS (AWS, Azure or Google Cloud Platform) systems leveraging the Secure Shell protocol (SSH+File Transfer).

Background
Centrify Infrastructure Services provides a full-fledged secure shell and file transfer capability (SSH Gateway).  This "jumpbox"  supports all the core features of the platform including multi-factor authentication, workflow, real-time monitoring and session capture and replay.

Goals of this Lab

• Identity Consolidation:
  • Leverage existing Organizational Directory Services.
  • Accomodate for user populations outside the organization (e.g. Federation, other Directories, etc).
• Usability:  Provide secure access to systems running the SSH Service without visiting the Centrify portal.
• Access Control:  Align with best practices for security access controls, like:
  • Identity Assurance via Multi-factor Authentication.
  • Adherence to the Least Privilege principle  (users shall only access systems and accounts that they have a business need to access).
• Auditability:
  • Event tracking (who, what, when).
  • Allow the real-time proctoring of shell sessions as well as the session recording to be replayed later (e.g. PCI DSS 10.2.2).
• Simplicity and multi-use:  Provide these capabilities with minimal infrastructure or to reuse components of Centrify Infrastructure Service (E.g. leverage other services like AD or LDAP Proxy, or RDP jumpbox services).

Requirements

• A Centrify Infrastructure Services instance (SaaS or Customer Managed) - 17.10 and above.
• A Centrify Connector running the SSH gateway in all the subnets required for SSH jumpbox access.
• A handful of test systems running the SSH Service.
• SSH and sFTP client software.
• If testing "true MFA": An OATH OTP, configured RADIUS token or enrolled Mobile Authenticator.
• Familiarity with Centrify Infrastructure Services.
  • Policy and Authentication Profiles.
  • A configured "Corporate IP Range." 
  • Familiarity with CPS Roles, Permissions and Sets.
• Understanding of the communication paths for CPS (e.g. between connector and instance (HTTPS), between connector and SSH Servers (standard SSH port TCP 22).  Note that these ports are customizable.
• Understading of Infrastructure Services Role-based Access Control.

Conceptual Diagram


This diagram showcases the major components, the location, firewall rules, and additional details depend on the environment.

Diagram for this Lab


High-level Implementation Steps
AWS

• In this implementation, I'm using an AWS VPC as my "corporate HQ"  it has an AD domain, some systems (Windows and Linux) as well as a hosted AD domain.  This will allow me to have different user populations.
• I am leveraging an existing Active Directory and DirectAudit infrastructure.
• Launched a Windows 2012 R2 instance with a public IP address, Fthis instance is in a security group,  that allows inbound HTTPS and SSH from the internet to the instance, plus it can reach the rest of the systems internally, including AD (to allow for it to be joined).
• For internet name resolution, I created a CNAME record in the rpdemo.net DNS domain for the cps record that resolves to the public DNS name for the EC2 instance above
• Obtained a publicly rooted certificate, and exported it with the private key for Privilege Service to use.
• Installed Privilege Service (on-premises) in single-master mode (no HA);
  Note:  The single-master configuration does not provide HA or allows for upgrades.  This is for testing purposes only.
• Added a Centrify connector with the adproxy and SSH gateway services.
• Configured Privilege Service to use my ISP's IP address as part of the corporate IP range.  This is to provide the assurance that only I can access it.
• Configured 2 roles:  An Administrator, and a Least Access role.
• Configured Workflow for the resources.

Microsoft Azure

• Created inbound rules that allow the connector in AWS to reach the systems over RDP and SSH.
  Note: Depending on the services needed, an additional connector in Azure (or GCP) is needed.
• Launched existing Windows and Linux systems.

Test Matrix (Success Criteria)

Category	Description	Result
Identity Consolidation	Users from Active Directory and Centrify Directory can access systems via Web Portal or SSH Gateway.	Pass
Identity Assurance with MFA	Users must use an MFA or Step-up method to authenticate via Web portal or SSH Gateway.	Pass
Policy	Users can only access from a specific subnet.	Pass
Least Access	Users can only access the systems based on business need to know via Web Portal or SSH Gateway.	Pass
Access Request	Users must request temporary access to shared accounts.	Pass
Monitoring (real time)	SSH/RDP – Sessions can be monitored in real time. SFTP – Active sessions can be tracked.	Pass
Advanced Auditing	Sessions can be reviewed after the fact (indexing, replay, etc.)	Pass
Infrastructure Simplicity and Reuse	The same components can be used for other capabilities (e.g. RDP, etc).	Pass

Test Videos
Identity Consolidation and  Assurance with MFA

Policy, Least Privilege and Access Request

Real-time Monitoring  + Session Capture and Replay

Infrastructure Simplicity and Reuse

A commentary on Privileged User Management

A commentary on Privileged User Management

When I visit customers and prospects, I see an amalgam of priorities, knowledge, organizational dynamics, but most commonly complexity and a feeling that most people don’t know where to start. Ultimately the decision is simple.  There’s no access controls without a consistent identity store.

I’m also surprised on how easy analysts are influenced by vendors. Let’s take for example the topic of passwords; I've  always conceded that shared account password management is needed in the enterprise, but that it only applies in break-glass scenarios, change control or network devices; however, vendors in their effort to expand have positioned their solutions as the “end-all-be-all” (regardless of the true need) which to me is a disservice to the customer or prospect.

My personal philosophy is clear, least privilege management is the right way to go because it applies in most of the cases (the cases would be larger if network devices had better AD integration); however, now that Centrify is in the SAPM business as well, I feel it’s my obligation to position it, but in its proper context and use cases.  This is validated by the fact that most data breaches have components of credential theft; threat agents are counting on somebody that has more power than they should have, to get to the sacred keys of the kingdom.

Here’s what I propose to readers of this post, (I will be the first to admit that I’m just reusing the 80/20 rule) but, I think that if 8 out of 10 privileged actions are part of my day-to-day job and they have been defined with a privileged elevation mechanism, I’m quite happy.  This is becoming increasingly important on Windows, where admin account (e.g. “-a”) accounts are no longer the best practice.  On UNIX/Linux privilege escalation has existed for years in the form of sudo.  What you’re trying to avoid here is that if you implement a password-centric system, users will naturally “camp” or will try to get around the proxy system (forcing the implementation of complex network rules).

This should settle the whole “what’s my goal post” question, and ultimately, it’s up to the organization dynamics to determine if this is a realistic and attainable goal.

Least Privilege Management - Where do I start?

Ultimately, the game it’s all about control.  Here’s a playbook that I often share with customers and prospects:

• First, you have to start with a Common Identity (e.g. AD)
• Then you have to be able to group systems based on a security governance model
  (e.g. web servers, database servers, PCI servers, Financial Systems)
• Implement granular access controls:

• Define where the user can log in as part of their job functions 

• Define how the user can log in to systems (E.g. SSH but not console;  RDP but not console)

• Define any time effectiveness of a role  (E.g. Backup guy should only run tar as root from 5PM to 6AM

• Reuse Processes

• Assign roles to AD groups

• Manage memberships or requests via your ITSM or workflow tool.

• This way you can use that tool for attestation as well.

With least privilege, where I see customers often think that the task will be very large because they must identify and catalog the tasks that users are performing with privilege; but the view is a bit myopic because those things are managed and it is after all a capability (people-process-technology) that should have its own road map.

At Centrify we suggest this:

1. Start with a “broad scope” but with a simple goal:  Eliminate shared account usage.  Maintain status quo as it relates to super users.  Allow them to elevate as root/Administrator; but deny them the knowledge of the password.  
2. As you are able to increase accountability, then start “narrowing the scope”; e.g. “What’s does a Database guy do, with privilege in their day-to-day?” 

As you move to this model, concede that there will be areas of improvement (hence the need for feedback and a road map). This is another area where customers and prospects have misaligned expectations;  you will have to work on privilege management all the time, this is not a "set it and forget it" type of deal.  There are governance and operations components, there's attestation

The other 20%, perhaps break/glass, or access to production systems, I’m happy with proper workflow/approvals and change control.  Otherwise I’m getting in the way of the user’s productivity and they will try to find ways around the “broker” system.

The ever-expanding definition of a Privileged Account

It's not just about root, Administrator, oracle, apache, jboss or xyz service/privileged account.  Your privileged users exist everywhere.   What about your social media accounts?  The embarrassment of losing control of these accounts is evident every day for corporations;  the same with SaaS applications.  Isn't the Sales Admin in Salesforce, or the Finance or CFO lead in Netsuite a privileged user?

In a hybrid enterprise, the rules have changed;  however, I believe that Centrify has you covered.  In the next post we'll continue this series and we'll talk about the Centrify value in the context of Privileged User Management.

Business Problems: Overcoming the Confidentiality and Integration challenges with Hadoop Clusters using Centrify

Background

Hadoop implementations present multiple challenges to enterprises at the Operating System layer(*), I like to categorize them in 2 areas:

Confidentiality

• Hadoop clusters are unsecure by default.  What that means is that there's no service-to-service authentication and that privileged users have access to world-readable information and can elevate to privileged Hadoop accounts.
• Multiple clusters are needed because of the development nature of the apps.  Typically at least a DEV/QA and PROD environments are needed, depending on the risk profile of the organization, each environment may be in different isolated environments and require different access control rules.
• Different types of users need access:  From the SysAdmin, to the Hadoop Admin, to the Data Scientist, they all have different access and privileged needs.
• The data classification of the business intelligence may require additional controls.  What if the cluster crunches Personal, Financial, Health, Energy or Card data?   SOx, PCI, HIPAA, NERC or FERC compliance is needed.

Integration

• Kerberos:  Many organizations balk at the proposition of standing-up a separate MIT Kerberos implementation; and even if AD is an option, test environments may be in a one-way trust.
• Different organizations == Different requirements, therefore the devil is in the details:
• Process
• Technology/Infrastructure
• People
• Regulations

(*) There are additional security challenges, like how to protect data at the Hadoop layer, for this, your trusted Hadoop vendor (Cloudera, Hortonworks, MapR, etc) have an ecosystem of applications.  Centrify can provide identity information to those apps.

Technical Briefing

The following videos provide technical demos on how Centrify can overcome these challenges

Putting it all together

• Centrify allows for OS level integration for Linux and UNIX systems that enables:
• Centralized Administrations of multiple Hadoop Clusters
• Regardless of how complex your AD may be 
• No schema extensions or software in domain controllers
• Using UNIX frameworks
• Kerberos just works out of the box
• Leverage AD fully:  Kerberos, Group Policy, PKI
• Centrify enables the implementation of strong access controls to enforce
• Least access
• Least privilege (RBAC- not password Centric)
• Easy attestation and reporting
• Separation of Duties
• Works on Windows to eliminate the problem of the persistent administrator
• For environments with Personal, Financial, Health or Card data
• Session transcription 
• Session replay
• Event consolidation
• Works on Windows
• Hadoop-exclusive features:
• adkeytab for advanced keytab/service account provisioning
• Kerberos infinite ticket renewal parameters and GPOs
• LDAP Proxy to assist apps like Sentry, Hue and Knox
• Partner with Cloudera, MapR and Hortonworks

Centrify + AD + Hadoop = faster, more secure and regulation-aligned big data projects.

Labs: PCI DSS 3.0 Req # 7 - Implement Strong Access Controls 10-minute Challenge

Challenge Accepted!

In a previous post, we outlined the PCI DSS3 Requirement 7 10-minute challenge.
This entry is to outline current environment, high level steps and verification protocol.

Here's the current environment as of today (excluding the 2-node Hadoop cluster):

Here's what we're adding for the challenge:

The cast of characters

• J. Peterman and Elaine Benes are the PCI Developers
• On Windows - PCI Developers shall perform developer tasks like:
• Opening SQL Server Studio
• Resetting IIS websites
• Control System Services
• On Linux -  PCI Developers shall perform LAMP functions like:
• Control the httpd service
• Elevate to the mysql account (without knowing the credentials)
• Edit the httpd daemon config file /etc/httpd/conf/httpd.conf
• Jerry Seinfeld is a Domain Admin
• George Constanza is the UNIX Sysadmin

Steps to the Challenge - 10 minutes

Planning
- Will use a new zone to prove this concept (may be needed for separation of duties) - name: PCI
- Will reuse the existing ZPA service (provisioning has nothing to do with PCI, will control access with Roles)
- A Combined UNIX/Windows role will be created with the following access:

• Role Properties
• Available 24x7
• Password Login and SSO enabled
• Non-Restricted Shell
• Access Rights
• PAM SSH
• Remote (Windows)
• UNIX Commands
• systemctl (start|stop|restart)*httpd  as root (authenticated)
• su - mysql  as root (authenticated)
• vi /etc/httpd/conf/httpd.conf
• Windows Applications
• iisreset.exe  as local administrator
• services.msc as local administrator
• SQL Management studio as local administrator

- PCI Developers group will be called - PCI Developers

Implementation

On the management station:

1. In ADUC create the PCI Developers role
2. In access manager set up the new zone.
3. Set up the Unix identity properties
4. Set up the UNIX commands
5. Set up the Windows Applications
6. Create the PCI Developers role, set up properties, add the rights
7. Perform the role assignment at the zone level.

On CEN2

1. Unpack the Centrify agent bits
2. Run adcheck
3. Join the zone
4. Run adquery user and dzinfo

On APP2

1. Install the Centrify Agent
2. Join the Zone and Reboot

Test Plan (Check) - 5 minutes

• We'll verify that PCI developers can:
• Only log in via SSH (Linux) and RDP (Windows)
• Perform administrative tasks on APP2 (Win Server 2012 R2)
  Not a member of Local Administrators or Domain Admins
• Perform LAMP admin duties on CEN2 (CentOS 7)
  They shall not know the root account.
• Windows Domain admins should not be allowed to log in to the PCI systems (Jerry)
• Enterprise UNIX admins - should not be allowed to log in to the PCI systems (George)
• Any other users can't access the systems (Soup Nazi)
• The model should work for both Unix/Linux and Windows.

First Video - Challenge Explained (5:03)

Second Video - Implementation (9:40)

Third Video - Verification (6:49)

Security Corner: PCI DSS 3.0 Requirement 7 - Implement Strong Access Controls 10-minute Challenge

Background

The Payment Card Industry (PCI) Data Security Standards (DSS) is a great measuring stick for the security posture of any organization.  In fact, I love it because it's so clear.

Requirement 7: "Restrict access to cardholder data by business need to know" poses an interesting set of challenges, because it requires the enforcement of the principles of:

• Least Access - users shall only access the systems they need access to
• Least Privilege - once in these systems, they shall only do what they're supposed to do
• Implement a Role-Based Access Controls (RBAC) model
• Shall be enforced across heterogeneous platforms (7.2.1)
• Ideally the process is consistent and easy to document and adhere to workflow (7.1.4, 7.3)
• Closed systems - All systems default to deny access unless (7.2.3)

Challenge

1. Implement the technical(1) controls of Requirement 7
2. Multi-platform:  Unix/Linux & Windows
3. Implement it in less 10 minutes or less
4. Prove compliance in 5 minutes or less

The Environment:

1. Active Directory 2012 Domain (based on the Microsoft Test Lab Guides)
2. One Windows Server
3. One RHEL 7
4. Centrify software already loaded on a management server (MMCs) and copied in target systems.

Access Rules

The access rules have to be defined as per 7.1.1.

 The card data environment consists of one Windows Server 2012, a RHEL 7 and an Ubuntu 14.04 servers.  The nature of the work performed is database (SQL Server) and Web (IIS) work on Windows.  The RHEL platform is used for an Apache/MySQL app.  There are two types of roles in this environment:

• Sysadmin (cross-platform)
• Sysadmins shall perform tasks as root in RHEL systems without knowing the root password. (7.1.2/7.1.3/7.2.2)
• Sysadmins shall be able to perform tasks as Administrator on Windows platforms without being a permanent member of the Local Administrators or Domain Admins group. (7.1.2/7.1.3/7.2.2)
• Developer (cross platform)
• Developers shall perform service control of Apache and IIS services  (service httpd start | stop | restart) and iisreset.exe - No root/apache/ credentials or ocal admin rights. (7.1.2/7.1.3/7.2.2)
• Developers shall be able to elevate to the mysql service account and to run the services.msc snap-in in Windows (to stop/start/pause) SQL without the root/mysql credentials or local windows admin rights. (7.1.2/7.1.3/7.2.2)

Additional Guidelines

• Because these are PCI systems, no one than the PCI Sysadmin and PCI developer Role can log in to the system.  This includes any other trusted administrators like Domain Admin. (7.2 - deny-all)
• Access to both roles is restricted to the terminal (SSH on Linux and RDP on Windows) no console access.
• The add/moves/changes process shall be controllable via AD Group membership.  This makes easy for other upstream tools to control workflow and approvals. This makes compliance with 7.1.4 (approvals) and 7.3 (documentation) much easier.

Our next post consists of a set of steps and video challenge. 

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.