A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 3

Background
This is the third article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure the Amazon Root account.
In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source. 

About Amazon AWS Identity and Access Management (IAM)
For those who aren't familiar with Amazon IAM, it provides capabilities that allow organizations to centrally manage Users, Roles, Rights and Policies efficiently for all services (compute, storage, database, application) provided by the platform. 

Another Identity Silo
Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception.  Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider.
Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.  The typical tasks include user creation, credential/password/key management, password resets, group/entitlement management and attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:



Once we adopt this "dual-management" we are promoting IT fragmentation, the potential consequences are complexity, limited productivity and possible security expose.  Finally, depending on the data classification or risk profile of the assets in AWS, this identity silo is subject to the corporate security policy (password policies, user attestation reporting, least access management, etc.)

In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect. 

This article provides a practical example that not only meets but exceeds the best practices around Amazon AIM, eliminates dual-administration and aligns administration with internal policies.

Using Centrify CIS & Active Directory to Secure Amazon's IAM
In this post I describe a framework to leverage Centrify Identity Service  to meet and exceed the Identity Management requirements for Amazon AIM while maintaining the corporate directory (AD) as the single-source of truth. 

The example used in this blog post focuses on Active Directory, however, those who are familiar with Centrify know that the user sources can be or any other internal LDAP source, Google Directory, Federated Partner or even Social Identity providers.
The solution outlined below establishes a SAML federation agreement between Centrify Identity Service (CIS) acting as the Identity Provider (IdP) and Amazon AWS IAM acting as as the Service Provider (SP);  Since CIS will be using Active Directory principals as an identity source, AD continues to be the single-source of truth for the enterprise and AD group memberships, AWS IAM Roles and CIS roles can be used to manage entitlements.

Enhanced Objectives

• Eliminate duplicated administration efforts and align Amazon IAM users with corporate policy
• Leverage AD Group membership (or CIS Roles) for Amazon IAM provisioning (add/moves/changes/deletions)
• Leverage AD Group membership (or CIS Roles) and IAM Groups for Entitlement Management
• Provide SSO to Amazon AWS with minimal federation infrastructure required
• Enforce Advanced Policies: Require Multi-factor Authentication or Enforce Access from the Corporate Network
• Limit access to IAM credentials to those with business need-to-know

Planning
Stakeholders

• Identity and Access lead:  Organizes and coordinates the effort.
• Security SME: Outlines the security requirements based on policy or risk profile
• Infrastructure SMEs: Execute the implementation of the tasks

Planning Discussions
Below are planning discussions that can be had around IAM:

