Business Cases - Web-Mobile SSO Planning Session II: Apps

Planning for Applications

When we plan for Applications (Web or Mobile), we need to think about different strategies.  These types of questions arise:

• How will the application be published?  
  Centrify provides the user portal, however, depending on your environment, you may have an intranet or content management platform that is used as a hub for applications.
  
• What is the policy to access these applications?
  Apps can have different assurance requirements.  Maybe certain portions of the HR app are for intranet-only access with step-up (or two-factor) authentication.  Maybe your Netsuite-based ERP should only be available from inside of the United States.
  
• Who should be entitled to access each app?
  Your security team may want to grant access based role or job function.  Centrify User Suite uses AD or Cloud Directory principals for app visibility.
  
• What are the authentication capabilities of the app?
  Modern (especially cloud-based apps) provide federation technologies (like SAML, etc) but legacy apps don't have those capabilities or aren't available in the current version.  Also (and unfortunately) not all apps may be looking at the corporate directory (e.g. AD) as the identity repository (which can enable Kerberos or NTLM).  CUS offers the flexibility of password-vaulting and replaying.
  
• How is the application provisioning model?
  This topic impacts the bottom-line of the business because the timely deprovisioning of cloud apps can impact the billing depending on how the application provider is metering the usage of the application.  In addition, some apps need to have entitlements provisioned as well for the purposes of role-based access.
  
