Centrify for UNIX/Linux/Mac Command Line Cheat Sheet

AD-bridging commands ("ad" commands)
adcheck - check OS, network and AD readiness for Centrify DirectControl

To check the system with domain (e.g. corp.contoso.com)
$ adcheck corp.contoso.com
To only perform OS checks
$ adcheck --test os
To only perform network-related tests
$ adcheck --test net corp.contoso.com
To only perform AD-related tests
$ adcheck --test ad corp.contoso.com
To check the system with a service domain controller (e.g. dc1)
$ adcheck --servername dc1 corp.contoso.com
To check connectivity only with DCs within the site
$ adcheck --siteonly corp.contoso.com
To check only on 3 (or n) DCs in a large domain
$ adcheck --bigdommain 3 corp.contoso.com
To check trust relationships (e.g. with hq.fabrikam.com)
$ adcheck --xdomain corp.contoso.com
To skip NTP checking (if you are not doing sync with AD DCs)
$ adcheck --skip-ntp corp.contoso.com


adinfo:  provides information about the status of the agent

Looking-up Basic Information
To check the general status of the client
$ adinfo
To see the current domain controller the client is using
$ adinfo --server
To see the current domain the agent is joined to
$ adinfo --domain
To see the status (mode) of the agent (connected to ad or in offline mode)
$ adinfo --mode
To see the version of the installed client
$ adinfo --version
To see the corresponding Centrify Suite Version
$ adinfo --suite-version
To view Active Directory connectivity to the current domain
$ adinfo --test
To view the current Active Directory site
$ adinfo --site
To see the current joined Centrify zone
$ adinfo --zone
$ adinfo --zonedn  (in distinguishedName format)

Advanced/Troubleshooting Information
DNS
To check for the "joined-as" name (local host name and joined as name may be different)
$ adinfo --name
To check the status of the DNS cache and stats
$ adinfo --diag dns

Connectivity
To check connectivity with an AD domain
$ adinfo --test [domain.name]
To check network connectivity statistics
$ adinfo --sysinfo neststate
To test connectivity against a specific domain controller
$ adinfo --T --servername [domain.controller.name]

Active Directory
To see the current AD Global Catalog
$ adinfo --gc
To see the domain/forest map
$ adinfo --sysinfo domain
To see the status of the AD computer trust relationship
$ adinfo --sysinfo adagent

Testing a user's password
$ adinfo -A --user [username] 
# this will prompt you for a password, the output is:
Password for user "username" is correct/incorrect

Configuration
To parse the contents of the centrify.conf file
$ adinfo --config
To show the client's in memory configuration parameters
$ adinfo --sysinfo config

Kerberos
To view Kerberos information like supported encryption types, key version and registered SPNs
$ adinfo --computer
To view the updated Kerberos configuration in the local system
$ cat /etc/krb5.conf
To list the principals in the system's krb5.conf file
$ dzdo /usr/share/centrifydc/kerberos/bin/klist -kt /etc/krb5.keytab
To determine the encryption types of the system's cached ticket
$ dzdo /usr/share/centrifydc/kerberos/bin/klist -fe /etc/krb5.ccache

PKI
adcert - centrify Microsoft PKI client

To perform auto-enrollment of Computer PKI certificates (requires elegible template and communications)
Using the computer object to authenticate
$ dzdo /usr/share/centrifydc/sbin/adcert --enroll --machine
Using a user to authenticate
$ dzo /usr/share/centrifydc/sbin/adcert --enroll --user [ADusername]


Dynamic DNS
addns - a dynamic DNS client for AD DNS or RFC 2136-compliant servers

To renew DNS using machine credentials
$ sudo addns --update --machine
To renew DNS using user credentials
$ sudo addns --update --user [ADusername]
To renew DNS only on a specific interface (e.g. eth0)
$ sudo addns --update --machine --interface eth0

Querying Centrify-enabled AD Users and Groups
adquery: provides information about Active Directory users and groups that are UNIX-enabled by Centrify

To view all Centrify UNIX-enabled users
$ adquery user
will show all AD users in Express mode / Only authorized in Zone mode
To view all Centrify UNIX-enabled groups
$ adquery groupwill show all AD groups in Express mode / Only unix-enabled in Zone mode
To view a user's entry (UNIX passwd file style)
$ adquery user [username]
To view a group entry (UNIX group filestyle)
$ adquery group [groupname]
To view only the user or group's AD group memberships
$ adquery user [user] --adgroup
To view all information about a user or group  (including AD object attributes)
$ adquery user|group [user or group] -A
To view the distinguishedName a user or group
$ adquery user|group [user or group] --dn
To view all information and include password expiration, account lockout/enabled state
$ sudo adquery user [user] -A
To view information about a computer
$ adquery user [computername]$ -A
To get results from cache (instead of fetching from AD)
$ adquery user|group [options] --cache-first

Centrify Cache Commands
adflush - clears the Centrify cache in the local computer (dc, gc, credential & dns)

To flush the authorization cache
$ dzdo adflush --auth
To rebind and force a new DC selection
$ dzdo adflush --bindings
To flush the DNS cache
$ dzdo adflush --dns
To expire the information from domain controllers and global catalogs
$ dzdo adflush --expire
To force complete removal/expiration even when disconnected (use carefully)
$ dzdo adflush --force
To refresh the krb5.conf file
$ dzdo adflush --trusts
To clear the health history
$ dzdo adflush --health
To clear the cloud connectors (in MFA scenarios)
$ dzdo adflush --connectors


Group Policy-related Commands
adgpupdate - triggers the group policy refresh interval

To refresh the GPOs in the system
$ adgpupdate
To refresh only computer GPOs
$ adgpupdate --target Computer
To refresh only user GPOs
$ adgpupdate --target User

adgpresult - to view a RSOP (resultant set of policy) to the local system or user

To view the report for computer and user
$ adgpresult
To view the report for the computer
$ adgpresult --computer
To view the report for the current
$ adgpresult --user
To view the report for a particular user
$ dzdo adgpresult --user [user.name]

Joining Active Directory
adjoin - joins an Active Directory domain

To run adjoin successfully, you need
> to be root or sudo
> to have the credentials (or the keytab) of an AD user that can join computers to a container (NOT Domain Admin)
> to know the Distinguished Name (e.g. "ou=servers,ou=unix") of the container that you will place the system in AD
> to know the domain name you're joining
> to have a clear network path to the DC or DCs you're using (dns, global catalog, kerberos, ldap, cifs, ntp).