1. What are the services being used in AWS? Will there be a process defined when new services are used?
2. Are there any AWS IAM Groups that provide separation of duties (e.g. EC2 Management vs. IAM Management)?
3. Will Active Directory Groups be mapped to AWS IAM Groups? or Will Centrify Roles be used?
4. Will contextual policy be needed?  E.g. restrict access to corporate sites, geo-fencing or time-fencing?
5. What will be the attestation process for AWS users?  (e.g. AD Group Management or CIS Roles/Reports)
6. Will Multi-factor authentication be required for IAM users?  What factors (Centrify MFA, Amazon Virtual Token (OATH), SMS, Phonefactor or Email?
7. Will approvals be required for IAM access?  (Request/Approval)
8. Will just-in-time provisioning be used (E.g. AD group addition triggers an AWS IAM provisioning)?
9. Will SAML, OpenID Connect or Amazon's API be used to establish AWS integration? 
10. Will users be allowed to log in with their AWS password or just with SSO?
11. How will users be uniquely identified in AWS? (should shortname, email, UPN or another field be used?)

 Our Example

• The organization uses Amazon EC2 to hosts servers in the cloud
• There are two types EC2 of users:  Users with Full Access and ReadOnly Users.
• Users with full access will be managed via AD Security group Membership (AWS-EC2-FullAccess)
• Users with read-ony access will be requested on-demand (must be approved) via a CIS Role;
• Another group (AWS-IAM-Managers) can manage IAM in AWS and will approve requests.
• All users must provide step-up authentication via Token, Email, SMS or Phone to access AWS
• The implementation will use the Centrify-provided SAML template
• The Centrify-Provided PKI Certificate will be used for the SAML Assertion
• Users will be identified in AWS with their Shortname.

 Technical Requirements

• Active Directory with security groups created and populated
• Centrify Identity Service Tenant
• A Member Server running the Centrify Cloud Connector with the AD Proxy capability enabled and connected
• An Amazon AWS Account and a user with IAM rights to create an Identity Provider and Roles

Implementation
This process implies a partial configuration in CIS, followed by the configuration in AWS, finishing-up in CIS again.

Initial Configuration in Centrify Identity Service
Add and Configure the Amazon Web Services (AWS) Console: SAML+Provisioning

1. In Cloud Manager, navigate to Apps > Add Web App
2. In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS Console SAML+Provisioning" template and click Add.
   
3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
4. In Application Settings:
   - Type your AWS Account ID (if you don't know it, go to "My Account" in AWS)
   - Click the "Download SAML provider metadata document"  link, this will save the XML file in your downloads folder
   
5. In Description, give the application a descriptive name (e.g. AWS Role-Based SSO)
6. Skip User Access and Policy (we'll revisit)
7. In Account Mapping , use the "Use Account Mapping Script" option and type the following:

   LoginUser.Username = LoginUser.Shortname

   This option will send the user's shortname as the identifier.  If there are duplicates, you can switch to mail or UPN.
8. Press Save, you'll have to return here for adjustments.

Configuration in AWS
Create the Centrify SAML IDP

1. Sign-in to AWS and navigate to Security and Identity > Identity and Access Management
2. On the left pane, click Identity Providers and press the Create Provider button on the right
3. Select SAML in provider type
4. In provider name type a descriptive name like "Centrify" or "CentrifySAML"
5. In Metadata Document, browse to the downloads location where the XML file from step 4 above was saved, press Next Step and press Create.

Configure the AWS IAM Roles for the Centrify SAML IdP

1. On the Amazon AWS IAM Dashboard, Click Roles > Create New Role
   The names of the roles about to be created must match the role names in Centrify Identity Service.
2. Example: EC2 Administrators - this role grants the ability to manage all aspects of EC2 instances, therefore a policy that matches that entitlement has to be tied to the role.
   Name: AmazonEC2Admins
   Role Type:  Role for Identity Provider Access > Grant Single Sign-On (WebSSO) access to SAML providers [Select]
   Establish Trust:  SAML Provider > Select Centrify > Press Next Step
   Verify RoleTrust: Press Next Step
   Attach Policy: type "AmazonEC2FullAccess" and Check the box
   This corresponds to the administrative role for EC2 instances
   Review:  Press Create Role
3. Repeat the process for the rest of the roles.  Make Sure that you are writing down the names of the Roles.

Finishing the Configuration in Centrify Identity Service
Create and Populate the Centrify Identity Service Roles

1. In Cloud Manager, navigate to Roles > Add New Role
2. Name: AmazonEC2Admins  (must match the name of the corresponding role in AWS)
3. Members: Populate based on your requirements.  For AmazonEC2Admins I'm leveraging AD membership
   
4. Press Save.
   Repeat with any other roles created in AWS

Complete the User Access Section of the AWS Role-Based SSO App

1. In Cloud Manager, navigate to Apps > Click your AWS SAML App
2. Go to User Access and check the box on the roles you've created.
   
3. Press Save, you are ready to verify.

Verification
At this point you can verify access.  If using Active Directory, simply add a user to any of the AD Security groups that grant access and the user will get the App automatically.  Upon clicking on it they'll be able pick the role (or roles, in case of multiple entitlements) and simply press sign-in.

They should only be entitled to the activities allowed by the policies associated with the role.  For example, in the case above the user will only be able to manage EC2 instances and details, no more than that.


Adjustments
Adding Multifactor Authentication , Limiting Access from the Corporate Network and Workflow and Approvals

• MFA is built-in to Centrify Identity Service.  All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set.  These include and are not limited to:  Centrify's Mobile Authenticator, Phone call, SMS, Security Question, Email or OATH Based OTP (Duo, Google Authenticator, Amazon Virtual OTP)
• To limit access based on the corporate IP range, all you need to do is populate the NAT addresses for the organization and check the appropriate box.
• To establish a workflow and approvals scheme, a role needs to be designated as the approver, see the video playlist below or the one included in part two to view the particulars.

Provisioning of IAM Users
There are instances in which it is desirable to have a provisioned user inside AWS IAM.  What needs to be reconciled is if users will know their IAM passwords, in that case they can go directly to the sign-in page and bypass the controls outlined above.  We can extend the SAML template to provide provisioning capabilities as well.

Enhancements of CIS 2016.2
Amazon AWS provides an virtual MFA capability that leverages OATH.  As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.

Video Playlist

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 2

Background
In a previous entry, I wrote an article titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" and I described the use of Centrify Identity Platform and Active Directory  to implement enhanced security controls to protect AWS deployments.

In this first part, we'll address how to secure the AWS Root Account.  Amazon suggests protecting the root account with Multi-Factor Authentication, however, in this article I'm describing a strategy to not only meet but exceed the requirements to protect this account.



Enhanced Objectives

• Eliminate sharing of the Amazon AWS root account
• Protect the password by not exposing it to any users
• Limit access only from the corporate network
• Limit access to the AWS account to those with business need-to-know
• Activate MFA with Centrify Step-Up Methods (Mobile Authenticator, Phone factor, SMS, Email, Security Question)
• Activate MFA with Amazon's OATH-based virtual MFA

The Value of Centrify Identity Service
Centrify Identity Service provides a powerful policy engine that allows for the implementation of these controls, not only for the Amazon AWS app, but for any web application that has a user/password authentication pattern and uses a shared account.

As customary, we'll use the Plan-Do-Check-Adjust methodology.

Planning
Role-Based Access Control
- Should the application always be accessible by a limited group of users?
   - Should application access be governed by AD group membership or Centrify Role?
Should the application be accessible to nobody and only requested on demand?
   - Who will approve the application access request?

Additional Controls

• Should the application be accessible only from the corporate network?
• Should the application be accessible at certain times?
• Should the application require step-up authentication.
• What should be the step-up mechanisms? (Centrify MFA, OATH OTP, Phone factor, Email, SMS, Amazon Virtual OTP,  etc)

An example
Access Control will be controlled by AD group membership (e.g. AWS-Root-Users); ad-hoc access will be controlled via workflow. The app will be accessible with a step-up mechanism. The approvers will be an AD group called AWS-Root-Approvers.

Implementation
This implementation steps assume you have a Centrify cloud connector set up providing bridging for an AD domain.

Access Control Building-Blocks
Create the AD Groups

1. In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.
2. Create Two AD groups:

- AWS-Root-Users: add the permanently authorized users.
- AWS-Root-App-Approvers: add a set of users that will approve access requests (ideally not the same as above to enforce separation of duties)

Create the AWS Root Role
Members of this role will have permanent access to the AWS Console as root. This is controlled by AD group membership.

1. In Cloud Manager, navigate to Role and Click Add Role
2. Description: AWS Root
3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

 
Create the AWS Root Approvers Role
Members of this role will be able to approve who gets to access this app. This is controlled by AD group membership.

1. In Cloud Manager, navigate to Role and Click Add Role
2. Description: AWS Root Approvers
3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

Configuration in Identity Service
Add and Configure the AWS User/Password App

1. In Cloud Manager, navigate to Apps > Add Web App
2. In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS User/Password" template and click Add.
   
   
   
3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
4. Description - in this step you will change the name to something descriptive to your environment. 
   
5. User Access - check the box next to the role you created for this purpose (in our example AWS Root)
   
6. Policy - we'll revisit this in the "Adjustments" section.
7. Account Mapping - This is where you'll securely store the AWS credentials. Select
   a) Select "Everybody shares a single username"
   b) Populate the username with the AWS root account email address and the password with the current password.
   
8. Press Save, you're ready for initial testing.

Verification
At this point you can sign-in to Centrify Identity Service with any user in the AWS Root CIS role or an access request can be triggered via the "Add Apps" menu of the User portal.

1. Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role
2. You should see the AWS As Root App.  Click on it.
3. This should launch a new browser tab and provide you with assisted injection of the credentials using the Centrify Browser Extension.
4. You can also test the Access Request/Workflow capability by logging in with a user that is not entitled to the application, then click "Add App" and search for the newly-created app. 

Adjustments
Limiting Access only from the Corporate Network
This is desirable if you want to make sure users can only access the AWS console from the on-premises corporate network. The planning steps imply the addition of corporate subnets to the Centrify Identity Service Settings and using the Policy tab of the AWS Root App to enforce these controls.

Adding Multifactor Authentication or Other Controls
MFA is built-in to Centrify Identity Service.  All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set.

Enhancements of CIS 2016.2
Amazon AWS provides an virtual MFA capability that leverages OATH.  As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.

Video Playlist

Business Problems: Using Centrify on Mixed Kerberos Environments (UNIX, Linux, OS X)

Background

Organizations typically use Centrify's Server Suite to simplify the implementation of Kerberos by using Active Directory and the DirectControl (adclient).  However, in special situations, there may be a need to support independent MIT Kerberos realms along with Active Directory participation.

Active Directory and Centrify:  Plug-n-play Kerberos for UNIX, Linux and Mac

Aside from establishing a secure communications channel with AD, provide identity information and privilege management, in UNIX, Linux or OS X systems, Centrify takes care of the Kerberos environment.  At a high-level, here's what happens:

Kerberos Configuration

• Configuration: The /etc/krb5.conf file is modified to include information about Active Directory's Kerberos realm, this includes encryption levels, realms (domains), KDCs (domain controllers) and trusted realms (using Microsoft's Kerberos extensions)
  This capability is very convenient, because when AD administrators add or decommission domain controllers or establish trusts, there's no need to go back and update the krb5.conf file.
  In failover scenarios, authentication also "just works" provided there's communication with the target DCs.
