Examples of Identity Assurance with Centrify MFA in AWS (Console, EC2 and CLI with PowerShell)

Note:  This is a repost of an article I recently wrote for the Centrify Community Techblog

Background

Centrify recently commissioned a study with Forrester Research that yielded some important information about the state of Security.  Bottom-line, we have decided to throw money and resources to the problems around information security rather than rethinking our approach, the results are more breaches and exposures.

You can access the study results here: https://www.centrify.com/lp/rethink-security-ebook

A key conclusion on over 200 organizations surveyed is that those with higher Identity and Access Management (IAM) maturity were breached 50% less while maintaining operational efficiency. 

As you read the previous paragraph, you may ask yourself: what is the first step the journey to the continuous improvement required for IAM maturity?  As illustrated in the model below,

a the key component is to establish identity assurance with technologies like MFA or PKI, however this is challenging enough because many organizations have not achieved this on-premises, much less in IaaS/PaaS platforms like Amazon AWS.

This is where Centrify can help.  This article is about guiding you on how to use the Centrify platform to establish identity assurance in several use cases:  

• Accessing the AWS Consoles with shared accounts (like Amazon root) or Federated identities
• Accessing EC2 instances locally (Linux or Windows)
• Accessing AWS commands via the CLI (E.g. PowerShell or Python)

Please note that identity assurance concepts apply to both users and systems (due to API access);  in this use case we'll focus on interactive (user) use cases.  For system/system or app/app, other mechanisms like PKI or Kerberos can be used and we can cover in another entry.

The Centrify Advantage

The biggest advantage for Centrify lies in it's platform and integrations, as a company that covers both Identity as a Service (IDaaS) as well as Privileged Identity Management (PIM) we understand that everything starts with Identity Consolidation.   This is not the "legacy" (metadirectory/connector-based mid-2000s) identity consolidation, this is the "straight-to-the-source" standards based approach using Federation in the IDaaS side, plus direct-integration (with Kerberos) in the case of heterogeneous OS platforms.  We add to this a series of services:

• A policy service
• A multi-factor authentication engine (that includes modern and legacy-based support)
• A risk-based engine (analytics) 

Our native integrations with Active Directory make us a prime vendor to consolidate capabilities;  here's an example, if an organization wants to secure access to a web app, integrate a non-windows platform to a central directory like AD and get MFA, they may engage 3 distinct vendors, however Centrify can help with world-class solutions on the three areas.  Let's look at a the examples.

  

Securing Shared or Federated Access to the AWS Console

Centrify Identity Service provides several turn-key templates to help with shared or federated (via SAML or using the AWS API) SSO for Amazon Web Services.  We have covered these integrations here:

• For a shared credential (like the amazon account)
• Using SAML or Amazon API for federated SSO + Provisioning

However, the powerful policy engine and the support for multiple authentication profiles makes this integration simple and flexible.  

Here's a quick demo on how this integration is enabled and the user experience:

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to Linux and Windows AWS EC2 Instances

Centrify Server Suite provides native integration with Active Directory, regardless of your deployment model. 

By leveraging AD (hosted by you or in AWS), you are eliminating the duplication of identity sources caused by SSH keys with the addition of DirectAuthorize technology that provides role-based access control and privilege elevation and is fully-integrated with the policy and authentication profiles provided by Identity Service or Privilege Service.  We have discussed these integrations here:
 

• MFA for UNIX/Linux
• MFA for Windows 

Provided the Identity Service/Privilege Service setup is correct and the proper PKI trust is in place, for Access and Privilege elevation, all we need to do is set up the proper checkbox at the role, UNIX command or Windows desktop or application.

 

Here's the user experience that meets the requirements for identity assurance via MFA for both Linux and Windows in the context of access and privilege elevation.

 

Notice how we achieved our goals:  identity consolidation and assurance while maintaining usability.

Securing Access to AWS CLI (e.g. PowerShell)

Administration of AWS Services is often performed via the AWS CLI (implemented via Windows PowerShell or UNIX CLI).

If you're using Centrify Identity Service with SAML federation into AWS, you can implement the SSO plugin provided with the template.

References:

• PowerShell script module help
• Using Python commands

Here's the user experience in PowerShell.  Note that the experience will be based on the authentication profile that applies to the user by policy.

