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.

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.

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\""

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

Understanding the Patterns for Identity Consolidation and SSO enabled by Centrify with AD on UNIX, Linux and Macs

Background

In the almost two years of Centrifying we have discussed Identity Consolidation with AD and Single Sign-on at length.  90% of organizations have Active Directory but sometimes over-complicate things when it comes to identity consolidation and SSO.

I had the chance to speak about this in a seminar and these two videos consolidate many entries that we've covered in this blog over the years.

Direct Integration

Name Service Switch, Pluggable Authentication Modules, GSSAPI, Kerberos and Proxies

• OpenSSH SSO over an outgoing external non-transitive AD one-way trust
• NSS and PAM using Oracle DB as an example (externally identified user)
• GSSAPI using MongoDB
• Kerberos using Hadoop (MapR example)
• LDAP Proxy to enable Couchbase console access.

Web-Java, SAP and DB2 Plugins

SPNEGO Plugins (Apache/Java);  ERP Plugin (SAP Netweaver, SAPgui), DB2 Plugin

• Apache SPNEGO
• JBoss SPNEGO
• DB2 Plugin
• Toolset:  Centrify-enhanced psftp;  addns, adcert

Conceptual Diagram

The idea is to eliminate complexity and promote reuse by committing to Active Directory, let the Centrify DirectControl agent do the heavy-lifting for Direct Integration and use the SPNEGO plugins when needed.


For the full briefing, including marketing slideware go here.

Basics: A Primer on Active Directory External One-Way Trusts with Centrify on UNIX, Linux and OS X

Background

Active Directory trusts are a broad topic and we typically have conversations with UNIX, Linux or Mac SMEs are excited about Centrify capabilities, but don't understand the purpose of trusts.

As a matter of fact, sometimes even the AD SMEs don’t understand the types of trusts in their own environment; this has the makings for interesting conversations.
The purpose of this blog post is to provide a primer on AD trusts (mostly by way of references) and to cover the considerations of Centrify deployments on the most popular type of trust: The external forest one-way trust.

I think that especially now that I see a lot of organizations extend their AD infrastructure to IaaS (like Amazon, Azure, Rackspace, etc) it's very important to know how these trusts work and what are the considerations to their Centrified systems.

What you need to know to understand this article
You must understand Active Directory basic concepts like forest, domain, sites, domain controllers, global catalog, DNS, and network connectivity.   A quick search should yield some interesting results;  you can also look at my personal blog.

My next advice will be to read about trusts and how authentication works with them, but this can be a very long and deep read. The best article about how trusts work is this one:
https://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx

Continue reading, and keep in mind, the main object of this article is to help UNIX, Linux and Mac OS X Centrify administrators get a basic understanding of external one-way trusts plus key-in on considerations for their Centrify deployments.

Needless to say, if you're supporting Centrify you need to know the basics like Zones, DirectControl, DirectAuthorize, Access Manager, Centrify PowerShell, etc.

Basics

Why Active Directory trusts exist?
There are several reasons, some of them are backward-compatibility, support for Kerberos realms, etc., however the most common reason is to support the account-resource model.

What is the account-resource model?
It's a security model in which user and group accounts exist in a centralized realm and resources (systems, apps, files, etc) exist on a different realm.

Notice the direction of trust, vs. the direction of access.  Believe it or not, if you understand the concept outlined in this illustration, you will get one-way trusts with ease.

Note:  The account-resource model is just one reason why AD trusts exist.  The key reason is the modern enterprise;  Global companies need ways to accommodate different access models especially when mergers and acquisitions happen too.  Since the modern enterprise is changing to expand the barriers of the datacenter, more capabilities will be created to support these scenarios.  AD one-way trusts, RODCs, etc are just some of the tools of the trade.

Other facts about Active Directory Trusts:

• There are different types of trusts: External, Real, Forest, Shortcut
• Trusts have transitivity: non-transitive, transitive
• Trusts have direction: one-way, two-way
• Trusts have scope: trusts may allow domain-wide or selective authentication