To join AD in workstation/express mode (AD user must be able to add computers to "ou=workstations,ou=unix")
$ sudo adjoin --workstation --container "ou=workstations,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD in Self-Service mode (AD/Centrify admin pre-created the machine ahead of time using AM or Centrify PS)
$ sudo adjoin --selfserve [domain.name]
To join AD in zone mode (e.g. Global zone)
$ sudo adjoin --zone Global --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD in zone mode and don't initialize (precache)
$ sudo adjoin --noinit --zone Global --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD and trust the Computer for Delegation (must know what you're doing - security implications)
$ sudo adjoin --trust Global --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD in workstation mode and specify a workstation license
$ sudo adjoin --licensetype "workstation"--workstation --container "ou=workstations,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To use an specific domain controller to join (e.g. dc1.hq.fabrikam.com)
$ sudo adjoin --server dc1.hq.fabrikam.com Global --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join a Mac in Workstation mode and instruct Centrify to use the Apple algorighm to generate UID/GID scheme
$ sudo adjoin --enableAppleIDGenScheme --container "ou=macs,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD and provide a different "AD name" than the local system name (e.g. adserver vs. localhost)
$ sudo adjoin --name adserver --container "ou=servers,ou=unix" --user [AuthorizedADUser] --verbose [domain.name]
To join AD using keytab (kinit Authorized AD user keytab first, then run adjoin without the --user option)
$ env KRB5_CONFIG=[/path/to/krb5.conf] /usr/share/centrifydc/kerberos/bin/kinit -kt /path/to/keytab [principal]
$ sudo adjoin --zone Global --container "ou=servers,ou=unix" --verbose [domain.name]

Leaving Active Directory
adleave - leaves an Active Directory domain

To run adleave succesfully, you neeed:
> sudo or root
> for online leave, authorized AD user credentials

Leave the domain and disable the computer object (orphan object left behind)
$ dzdo adleave --user [Authorized ADUsername]
Leave the domain and remove computer object (frees license)
$ dzdo adleave --user [Authorized ADUsername] --remove
Offline/forced leave (no AD connectivity required, must clean-up in AD)
$ dzdo adleave --force

Privilege Elevation ("dz" commands)
dzinfo - displays information of the user's access controls

To view self access (all)
$ dzinfo
To view the properties of the role(s), including effectiveness
$ dzinfo --roles
To view how you can access the system (PAM rights)
$ dzinfo --pam
To view the commands you can run
$ dzinfo --commands
To view the computer roles that apply to the system (requires elevation)
$ dzinfo --computer-role
To view authorization information about about another user (requires elevation)
$ dzdo dzinfo [user.name]
To test a command against the role
$ dzinfo --test [path/to/binary] [options]

Centrify-enhanced sudo
dzdo - centrify-enhanced sudo. Uses Centrify zone data in AD for commands, otherwise identical to sudo.

To view version information (as of 2015, based on sudo 1.8.10p3)
$ dzdo -V
Use man sudo or man dzdo for more.

DirectAudit Commands ("da" commands)
dainfo - shows information about the status of the audit agent

To view the audit agent status
$ dainfo
To view status with verbose output
$ dainfo --diag  (or dadiag)
To view contents of the configuration file
$ dainfo --config
To view audited status of another user (must elevate)
$ dzdo dainfo --username lisa.simpson

dacontrol - controls the status/configuration of the directaudit client (requires elevation)

To set the installation (if not set by Group Policy)
$ dzdo dacontrol --installation [installation-name]
To check if the audit agent is enabled
$ dzdo dacontrol --query
To enable direct audit
$ dzdo dacontrol --enable
To disable direct audit
$ dzdo dacontrol --disable

What happens when adjoin is run succesfully?
This activates the DirectControl agent (adclient/CentrifyDC service).
1. Creates a computer object in AD and sets SPNs for http, host, nfs, cifs, afpserver
2. Establishes a secure communication channel between the system and Active Directory
3. A forest/domain/site map is created to locate the nearest DCs
4. The Kerberos environment (krb5.conf, krb5.keytab) are maintained by Centrify (configurable).  A backup is created.
5. Network time is synchronized with AD DCs (configurable)
6. The PAM (Pluggable Authentication Modules) are modified to include Centrify auth, account, password, session modules. A back-up of the previous configuration is made.
7. The NSS (Name Service Switch) providers for users and groups defaults to AD first, then other methods (e.g. files, ldap, etc).  A backup of the previous configuration is made.
Note: in the OS X platform, the PAM/NSS functions are channeled via the Directory Services Plugin API.
8. An Access Control Model is enforced depending on the zone mode:
- In zone mode:  Authorization (RBAC) follows zone rules (defaults to closed, only authorized users can access and enabled groups are visible)
- In express/workstation mode:  Only Authentication is facilitated.  The system is open for all AD users and all groups are visible.
9. Privilege Elevation:  Centrify-enhanced sudo (dzdo) becomes active based on the roles/rights defined.
10. User/Group identity (RFC2307) data in AD is stored within the Centrify zone, NOT with the user/group object.
11. The virtual registry is initialized and group policies are enforced.

What happens when adleave is run succesfully?
1. Online the --remove object:  The object in AD is removed from the container and from the zone (frees license)
2. Online the without --remove object:  The object in AD is marked as disabled.  Must be ovewritten to rejoin.
2. Offline:  The object in AD is left orphaned.  Cleanup must happen via any Centrify API (AM, PowerShell, adedit)
3. The UNIX environment is reset and rolled back (Kerberos, PAM, NSS)
4. The Centrify adclient (CentrifyDC) service is disabled.

Important Files and Folders
/usr/share/centrifydc/ 
/bin > contains user binaries, including centrify-enhanced openldap tools like ldapsearch
/sbin > contains system binaries, including adcert and centrify-enhanced OpenSSH
/samples > sample files for hadoop, adedit and local account management
Note: on OS X El Capitan, things changed to /usr/local/share/centrifydc


/etc/centrifydc
/centrifydc > config files for the DirectControl agent
/centrifyda > config files for the DirectAudit agent
/centrifycc > config files for the Privilege Service CLI Toolkit for AAPM
/openldap > config files for Centrify-enhanced OpenLDAP proxy if installed
/ssh > config files for Centrify-enhanced OpenSSH

/var/centrifydc
kset* files > dynamic information about the environment
reg > virtual registry, contains the computer and user hives  (user GPO disabled on Servers)

/var/centrify
net/certs > location of any Microsoft Certificate Authorithy auto-enrolled certs, keys and trust chain

[LABS] Testing the Local Account Management feature of Centrify Suite 2016

Background
There are several kinds of non-user accounts like local admin accounts (e.g. root, Administrator), application service accounts (e.g. oracle, Apache), network services (e.g. hdfs, yarn) or batch job/multi-tier apps (e.g. sftp, ssh, etc.)  The goal of Local Account management is to leverage the existing management infrastructure and framework (Active Directory, Centrify Zones, DirectMange/PowerShell/UNIX adedit) and the Centrify client (DirectControl) to provide an additional set of security controls. Centrify Suite 2016 provides the ability to:

• Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)
• Control local UNIX primary or secondary groups (provision, visibility control membership, or removal from /etc/group)
• Perform actions upon user creation/deletion, e.g. home directories, environment variables, password management/lifecycle.

We will provide the basic building blocks for you to evaluate this feature in your lab to explore the feasibility of it.
Like other posts, we'll use the Plan-Do-Check-Adjust model.

Planning
Use these planning steps for your test environment. We'veve added enough information that can be recycled towards production deployments.

Potential Stakeholders