If you have multiple roles, you get to select them:

 

Finally, the authentication token is stored in the $me variable and the user can move-on to use AWS PowerShell commandlets.   See the pattern here?  Identity assurance with MFA and role-based access without compromising usability and achieving this with with a single solution set.

  

Metrics

A cliché of business schools is the statement "you can't manage what you can't measure"; but since we're dealing with IT security, you may want to track how we are performing towards our goal of consistent identity assurance, in these AWS examples, we can use AWS CloudWatch metrics to measure the percentage of access in the proper context (e.g. Console, EC2, etc) is performed with assurance.  Therefore a good metric to track would be:

 

MFA events are tracked for Linux, Windows and Identity Platform, this allows you to be creative and get information from CloudWatch or from Identity Service.

Note the CloudWatch widgets above.  In my Linux space, I have a ratio of close to 60% identity assurance (4 out of 7 successful logins were with MFA), however my track record on the sample data I created on Windows is much better (100%).  You use the same approach for privilege elevation via Centrify-enhanced sudo or Centrify Agent for Windows.

In the case of Identity Service or Privilege Service, the platform provide dashboards and reports like the Security Overview - User Logins

These dashboards allow for reviewing information within 7 days or 24 hours and to look at specific date-time ranges. 

Conclusion

Identity assurance is closer than what you think, with the "barriers of entry" for MFA solutions going down, it's all about working with the right partner and Centrify excels at securing apps, endpoints, infrastructure and secrets; finally, the obvious challenge is organizational dynamics;   If you still have groups opposed to centralizing directories or maintaining legacy infrastructure, you can split the project in several phases and attack the platforms that are easier from a people/process standpoint.  Once you can demonstrate identity assurance within those applications or infrastructure, it's going to be hard for those "holding on to the past" to ignore that the best practices are here to stay. The model applies to all aspects of any risk-sensitive information technology area and like every other framework it's not a silver bullet; new threats, attack vectors, compliance requirements and tools are introduced, therefore this has to evolve as well.

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

This article is a continuation an blog post I started last month about how Centrify supports multiple schemas to store UNIX information in Active Directory.  We also discussed the challenges with UNIX namespaces, the type of schemas supported by Centrify Server Suite and strategies for discovery leveraging PowerShell and other tools.


 In this part of the article we discuss strategies on how to source UNIX identity information into Centrify Zones in Active Directory.

Terminology

• Sourcing: extracting identity data and injecting from source to destination.  I don't mean synchronization.  This is meant to be a one-time thing.
• Provisioning:  Once identity migration happens, provisioning are the operational add/moves or changes.

Strategies
Centrify Standard Edition for UNIX implementations consist of analysis and design work to migrate (source) and operate (provision).  Organizational goals vary and must balance project and production needs. That's why a good design is based on a detail analysis of the organization's process.

Let's picture an organization with this makeup

In this case we have an organization that needs to maintain an old namespace because of legacy UNIX systems, however a big mistake that I see in many of our customers is not closing the project correctly.

In this scenario there should be a strategy like this:
For the migration

• Linux systems are going to be normalized and migrated, users keep their usernames and UID/GIDs if aligned with current username standards.  Duplicates will be taken care of.
• The AIX systems will be migrated to the Centrify DB2 Plugin that can take care of the existing challenges.  This is within a 3 month of Centrify operations.  A new child zone will be created for this purpose, during migration this will be overriden at this level. 
• The HP-UX systems will be retired with application attrition.  The vendor is out of business and management has given two years to find a replacement (most likely web-based).  This can be handled with a child zone or local overrides.
• Old NIS Maps:  The old nis maps will be maintained using the Centrify NIS proxy, but the application that relies on YP will be decommisioned in a year.  To compensate for the unencrypted traffic, Centrify DirectSecure will be implemented.

For operations

• Users will get a unix login name based on their AD username
• GIDs will be long integer numbers that are derived from the AD SID

Notice the clear end of the legacy operations.   Unfortunately, in the field this is not the reality;  many times organizations end-up carrying legacy problems for years.

Now let's talk about how to source and provision data for migrations and operations.

Sourcing Data Into Centrify Zones
Centrify zones can source data using different options.  Flexibility is the key here. Ultimately, a tool that uses the Centrify APIs is required to insert data into zones.  
The tools available are:

• With Centrify Access Manager (mmc snap-in)
  • Manually using the zone defaults
  • Manually using the import wizard
• Centrify DirectManage PowerShell
• Centrify adedit
• Centrify Zone Provisioning Agent
• Custom programs that use the Centrify DirectManage SDK

Using the Zone Defaults
Each zone can be configured to provide information from default values.  The options are:

• Login name:  defaults to the AD username (sAMAccountName) - it can be truncated.
• UID can be:
  • Not defined:  no value provided (requires manual intervention)
  • Auto-incremented:  this lends itself to collisions
  • Generated UID from SID: provides a unique 32-bit integer number generated using Centrify's algorithm
  • Use Apple UID Scheme:  provides a unique 32-bit integer generated using Apple's algorithm
  • RFC2307:  You need the 2016.1 version of AM to see this, but this option is quite useful to source existing RFC2307 data.

Import Wizard
The import wizard can process UNIX identity data from local files or a NIS directory.  The key is to arrive to a consolidated set of files and that the inconsistencies are understood.

Our professional services teams provide sets of of scripts to identity anomalies with user/group identities and once a consolidated /etc/passwd or /etc/group file has been identified, then the fun can begin:

Another benefit of the import wizard is that combined with the getent command, provides a fast way to onboard users and groups from 3rd parties.  This video should illustrate what I mean.

This topic has been covered as well in different entries:

• Migrating from /etc/users
• Migrating from /etc/group
• Cleanup with the adfixid & adrmlocal utilities by @tchariya