• System Key Table: The system keytab (typically /etc/krb5.keytab) is updated with entries for the Service Principal Names (SPNs) and information required for it to work in Active Directory.
• Kerberos Tools:   Centrify's MIT Kerberos tools are placed in the /usr/share/centrifydc/kerberos/bin folder.  These tools are optimized to work with Microsoft's Kerberos extensions.  In addition, tools like adkeytab are available to administrators.  adkeytab provides much more robust capability than traditional tools like kutil.

Other Configuration:
Name Resolution:  Although the Centrify's adclient will respect the settings in /etc/resolv.conf, Centrified clients support advanced capabilities like Dynamic DNS updates and maintain an independent DNS cache.  Part of the telemetry calculations performed when making sure DC connectivity is optimal include DNS sweeps.
Time Synchronization:  Kerberos has a mechanism to deter replay attacks that relies on KDCs and Kerberos clients to keep with a skew of 5 minutes or less.  Upon system join, system time uses the AD domain controllers as time source.

Finally, there's the issue of Kerberos principal format.  With Centrify, regardless of the case sensitivity of the AD user or UPN (Kerberos expects user@REALM) , Centrify will always work Active Directory implementations.

 

What about support for Mixed Environments?

Centrify has very large organizations that may fall in the following categories:

• Government, commercial, educational or research organizations that have MIT Kerberos realms defined, but need to provide interoperability while they migrate completely to Active Directory.
  We have also seen this with commercial organizations that have implemented MIT Kerberos realms for a particular application (e.g. Hadoop), but are ready to eliminate the duplicity and complexity introduced.
