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.

Basics: What constitutes a cloud identity?

Hola!! from Panama City.  At Centrifying we are tasked to represent Centrify in the ISACA Latin America CACS 2014.
We had a chance to educate the attendees in the challenges and concepts of cloud identity and SaaS access controls security.

Background

This new series focuses on Identity as a Service (IdaaS).  As you probably know by now, Centrify has two product lines Server Suite and User Suite.  The first basic topic is to understand what constitutes a cloud identity.  At a basic level, the identity that supports a SaaS application can be as simple as a unique identifier and a password; However, that doesn't translate into a very valuable app.

So what's the problem with SaaS apps as it relates to Identity?

Since SaaS apps extend the IT boundaries beyond the on premises data center over the Internet the most basic issues are around timely provisioning.  Once a user leaves the company if the offboarding process is not timely and efficient, the organization is exposed to a potential data loss.  Unfortunately, just like the issue with the  heterogeneous datacenter, the solution sets today promote capability and process fragmentation and here's where Centrify can help.  Furthermore, let's explore the problem by at further length.

The typical cloud IdaaS providers may make you think that the issue is just Cloud Identity and SSO (federation), but the problem goes beyond that.  Let's explore some aspects:

• License assignment:  this topic impacts the bottom-line.  How does your process makes sure that the user is properly licensed (no more than what they need), and that licences are administered accordingly.  

  

  Timely license management has cost implications

• Role, Profile or Group management:  Depending on the application, entitlements determine what the user can do within the application. This is key for sound security.
   

  

  Salesforce provides access to different functions based on the user's profile

• Multi-factor Authentication (MFA) and 2-Step-verification:  These capabilities are increasingly a must because they are the foundation for different types of policies.  The recent consumer services data-breaches illustrate that need.

  

  MFA and 2-step verification are a must nowadays, the issue is - how to standardize.

• Policies:  Each SaaS provider has a different way to deal with policies.  Would it be nice to do it in a single management framework? and wouldn't it be nice if it's enforceable across all endpoints including mobile devices?

  

  Different SaaS providers provide different policy frameworks

• Support for Mobile Device Management (MDM) Mobile Application Management (MAM) and Mobile SSO:  This capability is also a must;  as phones and tablets become more powerful, mobile computing is a big tool in the information worker arsenal.

  

  MDM has become commoditized, MCM is looking for a standard, but MAM and Mobile SSO are growing

Is there a Unified Solution out there that is friendly to Active Directory?

So the question is - What if there's a solution out there that allows you to use an existing infrastructure (AD) to solve all these issues without the need of additional infrastructure or the need of complex Identity synchronization?   

YES!

That is what Centrify User Suite is all about! The next posts will focus on the service and 3 apps: Google Apps, Office 365 and Salesforce.  The first post will explore what Federation is and isn't.  Look for the Cloud-labeled articles.

Troubleshooting: Understanding How Time Affects When Changes are Effective

The best way to summarize how time works in an AD environment that leverages Centrify agents for Unix, Linux and Mac OS X is to look at this formula:

Effective Changes = Σ(Provisioning, AD Replication, Cache Flush Interval)

Changes are additions, deletions or modifications of AD objects (LDAP).  This excludes real-time Kerberos transactions like authentication or password changes.

Provisioning

In Centrify for Unix/Linux, we call provisioning the action of assigning an existing AD principal (user or group) a UNIX identity (login,UID,GID,Home,GECOS,Shell).  In the case of users they also need a role to be able to log into systems; both actions can happen manually or automatically (via an Identity Management Solution that leverages the Centrify APIs, via the  Zone Provisioning Agent utility, or programmatically via Centrify PowerShell or Centrify adedit).
For example, in my environment I use ZPA and I assign the roles to AD groups so the management is simplified.  I've also nested my role-granting-group into the provisioning group.  This means that my modified equation is:

Effective Changes @ Contoso = AD Replication of Group Membership + ZPA Polling Interval + AD Replication of ZPA Provisioning + Cache Flush Interval)

Notice how my provisioning design has an impact on time.  I have potentially two actions that require AD replication and an agent that I've set up to poll every 15 minutes.

This means that a provisioning action can take as long as 15:30 from a provisioning + AD perspective in an intra-site scenario assuming (in the case of a user) that both the identity and the role were granted at the same time.

AD Replication

If you're relatively new to Active Directory and don't have an idea on how AD replication works, read these links and come back:

Basic Concepts: http://technet.microsoft.com/en-us/library/cc731537%28v=ws.10%29.aspx
How it works:  http://technet.microsoft.com/en-us/library/cc772726(v=ws.10).aspx 

In case you did not read the links above, the basic problem is that when you have a replicated database changes take time to propagate.  AD Sites (fast connected subnets) have internal (intra-site, shorter) and external (inter-site, longer) replication periods.

Intra-site replication is somewhat predictable.  A DC will notify to its nearest partner of a change within 15 seconds and this will cascade within a site.  Older versions (like Windows 2000) were set at 5 minutes.

Unfortunately in larger global environments AD inter-site replication times vary. It all depends how the AD team has tuned the environment based on the inter-network topology.   This is why to be an effective Centrify administrator you need to be in constant communication with your AD team. Replication affects availability for users and definitely affects your SLAs.  The best solution at a higher level is to use Microsoft's recommendations for AD replication in large environments and that they maintain current Subnet, Site and Domain Controller information.  This is very important.