DirectManage PowerShell
Active Directory PowerShell Modules can be combined with DirectManage PowerShell for some interesting sourcing/provisioning options.  For example:  You can identity all users with posixAccount information (generally those that don't have the uidNumber populated).
If using a Centrify Standard or RFC2307 zone, you can use this information to provision data into the zone.

$zone = Get-CdmZone -Name RFC
$posixinfo = Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell 
Foreach ($user in $posixinfo)
{
New-CdmUserProfile -Zone $zone –User $user.UserPrincipalName -Login $user.SamAccountName  -Uid $user.uidNumber -PrimaryGroup $user.gidNumber –HomeDir $user.unixHomeDirectory –Gecos $user.name –Shell $user.loginShell
}

 Alternatively, if you're using an SFU zone and the information is normalized, you only need to update the msSFU30NisDomain attribute to the NIS domain set for the zone in the particular domain. 

$zone = Get-CdmZone -Name SFU30
$nisdomain = $zone.NisDomain
$posixinfo = Get-ADUser -Filter * -Properties * | Where-Object {$_.uidnumber -ne $null} | Select-Object  UserPrincipalName, SamAccountName, name, uidNumber, gidNumber, unixHomeDirectory, loginShell 
Foreach ($user in $posixinfo)
{
Set-ADUser -Identity $user.SamAccountName -Replace @{msSFU30NisDomain =$nisdomain}
}

Zone Provisioning Agent
ZPA is a utility provided for automatic provisioning.  It relies on AD Security groups as the "source" and based on group memberships the service will provision UNIX user or group identities.  ZPA options extend the options seen on the zone defaults.

ZPA can be viewed as a provisioning utility rather than a "sourcing" tool.

Centrify adedit
adedit is a TCL-based utility that can be used to modify Active Directory data and it powers many of the operations performed by the centrify's adclient.

Here's an excerpt for user provisioning:

>bind centrify.vms
>select_zone "cn=rfc,cn=zones,ou=unix,dc=centrify,dc=vms"
>new_zone_user wanda.web@centrify.vms
>set_zone_user_field uname wanda.web
>set_zone_user_field uid $userUID
>set_zone_user_field gid 0x8000000
>set_zone_user_field gecos "Wanda Web"
>set_zone_user_field home "%{/home}/%{user}"
>set_zone_user_field shell "%{shell}"
>show
Bindings:
        centrify.vms: dc.centrify.vms
Current zone:
        CN=RFC,CN=Zones,OU=UNIX,DC=centrify,DC=vms
Current nss zone user:
        wanda.web@centrify.vms:wanda.web:134217728:134217728:Wanda Web:%{/home}/%{user}:%{shell}:
Forests have valid license:
>save_zone_user

adedit is a deep topic.  Here's the documentation:  https://docs.centrify.com/en/css/suite2016/centrify-adedit-guide.pdf

Centrify DirectManage SDK

The directmanage SDK provides the ability for developers to write their own apps for sourcing or provisioning.  The best resource to find documentation and other resources is to leverage the Centrify Developers page.  The sample applications are in the Suite.  Access Manager, Zone Provisioning Agent and the migration wizards are all created using the SDK by Centrify developers

There are also customers making very innovative use of these resources.


Conclusion
The key to current customers and prospects is flexibility.  Regardless of where and how complex your organization's UNIX identity data is, Centrify offers the deepest options to seamlessly integrate to your existing Active Directory regardless of deployment.

Scripting - Using Centrify PowerShell to Automate Access and Privilege Operations

Background

In some of the examples that we use in this blog, we leverage a basic reference design that consists of a Centrify Active Directory zone, a few computer roles, a UNIX and Windows SysAdmin role and some basic assignments at the Zone, Computer Role and System levels.  Since some of you have told me that you use the blog to follow along, I've decided to share the PowerShell code for this purpose.

There are several cast of characters that I create  (in this case, the Simpsons), but you can change it as needed.

Why post this?
As I meet with many of the current or prospective Centrify customers I see 3 common threads: many more of you are using public/private cloud (as evidenced by some of the recent posts) and want tools and examples of automation;  many of you are looking to leverage IT Service Management solutions for  workflow/approvals (like ServiceNow) and combine it with automation; this post provides some examples.

Disclaimer:  I am not a programmer.  I've made my forays into scripting in the past (mostly vbscript) but I'm not a PowerShell, Bash or any other type of programmer.  This is done for illustration purposes.  When working with scripts in production environments, you.must.add.error.handling!!!

The Basic Reference Design

The cadence will be the same as the GUI.  Create the zone, define rights, define roles, populate the roles and assign them.  These are considered the infrequent steps.
The normal operations are UNIX-enabling users, and performing role assignments directly or leveraging AD groups.  This is the same for Windows and UNIX.

PowerShell Modules

You'll need the Active Directory and the Centrify DirectManage PowerShell modules.

Import-Module ActiveDirectory
Import-Module Centrify.DirectControl.PowerShell

Notice that I'm assuming the default location.


Creating the Zone

$zone = New-CdmZone -Name "Model" -Description "Reference Zone" -Type hierarchical -Container "cn=Zones,ou=Unix,dc=example,dc=com"

Notice that I'm using a shortcut to create the zone and add it to a variable.  Obviously the Container assumes that your domain is example.com and there's a UNIX OU with a Zones SubOU contained within.

Defining the Rights

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Run any command as root" -Pattern "*" -MatchPath "*" -DzdoRunAsUser root -Authentication user 

Creates the sensitive command to run any command as root and requests authentication.

$criteria = New-CdmMatchCriteria -Description "Event Viewer" -FileType "exe" -FileName "eventvwr.exe" -Path "C:\Windows\System32\"

$cmd2 = New-CdmApplicationRight -Zone $zone -Name "Audit Windows Event Log" -MatchCriteria $criteria -RunasSelfGroups "Builtin\Administrators"

Creates Event viewer as Administrator.  The first part is to create the application criteria (a Windows application may contain multiple criterion), then we create the right with the proper criteria.

$cmd3 = Get-CdmPamRight -Zone $zone -Name "sshd" 

This is getting the stock sshd right.  Keep in mind that work in most Linux, but probably you'll have to create something different for Ubuntu or Solaris.

$cmd4 = New-CdmCommandRight -Zone $zone -Name "Audit RHEL Secure Log" -Pattern "tail /var/log/secure" -DzshRunas root

This is another platform-dependent command right.  

$cmd5 = Get-CdmPamRight -Zone $zone -Name "login-all"

This gets, the stock "login-all" PAM right for the SysAdmin Role.

Defining the Roles

$role1 = New-CdmRole -Zone $zone -Name "Mixed Auditor" -UnixSysRights login, ssologin, nondzsh -WinSysRights remote

Defines the Mixed Auditor Role with the ability to log in with a password and with SSO to unix systems and via Citrix or RDP to Windows systems.

Add-CdmCommandRight -Right $cmd4 –Role $role1 
Add-CdmApplicationRight -Right $cmd2 –Role $role1 
Add-CdmPamRight  -Right $cmd3 –Role $role1 

The previous 3 commands add the unix command, windows application and ssh rights into the Mixed Auditor role.

$role2 = New-CdmRole -Zone $zone -Name "UNIX Sysadmin" -UnixSysRights login, ssologin, nondzsh 
Add-CdmCommandRight -Right $cmd1 –Role $role2
Add-CdmPamRight -Right $cmd5 –Role $role2

The defines the UNIX SysAdmin role and adds the "Run any command as root" and login-all PAM right.

Defining Computer Roles

Computer Roles are groupings of systems.  They may contain UNIX or Windows systems that exist within the zone.  Computer Roles are stored within AD Security groups, therefore we have to define some groups, and groups have to be put in an OU.  In this case an OU called Demo.

$oupath = (Get-ADOrganizationalUnit -Filter 'Name -like "Demo"').DistinguishedName

New-ADGroup -Name "Centrify-Model-CR-WebServers" -Path $oupath -GroupScope Global

New-ADGroup -Name "Centrify-Model-CR-DatabaseServers" -Path $oupath -GroupScope Global

$crgroup1 = Get-ADGroup -Filter 'Name -like "Centrify-Model-CR-WebServers"'

$crgroup2 = Get-ADGroup -Filter 'Name -like "Centrify-Model-CR-DatabaseServers"'

The naming convention is easy to figure out for these AD groups:  Centrify-NameofZone-Type of Group-Description.

$crweb = New-CdmComputerRole -Zone $zone -Name "Web Servers"  -Group $crgroup1

$crdb = New-CdmComputerRole -Zone $zone -Name "Database Servers" -Group $crgroup2

At this point there's an empty zone, with a basic security access and privilege model.

UNIX-Enabling Users

To access a UNIX/Linux system, users need to have a UNIX identity in the Centrify Zone in AD;  this is quite simple using PowerShell.  In addition, they must have a role as well.

New-CdmUserProfile -Zone $zone –User marge.simpson@example.com -login marge.simpson -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

New-CdmUserProfile -Zone $zone –User bart.simpson@example.com -login bart -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

New-CdmUserProfile -Zone $zone –User maggie.simpson@example.com –login maggie.simpson -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

New-CdmUserProfile -Zone $zone –User homer.simpson@example.com–login homer -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

Since this is a clean environment, I'm using very few overrides and all UID/GID info is generated based on the user's SID.  

Granting access and Assigning Roles

A permanent assignment at the zone level

$role1 = Get-CdmRole -Zone $zone -Name "UNIX SysAdmin"  

New-CdmRoleAssignment -Zone $zone -Role $role1 -ADTrustee marge.simpson@example.com

As discussed in previous postings, these are rare and only assigned to senior trusted admins

A permanent assignment at the computer role level (WebServers)

$role2 = Get-CdmRole -Zone $zone -Name "Mixed Auditor" 

$crweb = Get-CdmComputerRole -Zone $zone -Name "Web Servers" 

New-CdmRoleAssignment -ComputerRole $crweb  -Role $role2 -ADTrustee bart.simpson@example.com

Note that this is a mixed role.  If the computer role has IIS and Apache servers, this auditor can review both the event log and the secure log.

A time-bound role assignment (perhaps a change control Window or a break-glass scenario) to an individual system

$role3 = Get-CdmRole -Zone $zone -Name "UNIX login"  

$comp = Get-CdmManagedComputer -Zone $zone -Name "your-zone-enabled-system" 

New-CdmRoleAssignment -Computer $comp -Role $role3 -ADTrustee homer.simpson@example.com -StartTime (Get-Date) -EndTime (Get-Date).AddMinutes(60)

In this example, Homer is getting the ability to log in to this system for an hour.  

Video

Centrify Server Suite 2015 - Highlights

Centrify has posted the new bits corresponding to Suite 2015 on their customer support website.   Here are some highlights of the new version

Base Agent (adclient)

• New version is 5.2.2
• Hadoop Features
• Enhancements to adkeytab  (it can now create accounts with the "Password Never Expires" flag).
• Sample scripts provided to automate keytab creation
• AD Kerberos credential renewal
• An XML definition file has been provided for Centrify Audit Trail events, this makes it easier to send to SIEM tools (very requested)
• Centrify-enhanced sudo has been upgraded (now based on 1.8.10p3)
• LDAP Proxy has been upgraded and now supports TLS (this is great), also a startup script has been provided.
• A new command line called adgpresult shows the group policies applied for the computer or user.
• Smartcard support on RHEL7
• Windows Agent now supports smart card for privilege elevation (awesome!)

Added platforms

-  CentOS 5.11, 6.6 (x86, x86_64)

-  Debian Linux 7.7 (x86, x86_64)

-  Fedora 21 (x86, x86_64)

-  Linux Mint 17.1 (x86, x86_64)

-  OpenSUSE 13.1, 13.2 (x86, x86_64)

-  Oracle Linux 5.11, 6.6 (x86, x86_64)

-  Oracle Linux 7.0 (x86_64)

-  Oracle Solaris 11.2 (x86_64, Sparc 64-bit)

-  Red Hat Enterprise Linux Server 5.11, 6.6 (x86, x86_64)

-  Red Hat Enterprise Linux Desktop 5.11, 6.6 (x86, x86_64)

-  Red Hat Enterprise Linux Server 5.10, 5.11, 7.0 (ppc64)

-  Red Hat Enterprise Linux Server 5.10, 5.11 (IA64)

-  Scientific Linux 5.11, 6.6 (x86, x86_64)

-  Scientific Linux 7.0 (x86_64)

-  Ubuntu Desktop 14.10 (x86, x86_64)

-  Ubuntu Server 14.10 (x86, x86_64)

-  SUSE Enterprise Linux 12 (x86_64)

Audit Agent

1. Version 3.2.2
2. XML Definition file for integration with SIEM tools
3. Improved manageability with PowerShell

• Cmdlet          Attach-CdaDatabase              

• Cmdlet          Detach-CdaDatabase      

• Cmdlet          Export-CdaAuditSessionRecording 

• Cmdlet          Get-CdaActiveDatabase           

• Cmdlet          Get-CdaAgent                   

• Cmdlet          Get-CdaAuditEvent               

• Cmdlet          Get-CdaAuditRole                

• Cmdlet          Get-CdaAuditRoleAssignment    

• Cmdlet          Get-CdaAuditSession            

• Cmdlet          Get-CdaAuditStore               

• Cmdlet          Get-CdaCollector                

• Cmdlet          Get-CdaDatabase                 

• Cmdlet          Get-CdaInstallation             

• Cmdlet          Get-CdaManagementDatabase       

• Cmdlet          Get-CdaUnixCommand              

• Cmdlet          Get-CdaUnixCommandTranscript    

• Cmdlet          Get-CdaWindowsEvent            

• Cmdlet          New-CdaAuditRole                

• Cmdlet          New-CdaAuditRoleAssignment      

• Cmdlet          New-CdaAuditStore            

• Cmdlet          New-CdaDatabase                 

• Cmdlet          New-CdaSearchCriteria           

• Cmdlet          Publish-CdaInstallation        

• Cmdlet          Remove-CdaAgent               

• Cmdlet          Remove-CdaAuditRole             

• Cmdlet          Remove-CdaAuditRoleAssignment   

• Cmdlet          Remove-CdaAuditSession          

• Cmdlet          Remove-CdaCollector             

• Cmdlet          Set-CdaActiveDatabase        

• Cmdlet          Set-CdaAuditRole                

• Cmdlet          Set-CdaAuditSession             

• Cmdlet          Set-CdaAuditStore               

• Cmdlet          Set-CdaConfiguration            

• Cmdlet          Set-CdaDatabase                 

• Cmdlet          Set-CdaInstallation             

• Cmdlet          Set-CdaManagementDatabase       

Upgrade (W2008R2) and Fresh Installation (W2012R2) Videos

Troubleshooting: Understanding How Time Affects When Changes are Effective

The best way to summarize how time works in an AD environment that leverages Centrify agents for Unix, Linux and Mac OS X is to look at this formula:

Effective Changes = Σ(Provisioning, AD Replication, Cache Flush Interval)

Changes are additions, deletions or modifications of AD objects (LDAP).  This excludes real-time Kerberos transactions like authentication or password changes.

Provisioning

In Centrify for Unix/Linux, we call provisioning the action of assigning an existing AD principal (user or group) a UNIX identity (login,UID,GID,Home,GECOS,Shell).  In the case of users they also need a role to be able to log into systems; both actions can happen manually or automatically (via an Identity Management Solution that leverages the Centrify APIs, via the  Zone Provisioning Agent utility, or programmatically via Centrify PowerShell or Centrify adedit).
For example, in my environment I use ZPA and I assign the roles to AD groups so the management is simplified.  I've also nested my role-granting-group into the provisioning group.  This means that my modified equation is:

Effective Changes @ Contoso = AD Replication of Group Membership + ZPA Polling Interval + AD Replication of ZPA Provisioning + Cache Flush Interval)