• Centrify SME or Security Lead:  These users are entitled to perform management of zone operations inside Active Directory.
• Account Owners:  These are the subject matter experts that understand how the user or group accounts are used in the environment.  They can answer questions like these
  a) What local user (or group) accounts are required in a system or collection of systems?
  b) Should the account have a password?  should the password be managed?
  c) What are the group account members?
  d) Should the user or group account be visible to apps using name service (NSS)?
• Security Lead for Password Management:   This is the SME for a shared account password management solution.  They may know how to invoke any tools to manage the lifecycle for a shared account.

Technical Requirements
Active Directory and Centrify

• A licensed or evaluation copy of Centrify Suite 2016
• An Active Directory test or production environment with Centrify a Centrify Hierarchical zone
• A UNIX/Linux system with Centrify DirectControl 5.3+

Password Management (optional)

• If using Centrify Privilege Service (CPS), you need the CLI toolkit for your platform and a Cloud Connector that can reach your test systems.
• If using a 3rd party password manager, you need the tools and knowledge of the methods provided by the vendor
  In this example, we'll be using CPS.

Resources

• Centrify Administrator's Guide for Linux and UNIX
• Centrify Privilege Service - CLI Toolkit
• CLI tools and scripts:  admanagelocal, adflush, cjoin (CPS) cgetaccount (CPS)

How Local Account Management Works
The design and management is very similar to what you're used today with Centrify and UNIX-enabled AD users or Groups.

Information about the local user or group is stored in Active Directory.  The local users or groups are defined in the zone.  The scope of the local account is determined by where the identity is defined and the role that is assigned.  For example, if an account should exist and be enabled in all servers, then it's defined in the topmost zone and assigned a role with visibility at that level.  If it should only be visible to a group of systems (e.g. Database Servers) this can be done at the child zone or computer role level.  The management is exactly identical to UNIX-enabled AD users.
Once the changes are made in AD and the flush interval passes (or the adflush command is issued) the local account actions will be triggered.
There are additional CLI tools:

• admanagelocal:  to view existing managed local accounts or refresh the changes (or use adflush).
• handle_local_accts.sh:  this is a sample script provided to perform post-provisioning actions (e.g. home directory creation).  There are two versions of this script, one included with DirectControl, another one included with the CPS CLI Tools.

A Basic Lab Design
In my test environment I have:



1. An AD domain (centrify.vms) with a single domain controller (dc.centrify.vms)
2. A domain-joined server called "member" that has Access Manager installed (Suite 2016)
3. A Centrify zone called global with 2 computer roles:  App Servers and Web Servers
4. Two Linux servers (engubu1404 in the App Servers collection and engcen6 a Web Server)
5. Optional:  because I'll be testing the password lifecycle management, I have a CPS tenant and a cloud connector running on member.  CPS will provide the shared account password management functionality and workflow.

Use Cases

We are going to focus in several use cases:
Local UNIX Group Tests

• Provision a local group:
  - to all domain-joined systems
  - to a subset or individual system
• Manage group memberships
• Remove from /etc/group

Local UNIX UserTests

• Provision a local user
  - to all domain-joined systems
  - to a subset or individual system
  - have the password randomized and the home directory created
• Disable the user
• Remove from /etc/passwd

Local User and Password Management (optional*)

• Provision a local user and manually manage the account's password
• Provision a local user and automatically manage the account's password
• Retrieve the password for usage in break glass or scripting scenarios (admin or request via workflow)
  * These tests are optional given that they require a password manager that provides certain toolsets

Implementation
Download and Install the Centrify Suite 2016 bits

1. Download the Standard Edition 2016 Consoles
2. Download the Centrify client bits for your platform
3. Install Access Manager
4. Install or upgrade your agents  (e.g. install.sh, rpm or yum, apt or dpkg, etc)
5. Join a zone (use adjoin)

Although these steps should be straightforward to you, they are documented here:


General Test Cadence
There's a simple methodology to these tests:

1. Perform the change or update (e.g. create the local user/group, make visible, remove, change membership, etc)
2. Open a session to a system in scope of the previous change
3. Run getent (passwd or group) [target user or group]  > these result should not yield the results
4. Run adflush or 'admanagelocal --reload' (with sudo or dzdo) > this step causes the flush interval to expire and the changes in the zone to be committed by DirectControl
5. Run getent (passwd or group) [target user or group]  > these result should yield the results expected.

For example, if you create a new UNIX group called my-group (GID 3232) in all systems, after an adflush all systems should produce the same result.  If you do this in an individual system (or group of systems.

Differences between Group and User tests
a) Local Users follow the same rules as UNIX-enabled AD users 
Local users must have an identity and a role assigned to be visible in a system.  This allows for you to scope the visibility to the zone (all), child-zone (subset), computer role (subset) or individual system.  This differs from Groups that can be enabled at the zone, child-zone or individual system.

You can even time-bound the visibility of the role assigned to a local user.
b)Users must belong to at least a singe existing primary group

Otherwise, the provisioning won't work.
c) Post-provisoning actions must be defined via parameter or GPO
Provisioning users does not mean that home directories, environment variables or the password lifecycle will be handled by the Centrify agent; those actions are customizable.  Centrify provides a parameter called adclient.local.account.notification.cli; it can be used with a provided script /usr/share/centrifydc/samples/localaccmgmt/handle_local_accts.sh to perform these actions.

d) Don't fall in the poor habits
Always prefer computer roles (users) and child zones (users, groups) instead of computer overrides.

Local Group Testing Video

Local User Testing Video (without actions)


Testing local user provisioning plus actions
Using the provided handle_local_accts.sh to enable provisioning actions
In order to allow for actions to be performed upon user provisioning (or de-provisioning), Centrify provides a sample script called handle_local_accts.sh that will perform actions like assign a random password, create home directories, etc.  To enable this script:

1. Enable the adclient.local.account.notification.cli parameter (set for none)
   

   $ dzdo vi /etc/centrifydc/centrifydc.conf
   # search for adclient.local.account.notification.cli
   # enable the parameter by removing the pound and
   # set it to the path of the sample file
   adclient.local.account.notification.cli /usr/share/centrifydc/samples/localacctmgmt/handle_local_accts.sh
   

2. Run adreload (as root or with sudo/dzdo) and restart your testing.
   For example, to verify that a home directory was created after enabling a local account, you can use the following sequence:
   

   # use access manager to enable the account (e.g. james-foo)
   $ dzdo /usr/share/centrifydc/bin/admanagelocal --reload
   $ getent passwd managed-all
   # this should confirm that the user is enabled
   $ ls -l /home
   # there should be an entry for the recently-created account

Testing local user provisioning plus password management
Using CPS to manage the password lifecycle of a Centrify-provisioned local user account
This test can be performed with any password manager that provides UNIX/Linux-based CLI utilities.  The idea is that upon local account creation, the password manager is notified of the account creation, the password is randomized, changed and managed by the solution.   This example uses Centrify Privilege Service to illustrate the use case.

To set up this test, you need to have a CPS tenant with a Cloud Connector that can reach your systems and a Linux system with the CLI Toolkit.

1. Create a CPS role for the systems that will be used for testing and assign the Privileged Management right
   
   You can also use an AD group and add your computer objects and use it to nest it into the CPS role.
2. Now you can download and copy the CLI toolkit to your test system.
   
   You can add the bits to your repository or copy the installation files manually.