• Organizations that have legitimate reasons to maintain MIT Kerberos implementations for critical apps or other situations.

There are 3 categories of implications:

• Name resolution implications:  In an ideal scenario, DNS is always symmetric and hierarchical; but we've seen situations in which systems have asymmetric configurations.
• Time source implications:  Although ideally, all systems sync up time with a hierarchical time source, sometimes IT organizations are quite fragmented.
• Kerberos configuration implications: 
• The Centrify client will only write information about local and trusted Active Directory realms and KDCs
• The system keytab is automatically set up or overwritten by adclient during system join.

With all those challenges, the idea is to eliminate additional complexity. 

 

Centrify Parameters to Support Mixed Scenarios

Here's a sample mixed scenario:

In a normal Centrify setup, James won't be able to log in or use tools in the EXAMPLE.COM realm, however everything will work fine for UNIX-enabled users in the corp.contoso.com.  Other key areas are the different time sources and potential asymmetry of DNS.

To overcome these issues, Centrify has 4 parameters (with corresponding Group Policy Objects):

adclient.krb5.autoedit:  when set to true (default), centrify's agent will maintain the system's Kerberos configuration (/etc/krb5.conf) file.  when set to false, the file will be left alone.

adclient.krb5.keytab:/path/to/file.keytab:  when set, this parameter will enable administrators to place the keytab used with AD in a different location than the default system keytab (/etc/krb5.keytab)

dns.dc.domain_name:  This configuration parameter allows administrators to specify domain controllers that service the target domain.  E.g.
dns.dc.corp.contoso.com: dc1.corp.contoso.com dc2.corp.contoso.com

adclient.sntp.enabled:  This parameter tells the agent if it will use the Windows Time Service running in the domain controller as the time source.


Tradeoffs
With this unorthodox configuration (basically multiple authentication sources) there tradeoffs;  part of the reason of any Centrify deployment is to promote simplicity.  Once the autoedit parameter is introduced, organizations lose the automatic maintenance of AD topology for Kerberos, however, this can be managed via group policy, or any config management tool (like Chef, Puppet, etc), but it requires constant communication between the UNIX/Linux or Mac administrators and Active Directory Administrators.
The benefit here is that Centrify has the maturity and flexibility to support these kinds of scenarios.

Centrify's Value Proposition - Part 3: Privileged User/Identity Management with Least Priviliege

In the third part of this series, we'll discuss how Centrify provides solutions for privileged user/identity management and maintains these principles:

a) Eliminates identity silos

b) Implements strong access controls without interfering with the user experience

c) Use what you have: infrastructure, processes, knowledge (less IT fragmentation)

d) Promotes operational efficiency

e) Provides strategic value, rather than tactical solutions

Organizations come to Centrify for privileged identity management or privileged user management because of combinations of the following challenges or circumstances:

•  Overall: They want to increase accountability and implement strong privileged user identity and access controls based on a common identity repository.
• They have Active Directory and multiple platforms, but primarily for UNIX, Linux and Windows
• They have a traditional (on-premise only) or hybrid (public/private cloud) enterprise
• They want to eliminate the use of shared credentials or persistent administrative accounts (root, administrator, “-a”, etc)
• Their existing solution does not provide flexibility on grouping systems based on a security governance model
• They might have chosen to implement a password-centric approach as their unique strategy and they’ve come to realize that their users are less productive (or supportive), that they’ve duplicated identity silos and that ultimately, their systems (the main goal) aren’t protected by it.
• On UNIX: They understand that using sudo/sudoers, although it’s mature may not be enough for high-risk, highly-regulated enterprises; they are tired of the complexities of managing a sudoers file and want more granularity and flexibility
• They want a higher-degree of control on how their users access systems (beyond just granting/denying access) cross platform.
• On Windows, they want to eliminate the problem of the Local Administrator, are conscious of the “pass the x” attacks and want to eliminate the “camping” issue with “-a” accounts.
• They need to provide separation of duties (operational rights vs governance rights)
• They need timely reporting of who has access to what system(s), what are their privileges, and what granted them access to do this.
• They don’t want to deviate from existing processes or realized that by implementing point solutions or “best of breed” they ended-up fragmenting their IT in the context of processes.
• They have regulatory requirements that they need to meet or exceed.  These may be SOx, PCI DSS, HIPAA, NERC, FERC, etc.
• They want to solve the Shared Account Password issue, but they want a solution that reflects the state of modern trends (they hybrid datacenter, IaaS, mobile-first, etc)
• They have high-security requirements like FIPS, solutions common-criteria certified, perhaps they rely heavily on Smart Cards.
• They want log aggregation that is simple to their native tools (ARCSight, LogLogic, Splunk, etc)
• They may need to go beyond the traditional security operations and provide session capture and replay from anywhere (remote or via console) because today they don't have that capability, are required to have it or simply, they might have gone the "jumpbox" route to realize that they are missing crucial sessions.
• They hate having to invest in multiple solutions to enforce the same basic security principles.  Each time they do, this may mean:
  - Evaluate a product
  - Invest or procure new hardware or software
  - Add additional infrastructure
  - Train or hire specialist
  - Maintain the solution down the road
  - Manage the vendor relationship

Here's a technical demonstration on how Centrify delivers this value:

The key differentiation areas are:

• AD Orientation - implemented in more of 90% of enterprises, users use a unique identity.
• Centrify Zones - unique patented way to create groups of systems in Active Directory
• Granularity of Access Controls - control HOW users log in to systems
• Granularity of Privileges - no need to know the privileged account password.
• Simple privilege elevation:  sudo-like tool in UNIX/Linux, shell and command line on Windows.
• No proprietary magic on how events are stored: no need to have a central system just to know who did what and when - need to rely on a central system to correlate who had a privileged account.
• Quick attestation and robust reporting - the data is in AD.
• Separates the operational tasks versus the governance tasks - to enforce SoD
• Works in multiple core platforms:  UNIX, Linux and Windows
• Protects your systems: Provides end-to-end enforcement of the rules as well as session capture and replay.

Finally, the end user experience is not affected, no identity silos are created  and your AD infrastructure, processes and technology are reused.  We propose that the "least access/least privilege" approach to Privileged Identity/Super User Privilege Management should be used at least in 80% of the use cases.

In the next post we're going to talk about the next 20%, this includes Shared Account Password Management, Proxied/Brokered/JumpBox initiated sessions (what gartner calls Privilege Session Management).

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.

Centrify's Value Proposition - Part 2: The hybrid and heterogeneous enterprise

Organizations with traditional (on-premise) and  hybrid (private/public cloud) with Active Directory, come to Centrify because:

• They have diverse platforms (UNIX, Linux, Macs) in their enterprise (on-premise and in the cloud).
•  They are looking to Centralize the administration (or implement effective controls) for user access in those different platforms.  Their reasons may be due to security, regulation, operational efficiency or simply because they are reacting to an audit or other event.
•  They are also looking to leverage the secure authentication methods provided by Active Directory. 
•  They are looking to find a way to effectively manage UNIX identities by using Active Directory, but preferably, they don’t want any schema extensions to AD or software loaded in Domain Controllers.
• Some other organizations (and this is quite common on the Mac side) are looking for a more robust way to support AD integration and are also looking to use a common management framework (like Active Directory Group Policies) to enforce security policy or configuration management policies.
• Other organizations are looking to focus on their core competencies because perhaps they invested a lot of engineering cycles using open source software (like Samba/Winbind, RedHat’s SSSD, OpenLDAP with MIT Kerberos) and realized that the speed of requirements and diversity of platforms does not align with their goals.  (E.g. a Financial organization spending hundreds of man hours on “manual” identity and access controls rather than portfolio analysis).  These types of organizations are ready for a solution that “just works”
• Organizations want solutions that are friendly to private/public cloud scenarios; this means a toolset that promotes automation.
• The organization may have high-security requirements like smartcard authentication, FIPS encryption or common-criteria certified solutions
•  Finally, some organizations tried to wait as long as they can keeping the status quo; and a compelling event has made them change like:

• Change of leadership

•  A merger or an acquisition

•  A new technology (like BigData)

•  Acknowledgement that advanced persistent threats can’t be ignored

•  Another solution isn’t providing timely updates, proper support or their future is uncertain

• An audit or data-breach

•  Perhaps there’s an old infrastructure (e.g. NIS, LDAP) that found fresh blood that isn’t afraid of “touching the server, who knows what will break”  <= yes, this sadly happens.

Everything I outlined above is core of what some analysts call “Active Directory Bridging” but when you look at it is much more; it is the basis for implementing critical access controls and a management framework that is based on reuse of existing infrastructure and processes rather than point solutions.  It’s also the foundation of making sure users can do their work, without interrupting their flow.

Here’s a technical demonstration on how Centrify provides value:


 A very unique capability that is exclusive to Centrify is the zones technology.  Nobody else can do what Centrify does to group systems in a hierarchical way while consolidating UNIX identities for Users, Groups and NIS Maps.

Note that also, a large number of "born-in-the-cloud" organizations are coming to Centrify for Web Application SSO and Enterprise Mobility.  We will cover that in other entry.

In the next post, we'll focus on how Centrify builds on their AD bridging capabilities to provide Privileged User Management on UNIX, Linux and Windows and how it uses it's Identity Platform for secure access and shared account password 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.

Implementing the Centrify's Account Prevalidation Capability on UNIX, Linux and OS X using Group Policies

Requirement
In case of an Active Directory catastrophic failure, a limited set of trusted administrators shall be able to log in to UNIX, Linux or OS X systems and perform the actions defined in their privileged management roles.

Scenario
Contoso has 3,000 servers and many of them on branch deployments and public clouds, there are no DCs in the branches.  WAN connectivity can be lost and a mechanism to allow trusted administrators to perform actions should be available.  It's highly unlikely the set of trusted admins have logged in to all systems. This is why Centrify implemented the account prevalidation feature.

Tools and Targets

• Group Policy Management
• Active Directory Users and Computers
• CLI tools:  adgpupdate, adgpresult, setspn & PowerShell(windows)
• Configuration files:  /etc/centrifydc/centrifydc.conf

 Planning

• Target Group:  Account prevalidation can be assigned to users or groups.  Ideally this would be assigned to groups so the management can be delegated to the Helpdesk, or front ended by an ITSM or Worfklow solution.
  This means that an AD Group should be requested.  Sample Name:   Centrify-Prevalidated-Admins
• Process: 
  Onboarding:  When senior UNIX, Linux or Mac OS X administrators are onboarded, the user template or form should be updated so they are added to this group by default.
  One-offs:   When critical projects are going on and stakeholders need to be added to this group, our ITSM tool will front end a workflow request that ends on a PowerShell action that adds (or removes) the user from the target group.
  Attestation:   This group does not have any additional rights, however it has to be attested as part of the disaster recovery plan.

Implementation
What you'll need

• Centrify Standard Edition or Centrify Identity Service Mac Edition  (licensed)
• A Windows system with Group Policy Management and the Centrify Group Policy Extensions (GPOE) installed
• An Active Directory group pre-populated with the users that will be prevalidated
• A GPO tied to the OU of the target UNIX, Linux or OS X systems.
• Rights to edit the GPO
• Centrified system in the OU that has the GPO linked to verify.

First, Gather information about the members of the group

From a Centrified System 
$ adquery group -A Centrify-Prevalidated-Users | grep members
members:centrifyimage.vms/Staff/IT/Diana Wirth

From Windows with PowerShell
PS > get-adgroupmember Centrify-Prevalidated-Users | Select-Object samaccountname

samaccountname
--------------
dwirth
rpimentel

Second, Configure the GPO

1. Open Group Policy Management
2. Create or edit the GPO in the corresponding forest/domain/OU.
   
3. In group Policy Editor, navigate to Computer Configuration > Policies > Centrify Settings(*) > DirectControl Settings(**) > Account Prevalidation.  In the right pane, double-click on "Specify allowed groups for prevalidation" select Enabled and populate the dialog box with the group predefined for this purpose and press OK and close Group Policy Editor.
   
   (*) If you don't see a Centrify Settings section, you don't have the Centrify GPOE installed.
   (**) If you don't see a "DirectControl Settings" folder, you need to add the template.

Third, Add the Preval SPN to the members of the group and commit the changes in the Centrified system

a) To add the SPN

# From Windows with the setspn utility
C:\> setspn -A preval/rpimentel rpimentel
Checking domain DC=centrifyimage,DC=vms

Registering ServicePrincipalNames for CN=Diana Wirth,OU=IT,OU=Staff,DC=centrifyimage,DC=vms
        preval/dwirth