Notice how my provisioning design has an impact on time.  I have potentially two actions that require AD replication and an agent that I've set up to poll every 15 minutes.

This means that a provisioning action can take as long as 15:30 from a provisioning + AD perspective in an intra-site scenario assuming (in the case of a user) that both the identity and the role were granted at the same time.

AD Replication

If you're relatively new to Active Directory and don't have an idea on how AD replication works, read these links and come back:

Basic Concepts: http://technet.microsoft.com/en-us/library/cc731537%28v=ws.10%29.aspx
How it works:  http://technet.microsoft.com/en-us/library/cc772726(v=ws.10).aspx 

In case you did not read the links above, the basic problem is that when you have a replicated database changes take time to propagate.  AD Sites (fast connected subnets) have internal (intra-site, shorter) and external (inter-site, longer) replication periods.

Intra-site replication is somewhat predictable.  A DC will notify to its nearest partner of a change within 15 seconds and this will cascade within a site.  Older versions (like Windows 2000) were set at 5 minutes.

Unfortunately in larger global environments AD inter-site replication times vary. It all depends how the AD team has tuned the environment based on the inter-network topology.   This is why to be an effective Centrify administrator you need to be in constant communication with your AD team. Replication affects availability for users and definitely affects your SLAs.  The best solution at a higher level is to use Microsoft's recommendations for AD replication in large environments and that they maintain current Subnet, Site and Domain Controller information.  This is very important.

