Active Directory provides a Public Key Infrastructure (PKI) capability with the Microsoft Certificate Authority. This is quite convenient to system administrators especially when combined with Group Policy since it allows for the automation of the Certificate lifecycle: issue, renew, revoke, supersede templates, etc.
We've discussed this before, but Centrified clients can also take advantage of Certificate auto-enrollment. This can happen automatically or manually using the adcert utility.
How it works?
The process works as follows:
When a system is joined to AD using Centrify, as part of the join the system will read the domain controller's SYSVOL for Group Policies. The system may download the trust chain (containing the trusted CAs or the local root CA) and any revocation information to the /var/centrify/net/certs folder.
If the auto-enrollment policy that applies to the system points to a usable template, the agent will attempt to enroll automatically when the GPO refresh interval starts. Note: there are different auto-enrollment GPOs depending on the version of Active Directory.
The agent will use the computer's credentials with the adcert utility and connect to the CA or Intermediate CA to obtain a certificate set for autoenrollment.
adcert will issue pkcs10 request for each template, if an issuing CA is found for the templates in question and the certificates, chain and private key (if defined exportable by the template) will be placed in the /var/centrify/net/certs folder with this format: [name of template].cert [name of template].key [name of template].chain
Once the certificate is in your system, you may be able to use it as is, or you may have to change the encoding using OpenSSL tools.
Hadoop implementations present multiple challenges to enterprises at the Operating System layer(*), I like to categorize them in 2 areas:
Confidentiality
Hadoop clusters are unsecure by default. What that means is that there's no service-to-service authentication and that privileged users have access to world-readable information and can elevate to privileged Hadoop accounts.
Multiple clusters are needed because of the development nature of the apps. Typically at least a DEV/QA and PROD environments are needed, depending on the risk profile of the organization, each environment may be in different isolated environments and require different access control rules.
Different types of users need access: From the SysAdmin, to the Hadoop Admin, to the Data Scientist, they all have different access and privileged needs.
The data classification of the business intelligence may require additional controls. What if the cluster crunches Personal, Financial, Health, Energy or Card data? SOx, PCI, HIPAA, NERC or FERC compliance is needed.
Integration
Kerberos: Many organizations balk at the proposition of standing-up a separate MIT Kerberos implementation; and even if AD is an option, test environments may be in a one-way trust.
Different organizations == Different requirements, therefore the devil is in the details:
Process
Technology/Infrastructure
People
Regulations
(*) There are additional security challenges, like how to protect data at the Hadoop layer, for this, your trusted Hadoop vendor (Cloudera, Hortonworks, MapR, etc) have an ecosystem of applications. Centrify can provide identity information to those apps.
Technical Briefing
The following videos provide technical demos on how Centrify can overcome these challenges
Putting it all together
Centrify allows for OS level integration for Linux and UNIX systems that enables:
Centralized Administrations of multiple Hadoop Clusters
Regardless of how complex your AD may be
No schema extensions or software in domain controllers
Using UNIX frameworks
Kerberos just works out of the box
Leverage AD fully: Kerberos, Group Policy, PKI
Centrify enables the implementation of strong access controls to enforce
Least access
Least privilege (RBAC- not password Centric)
Easy attestation and reporting
Separation of Duties
Works on Windows to eliminate the problem of the persistent administrator
For environments with Personal, Financial, Health or Card data
Session transcription
Session replay
Event consolidation
Works on Windows
Hadoop-exclusive features:
adkeytab for advanced keytab/service account provisioning
Kerberos infinite ticket renewal parameters and GPOs
LDAP Proxy to assist apps like Sentry, Hue and Knox
Partner with Cloudera, MapR and Hortonworks
Centrify + AD + Hadoop = faster, more secure and regulation-aligned big data projects.
Requirement
In case
of an Active Directory catastrophic failure, a limited set of trusted
administrators shall be able to log in to UNIX, Linux or OS X systems
and perform the actions defined in their privileged management roles.
Scenario
Contoso
has 3,000 servers and many of them on branch deployments and public
clouds, there are no DCs in the branches. WAN connectivity can be lost
and a mechanism to allow trusted administrators to perform actions
should be available. It's highly unlikely the set of trusted admins
have logged in to all systems. This is why Centrify implemented the account prevalidation feature.
Target Group:
Account prevalidation can be assigned to users or groups. Ideally this
would be assigned to groups so the management can be delegated to the
Helpdesk, or front ended by an ITSM or Worfklow solution. This means that an AD Group should be requested. Sample Name: Centrify-Prevalidated-Admins
Process: Onboarding:
When senior UNIX, Linux or Mac OS X administrators are onboarded, the
user template or form should be updated so they are added to this group
by default. One-offs: When critical projects are going on
and stakeholders need to be added to this group, our ITSM tool will
front end a workflow request that ends on a PowerShell action that adds
(or removes) the user from the target group. Attestation: This group does not have any additional rights, however it has to be attested as part of the disaster recovery plan.
Implementation What you'll need
Centrify Standard Edition or Centrify Identity Service Mac Edition (licensed)
A Windows system with Group Policy Management and the Centrify Group Policy Extensions (GPOE) installed
An Active Directory group pre-populated with the users that will be prevalidated
A GPO tied to the OU of the target UNIX, Linux or OS X systems.
Rights to edit the GPO
Centrified system in the OU that has the GPO linked to verify.
First, Gather information about the members of the group
From a Centrified System
$ adquery group -A Centrify-Prevalidated-Users | grep members
members:centrifyimage.vms/Staff/IT/Diana Wirth
From Windows with PowerShell
PS > get-adgroupmember Centrify-Prevalidated-Users | Select-Object samaccountname
samaccountname
--------------
dwirth
rpimentel
Second, Configure the GPO
Open Group Policy Management
Create or edit the GPO in the corresponding forest/domain/OU.
In group Policy Editor, navigate to Computer Configuration > Policies > Centrify Settings(*) > DirectControl Settings(**) > Account Prevalidation.
In the right pane, double-click on "Specify allowed groups for
prevalidation" select Enabled and populate the dialog box with the group
predefined for this purpose and press OK and close Group Policy Editor. (*) If you don't see a Centrify Settings section, you don't have the Centrify GPOE installed. (**) If you don't see a "DirectControl Settings" folder, you need to add the template.
Third, Add the Preval SPN to the members of the group and commit the changes in the Centrified system
a) To add the SPN
# From Windows with the setspn utility
C:\> setspn -A preval/rpimentel rpimentel
Checking domain DC=centrifyimage,DC=vms
Registering ServicePrincipalNames for CN=Diana Wirth,OU=IT,OU=Staff,DC=centrifyimage,DC=vms
preval/dwirth
Updated object
# From Windows using PowerShell
PS > Get-ADUser dwirth | Set-ADUser -ServicePrincipalNames @{Add="preval/dwirth"}
# From a Centrified System Using adedit
## Authenticate as someone who can edit the target object
$ kinit administrator
Password for administrator@CENTRIFYIMAGE.VMS:
# Open adedit, bind to domain and use the add_object_value function
$ adedit
>bind centrifyimage.vms
>package require ade_lib
1.0
> add_object_value "CN=Diana Wirth,OU=IT,OU=Staff,DC=centrifyimage,DC=vms" serviceprincipalname "preval/dwirth"
1
> exit
# Manually using Active Directory Users and Computers
Open ADUC
In the View menu, check "Advanced Features"
Open your target user > Attribute Editor > servicePrincipalName
Click add, and type preval/<user>, press OK twice.
b) To verify the SPN was added succesfully # from a Centrified system using CLI
$ adquery user dwirth --attribute servicePrincipalName
preval/dwirth
# from Windows using PowerShell
PS > Get-ADUser dwirth -prop ServicePrincipalNames | Select-Object Name, ServicePrincipalNames
Name ServicePrincipalNames
---- ---------------------
Diana Wirth {preval/dwirth}
c) To commit the changes to a system for the purposes of testing
## flush the cache - only if you want this immediately (will happen automatically after cache flush interval + gpo refresh
$ dzdo adflush
DNS cache flushed successfully.
Authorization cache store flushed successfully.
GC and DC caches expired successfully.
DA name cache flushed successfully.
DA installation information cache flushed successfully.
## perform a group policy update - again, this happens on the GPO refresh.
$ adgpupdate
Refreshing Computer Policy...
Success
Refreshing User Policy...
User Policy disabled on this machine.
## verify that the GPO inserted changes in the config file
$ adgpresult | grep Centrify-Prevalidated-Users
adclient.prevalidate.allow.groups = Centrify-Prevalidated-Users,
Notes: This process can also be implemented with a Management tool like Chef, Puppet, Spacewalk, etc. Ultimately the parameter that will be adjusted is the "adclient.prevalidate.allow.groups" in the /etc/centrifydc/centrifydc.conf file. This can also be part of a master config file that is enforced across the board, but watch out for conflicts with GPOs. You must pick a tool.
Verify and Test
To verify prevalidation you'll need a recently centrified system OR a system that you know one of your test subjects has never logged in. You will also have to switch the agent to offline mode. There are two ways to do it:
a) If this is a VM, go to the hypervisor console, and disconnect the network; OR
b) Force the agent to go offline by adding all your DCs to the dns.block parameter.
E.g. if I have 2 DCs (dc1.corp.contoso.com and dc2.corp.contoso.com), the parameter would look like this:
c) If you have console access, you can also disable the network interface momentarily.
This video explains the installation and testing process:
Adjustments
There are several areas of improvement for this process:
Automation
A really cool improvement has to do with the automation of the prevalidation SPN. For example, you can implement both in a Centrified UNIX/Linux system or with Windows PowerShell script that checks if new users are added to your target group, and automatically will add (or remove) the preval SPN.
Service Management and Approvals
If you have an ITSM (like ServiceNow) or an IdM with workflow/approvals, you can front-end this process by adding references and approvals to be able to answer these questions:
Centrify Identity Platform consists of two products: Identity Service and Privileged Service
Centrify Identity Service (formerly User Suite) has continued its meteoric rise and I want to congratulate many of my coworkers on their hard work and dedication.
In the past two weeks, to major publications have continued to highlight its critical acclaim:
Positions Centrify as a visionary, proving and validating the completeness of the vision that combines On-Prem/SaaS SSO with Enterprise Mobility Management plus robust policy, Multi-factor Authentication and VPN-less Access.
Ranks #3 among the solutions in a year that saw Salesforce, IBM and Microsoft enter the market and continues to beat the leader in execution and completeness of vision (#2 in pure play). It's only a matter of time given Centrify's leadership.
This is all looking at data from last year!!!! This is before App Gateway, Privileged Service, ServiceNOW integration and others were ready to go. Get the report here.
Calls out the integration of SSO+EMM+MFA+Management interface. Everyone else left to eat the dust.
Centrify Privileged Service (CPS) is a new entry (announcement) to the hybrid family of products that has a pure play in two areas (and growing): Shared Account Password Management (SAPM) and Secure Remote Access, but it builds on the existing capabilities of the Identity Service to deliver complementary capabilities to Server Suite.
RBAC continues to be the preferred method for Privileged Account Management (PAM), however, for emergency, one offs and change control, using a shared privileged account can be useful. Here's a video that illustrates the differences between the approaches:
Capabilities of CPS
Shared Account Password Management
Use your AD account and Multi-factor authentication to check out UNIX, Linux or Windows accounts, enforce policy, access anywhere (centrally or via mobile app). Upon check-out, the password is rotated for you.
Secure Remote Access
Leverage the existing cloud connector infrastructure to deliver secure remote access to resources regardless of their location (on premises or in the cloud IaaS).
Apps, UNIX, Linux and Windows sessions can be presented to users in a cohesive way
Much more to come, and many synergies with Server Suite
Very exciting time to be at Centrify and especially to help out prospects and existing customers.
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.
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.
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.
Note from July 2015: With the release of Centrify Suite 2015.1 (agent 5.2.3) adjoin has been modified to add the --computerrole parameter; this in effect eliminates the need for the steps below. I will leave the article intact for historical reasons, but if you're at 5.2.3 or above you don't need to do this anymore.
This post extends the use case to add the system to a computer role after the system ins joined. As you know Centrify computer roles are a powerful way to group systems by adding them to AD security groups. This increased flexibility allow for groupings of servers within zones. When combining the knowledge of the original post and this one, you can accomplish the following:
Launch a UNIX/Linux template used in a private or public cloud scenario.
During post-installation, the system joins a zone and a computer role automatically without human intervention.
Variables:
Domain to be joined
Zone to be joined
Computer role(s) to be joined
These parameters need to be passed to your automation or orchestration solution (or be part of your template for that type of system).
Implementation
Modifying the automation account permissions to add accounts to groups
So far, the automation account (ad-joiner in our example) only has the rights to add/move/change AD computer objects in an OU and to add/move/change computers in to the Centrify zone. We will grant this account the ability to add/move/change members of groups that are in a specific OU. In keeping with the least privilege model, we need to provide the account only the privileges it needs.
Like the previous example, we'll use the AD delegation wizard in the OU that contains the AD groups that are used to contain Centrify Computer Roles. There is already a canned delegation task that suffices "Modify the membership of a group"
Note: this is a one-time process.
Adding the system to the appropriate Computer Role
There are several ways to accomplish this because ultimately the action is to add a computer object to an active Directory group.
In UNIX/Linux, using adedit, it's as simple as illustrated in this example ( 5 lines)
$ adedit
# this opens the adedit TCL utility
> bind corp.centrifying.net
# binds to the corp.centrifying.net domain or returned by adinfo -d
# adds the awscentos01 computer object (append a $ to the output of adinfo -n) and joins it to the centrify-global-unix-cr-webservers AD group (you can pass as parameter or have as part of the template)
$ adflush
# flushes the cache to the access controls are updated. In older versions of the Centrify agent, this required a service restart so the machine re-authenticated against AD and refreshed the ACLs.
Notes:
This is the process that will repeat each time an instance is built.
This is also the area that I've found that many prospects and customers encounter challenges. Success in these cases has to do with simplicity and standardization. For example, if I have a naming convention and I'm adhering to the best practices (e.g. a separate OU to store AD computer groups) then the logic of my script is very simple. If I have NOT standardized and I have a centralized AD mess (or even worse, classic zones), then this will increase complexity significantly. For example. If I'm using a script that expects 3 variables: - AD domain, - Hostname: keep in mind, you can join a system to AD with one name, but the local honstname is different - Type of Server: (e.g. database server, web server, PCI server, etc) In a standardized environment you can afford to get those variables from the output of some of the centrify or environment variables. E.g.
