Wednesday, October 28, 2015

Utilities: Access Manager's Analyze Wizard

Background

Maintenance activities are part of any IT professional's basic tasks, and Centrify provides many tools for administrators to facilitate proper maintenance and cleanup of Centrify-related objects in Active Directory;  as a matter of fact, it's expected that any customer of Active Directory maintains basic "etiquette" like:

  • alignment with established naming conventions:  for example;  in the context of a computer role.  What's more descriptive for the AD group?  "webservers"  or "centrify-unix-global-cr-webservers"
    The first one could be any web servers, including IIS; however, the second one follows a naming convention that goes from the general to the specific.  We know it's related to Centrify due to the name, used for UNIX-like platforms, in the global zone, it's a computer role (cr) and the name is web servers.
  • do not use software that makes direct LDAP connections to domain controllers, leverage software that is aware of the AD topology defined in Sites and Services
    This one may not be very clear to everyone.  Unfortunately many IT Pros equate AD to LDAP and that could not be further from the truth.  Active Directory maintains a topology and uses DNS to ensure high-availability; sites and services aware programs (like the Centrify base and audit agents) will switch and perform telemetry calculations.  The issue with straight LDAP binds is that depending on the application, it may spawn multiple threads of TCP connections that don't act like web connections, these are persistent connections that use CPU and memory. It is not fun when you get a call with the "j'accuse" an application for killing a specific domain controller.  When in doubt, use the Centrify LDAP proxy instead of connecting directly to an AD domain controller.
  • cleanup after yourself: when objects are not used, delete them
    This may come as no surprise, but looking at many deployments, I don't see very good hygiene.  Perhaps it's important to understand how the internal workings on how Active Directory stores data.  Active Directory uses the extensive storage engine (ESE, legacy name "Jet") - ESE data only grows in size in the operating system;  however the engine is very mature and resilient;  it will perform online defragmentation; in addition, replication only happens with deltas.  If you cleanup after yourself, although the size of the file (ntds.dit) will continue to grow, internally it may be able to reclaim space.
  • communicate  and work together with your AD team
    This one may be a shock to those who are still stuck in the early 2000s.  When you implement a cross-functional solution like Centrify Server Suite that combines Security Capability (Access Control) with Directory Services (Windows) and Open Systems (UNIX, Linux, Mac); there's an underlying expectation that you will work together as a team. This means understanding that there's a dependency on a utility service (Active Directory) that both users and critical apps are relying on.  Network folks also have a role here;  new subnets have to be communicated to the AD team for proper sites and services topology;  AD teams MUST consider UNIX, Linux and Mac teams when major changes happen like Domain/Forest functional levels change or when new type of DCs are added (e.g. Windows 2012 R2+).  Security folks also need to understand that instead of having things done for them (e.g. those dreadful reports); they can work to have those created for them on SQL Server or using automated tools like PowerShell.  The game here is to provide results for the business while maintaining a proper security posture, not the early 2000's immature battle of "My Linux does not go near Windows"

Common Hygiene Issues

  • Orphaned Objects:
    This one is the most common in my opinion.  An orphaned object is created when the parent of a child object is deleted and the child is left behind.  Some apps (like ADUC) are smart enough to delete any child objects if the proper plugins are installed;  e.g. Exchange, Centrify.  Some examples include:
    • Deleting a user object without deleting any UNIX profiles
    • Leaving the domain with adleave and teh --force option (offline leave) and not cleaning up the computer object in AD.  The proper way is to perform an adleave with connectivity with the --remove option.
    • Deleting zones without proper cleanup:  many customer are phasing out classic zones and not properly decommissioning them.
  • Unused Objects: Some examples include:  empty roles, unused roles, etc.
  • Improper permissions:  For example, a computer that can't update it's OS information.

The Analyze Wizard Tool

Centrify's Access Manager includes a Utility called the Analyze Wizard.  This tool allows for the identification and correction of common issues.

You can launch the Analyze Wizard from the left pane of Access Manager by right-clicking the DirectManage Access Manager [domain controller] node and clicking "Analyze"

Once launched, you can select the checks to be performed.

Once you run the Analyze tool, it will present its results in a brand new node in the left pane of Access Manager.

You can browse to the issues, as you right click them it will provide you an automated way to resolve the issues provided that you have the proper rights in Active Directory.

Thursday, October 22, 2015

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.
    Amazon Article - az checklist root account.jpg
    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.
    Amazon Article - az rbac.jpg
    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 Article - az checklist MFA.jpg
    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.
    Amazon Article - az checklist policy.jpg
    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

Amazon Article -the solution.jpg
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.