• What is the strategy for on-premise apps?
  Are these apps accessible via an existing VPN infrastructure (e.g. CheckPoint, Cisco, Microsoft's DirectAccess or others) or will you make use of the Centrify App Gateway (VPN-less access)?
  

These are high-level categories, there are advanced topics like timeouts, attribute-mapping, provisioning of certificates for federation trust, etc; but we will cover each scenario individually.

We will start by publishing these Web applications:

• On-premises SharePoint (as a shortcut)
• On-premises Apache or Java-based apps (leveraging NTLM, Kerberos & ADFS-less WS-Fed apps)
• Google Apps
• Salesforce
• Office365.

Later we'll move on to Mobile apps on the Google Play and Apple App Store.

Business Cases - Web-Mobile SSO Planning Session I - Global Settings

In a previous post, we discussed the requirements for the Web and Mobile SSO use case, and although our labs are aimed to help with testing or proofs of concepts, we typically address the planning.  Many of the topics in the requirements are huge (like o365 or GoogleApps migration), but we'll do the best we can to outline some of the key parts of planning.

Project Management and Methodology - the PMO would like to use the same methodology (DEV-QA to PROD) for this project.

What this means is that you need to have multiple cloud tenants a test and a production tenant.  Ideally, you will have a test environment that mimics your existing infrastructure.  My advice is that you use a rolling wave when it comes to IdaaS as well.  Scenarios like switching how people access your CRM (e.g. Salesforce) or ERP (e.g. Netsuite) can affect the bottom-line.  I won't be implementing this, but keep it in mind when implementing any cloud service.

Marketing - Branding and imaging should be maintained.

Organizations pay a lot of money to establish a brand identity;  your Cloud-based solutions should allow you to maintain that branding.  Centrify offers the ability to implement logos for the self-service portal, email invitations, mobile enrollment, etc. In addition, the main corporate color can be implemented as well.  This means that ahead of time you need to collect:

• The Pantone color code for your organization (main color) for the portal ribbon
• The corporate logo in several sizes:
• 137x35 to be used as the login image
• 160x36 to be used as the portal image

Business Requirement - The IT organization wants to shift capital expense (capex) to operational costs (opex)

From an accounting perspective, organizations prefer to shift costs to the capital expense category due to tax benefits;  in addition, clouds allow for commoditization of IT infrastructure services that in the traditional way would require space, power, cooling and personnel to support those solutions. The biggest example is email; HOWEVER, this has to be reconciled with security requirements.

Access to these applications has to be granted to Active Directory users, but there are instances in which partners need access as well (who won't have AD accounts).  

A lot is stated in this paragraph.  In the context of Centrify User Suite this means:

• Deployment of Cloud Connectors (CC):  CCs are Windows computers that use the service bus to talk to the Centrify Cloud Service and internally to Active Directory.  They provide many capabilities, but the main one is the avoidance of explicit replication of data to the cloud. When planning for Cloud Connectors
• Keep in mind the requirements:  As you add more users, keep in mind that the cloud connector's cache will grow.  At the time of this writing Cloud Connectors require a 64bit system with a multicore processor and 8GB of RAM with 4GB dedicated for the cache.
• Availability requirements:  You need at least two cloud connectors for basic load-balancing and fail-over.  If you are in a multi-national organization, placement of the cloud connectors should be based on the data-center location in the cloud.
• Internal placement:  Like any AD services, the closer you are to a global catalog domain controller the better.
• If using the Microsoft CA, make sure that you place the cloud connector near an issuing CA.
• Connectivity:  Although cloud connectors only perform OUTBOUND connections, there are certain domains that need to be reachable.  A list is here.
• Active Directory permissions:  Although no changes will be made to AD (in terms of schema extensions or services) the computer running the cloud connector will be able to access AD.  Permissions are required for this operation.  The instructions are here.
• Allowing MDM capabilities from Active Directory Users and Computers (ADUC) and Group Policy Management:  You must plan which administrators will provide helpdesk-assisted MDM capabilities using ADUC or which AD admins will be allowed to edit Mobile-related GPOs.
• Use of the Centrify Cloud Directory:  In those instances in which third parties (contractors, partners) need access to internal apps, but can't have an AD accounts, this will be the preferred method.

These users may access using rich clients (browser) or mobile devices (iOS/Android browser and mobile apps);  connections can be centralized via a portal, directly initiated or via intranet shortcuts.  In the case of Office365, users will continue to use their full clients (Outlook, Lync, etc) on their Windows and Mac workstations.

This paragraph also contains major implications.

• Mobile Access:  This means that corporate information may be accessed from devices that aren't under the control of IT.  Fortunately User Suite provides Mobile Device, Container and Application management for iOS and Android.
• iOS:  Managing iOS devices means that an APNS certificate needs to be configured in the cloud service.  In addition, if apps are purchased by corporate or devices are running in kiosk mode
• Portals, Direct Connections and Shortcuts:  Centrify provides the cloud portal for self-service of apps, mobile and AD/cloud directory; however it's possible that users may access apps directly, in that case, users will be redirected to be authenticated by Centrify if they don't have an active valid session.  Shortcuts can be deployed in the intranet as well.
• The topic of Office 365 migration is huge, however, from a rich client perspective, this means that the lowest version of office has to be Office 2010 with the latest and greatest service packs.

Availability - As a global company, close to 100% uptime, geographical layout and redundancy are a most.

As of this writing, Centrify relies on a robust infrastructure (Microsoft Azure) to provide high performance, high availability and redundancy.  Stats on the availability of the service can be viewed at http://www.centrify.com/cloud/service-status.asp 

Disjointed Namespace - The solution should accommodate for a different domain (for AD) than the business name (Internet DNS name).  It uses corp.contoso.com internally, vs. centrifying.net outside.

This is very common;  typically the Active Directory suffix of the UPN (user principal name) is different than the DNS suffix commonly used to do business  (typically the suffix of the email address);  this means that a company may do business as na.ad.company.com;  but users of that region use @na.company.com as the common suffix.  Centrify User Suite provides settings to accommodate this scenario.

Go to Session I Lab Videos:  http://centrifying.blogspot.com/2014/12/labs-web-mobile-sso-planning-session-i.html

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.

Security Corner: Establishing an Identity and Access Governance Model for UNIX/Linux with Centrify and Active Directory - Part 1

Background

An Identity and Access governance model establishes how end users will access your systems, this entails

• Establishing the rules of who should have access to which system
• Establishing what functions (or privileges) they're allowed to perform or use
• Establish the provisioning process (Add/Moves/Changes)

But first, a quick refresher:

Provisioning

As defined by the dictionary, provisioning  means to provide, the reverse is to withdraw or to deprovision.  

In Identity Management, provisioning may mean User provisioning into different systems from an authoritative source.  User provisioning as per Gartner is a whole IT capability (and a source of much confusion)

In the context Identity and Access Management with Centrify for UNIX, the authoritative source is Active Directory;  regardless of how the Active Directory user is provisioned (manually, with an Identity Management solution like Oracle, Courion or Sailpoint, or with other tools) UNIX identity provisioning in AD can be performed in different ways.  With Centrify, the preferred method is with a SCP that contains the user's identity (created manually via Access Manager, or automatically with the ZPA).  

Fortunately, Centrify makes the integration very easy.  It's all about placing users in a security group in AD.

As a refresher, for an AD user to have access to UNIX system in a Centrify Zone, they need two things:

• A user Identity
• A role that allows the right to log in

Therefore, both identities and roles can be granted (provisioned) and removed (deprovisioned).  Centrify implements an RBAC model for UNIX that grants Access and Privileges.

The group nesting feature of AD can be leveraged
to provide Identity and Access with automation.

Access

In a properly managed enterprise, not everyone has access to all systems, and with Centrify you can implement virtually any governance model.  The design ideally is as flat as possible, with a single hierarchical zone and computer roles as the way to establish a governance model.  For example, in our lab we have a simple Access Model:

• Web Servers can be accessed by super users and web administrators
• Database Servers can be accessed by super users and DBAs
• Filers can be accessed by super users, and all UNIX users are listed in the system.

This model works great for our example, but we know that the real world is different.  The guideline is to try to enforce the least access principle.

In Centrify,  access is granted by direct assignment or by making a user a member of an AD group that has been granted the assignment (role granting group), the rest implies to manage the server memberships.

For example:  when a new web server is provisioned, it's dropped into the Web Servers group, and by way of the role assignment, all users that have access (and privileges) will get access automatically.

Privileges

With Centrify, in UNIX, the rights are:

• PAM Access: meaning, "how the system is accessed" or "what protocol"   this allows to grant access via the console and SSH for super users, but only SSH for the rest of the world.  We can go deeper into SSH rights, like allowing a secure file copy, but we aren't going to go that deep.
• Commands:  meaning "what can the user do?" "in the context of what account?" etc.  For example, a super user may leverage Centrify-enhanced sudo to run any command as root, but a DBA may only have one privileged command, like "su - oracle"

Note that Centrify can also perform privilege management for Windows, but that's a whole other topic.  In here, the idea is to start broad (define super users and regular users) and slowly adjust to provide people with the roles that give them just what they need, again, in accordance with the least access principle.

With Centrify roles, there are other settings that can be adjusted like:

• At what time is the role available?  (e.g.  backup operator that runs the tar command as root from 10pm to 4am)
• What is the shell experience for privileged commands (a whitelist of commands or a free-range shell)
• Is the role permanent or just temporary (like in a change control window)

In Centrify,  privileges are granted by direct assignment or by making a user a member of an AD group that has been granted the assignment.

Putting it all together

1. Centrify does not provision AD users, this happens upstream (manually, Idm, etc)
2. To access Centrified servers in AD in a zone a user needs an identity and a role that grants access and privileges.
3. Identities can be granted manually or automatically (by placing the user into an AD provisioning group)
4. Access and privileges can be granted manually or automatically (directly or by placing a user into an AD role-granting group)
5. The reverse of 3 and 4 is possible.
6. Automation and integration is always possible and very simple due to the link to AD groups.