3. Install the CLI toolkit and add the system as a CPS resource (e.g. in my engcen7 RHEL system)
   

   # install the CPS CLI toolkit bits
   $ dzdo yum install centrifycc-rhel6-x86_64.rpm
   # add the system as a CPS resource
   $ dzdo cjoin -k -n engcen7 -a engcen7.centrify.vms
   # The command joins a system using Kerberos, names it engcen7 and gives it the 
   # hostname/ip of engcen7.centrify.vms (FQDN instead of address).  
   # You can verify the status using the cinfo command.

4. Switch the provisioning handler.  The CPS CLI toolkit includes another version of the handler.
   

   $ dzdo vi /etc/centrifydc/centrifydc.conf  # modify the parameter below
   adclient.local.account.notification.cli /usr/share/centrifycc/samples/localacctmgmt/handle_local_accts.sh
   

5. Run adreload (e.g. dzdo/sudo adreload)
6. Now you can add a new local account using access manager (e.g. managed-all)
7. First, verify that the home directory has been created, and then verify in the CPS accounts page that the account exists under the server.
   
8. You can also use the cgetaccount command to check-out the password for temporary use directly from the CLI.
   
   This is not really a practical example, most likely you'd assign the value of the password to a variable and use it on a script.

Provisioning local account with actions (random password/home directory) video

Provisioning local account with password lifecycle management (requires CPS or Password Manager)


This last video provides an example of Server Suite and Privilege Service working together:

1. We review the set up in the Centrify Privilege Service (connector, managed system role)
2. We verify the CLI toolkit in the target systems
3. We join the system as a resource in CPS (using cjoin)
4. We enable the adclient.local.account.notification.cli parameter to use the handle_local_accts.sh provided with CPS and reload the configuration
5. We enable our test account in Access Manager
6. We verify that the account exists in /etc/passwd and that home directory has been created
7. We verify that the acccount exists under the CPS server resource
8. We check-out the password via CPS Web GUI and UNIX CLI (with cgetaccount)
9. We perform an assisted SSH session with the account via CPS console.

Adjustments
There are several improvements to be made, for example:

• Customize the handler script to be suited to your environment
• Use your existing password manager to manage the lifecycle
• Upon deprovisioning, the home folder can be gzipped+tar and removed

[LABS] Testing the Centrify Reports Feature of Centrify Suite 2016

Background
This article describes the steps to install, configure and test the Centrify Reports feature included with Centrify Suite 2016.  You will find this article useful if you're looking to accomplish the following goals:

• Increase the speed of Access and Privilege related reports
• Provide information to your Security or Audit counterparts for Access or Attestation purposes
• Automate Attestation report generation and delivery
• Provide a data source for custom report generation.

Disclaimer:  This post is not a best practice, it's simply to aid you to study and test the feature before your consider it for production scenarios.

What is the Centrify Reports feature designed for?
It's designed to overcome the limitations of existing report generation via LDAP (speed), provide flexibility (SSRS or Bring your Own Reporting), and increase productivity (automate report generation and distribution).

Can you describe an example?
The typical scenario is that depending on your risk or regulatory profile you need to provide user entitlements (who has access to a server or collection of servers in a Centrify zone and  what can they do with Privilege using DirectAuthorize).  For example:

• Who has access to UNIX/Linux or Windows Server? What privileges do they have (dzdo/dzwin)? What AD object grants access?
• Who can access this collection of systems? What privileges do they have (dzdo/dzwin)?

These entitlement reports, are used typically in attestation exercises.  Attestation may be done manually (you get together an ratify that these are the proper people that should have accesss) or automatically using a Security Governance tool (at that point, a feed is inserted to the tool)..  As always, we'll be using the Plan-Do-Check-Adjust methodology.  In the labs, the goal is to test the features to be able to produce an viability assessment of the feature.

Planning
Use these planning steps for your test environment. We'veve added enough information that can be recycled towards production deployments.

Basic Requirements

• Obtain access and privileges reports in a timely fashion (for example, delivered daily, weekly, monthly or quarterly)
• Minimize impact to Active Directory domain controllers
• Automate delivery (e.g. email or shared folder)
• Allow reports consumers to customize reports based on their needs

Potential Stakeholders

• Active Directory Administrator:  To request and set up the account used to replicate AD Group and Centrify zone data to SQL Server.
• IT Infrastructure:  You can set up different distribution methods like file or web server and email.  The infrastructure SME will allocate shares, permission, SMTP relays or web servers.
• Security or Audit Analysts:  These are the consumers of this data.  They provide input on report data/distribution, etc.
• Database (SQL Server) Administrator (optional):  To work to set up a database instance (most likely in production);  if in a test lab, the Centrify bits include SQL Express.
• Reports SME (optional):  Depending on the size of your organization, you may have report developers that can customize the reports based on your security or audit needs.

Technical Requirements
Active Directory and Centrify

• A licensed or evaluation copy of Centrify Suite 2016
• An Active Directory test or production environment with Centrify hierarchical zone data (HZ Zones have RBAC)
• A domain-joined Windows server, ideally 2008 and up
• An Active Directory Service account (or two depending on your setup)
  An account needs the "Replicate changes" right in AD (to be able to read AD data and copy it to SQL)
  An account needs the "logon as a service" right in the system that runs the synchronization
• A Windows administrator or local admin rights to install programs in the test server.

SQL Server

• Versions validated: 2008, 2008R2, 2012, 2014;  Standard, Enterprise or Express (included with Centrify Suite 2016)
  Note:  with SQL Express, you have limitations on scale and capabilities.  E.g. can't do file/email subscriptions.
• If you need to test custom reports, email delivery, scheduling, etc; you'll need a Standard or Enterprise version of SQL
• If you want to test the Centrify-provided reports, you need to deploy SSRS
• If you want to test with a custom tool (e.g. Tableau) you'll need that software.

A Windows Server 2008 and up to install the Centrify Reports Service.  Depending on your deployment model, this may be the same machine as SQL or if it's a production design adhere to your organizational best practices.

Resources

• Centrify Administrator's Guide for Reports
• SQL Server Documentation (or leverage your DBA)
• Social: 
  What rights does “Replicating Directory Changes” actually grant in Active Directory?Please explain: "Replication Synchronization" permission in Active Directory
  Note: depending on the experience of your AD team, they'll know what the rights are used for; this is not unorthodox because it's a common practice when setting Sharepoint, FIM, Office365 DirSync or other services, however as we know you may get push-back based on lack of cognitive knowledge.

Design
Your design is going to be dictated by the capabilities that you with to test and your requirements.  Examples:

• If reports delivered via file-share or email are required and you'll use SSRS, then you need SQL server standard or enterprise.
• If you have your own reporting tool, SSRS is not needed, all you need is connectivity between your tool and the SQL server database instance that was used to sync the AD data that contains the Centrify access control data.

Here are some suggested(*) deployment models:

Note that the common denominators are AD, Centrify Hierarchical zone data and the service account required to sync AD data to SQL server.
(*) Remember that this is a "labs" post and this is a new feature.  Although I have input from beta testers, the true best practices come from our professional services organization.