Friday, October 9, 2015

Utilities: install.sh

Background

Automation and orchestration are key capabilities of the modern IT infrastructure.  Whether organizations are using private or public clouds, tools like Bladelogic, System Center, Satellite, Chef, Casper, Puppet or homegrown scripts - software should be orchestration friendly.

Centrify Server Suite for UNIX, Linux, and Mac offers a facility that should be leveraged by any savvy IT infrastructure team.  The tool is a script called install.sh.

This script is shipped with the gzipped tarball for Centrify software, for example, here are the listings for a RHEL-based system (excluding the release notes):

  • adcheck-rhel4-x86_64
  • centrifyda-3.2.3-rhel4-x86_64.rpm
  • centrifydc-5.2.3-rhel4-x86_64.rpm
  • centrifydc-install.cfg
  • centrifydc-ldapproxy-5.2.3-rhel4-x86_64.rpm
  • centrifydc-nis-5.2.3-rhel4-x86_64.rpm
  • centrifydc-openssh-6.7p1-5.2.3-rhel4-x86_64.rpm
  • centrify-suite.cfg
  • install-express.sh -> install.sh
  • install.sh

Note that all the installation bits are shipped in the native package manager or the platform, this gives the opportunity to the administrator to bypass install.sh and use the native installer.  E.g.  to install only the base agent, you can run

rpm -Ivh centrifydc-5.2.3-rhel4-x86_64.rpm

Many admins just simply add the RPMs to their repositories and can use facilities like yum to install or maintain the package.

Capabilities of install.sh

  • Interactive install/join operations:  walks the user through a series of menus and options
  • Automatic with command options:  can be run manually or by an orchestration facility for installations and joins.
  • Automatic with an answer file:  any of the .CFG answer files can be used with install.sh
  • Kerberized:  install.sh calls adjoin and other utilities that can benefit from Kerberos keytab preauthentication.

What does install.sh do?

install.sh is a script;  it acts as an abstraction layer between the package manager of the native OS and any other tool or manual script.  This is very powerful because eliminates the nuances related to each operating system, architecture or distribution.

For example, some AIX systems use the installp facility, RHEL and derivatives use RPM, Debian derivatives like Ubuntu use dpkg, OS X systems use Install.app and so on;  install.sh allows for the administrator to have a QA tested way to install Centrify software and perform additional tasks.


When preparing for a release, Centrify will QA install.sh against all the supported platforms.


Basic Automation Playbook

What you need:
a) The keytab for an AD user that can join systems (or remove them) to the target OUs
For more info on how to create this, click here.
b) A krb5.conf file for a working system
d) Install.sh (or the native package manager utility)
e) If not using install.sh, you'll need adjoin (or adleave)

Sample Command Sequences

Sample 1:  In this sequence, we use an /temp/ad-joiner keytab with a /temp/krb5.conf and we'll use install.sh to install standard edition and join a zone called  myzone in the acme.test domain in the "My Servers" OU.

env KRB5_CONFIG=/temp/krb5.conf  /usr/share/centrifydc/kerberos/bin/kinit -kt /temp/ad-joiner.keytab ad-joiner

 ./install.sh  --std-suite  --adjoin_opt="acme.test -z myzone -c acme.test/My\ Servers"


Sample 1:  In this sequence, we use an /temp/ad-joiner keytab with a /temp/krb5.conf and we'll use install.sh to install standard edition and join a zone called  myzone in the corp.contoso.com domain in the "My Servers" OU.

env KRB5_CONFIG=/temp/krb5.conf  /usr/share/centrifydc/kerberos/bin/kinit -kt /temp/ad-joiner.keytab ad-joiner

 ./install.sh  --std-suite  --adjoin_opt="corp.contoso.com -z myzone -c corp.contoso.com/My\ Servers"

Sample 2:  In this sequence, we use an /temp/ad-joiner keytab with a /temp/krb5.conf and we'll use rpm to install the standard package and adjoin to join the Global zone in the corp.contoso.com domain and put the computer under the Centrify\Servers OU.

env KRB5_CONFIG=/temp/krb5.conf  /usr/share/centrifydc/kerberos/bin/kinit -kt /temp/ad-joiner.keytab ad-joiner

rpm -Ivh centrifydc-5.2.3-rhel4-x86_64.rpm

adjoin -z Global -c "ou=servers,ou=centrify" corp.contoso.com


install.sh Help file

This script installs (upgrades/uninstalls) Centrify Suite.
Only the superuser can run this script.

Usage:
  install.sh [-n|--ent-suite|--std-suite|--express] [-e] [-h] [-V] [-v ver] [-l log_file]

