Centrify Identity Service named in the leaders for 2016 IDaaS MQ

This is a testament to a lot of hard work from Product and Engineering teams.  Tip of  my hat!

Gartner MQ:  https://t.co/8bMQDFFoHG  (must have a Gartner account)
Centrify Blog by Corey:  http://goo.gl/w14ZmM

A Playbook to Secure your Amazon AWS Server Infrastructure using Centrify and Active Directory

Background

Amazon AWS EC2 is quickly becoming one of the most popular options for Enterprises to extend their Data Center infrastructure out in the cloud. IaaS vendors like Amazon provide an array of services that include directory services, orchestration, automation, APIs and more.
It's important to understand that flexibility can slowly become chaos, especially for enterprises that have fought hard to consolidate processes around Identity and Access Management.
This multi-part series discusses a basic IAM playbook that can be enabled with Centrify’s Identity Platform (Identity Service, Server Suite and Privilege Service). The principles continue to be the same: Implement Strong Access Controls using what you have: Active Directory as the Identity Store and enhance the experience and security controls leveraging Centrify Technologies.

Part I - The Requirements and Challenges

Identity and Access Management Requirements

1. Secure Access to the Amazon Root Account
   The experts at Amazon will be the first to tell you.
   
   Don't use your Amazon root account as the means for regular administration. Don't share it. Look at this account only for break-glass scenarios
2. Use Role-Based Access Control
   This is another best practice documented by our friends at Amazon.
   
   However, what's not very obvious is that you may want to do this from a common identity source. We don't want AWS to become an additional identity silo.
   Remember, there's always attestation needs. We need to be able to report who can perform which actions in the Amazon Console. 
   Also, remember, RBAC needs not only apply to the Amazon console, but to the systems that are running in the IaaS cloud;  you must be able to enforce the least access, least privilege, separation of duties and be able to attest or report which users has access to each system, what can they do with privilege and how they got granted the access.
3. Use Multifactor Authentication
   
   Amazon recommends strong controls for the root account; however, We argue that we have to apply stronger controls like being able to access the console only from on-premises in some cases (or example, when using the amazon root account) and apply MFA across the board in cases where the user is accessing externally.
   
   The challenge for many organizations is that Multi-factor Authentication is also a fragmented capability, because most IAM vendors until recently have not considered it a must have.
   There’s also the issue of modern use cases. Physical OTP tokens are expensive and don’t provide enough information for the modern enterprise. We need more significant information and workflow-like capabilities and to be able to use that same scheme in other use cases, like when elevating to use your privileges.
   Since all roads point to the mobile device in your pocket, this means strong Enterprise Mobile capabilities to secure that device as well.
   
   Finally, wouldn't it be better to go beyond MFA and be able to apply stronger policies?  Perhaps only allow access to the AWS console only from your on-premises infrastructure?  Provide authentication policies that request MFA before the user's password?
4. Apply a Security Policy
   This is another item in the Amazon checklist, they specificaly talk about passwords.
   
   However, organizations with mature security practices understand that using a common identity store (like Active Directory, used in 90%+ organizations) also allows for consolidating policy definition and enforcement.
   Amazon systems can be integrated to the common directory for the purposes of Access Control.
   This step requires the extension of your corporate IT directory to the IaaS infrastructure. This can be accomplished several ways (in the case of AD). A resource domain with a 1-way trust and a site-to-site VPN, an RODC, etc.
   
   The benefits of this approach include less IT fragmentation and complexity, and consolidation of processes and tools, however, the solution should be ready for automation and orchestration; one of the principles of public/private clouds is elasticity, this means that if machines are spun up or down, the tools should have simple ways to satisfy these needs.
5. Session Management
   Systems in the Amazon cloud should be accessed in a way that allows for accountability, centralization of access and enforcement of strong policies. Although it's possible to access directly via Amazon, this tends to open itself to challenges with sessions and key management.
6. Password Management
   Finally, we need to eliminate the human challenge of shared credentials. Accounts like root, Administrator and any others should be brokered with a repeatable process: request/approve-check-out-check-in-rotate.

Part II - The proposed Solution


Part III - See the Solution in Action



Series
Part 2 - Protecting the Root Account with Centrify Identity Service
Part 3 - Implementing Amazon IAM using Federation with Centrify Identity Service
Part 4 - Securing Linux and Windows EC2 Instances using Centrify Server Suite and AD
Part 5 - Securing Password and Sessions using Centrify Privilege Service

This article was originally published in the Centrify Community.

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.

Labs - Web-Mobile SSO Planning Session I Videos

The videos below correspond to the first planning session for the Web-Mobile SSO use cases.

Lab 1 - Centrify User Suite Branding and Domains



Lab 2a - Cloud Connectors and Active Directory Integration



Lab 2b - Cloud Connectors and Active Directory Integration



Lab 2c - Exploring the AD Integration using Centrify Cloud Connectors



Lab 2d -  Understanding Login Suffixes

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

Business Cases - Web/Mobile SSO Case Requirements

We will start a series focusing on the Centrify User Service and to give it the right context, just like we did a year ago with Server Suite we are basing this in a set of business requirements.

Here's a summary of the requirements:

Web and Mobile SSO
Our organization currently uses Salesforce, Office365, Google Apps, Sharepoint (internally), has Apache/Java (internally) and they need SSO;  some of these apps are SAML, WS-Fed, User/Password or may be using the Centrify on-premise app plugins.

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).  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.

Security Requirements
Confidentiality - no synchronization of personal identifiable information off premises; encryption in traffic and at rest is required.
Access Control - the security department wants to have the flexibility to set policies that allow to control access based on time/day, network or geographical location (to limit apps to be intranet accessible only, not via the web);
Step-up Auth - One-time-passwords (two-factor) should be an option for sensitive use cases.
Governance -   Entitlement management and separation of duties should be enforced.
Availability
Availability - As a global company, close to 100% uptime, geographical layout and redundancy are a most.

Infrastructure Requirements
Business Requirement - The IT organization wants to shift capital expense (capex) to operational costs (opex);
Self-Service - the solution should provide flexible self-service options to minimize calls to the help-desk.
Office 365 - all features (rich or web clients) should be supported, ideally without added infrastructure complexity.
Decrease VPN usage - ideally this solution should provide alternatives to VPNs for internal-only apps.
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.

Other Requirements
Project Management and Methodology - the PMO would like to use the same methodology (DEV-QA to PROD) for this project.
Marketing - Branding and imaging should be maintained.


Go to Planning Session I:  http://centrifying.blogspot.com/2014/12/business-cases-web-mobile-sso-planning.html

News: Making Strides!

I'm very proud to see that Centrify has been named as a Visionary in the Identity as a Service (IdaaS) providers.

Gartner
https://www.gartner.com/doc/2756517/magic-quadrant-identity-access-management
Centrify
http://www.centrify.com/lp/gartner-magic-quadrant-for-idaas/

Exciting times!!