How frequently should access and privilege data be synchronized between AD and SQL Server?
The answer to this question depends on the attestation requirement.  Examples:

• Some organizations do quarterly user access/privilege attestation exercises.  Perhaps synchronizing every quarter is fine in this organizations.
• Some organizations practice just-in time privileges (e.g. nobody has privileges or knows privilege account passwords) and they need reports daily to make sure there are nobody has any sticky privileges.  Daily reports that get delivered to a security analyst are required in this case, so a daily sync is in order.

The key here is that attestation has a component of comparing the access/privilege data from one time period to another and you have to plan your synchronization based on that.  Technically,  after the first sync or a rebuild, only the delta changes are requested from AD, this ensures that these operations don't negatively impact your Domain Controllers.  In a complex environment, your AD lead should understand that proximity to a Global Catalog will be an important design consideration.

Implementation
Download Suite 2016 from the Customer Support Portal and unzip the bits in an accessible folder on the domain-joined server.

Set up the AD Service Account
This step may be done for you by a Windows administrator.

1. Open Active Directory Users and Computers and navigate where you want the account to be created (OU or container)
2. Right-click the OU, New User and in the form type the First Name, Last Name and User logon name (e.g. centrify-reports) and press next
   
3. Set up a password for the account, depending on your practices, you may set the account's password to never expire, press next and then finish.

Delegate the Rights to Replicate Directory Changes from AD
In my example, I'm delegating at the top level of the domain, depending on the location of your users/groups, this may change.  This step may be done for you by a Windows administrator.

1. In Active Directory Users and Computers, right click the domain (e.g. corp.contoso.com) and select "Delegate Control" and press next on the first wizard page
2. Users or Groups:  Press the add button and find the newly created account, then press OK and press next.
3. Tasks to Delegate: Select "Create a custom task to delegate" and press next
4. Active Directory Object Type:  Keep the default radio button and press next
5. Permissions:  In permissions, scroll down and check the "Replicating Directory Changes" permission and press next and finish.
   

Delegate the Rights for the Account to run as a Service
In my example, I'm using AD Group Policy to grant my user the right to run as a service in that system.  The system is in an OU called Servers.  This step may be done for you by a Windows administrator.

1. Open the Group Policy Management tool and navigate to the OU that corresponds to the server, create or modify a GPO in and link it to that OU, right click it and select Edit (launches the group policy management editor).
   Alternatively, you would do this the Local Security Policy for the system.
2. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment and find the GPO named "Log on as a Service" and double-click it.
3. If not checked, check the "define these policy settings" and press the Add User or Group, click browse and make sure that the "From this location" has the AD domain selected otherwise click Locations and select it. 
4. Type the name of the service account and press check names.  Press OK three times.
   
5. Now you can close GPME and GPMC.

Installation of Report Services
You need administrative rights to install and configure this software.  This may have been granted to you or you're assisted by a Windows administrator.

1. Using Windows Explorer, find the unzipped Centrify 2016 folder and navigate to DirectManage > Report Services and either the MSI or EXE file in that folder (it's the same)
2. EULA Page:  Accept and press next
3. Destination Folder:  Select the proper destination or leave as default and press next and press install.
4. In the final page, leave the Config Wizard box checked.

The Report Services installation package installs 3 key apps:

• Configuration Wizard,
• Report Services Control Panel, and
• Report Services launcher.

Now you have two options for configuration, with SQL Express (included) or with SQL Standard or Enterprise

Configuration for SQL Express or Standard/Enterprise

1. Launch the centrify Report Services Configuration Wizard and press next in the welcome page.  The next steps depend on your setup:
2. If using SQL Express:
   SQL Server Page:  Select the "Install SQL Server Express instance on this computer" and use the default name (REPORTS) or change the name and press next.
   SQL Server Package:  press next or specify an alternative set of bits (must know what you're doing), press next.
3. If using SQL Standard or Enterprise:
   In this step, you're either authorized at the SQL server level login (integrated or mixed) or assisted by your SQL DBA
   SQL Server Page:  Select the "Use an existing instance" and browse to the instance to be used; press next and give it some time to connect.
4. Deploy Centrify Reports (optional):  You can choose to deploy the Centrify attestation reports to the SQL Server Reporting Services website.  This is only optional if you plan to use another reporting tool, press next.
   Note that you may need to run the Reporting Services Configuration Manager applet to determine these URLs.
5. Monitored Domains:  Defaults to the local domain, add any additional (you must have had delegated the account permissions and the proper AD trust direction has to be in place), press next.
6. Sync Schedule:  Select an appropriate frequency based on your reports needs, press next
7. Report Services:  Select "use account" and browse for the AD service account set up.  Type in the password and press next.
   At this point, the wizard will check if the account has the proper permissions in the monitored domains.  If you did not get the correct delegations, this will fail.
8. Press close and then next.
   At this point the installer will perform an assisted installation of SQL Server Express.
9. Once completed, you'll get to the configuration completed page and the check box to do an initial sync will be selected.  When you press finish, the service will do the initial sync.  From that point on, all will be delta synchronizations.

Verification (Check)
The verification steps vary depending on the features you've deployed. However, a key step is to verify that AD roles and rights and principal data is being sent to SQL server in the interval that is set.  For this you can use the Report Service Control Panel.

If you chose to deploy the SSRS reports, you should be able to use the Report Services shortcut and access the sharepoint-based report services.  This grants access to subscriptions, report builder, etc (if you're not running Express).

Here are some verification videos: 

Adjustments
There are may adjustments to be made to this configuration.  Some may or may not be related to Centrify technologies:

• Set up a file share subscription
• Set up a SMTP distribution email
• Use a custom tool for reporting
• Programmatically retrieve reports data

The good news is that all the building blocks already are in place.  Future entries can cover these topics.

Centrify Server Suite 2016 - New Features in Action

Centrify Server Suite 2016 - New features, New Platforms, New Possibilities

Just in time for the Holidays and the New Year Centrify delivered Server Suite 2016;  this release is focused on unleashing the power of the Centrify Platform:

a) Server Suite

b) Identity Service

c) Privilege Service

As well as continuing to delight customers and prospects.

Here are a few demos:

Step-Up Authentication (+ CIS)

Reporting Services (+SSRS)

Local UNIX User and Group Management

Privilege Service Integration - Automation Unleashed

Centrify Start Menu for DirectAuthorize Windows, CLI Tools, PowerShell, GPOs

New Supported Platforms (CDC)

-  Windows 10 (x86_64)

-  Mac OS X 10.11 (x86_64)

-  Fedora 23 (x86, x86_64)

-  CentOS 6.7 (x86, x86_64)

-  Oracle Enterprise Linux 6.7 (x86, x86_64)

-  Red Hat Enterprise Linux Desktop 6.7 (x86, x86_64)

-  Red Hat Enterprise Linux Server 6.7 (x86, x86_64)

-  Red Hat Enterprise Linux Server 6.7 (ppc64 – no Power8)

-  Red Hat Enterprise Linux Desktop 7.2 (x86_64)

-  Red Hat Enterprise Linux Server 7.2 (x86_64)