Updated object

# From Windows using PowerShell
PS > Get-ADUser dwirth | Set-ADUser -ServicePrincipalNames @{Add="preval/dwirth"}

# From a Centrified System Using adedit
## Authenticate as someone who can edit the target object
$ kinit administrator
Password for administrator@CENTRIFYIMAGE.VMS:

# Open adedit, bind to domain and use the add_object_value function
$ adedit
>bind centrifyimage.vms
>package require ade_lib
1.0
> add_object_value "CN=Diana Wirth,OU=IT,OU=Staff,DC=centrifyimage,DC=vms" serviceprincipalname "preval/dwirth"
1
> exit

# Manually using Active Directory Users and Computers

1. Open ADUC
2. In the View menu, check "Advanced Features"
3. Open your target user > Attribute Editor > servicePrincipalName
4. Click add, and type  preval/<user>, press OK twice.

b) To verify the SPN was added succesfully
# from a Centrified system using CLI

$ adquery user dwirth --attribute servicePrincipalName
preval/dwirth

# from Windows using PowerShell
PS > Get-ADUser dwirth -prop ServicePrincipalNames | Select-Object Name, ServicePrincipalNames

Name                                  ServicePrincipalNames
----                                  ---------------------
Diana Wirth                           {preval/dwirth}

c) To commit the changes to a system for the purposes of testing

## flush the cache - only if you want this immediately (will happen automatically after cache flush interval + gpo refresh
$ dzdo adflush
DNS cache flushed successfully.
Authorization cache store flushed successfully.
GC and DC caches expired successfully.
DA name cache flushed successfully.
DA installation information cache flushed successfully.


## perform a group policy update - again, this happens on the GPO refresh.
$ adgpupdate
Refreshing Computer Policy...
Success
Refreshing User Policy...
User Policy disabled on this machine.

## verify that the GPO inserted changes in the config file
$ adgpresult | grep Centrify-Prevalidated-Users
        adclient.prevalidate.allow.groups = Centrify-Prevalidated-Users,

Notes:  This process can also be implemented with a Management tool like Chef, Puppet, Spacewalk, etc.  Ultimately the parameter that will be adjusted is the "adclient.prevalidate.allow.groups" in the /etc/centrifydc/centrifydc.conf file.  This can also be part of a master config file that is enforced across the board, but watch out for conflicts with GPOs.  You must pick a tool.

Verify and Test
 To verify prevalidation you'll need a recently centrified system OR a system that you know one of your test subjects has never logged in.  You will also have to switch the agent to offline mode.  There are two ways to do it:
a) If this is a VM, go to the hypervisor console, and disconnect the network; OR
b) Force the agent to go offline by adding all your DCs to the dns.block parameter.
E.g. if I have 2 DCs  (dc1.corp.contoso.com and dc2.corp.contoso.com), the parameter would look like this:

dns.block:  dc1.corp.contoso,com, dc2.corp.contoso.com

c) If you have console access, you can also disable the network interface momentarily.

This video explains the installation and testing process:


Adjustments
 There are several areas of improvement for this process:

Automation
A really cool improvement has to do with the automation of the prevalidation SPN.  For example, you can implement both in a Centrified UNIX/Linux system or with Windows PowerShell script that checks if new users are added to your target group, and automatically will add (or remove) the preval SPN.

Service Management and Approvals
If you have an ITSM (like ServiceNow) or an IdM with workflow/approvals, you can front-end this process by adding references and approvals to be able to answer these questions:

• Why is this user a member of this group?
• Who approved?
• What's the reference number

Mac OS X Extras: Using Centrify and your Windows Infrastructure to provide 802.1x EAP-TLS to Mac OS X Systems

Background

Secure access to Wifi or Ethernet networks is a goal of any security conscious IT infrastructure team, however diversity of platforms makes this goal very hard to achieve, especially when organizations are looking to standardize but have diverse client platforms.

In a Windows world, capabilities such as Active Directory Certificate Services, Group Policies, the Network Policy Service and Windows clients make this goal relatively simple.  The popularity of Mac Workstations has forced many organizations to face this challenge.

The good news is that Centrify has worked very hard to make sure that IT Infrastructure folks can leverage their existing Windows infrastructure to solve this challenge on the macs.
The challenge for any technical lead is that the expertise required just to meet the prerequisites is going to be scattered all over the organization; this means that it's time to flex the ability to coordinate and get people to work together.  Hopefully this post provides a lot of clarity.

How easy is it to implement?

It is as easy as enabling one of the Centrify-provided GPOs for Mac OS X.  Specifically the "Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1x Settings" and you can pick your flavor:

• Enable Machine Ethernet Profile
• Enable Machine Wi-Fi Profile
• Enable User Ethernet Profile
• Enable User Wi-Fi Profile