That being said, there are things that you can do to make sure things happen faster. 

For example, if there is a new add/move or change and the target is a key server in a specific location, you can log into the server and find out what domain controller the server is currently talking to with the adinfo command (or adinfo --server).  If you're making the provisioning via ADUC, adedit or Access Manager, make sure you're talking to the same DC.  At that point you basically have eliminated AD time from the equation and you can issue an adflush when these changes are made.

If you're using The Windows PowerShell Centrify commandlets, you can use the echo %logonserver% command in a windows prompt to find out which domain controller you're currently talking to.

Centrify Agent Cache

We've talked about the cache in previous posts;  however, all you need to know that to improve performance and to provide high-availability the Centrify agent for Unix, Linux and Mac does not bother AD persistently to ask for changes;  this happens by default every hour.

Putting it all together

Looking back at my example, this means that in an intra-site scenario with two domain controllers like in my lab contoso environment, the length of time for an effective for a user change can be as long as 65:30 minutes. Because it takes up to 15 seconds for replication to happen on the provisioning/role granting action, up to 15 minutes for ZPA to poll, 15 additional seconds for the ZPA change to propagate and up to 60 minutes for a Centrified system to update its cache.

How to perform manual add/moves/changes in an effective matter

1. Determine the key system, and issue an adinfo command to determine the domain controller the agent is talking to.  (adinfo --server)
2. With that information, connect your ADUC or Access Manager consoles to the target DC.  (on AM, use the "Connect to remote forest" option; on ADUC use the "Change Domain Controller" option).
3. Perform your changes in AD (add/moves/changes)
4. Perform an adflush in the target system  (if it's a local override, you need to restart the agent)
5. Verify the changes with adquery, dzinfo, etc.

Note:  Flushing the cache (by interval or manual with adflush) is an expensive operation, I recommend that you keep the default cache flush interval of 3600 seconds (one hour) and try to establish a proper Service Level Agreement for these operations.