-  Red Hat Enterprise Linux Server 7.0, 7.1, 7.2 (ppc64 – no Power8)

-  Scientific Linux 6.7 (x86, x86_64)

-  Ubuntu Desktop 15.10 (x86, x86_64)

-  Ubuntu Server 15.10 (x86, x86_64)

-  SUSE Linux Enterprise Desktop 11 SP4 (x86, x86_64)

-  SUSE Linux Enterprise Server 11 SP4 (x86, x86_64, ppc64, ia64)

-  SUSE Linux Enterprise Server 12 (ppc64 – no Power8)

-  Oracle Solaris 11.3 (x86_64, SPARC)

Centrify DirectControl for UNIX/Linux/Mac and servicePrincipalNames

Background

IT Ops often ask themselves about servicePrincipalNames in the context of Kerberos and ActiveDirectory.  When a system is Centrified, part of the process is to populate some of these entries to facilitate certain services to "just work";  SPNs play a part on that equation;  however there may be conflicts as well;  many organizations use Centrify software to simplify and secure Hadoop implementations at the OS-layer;  there may be conflicts with other Kerberos-enabled apps as well.  This quick article consolidates the questions that we commonly get as it relates to SPNs and Centrify DirectControl.

What is a Kerberos SPN?

ServicePrincipalName is the name by which a Kerberos client identifies an instance of a service.  The simple format entry in Active Directory looks like this:  service/realm:PORT.  E.g. HTTP/host.example.com

What does this have to do with Centrify?

Centrify uses Kerberos for authentication against Active Directory.  When you join a UNIX, Linux or Mac system into Active Directory using Centrify, there are a set of ServicePrincipalNames defined for the system by default.  Some of these are (varies between platforms). 

afpserver:  for an Apple file server

cifs: for a Samba file server

ftp: for a Kerberos-enabled ftp server

host: for host services like SSHD

http: for Web Servers that use SPNEGO

ipp: for web-based printing

nfs: for Kerberos-enabled NFS

How commonly used are this servicePrincipalNames?

In an Active Directory environment, because it uses Kerberos as the authentication protocol, you interact with Kerberos-enabled services all the time.  As an example, right now, you can connect to a Centrified system using ssh.  When you do, you are getting a service ticket for the HOST service for that system.  You can verify this with the klist command on Windows or in UNIX.    For example:  Diana (dwirth) connects to two centrified systems using PuTTY (engcen6 and linux2); then she opens PowerShell and verifies that she has a service ticket.

Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.

PS C:\Users\dwirth> klist | sls host

    Server: host/engcen6.centrify.vms @ CENTRIFY.VMS
    Server: host/linux2.centrify.vms @ CENTRIFY.VMS

When does the service registration happen, when I install your CentrifyDC package?

No.  Remember that installing our packages only will place our binaries in your system.  These changes happen when you run the adjoin command OR on the AD side, when you use the "Prepare UNIX computer" option in Centrify Access Manager or when you use the New-CdmManagedComputer PowerShell commandlet.

You have a chance to add/remove or modify SPNs during the Pre-Create stage.

Why do you do this?

To make sure that certain common services that rely on Kerberos just work out of the box.

Can I control the behavior of the default SPNs?

Yes.  The adclient.krb5.service.principals parameter takes care of what SPNs are set up in the computer’s AD object and its corresponding system keytab entries. All you need to do is enable the parameter, PRIOR to running adjoin to join AD and only the entries defined will be created by default.  From the Centrify UNIX configuration guide:

"adclient.krb5.service.principals

This configuration parameter specifies additional service principals 
for entries in the Kerberos key table. The key table is populated by 
default with the service principals host, http, cifs, and nfs.
This parameter's value must be one or more principal service names, 
separated by a space or by a comma. For example:

adclient.krb5.service.principals: http ftp cifs nfs

If this parameter is not defined in the configuration file, no 
additional principal names are added to the Kerberos key table."

You can also leverage the Precrate option in Access Manager or the New-CdmManagedComputer PowerShell commandlet.

How can I see the existing registered SPNs for a Centrified system?

On UNIX/Linux/Mac CLI:   Use the “adinfo –C” command from the CLI. 

1. Make sure you have a current Kerberos ticket. If you get a "cannot bind" error, just kinit and reauthenticate against AD.

$ adinfo -C
Computer Account Diagnostics
  Joined as: engcen6
  Trusted for Delegation: true
  Use DES Key Only: false
  Run adinfo as root to examine local key info
  Key Version: 11   (local key version unavailable)
  Service Principal Names: myservice/engcen6
                           myservice/engcen6.centrify.vms
                           nfs/engcen6.centrify.vms
                           nfs/engcen6
                           ipp/engcen6.centrify.vms
                           ipp/engcen6
                           http/engcen6.centrify.vms
                           http/engcen6
                           host/engcen6.centrify.vms
                           host/engcen6
                           ftp/engcen6.centrify.vms
                           ftp/engcen6
                           cifs/engcen6.centrify.vms
                           cifs/engcen6
                           afpserver/engcen6.centrify.vms
                           afpserver/engcen6

Supported Encryption Type(s): RC4-HMAC
                              AES128-CTS-HMAC-SHA1-96
                              AES256-CTS-HMAC-SHA1-96

Operating System Version: 6.1:6.5 (Final)

From Windows using the CLI:  Use the “setspn.exe –L <hostname>”

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\>setspn -L engcen6
Registered ServicePrincipalNames for CN=engcen6,OU=Servers,OU=centrifyse,DC=cent
rify,DC=vms:
        myservice/engcen6
        myservice/engcen6.centrify.vms
        nfs/engcen6.centrify.vms
        nfs/engcen6
        ipp/engcen6.centrify.vms
        ipp/engcen6
        http/engcen6.centrify.vms
        http/engcen6
        host/engcen6.centrify.vms
        host/engcen6
        ftp/engcen6.centrify.vms
        ftp/engcen6
        cifs/engcen6.centrify.vms
        cifs/engcen6
        afpserver/engcen6.centrify.vms
        afpserver/engcen6

From Windows Using Active Directory Users and Computers

1. Make sure that the Advanced Features check is set in the View menu.
2. Find the computer object > right click > Properties > Attribute Editor
3. In the Attribute Editor, find the servicePrincipalName field.
   

What if I need to change the SPNs for an existing system?

There are several ways to do it.  The easiest way to do it is using adkeytab; however if you want this to happen automatically during join, you have to modify the configuration file.

You can also use adleave/adjoin, however this has the drawback that the agent will be disabled temporarily.

Using adkeytab 
To add an SPN to the computer

Example:  adding the oracle service to the shortname engcen6 – notice that you need to be root or elevate to change the system keytab, plus you'll need an AD user that can modify the computer object in AD.