However, this entry would not be useful if I just show you that you can enable the GPO, perform a policy refresh and just like magic: network access.

What I've noticed from prospects or customers that are looking to test these capabilities is that they don't understand all the moving pieces that need to be in place in order for this to work. 

In this post we'll use a checklist to make sure that you understand what needs to be in place to be successful.  

Note:  If you already have 802.1x EAP-TLS running with your Windows infrastructure today, you are very well-positioned for success.

Pre-Requisites

• About adcert
• Certificate Auto-enrollment on Mac OS
• Lab Setup: Microsoft Test Lab Guide (read on the PKI parts)

Building Blocks

Active Directory and Windows Services:  There are several ways to accomplish this goal, but in this particular instance, because our goal is to consolidate processes, knowledge and infrastructure, we are leveraging Windows capabilities like Active Directory, AD Certificate Services and the Network Policy Service.  AD Groups will be key to provide access controls;  OUs will determine the scope of GPOs to be used.

Public Key Infrastructure:  PKI is needed to provide the encryption, non-repudiation and authentication between the back-end infrastructure (Active Directory) and the client (Ethernet or Wifi).  The key here is the certificate life-cycle management, this is where Windows PKI uses Group Policy.
PKI Disclaimer:  PKI is not joke.  Any proper implementation needs to provide the assurances that PKI is aligned with your security policy.  If your organization does not have a policy for PKI (general assurances, handling of private keys, policies, templates,  Root and SubCAs) consult an expert.

A Policy/Configuration Management Engine:  Group Policy provides the rules and the enforcement for configuration items and even provides certificate auto-enrollment - a way to manage the certificate lifecycle (issuance, renewal, revocation, etc); in addition, GPOs will be the way that Centrify will provide the Apple profile information.

Network Policy Service: The NPS service on Windows provides the services like Remote Authentication Dial-in User Service (RADIUS) and the policy rules to enable 802.1x.  The NPS Service interacts with Active Directory to leverage groups and attributes.

802.1x-Capable Network Devices:  Any modern switch or access point supports 802.1x EAP and RADIUS.

Centrify Agent for Mac OS X:  This use case showcases the power of the Centrify agent.  Not only it leverages its ability to integrate with AD, but to use advanced services and perform this cohesively within the MacOS platform.  Key capabilities:  Certificate Auto-Enrollment, System Profiles, GPO Engine.

The Lab

• For AD and PKI:  Modified Microsoft Test Lab Guide:  Provides the corp.contoso.com domain with a running Microsoft CA.  The RootCA (corp-DC1-CA) certificates are deployed using GPOs.
  Translation:  A common Certificate Authorithy with the proper Certificate Revocation publication methods needs to be provisioned. I did not set APP1 as a SubCA.
• For RADIUS and Policies:  I'm piggybacking on my APP2 Windows 2012 server
• Network Devices:  I'm using Cisco small business (300 series) switch and a TPLink (TL-WA90x) Wireless Access Point.
• Mac Client:  Old Macbook running 10.7 and Centrify 5.2.1

Basic Checklist

OS X System is Centrified
Centrify agent is connected  (run adinfo -m)

PKI Checklist

All Systems have a Root CA in their trust chain?
The Network Policy Server has a computer certificate?
A proper 802.1x certificate template was set up for Mac Systems?
The Mac Auto-Enrollment GPO has been properly deployed?

Was the computer Certificate on the Mac based on the proper template?

You may need to look in the CA's Issued Certificates.

With PKI it's all about consistency.  All systems trust the Enterprise CA; All Certs are Issued by the CA or SubCAs and Programs (like NPS) are using the same trust chain.

NPS/Network Device Checklist

RADIUS clients have been set up properly on the NPS Server
RADIUS servers are properly configured on the network devices
Is there connectivity between RADIUS clients and servers?

Connection Request Policies are set up appropriately (Conditions/Settings)
Network Policies are set up to Allow access based on Conditions
Clients Meet the Conditions

Any conditions added (like AD group membership) must be met in order to have successful connections.

For example, if you're using a condition in which your Mac has to belong to a group called "Mac Workstations 802.1x" you can use the 'adquery user -A computername$ | grep MemberOf'  command to enumerate the AD groups that the computer belongs to

$ adquery user rpmacbook$ -A | grep memberOf

memberOf:corp.contoso.com/Mac/Corporate/Mac Workstations 802.1x,corp.contoso.com/Users/Domain Computers

802.1x Mac Group Policy

Is the Mac System Wifi-capable?
Wifi SSID is correct?
Template Name is correct?

The template Display Name may be different than the template Name

Has the policy been refreshed?  (adgpupdate - remember replication!)
System Preferences > System > Profiles contains payload?

Connected?


Video Playlist