That being said, there are things that you can do to make sure things happen faster. 

For example, if there is a new add/move or change and the target is a key server in a specific location, you can log into the server and find out what domain controller the server is currently talking to with the adinfo command (or adinfo --server).  If you're making the provisioning via ADUC, adedit or Access Manager, make sure you're talking to the same DC.  At that point you basically have eliminated AD time from the equation and you can issue an adflush when these changes are made.

If you're using The Windows PowerShell Centrify commandlets, you can use the echo %logonserver% command in a windows prompt to find out which domain controller you're currently talking to.

Centrify Agent Cache

We've talked about the cache in previous posts;  however, all you need to know that to improve performance and to provide high-availability the Centrify agent for Unix, Linux and Mac does not bother AD persistently to ask for changes;  this happens by default every hour.

Putting it all together

Looking back at my example, this means that in an intra-site scenario with two domain controllers like in my lab contoso environment, the length of time for an effective for a user change can be as long as 65:30 minutes. Because it takes up to 15 seconds for replication to happen on the provisioning/role granting action, up to 15 minutes for ZPA to poll, 15 additional seconds for the ZPA change to propagate and up to 60 minutes for a Centrified system to update its cache.

How to perform manual add/moves/changes in an effective matter

1. Determine the key system, and issue an adinfo command to determine the domain controller the agent is talking to.  (adinfo --server)
2. With that information, connect your ADUC or Access Manager consoles to the target DC.  (on AM, use the "Connect to remote forest" option; on ADUC use the "Change Domain Controller" option).
3. Perform your changes in AD (add/moves/changes)
4. Perform an adflush in the target system  (if it's a local override, you need to restart the agent)
5. Verify the changes with adquery, dzinfo, etc.

Note:  Flushing the cache (by interval or manual with adflush) is an expensive operation, I recommend that you keep the default cache flush interval of 3600 seconds (one hour) and try to establish a proper Service Level Agreement for these operations.

Troubleshooting: My brand new users aren't available or can't log in

Background

This is probably the most common task to troubleshoot is user's availability in a system.  Granting access to a brand new user (or users) to a system.  The user may or may not be available to the system or can't log in.

In this initial article, we will cover the mechanisms to minimize replication and techniques on how to rule out issues with the user's AD account.

What you've probably done so far:

1. You set up a Centrify zone or child zone with the corresponding user and group defaults
2. You've configured authorization (computer roles, UNIX rights, roles and role assignments)
3. Installed the Centrify agent and joined one or two Unix or Linux systems
4. You're trying to test a user or two but have no luck

Symptoms:

Unfortunately, your user does not show up in the system (adquery user does not show the user or users), possibly the user shows up, but can't log in;  Maybe the user shows up and can log on after a long time (undetermined time).

Remember:

By default in zone mode (unlike in Express mode) no users have access to the Unix, Linux (or Windows) systems that belong to the zone.  

Troubleshooting Checklist

We can use a two-category technique to troubleshoot this issue.  We can divide it into time and configuration items.  Time can be proactively managed and configurations can be verified and ruled out.

• Enough time should have passed for
• Any Identity Management tool to work (IdM solution, ZPA or program)
• AD replication to complete
• The cache flush interval complete (or the adflush command issued in a target system)
• In order to access a Unix/Linux system, a user needs an identity and a role
• To get an identity: the AD user has to be added to the zone to get a login, UID, GID, GECOS, Home and Shell based on the zone defaults to get an identity
• To get a role:  the role has to be assigned to a user directly or to a group that the user is a member of.
• The role needs to have at least the intended PAM logon right for the user to be allowed to log in.
• The role assignment has to be properly scoped (Zone, Child Zone, Computer Role or System level)
• The role has to be properly created:  logon options, hours, auditing, etc.
• The user's AD account should not be subject to any restrictions (logon, computer)
• The user's AD account should be usable (not expired, disabled or locked)
• The user is not listed in the /etc/centrifydc/user.ignore file
• The user principal has to be readable on the correct side of the one-way trust

Where to go now?

• First, try to understand how provisioning, AD replication and the agent's cache can affect when changes are effective.
• After you've ruled out time, now learn how to rule out the user's AD account.
• Learn how to spot configuration issues
• Learn how to use the addebug tool
• WIP...

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.

Labs: Centrify Zone Provisioning Agent - Installation, Configuration and Testing

Background

ZPA is a Centrify utility that can be used for automatic provisioning.  It can UNIX-enable Active Directory users and groups.  Read this post to learn about ZPA:
http://centrifying.blogspot.com/2014/01/basics-automatic-unix-profile.html

Installation

Configuration and Testing

Errata

- Identity overrides can happen at the zone level, child zone level and system level.
- It's recommended that you install in the Centrify common components (for troubleshooting purposes)
- The UNIX Super Users group also needs to be nested  in the provisioning group, otherwise they will lose their UNIX profile.
- The ZPA account needs to be made a local administrator in APP1 (if you want the troubleshooting components to work)
- The Provisioning tab under zone properties needs to be installed on CLIENT1 using ZPA setup.