1. Run “dzdo adkeytab --addspn --principal [principal in correct format] --user [ad-user-that-can-modify-computer-object] --verbose”
   

   $ dzdo adkeytab --addspn --principal oracle/engcen6 --user dwirth --verbose
   Active Directory Password:
   ADKeyTab version: CentrifyDC 5.2.0-218
   Options
   -------
   use machine ccache: no
   domain: centrify.vms
   server: null
   user: dwirth
   container: null
   account: null
   trust: no
   des: no
   dwirth@CENTRIFY.VMS's password:
   Attempting bind to centrify.vms site:Demo-Network server:dc.centrify.vms: ccache:MEMORY:0x5666c0
   Bind successful to server dc.centrify.vms
   Searching for AD Object: filter = (samAccountName=engcen6$), root = DC=centrify,DC=vms
   AD Object found: CN=engcen6,OU=Servers,OU=centrifyse,DC=centrify,DC=vms
   Key Version = 11
   Success: Add SPNs: Default Key Tab
   

2. Verify the new SPN with “adinfo –C”
   

   $ adinfo -C | grep oracle
     Service Principal Names: oracle/engcen6
   

3. Optional:  List the contents of the system keytab
   

   dzdo /usr/share/centrifydc/kerberos/bin/klist -kt /etc/krb5.keytab | grep oracle
     11 12/16/15 07:27:47 oracle/engcen6@CENTRIFY.VMS
   [output truncated]
   

   The KVNO goes up, and the new entry is present.

To remove an SPN from the computer (example:  removing the entry I added above to the same system)

1. Run “dzdo adkeytab --delspn --principal oracle/engcen6 --user [ad-user-that-can-modify-computer-object] --verbose”
   

   $ dzdo adkeytab --delspn --principal oracle/engcen6 --user dwirth --verbose
   ADKeyTab version: CentrifyDC 5.2.0-218
   Options
   -------
   use machine ccache: no
   domain: centrify.vms
   server: null
   user: dwirth
   container: null
   account: null
   trust: no
   des: no
   dwirth@CENTRIFY.VMS's password:
   Attempting bind to centrify.vms site:Demo-Network server:dc.centrify.vms: ccache:MEMORY:0x5666c0
   Bind successful to server dc.centrify.vms
   Searching for AD Object: filter = (samAccountName=engcen6$), root = DC=centrify,DC=vms
   AD Object found: CN=engcen6,OU=Servers,OU=centrifyse,DC=centrify,DC=vms
   Key Version = 11
   Deleting SPN oracle/engcen6
   Keeping SPN myservice/engcen6
   Keeping SPN myservice/engcen6.centrify.vms
   Keeping SPN nfs/engcen6.centrify.vms
   Keeping SPN nfs/engcen6
   Keeping SPN ipp/engcen6.centrify.vms
   Keeping SPN ipp/engcen6
   Keeping SPN http/engcen6.centrify.vms
   Keeping SPN http/engcen6
   Keeping SPN host/engcen6.centrify.vms
   Keeping SPN host/engcen6
   Keeping SPN ftp/engcen6.centrify.vms
   Keeping SPN ftp/engcen6
   Keeping SPN cifs/engcen6.centrify.vms
   Keeping SPN cifs/engcen6
   Keeping SPN afpserver/engcen6.centrify.vms
   Keeping SPN afpserver/engcen6
   Removing SPNs from ADObject engcen6
   Removing spns and from config file for engcen6
   Removing SPNS from Keytab for engcen6
   Success: Del SPNs: Default Key Tab
   

2. Verify the new deleted SPN with “adinfo –C”
   

   $ adinfo -C | grep oracle
   $
   

   No results imply that there's no entry.

Using adleave/adjoin 

1. Edit the /etc/centrifydc/centrifydc.conf file and use the krb5.service.principals parameter to reflect the desired SPNs and save the file
2. Note the Zone and Computer Roles the system belongs to  (using access manager, UNIX CLI or ADUC)
3. Leave AD by running “dzdo adleave –r –u [AD-user-that-can-remove-the-computer-object]”
   this will leave the domain and remove the computer object;  if you rather do an offline leave, use the adleave -f command.
4. Join AD by running the “[elevate] adjoin –z [zone] –c [container-in-ad] –u [ad-user-that-can-join]  [domain.name]” 
   if you have to join any computer roles, use the –computerrolrole parameter and list the computer roles.
5. Verify that the newly-joined system has the SPNs you require by using adinfo -C

Do you know any instances of conflicts with these SPNs?

Yes.  Other Kerberos-enabled apps may rely on these SPNs.  Some notables:

• Hadoop:  Applications like Cloudera Manager, Hortonworks Ambari or MapR Control System will create HTTP records for SNEGO-enabled services.  The best practice is to disable the http SPN using the krb5.service.principals parameter PRIOR to joining any systems that will participate in Hadoop clusters.
  For example, if I forgot to remove the http entry and I already joined my Hadoop node, all I need to do is run the "sudo adkeytab --delspn --principal http/shortname --principal http/fqdn --user myuser"  > this will remove all http SPNs.
• Certain Java apps:   Some Kerberized java applications may have other conflicts.  Applications vary.
• Mixed Kerberos Environments: In environments with mixed Kerberos environments (where AD and MIT Kerberos coexist) there may be conflicts, however if you follow the guidelines on Mixed Kerberos, there should be none given that the realms are different and the system keytabs & krb5.conf files are independent.

Centrify and Active Directory Functional Upgrades

This article was written originally for the Centrify Community.

What are Active Directory Functional Levels?
When Microsoft introduces new versions of Windows Server, they may add new capabilities to Active Directory. These new capabilities impact the environment and require planning, the “functional levels” can be introduced by the organization as they become ready. There are two types of functional level upgrade: domain and forest; the scope of forest functional levels affect the whole subtree, and domain-level changes only affect the target domain. A very common misconception is that all features are enabled. A functional upgrade may make a new capability or schema objects available, but it does not mean that your organization is ready or will use those capabilities.

Why should I know this, I only deal with UNIX | Linux | Mac OS X and upper-layer apps (Apache, Java, SAP, DB2)?
When your organization committed to use Active Directory on non-Windows platforms, they gained efficiencies and improved security capabilities, however, AD becomes an integral piece of infrastructure just like power, cooling, switching/routing, etc. All systems relying on AD must be aware of “functional-level” major changes.

What will be the impact to my UNIX, Linux or Mac systems when the Functional level goes up?
The answer to this question really depends on how well you manage your environment.
The rule of thumb is this. If you deployed Centrify in your UNIX, Linux or Mac environment a few years ago and time constraints have kept you from maintaining it (or because it just works), you’ll have a tougher time. If you’ve been keeping-up with the software lifecycle (upgrades) and are listening-in your AD planning calls; you may be so ready that your impact could be close to nothing.
To level-set here, this is not a “Centrify-only” consideration; this affects software and hardware that integrates to Active Directory. This article is to deep-dive into Centrify Server Suite and Identity Service Mac Edition (on-premises client).

You caught my interest. Can you tell me more about Active Directory functional levels?
The best source of information is this Microsoft TechNet article: https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx. If you want to be better informed, see the reading list below.

What happens when I raise the Domain Functional Level as it relates to Centrify?
The answer depends on what your current functional level is and what functional you're raising it to.
Let’s focus on 3-key aspects of going from DFL 2003 and DFL 2012 (conveniently how I set up my lab :smileyhappy:).