where:
  -n             Custom install/upgrade/uninstall in non-interactive mode.
  --ent-suite    Install Enterprise Suite in non-interactive mode.
  --std-suite    Install Standard Suite in non-interactive mode.
  --express      Install Centrify Express in non-interactive mode.
  --bundle       Install Centrify Suite using bundle.
  --suite-config <config_file>
                 Override default suite config file with <config_file>.
  -e             Uninstall (erase) CentrifyDC.
  -h, --help     Print out this usage and then exit.
  -V             Print out installer version and then exit.
  -v <ver>       Install CentrifyDC <ver> version.
                 Format: x.x.x or x.x.x-xxx. x is number.
  -l <log_file>  Override default log-file PATH with <log_file>.
  --rev <rev>    Package OS revision to install.
  --custom_rc    Return meaningful exit code.
  --override="<options>"
                 In non-interactive mode, override default options with <options> list.
                 Format: --override="CentrifyDC_openssh=n,CentrifyDA=R"
  --adjoin_opt="<adjoin_options>"
                 Override default adjoin command line options with <adjoin_options>.
  --enable-da    In non-interactive mode, once joined to a domain,
                 enable DA for all shells.
  --disable-da   In non-interactive mode, disable DA NSS mode after install.

Examples:
  ./install.sh        -n  --override="INSTALL=R,CentrifyDC_nis=Y,CentrifyDC_openssh=N,CentrifyDA=N"
  ./install.sh        --std-suite  --adjoin_opt="acme.test -p pass\$ -z t_zone -c acme.test/My\ Servers"
  ./install-bundle.sh --std-suite "--adjoin_opt=\"acme.test -p pass\\$ -z t_zone -c acme.test/My\\ Servers\""

Saturday, October 3, 2015

Business Problems: What does 'Secure' mean to you? Your answer may impact your ability to launch your BigData Project

We've had an opportunity to man the Centrify booth at the Strata+Hadoop show in New York this past week and we were constantly surprised by the focus on the core capability, but when we engaged passers by, the were unaware of the following facts:

  • A large majority of Big Data projects never make it into production
  • The most visible examples of Big Data projects that add value to organizations involve data that may contain Personal Identifiable Information (PII) or financial information.

It does not take a security expert to realize that these projects would be subject to the biggest security requirements.

When challenged, we heard answers like "but [management tool] can be integrated to Active Directory" (on the more informed side of the spectrum) or simply, people were focusing on areas like table-level security.

It became clear to me, that "to secure" a capability has a different meaning depending on who you ask (e.g. Big Data Scientist vs. Linux administrator vs. Security Analyst);  this is why at Centrify we always encourage the main stakeholder to bring in their infrastructure and security peers.

The key takeaway is that regardless of who you ask, there are reasons like
  • people: being able to find capable data scientists
  • data: availability of the data
  • cost
  • dynamics: integration with business processes
  • need: is it just a fad (business want to jump into the BigData bandwagon without real requirements)
But security will always come up, that's a common denominator across all Big Data.  We know this first hand because that's what we do.  Upwards of 60 of our customers are using Centrify to align their Big Data deployments with security requirements.

If you're tasked to launch a Big Data project, you have all the opportunity to get a leg-up on this problem and attack security early.

At a basic level you have to look at this in terms of layers.


To simplify, there's two of them:  The Identity/Infrastructure layer and the Big Data layer.  The concerns and focus are completely different.

OS Layer
I also like to call it the Identity/Infrastructure layer because it plays directly into what Identity and Access Management is set out to do:

a) Use a common directory to identify and authenticate users
b) Enforce the least access principle
c) Enforce the least privilege principle
d) Eliminate the human problem of shared accounts
e) Implement strong controls (e.g. end-to-end session auditing or multi-factor authentication) when needed
f) Be able to attest who has access to a system
g) Provide reporting and tools for attestation

Big Data Layer
I can't even pretend to advise on the Big Data layer, but all I know is this:
If you can't identify - you can't authenticate - if you can't authenticate, you can't authorize;  and if you can't authorize, you can't enforce strong access controls.  Regardless of Knox, Sentry and any other security initiatives at the Big Data layer, you need robust OS services to optimize those.

A promising future
We were also excited by the bright spots:  Cloudera, Hortonworks and MapR are taking security very seriously because they realized that this affects their ability to bring nodes into production.

Centrify is here to help!!!   Learn what we mean by "secure" - it's all about the OS Layer (Identity and Access Control)

Overcoming the Hadoop Security Challenges at the IAM layer with Centrify