Basics: Centrify Zone Schema Types and Identity Sourcing - Part I

A common category of questions we get from Centrify prospects and customers is around UNIX identity storage and options for sourcing.  The most frequent is:  How do we get UNIX identity data to your solution?

I typically tend to answer:  Where does your UNIX identity data resides?
The answer to this question varies.  I've heard all kinds of responses, including silence or arguments between team members.  Ultimately it boils down to two categories:

Rationalized(*)

Not Rationalized

There is a naming convention established and the convention is enforced A directory may or may not be in place  (e.g. LDAP, NIS, etc) Every user has a unique login, UID and Primary Group Every UNIX group is defined with the same unix-name and GID, has the same meaning and group members There is typically a unified strategy for multi-protocol filers There is a unified (or centralized) sudoers files

The naming convention is spotty or non-existent A directory may or may not be in place  (e.g. LDAP, NIS, etc), but there are pockets of "other stuff" Users may have different naming for login or different UIDs  (e.g. jdoe (501:501) vs john.doe (10001:1) Groups may have different unix-names, different GID numbers, members or meaning. Centralized sudoers files may or may not exist or contain outdated information.

^(*)Note: "Fully-rationalized" is typically an aspiration.  Organizations may have historical or legacy reasons as of why they may keep older systems that do not conform to the standards (and yes, Centrify has you covered).

Other questions that follow are:  Will you be using the SFU or RFC2307 fields? What are these zones that you speak of and what are the AD implications?  Can you make use of my existing UNIX information?  How painful (or painless) will the process be?

The answer to the last question varies between organizations.  Some organizations believe the process will be cumbersome and choose to continue with the status-quo (after all, their problems are well documented); others make the painful decision to not get help or training (a decision that really baffles me).

This article explores the different schemas used by Centrify Zones and provides an overview of sourcing options. The topic is very relevant due to the following facts:

• Microsoft's deprecation of Identity Management for UNIX and Services for NIS
  https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/
• Limitations of current OS-native alternatives and less investment from alternative 3rd. parties.

Having a solution that provides flexibility, especially in such an important capability that is the foundation to secure critical systems is key for large enterprises.  Let's get started.

Basics

• UNIX identity data consists of login, UID, GID, Home Directory, Shell and GECOS.
• Centrify Zones leverage Active Directory to provide Identity Management for UNIX, Linux and Macs and Role-Based Access Control + Privilege Management for UNIX, Linux and Windows.

UNIX identity may reside on:

• Local /etc/passwd and /etc/group files on each individual system (could be the same for /etc/sudoers)
• Network-based passwd and group files on LDAP or legacy NIS directories (same for /etc/sudoers)
• In Active Directory in the msSFU30 fields (pre-Windows 2003R2) or the RFC2307bis (after Windows 2003R2) and are attributes of the posixAccount class.
• In other LDAP-like directories that rely on synchronization (e.g. Oracle, Red Hat, Apple or other third party software, etc)

Centrify Data Storage: Zones
Identity data is inside the Centrify Zone.  A Zone is a set of AD objects that consolidate identity and privilege information.  Centrify identity data is stored on a serviceConnectionPoint linked to the user or group object.  This chalk-talk covers this information in detail.

Benefits:

• Provides the ability to limit the visibility (and access) of users/groups in different contexts.
• A user (or group) may have different identities in different contexts (especially useful in M&A activities or consolidations)
• Provides the capability to group systems (teams of servers) using different options
• Its structure is hierarchical, provides inheritance and object reuse
• Aligns organizations with the principle of separation of duties
• Multi-platform (allows the grouping of UNIX, Linux, Windows and Mac systems)
• Highly-scalable (overcomes the limitations of other schemes like Auto Zone)
• Provides support for different schemas (SFU, RFC2307) and UID/GID Schemes

Types of Zones and Schemas
Zones can be Classic or Hierarchical.  Because Classic zones are no longer the best practice, they exist for backwards compatibility.  In the rest of this article, a Centrify Zone is always considered to be a hierarchical zone.

Centrify Standard Schema: UNIX attributes are stored in the keywords multi-valued attribute of the user or group's serviceConnectionPoint


The standard schema was very useful, especially in old Windows 2000 deployments.
Here's how to create a Standard zone using Centrify DirectManage PowerShell:

$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms"  #substitute with your container DN
New-CdmZone -Name Standard -Container $cont -Schema standard -Type hierarchical

SFU Schema: UNIX attributes are stored with the user or group object and the msSFU30NisDomain is populated based on the zone's NIS domain setting.

Using the SFU schema allows the automatic sourcing for all users that have the RFC2307 UNIX fields populated along with the the msSFU30NISDomain attribute.  The drawback is that you must have rationalized your environment and overrides won't be possible (more about overrides below).

PowerShell:

$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms" # substitute for your container DN
New-CdmZone -Name SFU30 -Container $cont -Schema sfu -NisDomain SFUX -SfuDomain centrify.vms -Type hierarchical

When planning to use SFU as a schema, you are bound by the limitations of having the data with the AD object, most notably UNIX names.  You cannot have identity overrides (for example, changing the UNIX name of a group).  This is illustrated below:


RFC2307-compatible schema:  UNIX attributes are stored with the serviceConnectionPoint that defines the user or group.


PowerShell:

$cont = "cn=zones,ou=UNIX,dc=centrify,dc=vms" # substitute for your container DN
New-CdmZone -Name RFC -Container $cont -Schema rfc -Type hierarchical

Tips on Discovering UNIX Data
Due to the fragmented nature of heterogeneous environments (and the fact that they've been around for a long time), information seems to be all-over the place, but here are many tips.

• UNIX Identity data in files (/etc/passwd or /etc/group) may have different inconsistencies like:
  • unix users with more than one UID
  • unix users with more than one GID
  • unix users with multiple unix names
  • unix users with different shell or home directories  (e.g. /home/user vs. /exports/home/user)
  • unix groups with more than one GID
  • GIDs with different group names
  • unix groups with different group memberships
  • sudoers files with non-existing groups, aliases or unix names

Identifying this information can help with the identity rationalization process.

• UNIX Identity data in Active Directory
  • Different schemas (SFU vs RFC2307)
  • Multi-domain forests with inconsistent NIS domain data
  • AD data that is no longer relevant

PowerShell Discovery Query (RFC2307)

Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} 
| Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, 
gidNumber, unixHomeDirectory, loginShell | Format-Table

Conclusion for Part I:
Part of the reason why Centrify has been successful is the flexibility of our toolset, the experience of our Professional Services organization, our willingness to listen to our customers and the consistent investment on the product. 

The benefits of having a unified namespace while using a common infrastructure are critical for security, functionality and productivity.  In the field we still see many organizations struggling with this core concept.  With Centrify enterprises are covered not only on a family of Linux systems, but in critical UNIX systems that run AIX, HP-UX, Solaris, OS X and other commercial Linux distributions.

In part 2, we'll discuss some options on how to source data into Centrify zones using multiple toolsets.

Lab 16: Configuring ZPA for Automatic UNIX Group Provisioning

Background

Posting:  http://centrifying.blogspot.com/2014/03/basics-automatic-unix-profile.html
Automatic Provisioning for Users: http://centrifying.blogspot.com/2014/01/labs-centrify-zone-provisioning-agent.html

Part 1

1. We configure grant the proper rights to the Centrify ZPA AD service account
2. We create the Source Group
3. We create a test group (UNIX-HQ-webadmin) and nest it to the source group.
4. We test and verify that automatic provisioning is working

Part 2

1. We verify that add/moves/changes are working as expected.
2. We modify the UNIX group profile with account overrides
3. We modify the UNIX group provisioning to automatically set the unix name and GID based on our needs.
4. We add the dbaadmin group.
5. We verify that regardless of the membership, only the users who have been granted rights to the system are the ones in the NSS group.

Basics: Configuring the Centrify Zone Provisioning Service for Automatic Secondary UNIX group provisioning

Background

In a previous posting we discussed how to implement automatic provisioning of UNIX user identities using Centrify's Zone Provisioning Agent (ZPA).
As part of BP#2, one of the key requirements was to implement a provisioning model for secondary UNIX groups and to make it resemble the existing one for users.
This capability consists in the automatic creation of the secondary UNIX group as well as the lifecycle maintenance of members (add/moves/changes).

All the principles applied in the basic posing about ZPA apply here, but in the context of UNIX secondary groups.  Let's apply the Plan-Do-Check-Adjust methodology.

Planning for Secondary Group Provisioning

Is the secondary group needed
The first place to start is to ask "Why is this secondary group required?" -  remember that with Centrify there is no need to have these groups for Access or Privilege purposes, Zones and RBAC take care of all that. In these exercises, the typical answer "Because that's the way is done" is not a good answer so you may have dig deeper.

Naming Conventions
The same rules of UNIX systems apply here as well, but they are a bit more stringent;  the 8 character limit for users is platform-dependent;  the UNIX group case, it may be more of a hard requirement.

Active Directory
Basically the way UNIX Groups work in Centrify is as follows;  there is a security group in AD for each secondary group in UNIX;  the memberships are handled from AD (the process consolidator and time saver), however, governance and processes have to be taken into account.  Questions such as:

1. How are AD Security group are requested today?
2. How is the membership lifecyle managed (add/moves/changes)?
3. Are group memberships subject to any attestation process?

Need to be understood and agreed upon.  

Group Merging

Group Merging is the ability to mix members from other Name Server Switch groups (like /etc/group) with UNIX Enabled AD groups. For example, if an application requires the enumeration of all the members from the software group (UID 200) and the application uses local users (e.g. like the db2inst account) and AD users (like jessie.matthews), then this feature needs to be implemented as well.

Implementing (Do) Secondary Group Provisioning

The process is as follows:

1. Make sure the service account used for ZPA has the proper delegation to add/remove/modify group profiles.  This is done through the Delegation Wizard of the zone.
   
2. An Active Directory "Source" Group is created.
3. ZPA is configured to look at that group as the source group.  For consistency, this group is stored in the OU designated for provisioning 
4. The rules for GID are set, the options are:

• An unique value generated from the group's System ID (SID)
• The RFC 2307 attribute (has to be populated in the object manually or programatically)
• Using the defaults set in the zone (Group Defaults tab)
• Using Apple's scheme (this is new for version 2014)
  
5. The naming rules are set (truncation, character sets, prefixes, etc)
6. Once this is set, ZPA is ready to provision UNIX groups.

Verifying the Implementation (Check)

Verifying group creation:

1. Restart ZPA (so the new zone provisioning configuration is processed)
2. Create an AD Security group.
3. Nest the group (make it a member) of the source group in the previous step.
4. Wait the ZPA refresh cycle or restart the service.
5. Verify that the new group exists under Zone > UNIX Data > Groups.
6. Verify that the group exists in the adequate UNIX systems.  There are several ways:
   getent group | grep <unix name of group>
   adquery group | grep <unix name of group>
7. To verify the group's deletion, just remove the AD group from the source group and cycle ZPA;  the UNIX group will be removed from the zone.

Verifying Add/Moves or Changes

1. Add a user to the previously provisioned group
   Note:  this user needs to be at least listed in the system, otherwise he/she won't show. For example, if the user has a UNIX identity, but only has access to web servers, the user will not show in the Database Servers by virtue of the access rules enforced by Centrify.
2. Wait the ZPA refresh cycle or restart the service.
3. Verify that the user's UNIX name is in the list of users for that group.
   There are several ways:
   getent group | grep <unix name of group>
   adquery group | grep <unix name of group>
4. Remove the user from the AD group (go to step 2) and in step 3 verify that the user is gone.

Performing Adjustments

Adjustments may vary depending on the results.  They can be:

• Adjusting how the GID is generated (or reviewing the provisioning process)
• Adjusting how the UNIX name of the group is generated.
• Adjusting group merging options.

Basics: Automatic UNIX Profile Provisioning Using Centrify's Zone Provisioning Agent

Background

In a previous posts we discussed what's in a UNIX profile, we have also discussed the concepts behind Centrify Zones, how Active Directory users can be UNIX-enabled using Centrify and what are some of the considerations and strategies for UNIX identities;  the problem has been that our labs have been focused in manual Identity manipulation.

The reason for this is simple:  understanding the basics is establishes the best foundation to address complex issues; but since we have gone over man manual scenarios, in this posting we will discuss automatic provisioning with the Zone Provisioning Agent (ZPA) utility.  The rest of the labs will use ZPA with a rationalized namespace.

Why Exceptions are Bad

In IT infrastructure, Security as well as in Identity and Access Management, designers need to strive for standardization and simplicity; sadly the reality is that organizations are complex today because problems are addressed in a reactive matter and rarely the root cause of issues are addressed, instead, organizations throw technology and resources at the problem.

Getting to a standard Identity Provisioning process is hard and the most challenging part is the ability to make the process standard and repeatable enough that exceptions are almost eliminated.   Exceptions introduce overhead and unnecessary risk; any system administrator with a certain degree of experience knows this and the sad thing is that some of them have figured out that complexity keeps them employed and enjoying the status quo.

Exceptions = More complexity = More stress = More work = More cost = Lower Satisfaction

In addition, to be completely fair, not all organizations can afford to completely aim and then shoot.  This is why solutions need to allow a certain degree of flexibility.

Centrify Zone Provisioning Agent

The Zone Provisioning Agent (or ZPA) is a utility included with Centrify Standard Edition that allows the automatic provisioning of UNIX identities leveraging Active Directory Security groups.
Yes, we get to reuse the same process again.
ZPA waits a preset number of minutes and searches in Active Directory for provisioning groups, and based on the zone defaults, will automatically UNIX-enable a user.

ZPA is implemented as a Windows Service or it can be run as a command utility called zoneupdate.exe.
Zoneupdate provides an interface to work with scripting or Identity Management solutions.

Like any other solution, ZPA has to subscribe to the Plan-Do-Check-Model.

Planning for ZPA

• Understand the impact of ZPA - once a zone has been enabled for automatic provisioning, AD users can't be UNIX-enabled manually, overrides are still possible at the zone, child zone and system levels.  The unavailability of manual provisioning, stresses that the process has to be clean of major exceptions.
• Determine how you're handling the Unix Name (RFC 2307 uid attribute).  This is important because some UNIXes need to be enabled for long name support and you may have naming conventions to consider.
• ZPA allows to handle any exceptions on the settings for the UNIX name.
  
• ZPA can use any attribute stored in the user object as the RFC2307 uid field, therefore if you have any scripts, IdM solution, etc that make transformations and write them into this field, they can be leveraged by zpa.  The default is the AD username:  ${u:sAMAccountName}
• ZPA requires a master provisioning AD security group per zone;  this means that we need to create and populate an AD Security group with the users that require provisioning.
  Sample Design (Nested Groups):  
  You can leverage Active Directory group nesting to kill two birds with one stone.   For example:  Jeremy is a member of the UNIX Database Servers Users group;  since this group grants the role in the appropriate number of systems, we can safely assume that he requires a UNIX profile, so if we have a Provisioning group called UNIX All Users, all we need to do is nest the role-granting AD group in to the provisioning group.
  
  
  This design simplifies operations because either manually, programmatically or by virtue of using an Identity Management tool, adding or removing the user to the role-granting group, has the effect of provisioning or deprovisioning access.
• ZPA high-availability:  All services need to be planned with HA in mind.  Running multiple ZPAs is not uncommon.
• Planning for Exceptions:  In this model, Centrify allows for identity overrides at the child or system levels.
• Planning for Migrations from existing Manual to ZPA zones:  In this case, the brief moment in which the accounts won't be available has to be accounted for.
  All users will lose their UNIX identities until the next polling interval kicks-in.  If well planned, this should be negligible in a medium to small environment.

Implementing ZPA (Do)

To Implement ZPA, at a high level:

1. Create the Provisioning group and populate it with the appropriate users and/or groups.
   If using the model outlined above, nest the role-granting groups into the provisioning group.
2. Request an Active Directory service account to run ZPA.
3. Delegate the proper permissions for Users (or Groups) for ZPA to be able to perform the functions desired.
4. Install ZPA in a highly-available system.
   Note:  If it hasn't been done, your existing Access Manager consoles have to be extended with ZPA setup to have the Provisioning tab enabled.
   
5. In Access Manager Configure the zone for automatic provisioning (if this zone had users, the UNIX-identities will be deleted)
6. Configure the account and the polling interval for ZPA
   (You may need to make sure that the service account has the proper log on locally rights)
7. When the service starts, all identities will be provisioned.

Verifying the Implementation (Check)

1. In Access Manager, verify that all UNIX Identities are accounted for.
2. In the UNIX systems, make sure that after an adflush all users for the corresponding system are accounted for.
3. Add a user to one of the role-granting groups.  Trigger a polling interval.  Verify that the user has a UNIX identity.
4. Remove the user from the role-granting group. Trigger a polling interval.  Verify that the user has lost his UNIX identity.

Adjusting the ZPA Implementation

There are multiple reasons to adjust a ZPA implementation, but the most common are:

• Provisioning SLAs:  Provisioning is composed of multiple parts:  from user creation or provisioning, to workflow/approvals, AD-replication, cache-flush intervals and now ZPA.  The polling interval may need to be adjusted for Service Level Agreements.
• Performance:  Network, domain controller availability, etc.
• Availability:  Redundancy, etc.

Videos on setup here: http://centrifying.blogspot.com/2014/01/labs-centrify-zone-provisioning-agent.html

Zoneupdate Help

Usage: ZONEUPDATE [options] zone1 [zone2 zone3...] Options

/z|SourceZone:Path  
Copy user attributes from the source zone (specified in canonical name format, for classic zone only).

/d|Domain:DomainName
The FQDN of the target domain.

/dc|DomainController:DomainControllerNameThe target domain controller to connect to.

/u|UserSource:ADGroup[@domain]

The AD group used to populate the users in the zone.

/g|GroupSource:ADGroup[@domain]The AD group used to populate the groups inthe zone.

/uu|UserUid:<Option>
The method to generate the UID for a user profile. Option can be one of the following values. Auto is the default if this option is not specified.

/us|UserShell:<Option>

The method to generate the UNIX shell for a user profile.

Option can be one of the following values. 

/uh|UserHomeDirectory:<Option>

The method to generate the home directory for a user profile.

Option can be one of the following values. 

/uc|UserGecos:<Option> (For hierarchical zone only)

The method to generate the Gecos in a user profile.

                     

/gg|GroupGid:<Option>

The method to generate the GID for a group profile.

/gn|GroupName:<Option>

The method to generate the UNIX name for a group profile.

Option can be one of the following values. SamAccountName

is the default if this option is not specified.

                     

Methods:  

SamAccountName is the default if this option is not specified (for login, UID, GID).

Auto is the default if this option is not specified.

Auto            - Auto-generate from the AD group's SID.

RFC2307         - Group's AD RFC 2307 gidNumber attribute.

ZoneDefault     - The GID of this group in the default value zone for the target zone. Use the next GID of the target zone if the default value zone is not available.

SourceZone      - The GID of this group in the source zone.

(for classic zone only)

<Empty>         - Leave empty option for undefined GID.

(for hierarchical zone only)

                     

/v|Verbose           Verbose output messages.

/p|Preview           Preview only. No provisioning changes will be made.

/l|Log:<Level>       

Turn on the log file. The log file will be created in'C:\Documents and Settings\<CurrentUser>\Application Data\Centrify\Zone Provisioning Agent\Log'

Log level can be Error, Warning, Information or Verbose.

Example:

    zoneupdate /u:"Domain Users" /g:"Domain Users" /d:centrify.dev zone1 zone2

Basics: Centrify Zones

What are zones?

• As per Dictionary.com:
  noun. "Any continuous tract or area that differs in some respect, or is distinguished for some purpose, from adjoining tracts or areas, or within which certain distinctive circumstances exist or are established."
• A marketing name (1, 2, etc.)
• A mechanism to establish a Security Governance model using Active Directory and Centrify technologies across UNIX, Linux and Windows  (yes, Windows).

The third option is the best definition because of the key concept of security governance.  In the context of security, Centrify zones are AD constructs that allow the storage of multi-platform systems, UNIX identity data and Authorization information.  It leverages the RFC 2307 specification, proprietary Centrify techniques and the Windows Authorization Manager API to allow the implementation of the following security principles:

1. The "least access" principle:  an internal control that states that end users shall only have access to the systems based on business need to know.
2. The "least privilege" principle:  an internal control that states that end users shall only have the rights and privileges in systems based on business function.
3. The "separation of duties" principle: an internal control that requires more than one person to perform a function in order to prevent fraud or error. 

All these principles are the basis for Role Based Access Controls (RBAC). 
Zones also allow for flexible Management of UNIX identities (login, UID, GID, login, Shell, etc.) 
Process Reuse
A very overlooked advantage of Zones is that they allow organizations to reuse their current processes for the purpose of UNIX identity provisioning (or deprovisioning), access management and privilege management.  The process is the practice of adding or removing users from Security groups in AD.  For years this process has been used to grant privileges, access to file shares, printers, Exchange Services, SharePoint sites, etc.

What does this mean?
It means that integrating any solution to Centrify for the purposes of UNIX identity provisioning or privilege management is very easy and it doesn't require dedicated connectors or agents.  ANY Identity Management platform or solution has the ability to integrate to AD and to add/remove users into Security Groups.
Regardless of the solution (Oracle, Courion, Microsoft FIM, Sailpoint, etc.) all of them have that capability, and many of them with workflows.

Centrify Zones History
Zones used to be flat constructs (classic zones), this made it very cumbersome for organizations to manage them.  This changed a few years ago when Centrify introduced hierarchical zones.  The real power of zones was unleashed when the authorization components were introduced.  Since version 2013, now zones can be used to segregate and perform privilege management both UNIX/Linux and Windows systems!!!  This has huge implications for organizations that are security and cost conscious.  
Moderation note:  It is the opinion of this author that classic zones should be deprecated.  This blog does not cover them.

What are the design rules for zones?

• A single zone and computer roles should satisfy the needs of most organizations;  however there may be regulatory or legal reasons to implement other zones (for example: European Union Rules, Separation of Divisions, PCI, etc.)
• Each zone used to control UNIX system access has to have a set of defaults for identity data (UID, GID, login, Shell, GECOS).  Access Manager provides multiple options, but the default options are typically fine for a manual provisioning scenario:
  login is the AD samAccountName  (username)
  UID/GID the best option is to generate the UID from the SID - this provides uniqueness.
  GECOS defaults to the AD Display Name.
  Home and Shell use variables to specify the defaults for the system.  These can come very handy.
• For each zone dedicated for UNIX purposes, provisioning mechanisms need to be accounted for.
• Identities shall be provisioned at the zone level.  Identity overrides shall be considered exception.
• RBAC Assignment at the zone or computer level overrides shall be used sparingly.  On the flip side, Computer Role level RBAC assignments are the preferred method.

Like we have previously outlined, zone design is subject to the Plan-Do-Check-Adjust method too.

What is AutoZone Mode?

AutoZone is a mode operation for Centrify Agents that allows the UNIX, Linux or Mac system to be joined to Active Directory with no access restrictions (like any client workstation), therefore any user in the domain (or in a trusted domain) can log in to the system.
AutoZone is the only mode of operation of the Centrify Express for UNIX/Linux.  Although desirable in client scenarios, it is not a proper security practice to allow everyone to log in to sensitive systems.  

Other disadvantages of AutoZone are the following:

• A high-degree of planning is required to deploy in AutoZone mode.  The caching required for all objects (especially) in large domains may affect performance during cache buildup.  The rule of thumb is that the domain is larger than 1500 users, then limits have to be established.
• AutoZone (express) does not allow for Identity Overrides (manipulating login, UID, GID, etc)
• AutoZone does not include the authorization components.  No least access or grouping of systems or Privilege Management (no RBAC)

AutoZone is covered in a very limited basis in this blog.

Basics: Active Directory

Directory Service
Active Directory (AD) is Microsoft's official Directory Service. It was introduced with Windows 2000 and is the successor of NTDS 4.0 (Windows NT 4.0 Directory Services).  Microsoft made some good decisions when designing AD, because it included a Kerberos implementation with their existing capabilities.
AD not only stores users, computers, printers, etc; but since version 31 (Windows Server 2003 R2) it contains the RFC 2307 schema (more on that later).

In Summary, Active Directory provides:

• An LDAP Directory that supports Discretionary Access Control Lists (securable objects)
• A Kerberos authentication infrastructure
• Group Policy, for policy enforcement and computer and configuration management 
• A Certificate Authority that leverages Group Policy for digital certificate life-cycle management
• Highly-available and highly scalable:  this is a key capability, especially for big enterprises

Basic AD Concepts

For an official explanation, go here.  I think that understanding these basic concepts will help understand the rest of this blog.
 

Component	Description
Organizational Units	OUs are like folders.  They can store objects.  Use them to organize your domain in a way that makes sense to you or your organization.
Domains	Domains are containers that share a common database and security policy.  Think about them as a major management unit.  They can span multiple locations and can contain millions of objects.
Domain Trees	Domain trees are hierarchical structures.  They are named like DNS.  E.g.  contoso.com is a parent domain.  sub1.contoso.com and sub2.contoso.com are part of the contoso tree.
Forests	A forest is a full instance of AD.  It can contain multiple domains that share the same global structure, schema and directory configuration.  Forests serve as security boundaries.
Sites and  Services	Sites are typically collections of subnets connected to a fast network link. Services are scoped to sites, so that services that rely on Active Directory can find the best connected server

Name Resolution

Active Directory depends on DNS to provide name resolution and also has the ability to store the DNS database in Active Directory, this makes DNS fully replicated and scalable; however it's possible to host AD DNS zones in BIND servers. SRV records provide the information required by hosts to find the nearest services.

Domain Controllers

Domain Controllers (DCs) contain a copy of the Active Directory database.  DCs process and return results of LDAP queries, process authentication requests (over Kerberos), and present Group Policy objects that are processed by clients.  Communications between DCs and clients are encrypted.

There are special domain controllers:

RODCs - DCs that only contain read-only data

Global Catalogs - Contain a subset of attributes for all the objects in an AD forest

Flexible Single Master Operations (FSMO) - these are DCs that hold special roles in an AD given that there are DCs that have an authoritative copy of a particular role.  Read more here.
Connection Points According to Technet:   "A Connection Point object represents one or more instances of a service that is available in a network." Centrify uses service connection points to instantiate multiple UNIX identities for AD principals.   For now, these are enough concepts.  We will cover more concepts throughout the process.