Kerberos
Centrify DirectControl (centrifydc/adclient), just like any other Active Directory client, uses Kerberos as the authentication protocol. In Kerberos session tickets encrypted using cyphers (algorithms).
As time goes both computers have more power and mathematicians grow smarter or find issues with existing algorithm. A very good example is the Data Encryption Standard (DES), it has been around since the 70s and it was broken in the late 90s; therefore DES became phased out by AES officially in 2002.
One of the changes introduced by a DFL is better encryption algorithms.

• Raising the DFL to Windows Server 2008 implements AES 128 and AES 256 for Kerberos.

This is why Microsoft's first guidance is to perform an inventory of your AD real estate. When this change happened, many older systems could not authenticate as illustrated in this example. In some instances, even a non-DFL change like adding a “newer OS” to perform the domain controller role can introduce side effects. For example, introducing a Windows Server 2012 Domain Controller to a Windows 2003 DFL Domain will immediately will disallow older crypto algorithms.

Summary – stronger cryptography is good, however, raising the DFL to Windows 2012 OR introducing a Windows 2012 domain controller in a 2003 forest requires at a minimum Server Suite 2014.1 (5.2.x).

KRBTGT Password Change
Active Directory has a built-in account called “krbtgt” (Kerberos TGT). This account has a complex password that is only known to low-level services; However, this is a very important account because every Ticket Granting Ticket (TGT) generated by users and computers is encrypted with a key that is derived from this password. As you probably can infer from the previous topic, once you switch the cypher, the secret is updated as well.

• Raising the DFL will change the password of the KRBTGT account; this makes older secrets invalid.

Microsoft, as part of their strategy to mitigate advanced attacks like Pass-the-Hash (PtH) and others has established new best practices around the krbtgt account, but that’s the topic for another post.

Summary: When using stronger crypto, the passwords for the krbtgt will change.

SID Compression
The Windows Security Identifier (SID) is the unique and immutable identifier for an AD principal (user, group, etc.). Microsoft Kerberos implements methods that use the Privilege Attribute Certificate (PAC), in an over-simplistic way, the PAC contains information about the group membership and authorization information for the corresponding security principal.
Active Directory clients often need to make decisions about access control with information contained in the PAC; however when principals belong to large numbers of groups the information can't fit inside the data structure and that's why SID compression was implemented. Within Centrify Server Suite, this is very important especially in the context of Zones and DirectAuthorize.

• Windows 2012 Domain Controllers implement SID compression and is turned on by default.  If an AD client can't decompress the SID to view the PAC, it will have functionality issues.

This has caused many known issues, however there's flexibility given that you can disable SID compression at the object  level or at the DC level.

Summary: SID compression is enabled on Windows 2012 DCs.  This is important for group enumeration and authorization.

Now you made me worried, What should I do?
 No need to be worried, there are plenty of resources available (see the reading list below); I think that by reading this article you should be informed and dangerous enough, however my advice is this:

• Keep your agents up-to-date.
  This can be painful, but if you’re within the 3-year software life-cycle (for standard support, 5 years for premium), you should be fine. Keep in mind, you have to also be realistic. For example, Windows 2012 R2 was released in October of 2014 and Server Suite 2014.1 was released in August. In that case Centrify was ahead of the ball if organizations were looking to deploy that version of the software. In some instances we are behind and provide functionality based on the needs of our customer base.
• Maintain your consoles and utilities up-to-date
  Consoles and PowerShell commandlets are backwards compatible. Tools like Deployment Report can be great tools to inventory clients.
• Familiarize yourself with Microsoft’s methodology
  The methodology is outlined here: http://blogs.technet.com/b/askpfeplat/archive/2013/04/29/upgrading-or-migrating-active-directory-to-windows-server-2012-build-your-roadmap-now.aspx
  If you are working closely with your AD team, in the Assess phase you should be providing an inventory of all your Centrify clients and inform them if the version installed will support these key things: AES Encryption, KRBTGT password changes and SID Compression.
• Document  any exceptions
  You should also inventory if you have hardcoded certain parameters like adclient.krb5.permitted.encryption.types. Ideally you should let DCs negotiate with the client, they typically go for the maximum (AES256).

Any tools, tips or tricks to share?
You can use Centrify CLI tools, Consoles and Utilities to discover, diagnose and collect information for your Functional Upgrade project.  Here are some examples:

Determining the Centrify version (per system - see below for inventory)

$ adinfo -v
adinfo (CentrifyDC 5.2.3-429)

Determining the forest and domain functional levels (per forest/domain)

$ adinfo --diag | grep Functionality
    domainFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    forestFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    domainControllerFunctionality: 6
    domainFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    forestFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    domainControllerFunctionality: 6

Determining if the encryption types have been changed (per client exception)

$ grep encryption.types /etc/centrifydc/centrifydc.conf
# adclient.krb5.tkt.encryption.types: aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
# * the default encryption types permitted for Windows 2000 server and
#   adclient.krb5.permitted.encryption.types: arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
# * the default encryption types permitted for Windows Server 2008 domain
#   adclient.krb5.permitted.encryption.types: aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc

Determining the Kerberos system key table (keytab) encryption (per agent)

$ dzdo /usr/share/centrifydc/kerberos/bin/klist -ke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (ArcFour with HMAC/md5)
[output truncated] 

For each ServicePrincipalName (SPN) you should see an AES256 entry for DFL 2008 and above.

Determining if the encryption type on the system's ticket cache

$ dzdo /usr/share/centrifydc/kerberos/bin/klist -fe /etc/krb5.ccache
Ticket cache: FILE:/etc/krb5.ccache
Default principal: engcen6$@CENTRIFY.VMS

Valid starting     Expires            Service principal
12/08/15 14:56:35  12/09/15 00:56:34  krbtgt/CENTRIFY.VMS@CENTRIFY.VMS
        renew until 12/09/15 14:56:35, Flags: FRIA
        Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC

Building an Inventory of Centrify agents and versions
Open Access Manager > Right Click "Centrify DirectManage Access Manager [dc]" > Select Deployment Report (Standard Edition)


What if I want to test this?

You'll need
a) A Windows Server (2003 or 2008) acting as a DC at the low level (e.g. Windows Server 2003 DFL)
To test the raising of the DFL to
b) A Windows Server 2012 member server that you can promote to a DC
To test the introduction of a 2012 DC
c) A Centrify client in any mode (Express | Workstation | Zone) for UNIX, Linux or OS X.

Video


Reading List

• https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx
• http://blogs.technet.com/b/askds/archive/2011/06/14/what-is-the-impact-of-upgrading-the-domain-or-forest-functional-level.aspx
• http://blogs.technet.com/b/askpfeplat/archive/2013/04/29/upgrading-or-migrating-active-directory-to-windows-server-2012-build-your-roadmap-now.aspx
• http://blogs.technet.com/b/askpfeplat/archive/2012/09/03/introducing-the-first-windows-server-2012-domain-controller.aspx
• http://windowsitpro.com/security/resetting-password-krbtgt-active-directory-account
• http://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf
• http://social.technet.microsoft.com/wiki/contents/articles/24370.sid-compression.aspx
• https://support.microsoft.com/en-us/kb/2774190