A reference model to understand External one-way trusts


The layers are:  TCP/IP (network communications), name resolution, active directory and Centrify layer.  The idea is that the model mimics the OSI model, in which if a lower layer fails, the upper layers won't work either.

TCP/IP Layer

There are different communications requirements for things to work as expected, but we need to concentrate first in what kind of traffic we will be dealing with.

The considerations for communications are very important especially in DMZ scenarios;  the key here is that most likely there’s conversations between 3 different subject-matter-experts:  the UNIX, Linux, Mac SME, the AD SME and the Network/Firewall SME.

• Traffic between forests to establish the trust relationship in the first place  (not in scope for this article, but read the Network Ports used by Trusts section of this link.
• Traffic between the Centrify AD client and its local domain controllers
• Traffic between the Centrify AD client and remote domain controllers (from the trusted domain) for referrals (see below in the AD layer)
• Traffic between systems with AD tools and Centrify tools for referrals and the object picker (see below in the AD layer)
•  If DirectAudit is in use:  Traffic between the audit agent and the collector and between the collector and the database and management server.  <= this will be discussed later
• If DirectSecure is in use, GPO traffic to obtain PKI certificate auto-enrollment and IPSec rules implies connectivity between domain controllers (to get GPOs) and CAs or SubCAs to get the certificates themselves.   <= this will be discussed later

The ports required for AD communication can be determined very quickly with DirectControl, (just run the “adinfo –T” command)  but here’s a summary:

• TCP 53 (DNS) -  without name resolution there’s no communication.  Period.  This means that A and SRV records must be resolvable by all systems on each side of the trust relationship.
•  TCP 3268  (Global Catalog):    In AD, a domain controller with the Global Catalog role contains a partial replica of all objects in AD.  Global Catalog placement has performance implications.
• TCP and UDP 389 (LDAP):  This should be self-explanatory.
• TCP 445 (modern Server Message Block):  This is optional, but required for GPOs used for config management.
• TCP 88 (Kerberos KDC):  Self-explanatory;  this the port for Kerberos communications.
• TCP 464 (Kerberos password change):  This is the port for password change operations 
• TCP 123 (SNTP):  This is optional, to sync time with the domain controller’s Windows Time Service.
• Ephemeral ports(*):  These are often overlooked, but these are the high-ports used for socket communications.

(*)Note: Microsoft has changed the ephemeral port range over the years and the best way to see the ones that apply to your version of Windows is to look at the output of the netsh command with some options:

C:\Windows\system32>netsh int ipv4 show dynamicport tcp

Protocol tcp Dynamic Port Range

---------------------------------

Start Port      : 49152

Number of Ports : 16384

Bottom-line:  Expect to allow communications from Centrified systems and management stations to at least two domain controllers from your trusted forest. 

These can be read-only DCs  (RODCs) and depending on forest complexity, these may have to be Global Catalog.

This is not an issue on flat networks, but definitely more complex high-security scenarios like DMZs.

In the illustration above, this is a post-trust establishment scenario with one RODC in the trusting side and a firewall only allowing traffic for the RODC to be updated by the trusted domain DCs.

Both referral traffic from Centrified systems and management stations are serviced by the RODC.
Note:  This is just one way of going about this scenario, there are several ways with pros and cons.

Name Resolution Layer

Name resolution by way of DNS is often overlooked by many administrators, the key to understand here is that Active Directory clients use Kerberos for authentication and in a "Kerberized" world there’s no functionality without being able to resolve names;  DNS symmetry is key;  fortunately most AD deployments use domain controllers as DNS servers, but in scenarios in which other DNS servers are used, DNS Zones holding AD SRV records have to be accessible. 

In my demo environment, I used the “conditional forwarding” capabilities of Windows DNS.

Note that I can get away with this because my network is flat.  If I was dealing with a DMZ scenario I would either host a replica and protect it with firewall rules or IPSec encryption for DNS traffic.

For legacy apps, careful thought must be given to short names, especially watch out for duplicity or short names exceeding 15 characters.  Read the best practices for naming in Active Directory.

In addition there's the issue of Kerberos realms vs DNS Names:  with active directory these are often the same, but it does not have to be like that.

Active Directory Layer

The AD layer deals with all the Active Directory-related capabilities needed for the trust to work as expected and these include trusts, referrals, object picking, authorization and group scoping

Trusts

Because this topic focuses on the external non-transitive one-way trust, it’s important to know it may be selective; but to keep things simple, let’s assume it’s a domain-wide trust.

Going back to the basic principle with an example illustrated in the figure below.

If Fabrikam (HQ) trusts Contoso (CORP), that means that users from the corp.contoso.com can access resources from hq.fabrikam.com; 

Trusts are set up with a dual authorization (just like launching a rocket).  If you look at Active Directory Domains and Trusts for both sides you’ll see this:


The non-transitivity of the trust is what provides the assurance that accounts from the trusting domain won’t be able to access resources from the trusted domain.

Authorization

We have talked about authentication in most of this entry, but we haven’t addressed authorization.  

Going back to the basic principle of the example:

"If hq.fabrikam.com trusts corp.contoso.com, that means that users from the corp.contoso.com can access resources from hq.fabrikam.com"  

HOWEVER, this does not mean that users from corp.contoso.com have any privileges on hq.fabrikam.com;  this will only happen if it’s explicitly granted. 

The common practice in a centralized account-resource model is to add the Global Domain Administrators group from the trusted domain into the Builtin Local Administrators group from the trusting domain, this will allow for Centralized administration, and since there’s really no accounts used by users in the resource domains (other than contingency or service accounts), the unique credential principle is maintained.

This has implications to the Centrify best practices and we’ll discuss this on the Centrify layer.

Group Scoping

A key concept in the access model is group scoping.  In a nutshell it means that security groups (the groups used for authorization) have different scopes:  Universal, Global and Domain Local. 

The key here is that Domain Local groups can contain principals (users/global groups) from the local domain and any trusted domain.  Global groups can only contain principals from the same domain.

For the sake of simplicity I will ignore Universal groups.  Please see this article for an in depth comparison.

The best practice is to Assign Rights (or entitlements) to Domain Local Groups and add users or Global Groups to the Domain Local group.  From that point on, the add/moves/changes of rights and entitlements are managed via group memberships.

See the example above:   The Domain Local Administrators group from hq.fabrikam.com contains the Global groups from corp.contoso.com and hq.fabrikam.com and the local Administrator domain account.

Referrals

I’ve mentioned referrals before in this topic. 

A referral happens when a system from the trusting domain has to authenticate a user from the trusted domain.  Let’s look at an oversimplified example:

•  If the system centos66 in hq.fabrikam.com needs to authenticate user joe@hq.fabrikam.com, the authentication will happen locally against the fab-dc1.hq.fabrikam.com domain controller.
•  If the system centos66 in hq.fabrikam.com needs to authenticate user jerry@corp.contoso.com, provided that the user has a UNIX identity and a role that allows login, the authentication will be referred to dc1.corp.contoso.com to satisfy the request.

The same thing happens with Windows systems or tools like ADUC, Access Manager, PowerShell, etc.

For more information, please read the “Kerberos-Based Processing of Authentication Requests Over Forest Trusts”  section of this link.

Object Picker

When using tools like Active Directory users and computers or Access Manager, in order to pick foreign principals you use the object picker. 

Here’s an example below:

This screenshot is from Access Manager running from the trusting forest (hq.fabrikam.com)  and corp.contoso.com is the trusted external forest.

This means that in this case, the Access Manager console must have at least 2 layers (communication and  name resolution) in order to get to this point;
Note:  The fact that we can get there does not mean that we can browse the trusted forest, we must have a valid AD account from that forest.  Remember, we are going against the direction of access.

Contrast with this:

This screenshot is from Access Manager running from the trusted domain (corp.contoso.com) notice that you can’t even pick from the trusting domain (hq.fabrikam.com) because of the fundamental way trusts.  Principals from the trusting forest can’t access resources in the trusted forest.

This sounds like a broken record, but believe it or not, this is the main source of confusion for the IT leads we work with.

Centrify Layer

This layer covers the behavior of Centrified systems when an external one-way trust is established, management tools, and how the best practices change in the account-resource model.

Verifying TCP/IP Connectivity using Centrify CLI Tools

Like I explained before, the adinfo –T command will be very handy.  Let’s look at the output of this command from two perspectives:

corp.contoso.com (trusted)

hq.fabrikam.com (trusting)

[george@cen1 ~]$ adinfo -T && adinfo -T hq.fabrikam.com Domain Diagnostics:   Domain: corp.contoso.com     DNS query for: _ldap._tcp.corp.contoso.com     DNS query for: _gc._tcp.corp.contoso.com   Testing Active Directory connectivity:     Global Catalog: dc1.corp.contoso.com       gc:       3268/tcp - good     Domain Controller: dc1.corp.contoso.com       ldap:      389/tcp - good       ldap:      389/udp - good       smb:       445/tcp - good       kdc:        88/tcp - good       kpasswd:   464/tcp - good       ntp:       123/udp - good Domain Diagnostics:   Domain: hq.fabrikam.com     DNS query for: _ldap._tcp.hq.fabrikam.com     DNS query for: _gc._tcp.hq.fabrikam.com   Testing Active Directory connectivity:     Global Catalog: fab-dc1.hq.fabrikam.com       gc:       3268/tcp - good     Domain Controller: fab-dc1.hq.fabrikam.com       ldap:      389/tcp - good       ldap:      389/udp - good       smb:       445/tcp - good       kdc:        88/tcp - good       kpasswd:   464/tcp - good       ntp:       123/udp - good

[rpimentel@centos66 ~]$ adinfo -T && adinfo -T corp.contoso.com Domain Diagnostics:   Domain: hq.fabrikam.com     DNS query for: _ldap._tcp.hq.fabrikam.com     DNS query for: _gc._tcp.hq.fabrikam.com   Testing Active Directory connectivity:     Global Catalog: fab-dc1.hq.fabrikam.com       gc:       3268/tcp - good     Domain Controller: fab-dc1.hq.fabrikam.com       ldap:      389/tcp - good       ldap:      389/udp - good       smb:       445/tcp - good       kdc:        88/tcp - good       kpasswd:   464/tcp - good       ntp:       123/udp - good Domain Diagnostics:   Domain: corp.contoso.com     DNS query for: _ldap._tcp.corp.contoso.com     DNS query for: _gc._tcp.corp.contoso.com   Testing Active Directory connectivity:     Global Catalog: dc1.corp.contoso.com       gc:       3268/tcp - good     Domain Controller: dc1.corp.contoso.com       ldap:      389/tcp - good       ldap:      389/udp - good       smb:       445/tcp - good       kdc:        88/tcp - good       kpasswd:   464/tcp - good       ntp:       123/udp - good

This confirms that Centrified systems in Fabrikam will have no issues with queries or referral traffic.

Centrify Agents and Trusts

On startup, join, forced cache expiration or when the 8-hour domain discovery threshold is met, the Centrify agent interrogates domain controllers and if required, it will update its Domain Map.

A key command to review the domain map is the “adinfo --sysinfo domain”; let’s look at the output from both sides               

corp.contoso.com (trusted)

hq.fabrikam.com (trusting)

$ dzdo adinfo --sysinfo domain AD Password: System Diagnostic ========Domain info map======== DC=corp,DC=contoso,DC=com     CN              = CORP.CONTOSO.COM     SID             = S-1-5-21-2180375406-786980114-1643973036     TRUST_ATTRS     = 0x20     TRUST_DIRECTION = 3     TRUST_TYPE      = 2     NTLM NAME       = CORP     LOCAL FOREST    = YES CN=hq.fabrikam.com,CN=System,DC=corp,DC=contoso,DC=com     CN              = HQ.FABRIKAM.COM     SID             = S-1-5-21-2165579280-668341325-710928106     TRUST_ATTRS     = 0x0     TRUST_DIRECTION = 1     TRUST_TYPE      = 2     NTLM NAME       = HQ     LOCAL FOREST    = NO

$ adinfo --sysinfo domain System Diagnostic ========Domain info map======== DC=hq,DC=fabrikam,DC=com     CN              = HQ.FABRIKAM.COM     SID             = S-1-5-21-2165579280-668341325-710928106     TRUST_ATTRS     = 0x20     TRUST_DIRECTION = 3     TRUST_TYPE      = 2     NTLM NAME       = HQ     LOCAL FOREST    = YES CN=corp.contoso.com,CN=System,DC=hq,DC=fabrikam,DC=com     CN              = CORP.CONTOSO.COM     SID             = S-1-5-21-2180375406-786980114-1643973036     TRUST_ATTRS     = 0x4     TRUST_DIRECTION = 2     TRUST_TYPE      = 2     NTLM NAME       = CORP     LOCAL FOREST    = NO

The key fields here are the trust type and trust direction.  Direction 3 means two-way (always with the local domain),  Direction 2 means one-way;

Workstation Mode vs. Zone Mode

In my test environment in the trusting (resource) domain (hq.fabrikam.com) I have two systems:

• A CentOS 7 system joined in workstation mode called cen2
• A CentOS 6.6 system joined in zone mode called centos66

Workstation mode (Auto zone) won't work in a 1-way trust scenario.   The reason has to do with the way AZ generates UNIX identities.  The UID/GID parts of the UNIX identity are generated on the fly based on the user or group's Active Directory SID (unique identifier), however since the system is in a resource forest, based on the security model it can't even read the object's SID.  The alternative is to use Centrify Zones. 



Note:  AutoZone will work over a transitive 2-way trust.
 

In Zone mode, only authorized users from the local and trusted forests that that have been UNIX-enabled will have access to the system. When you use Access Manager and use the object picker to select an object from the account domain, you must do so with a authenticated user from the trusted domain, at that point our software can see the user/group information and will create the proper identity information in the zone.

Note the red arrow next to Jerry’s name.  This indicates a foreign principal.

Now let’s look at the output of "adquery user -P" (to show user principal names only) from our zoned computer (centos66):

$ adquery user -P

felderi.cibao@hq.fabrikam.com

jerry.seinfeld@corp.contoso.com

rpimentel@hq.fabrikam.com

And the UNIX identity is defined as per the zone settings:

$ adquery user -A jerry

unixname:jerry

uid:1149240405

gid:1149240405

gecos:

home:/home/jerry

shell:/bin/bash

auditLevel:AuditIfPossible

isAlwaysPermitLogin:false

dn:CN=b8cdb1f6fdf447d5b2c43f77e6609ab2,CN=Foreign User,CN=One Way Trust,DC=corp,DC=contoso,DC=com

samAccountName:jerry.seinfeld

sid:S-1-5-21-2180375406-786980114-1643973036-1109

userPrincipalName:jerry.seinfeld@corp.contoso.com

canonicalName:corp.contoso.com/One Way Trust/Foreign User/b8cdb1f6fdf447d5b2c43f77e6609ab2

passwordHash:x

guid:f6b1cdb8-f4fd-d547-b2c4-3f77e6609ab2

zoneEnabled:true

Express Mode

In Express (limited freeware) mode, one-way trusts are not supported because it uses Auto zone mode.

Access Manager and the Delegation Model

In order to enforce Separation of Duties, Centrify best practices promote the separation of Governance activities vs. Operations activities.  However, the group scope and where accounts reside determine many of the practices.

For example, if you used Access Manager to generate the recommended deployment structure, most likely you’ll have these groups:

Notice the scope “Security Group – Domain Local” -  this means that if you’re in a pure account/resource model, you will have to add the Global Security groups from the trusted forest into the corresponding group.

E.g. if you want the Global group Centrify Administrators from the corp.contoso.com account domain  to manage Access/Privileges, I would add them to the cfyA_Global_* Domain Local groups.

Zone Provisioning Agent

The Centrify Zone Provisioning agent (ZPA) is a key tool for Identity and Access provisioning.   Some other customers may be using the Centrify DirectControl SDK, Centrify PowerShell or the TCL-based adedit scripting language to automate these actions.

When creating the Active Directory Security groups for Automatic UNIX identity provisioning for users and groups you have think about the access and trust direction before you decide your strategy. 

The main reason is that principals from the trusting forest can’t see the group memberships of the trusted forest.

If you make the mistake of

1. Create a Domain Local group for Identity Provisioning
2.  Nest a Global Group from the trusted forest

What will happen is that ZPA won’t be able to see any add/moves or changes to the group and provisioning won’t happen as expected.
Let’s look at this from the agent’s perspective using CLI tools.

I have a system called CEN1 that belongs to a zone in corp.contoso.com.  I will attempt to use the adquery group command to view the members of a well-known AD group:

[george@cen1 ~]$ adquery group -A "Cert Publishers@corp.contoso.com" | grep members

members:corp.contoso.com/Domain Controllers/DC1

Let’s now try to see if we can see the same group memberships from the trusting forest Fabrikam.

[george@cen1 ~]$ adquery group -A "Cert Publishers@hq.fabrikam.com" | grep members

members:hq.fabrikam.com/Domain Controllers/FAB-DC1

As you can see, this is consistent with the direction of access principle of AD trusts, and since group memberships are public to authenticated users from trusted forests, George has no issue seeing this information.

Let’s repeat the same process from cen2 in Fabrikam.

[jerry.seinfeld@corp.contoso.com@cen2 ~]$ adquery group -A "Cert Publishers@hq.fabrikam.com" | grep members

members:hq.fabrikam.com/Domain Controllers/FAB-DC1

Let’s now try to see if we can see the group memberships from the same group from Contoso:

[jerry.seinfeld@corp.contoso.com@cen2 ~]$ adquery group -A "Cert Publishers@corp.contoso.com" | grep members

Error: No such group Cert Publishers@corp.contoso.com

This is where working with Centrify Professional Services yields the best results.  They have tools to enable these kinds of scenarios.

The Missing Layer:  Automation, Orchestration and Interoperability

It’s very easy to focus on a single product or infrastructure, it’s also quite common for niche solutions to be closed or require specialized connectors (or extra investment to facilitate automation, orchestration and interoperability), however, with Centrify that’s not the case.

• This can be overlooked however those are the building blocks that make technology and business processes work well.  Here are some examples:
• Contoso may be using ServiceNOW to provide workflow, approvals and service management, there are SN considerations as well as the 4 layers.
  For example:  When a user requests access (or is removed) to/from a server or group of servers the resulting action is an add/removal from an Active Directory group.  Most likely this will be a Domain Local Group in Fabrikam.
• If Contoso is using ARCSight for log aggregation, the communication path for agents (syslog, event log) has to be clear, as well as for any additional infrastructure.
• Contoso can also be using  Centrify Privilege Service (CPS) to enable Password Management and Session Brokering, perhaps a Cloud Connector may be needed.

Conclusion

In summary, Active Directory Trusts are very powerful, but unfortunately not well understood.  Designs may vary, but a trust design that has been well researched can safely extend the boundaries of organizations.

The key concept in an external, non-transitive one-way trust is that the direction of access is opposite the direction of trust, effectively protecting the trusted domain;

In addition, network connectivity, name resolution, Active Directory considerations and Centrify design and tools have to be cohesive for things to work.

At Centrify, we have this basic test when it comes to one-way trusts:   Show me a Windows client work as expected.  If it does, a Centrified AD client should work as well.