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.
Couchbase is including LDAP support in the upcoming March
release and we wanted to preview how to leverage your existing Centrify assets
to help with this scenario. The instructions below are for testing purposes only. This capability will provide the ability to use LDAP users (From AD or other LDAP directories) to be provisioned as Full or Read-only administrators of the web console.
About this configuration
In this configuration Couchbase is using saslauthd to
connect to LDAP. By leveraging the Centrify LDAP Proxy, this
configuration can benefit from the robust capabilities of the Centrify agent
(AD sites and services awareness, performance, caching, etc).
With a
privileged user, install the Centrify agent. rpm –Uvh centrifydc-<version>
(e.g. centrifydc-5.2.2-rhel3-x86_64.rpm)
Check
if all is OK to join Active Directory adcheck <your domain> (e.g. adcheck corp.contoso.com) Make sure you fix any issues (e.g. DNS, DC connectivity, etc)
Join
active directory (you’ll need an account that can join computers in AD) adjoin –z Model –c “ou=Servers,ou=UNIX” –u jerry.seinfeld -V corp.contoso.comJoins the corp.contoso.com in Centrify zone mode (Model) mode, and places the computer on the /UNIX/Servers OU and uses jerrry.seinfeld's account for the corp.contoso.com domain.
Step 2 – Install, configure, start and test the Centrify LDAP
Proxy
Install
the Centrify LDAP Proxyrpm
– Uvh centrify-ldapproxy-<version> (e.g.
centrifydc-ldapproxy-5.2.2-rhel3-x86_64.rpm)
Elevate and start
the proxy manually or configure a startup script. For example dzdo
/usr/share/centrifydc/libexec/slapd -f
/etc/centrifydc/openldap/ldapproxy.slapd.conf -h ldap://cen1.corp.contoso.com This makes the LDAP proxy to
start reading the indicated startup file and listens to the hostname
cen1.corp.contoso.com
To test
that the LDAP proxy is responding to queries, use ldapsearch:$ /usr/share/centrifydc/bin/ldapsearch
-h cen1.corp.contoso.com -x -b "ou=staff,dc=corp,dc=contoso,dc=com"
"(cn=George Constanza)"
Your search should yield results.
Step 3 – Install and Configure and Test saslauthd for LDAP
a.Edit the /etc/sysconfig/saslauthd and make sure the MECH
parameter is set to LDAPMECH
= ldap
b.Configure the LDAP parameters for SASL the config file should be
on /etc/saslauthd.conf. You need to add the ldap_server parameter (the system
running the Centrify LDAP proxy) as well as your search base and the attribute
that corresponds to the user name. With Centrify you can use the AD name
(samAccountName) or the uid contained in the PosixAccount class. In my test scenario: ldap_servers: ldap://cen1.corp.contoso.comldap_search_base:
ou=Staff,dc=corp,dc=contoso,dc=com=ldap_filter:
(samAccountName=%u) Note that in a production environment you’ll use multiple
proxies for HA and secure LDAP (ldaps://) and most likely your Couchbase configuration will be clustered. Use the same availability controls for the Authentication that you are using for the cluster.
c.Start the saslauthd service (or set it to start automatically
with chkconfig)$ dzdo service saslauthd start
Test
saslauthd for LDAPUse the testsaslauth script to test LDAP authentication:/usr/sbin/testsaslauthd
-u george.constanza -p <cleartextpw> -f /var/run/saslauthd/mux
If everything is well
set up, the output should be: 0: OK "Success."
Steps 1 to 3 - Potential misconfigurations:
Firewall ports are not open for LDAP
The Proxy is not started or hasn't started with the appropriate
protocol or hostname.
The configuration of saslauthd is incorrect (look at
/etc/sysconfig/saslauthd OR /etc/saslauthd.conf)
Your LDAP filters are not correct.
Step 4 – Install Couchbase and Perform Initial Setup
Add the following lines to the /etc/rc.localfor
i in /sys/kernel/mm/*transparent_hugepage/enabled; doecho never > $i; donefor i in /sys/kernel/mm/*transparent_hugepage/defrag; doecho never > $i; done
Provided
that your firewall ports are open, you can go to a browser and navigate to the
Couchbase admin page: http://your-hostname:8091
Follow the steps to complete
the initial configuration (hostname, cluster, sample apps, Administrative user,
etc)
Note: In my environment I
performed a reboot. Keep in mind that if you ran the Centrify LDAP proxy
manually, you need to launch it again and restart saslauthd before the next
step.
Step 4 – Set up Couchbase for LDAP and test settings
Log in
to the couchbase administrative interface with your administrator account.
Navigate
to Settings > LDAP Auth Setup
Under
Setup, check the Enable Checkbox and press Save.
Add a
Full or Read-Only administrator (I used the AD username, since my LDAP filter uses samAccountName). E.g. George.Constanza
To test
the user, use the Validate box.
Sign
out of the Console. Attempt login with the newly assigned
Admin. If your admin is Full, they’ll get access to all the
settings, if they are read-only, they’ll get the settings grayed out.
Summary
Setup was fairly simple using the Centrify LDAP proxy. The benefits are tangible because the underlying adclient agent serves as a way not to have to maintain multiple LDAP entries and for additional performance gains. Keep in mind, this was a "quick-and-dirty" setup, in reality you would have to account for LDAPS and HA.
As far as Couchbase goes, I was very impressed with how simple it was to set up and things just worked. They have been adding security features incrementally, and we are hoping that we can see them leverage PAM, Kerberos, PKI and to be able to leverage NSS UNIX users/groups for at least administrative interfaces; this will enable Centrify users to expose AD capabilities and accelerate the security posture of the platform. We are keeping our eyes and ears locked on these newer technologies.
In the meantime Centrify has been gearing-up for the release of Centrify Suite 2015, part of what's coming is improvements on all popular Hadoop implementations with Cloudera, Hortonworks and MapR. As a preview, David has released a few of companion whitepapers:
Secure access to Wifi or Ethernet networks is a goal of any security conscious IT infrastructure team, however diversity of platforms makes this goal very hard to achieve, especially when organizations are looking to standardize but have diverse client platforms.
In a Windows world, capabilities such as Active Directory Certificate Services, Group Policies, the Network Policy Service and Windows clients make this goal relatively simple. The popularity of Mac Workstations has forced many organizations to face this challenge.
The good news is that Centrify has worked very hard to make sure that IT Infrastructure folks can leverage their existing Windows infrastructure to solve this challenge on the macs.
The challenge for any technical lead is that the expertise required just to meet the prerequisites is going to be scattered all over the organization; this means that it's time to flex the ability to coordinate and get people to work together. Hopefully this post provides a lot of clarity.
How easy is it to implement?
It is as easy as enabling one of the Centrify-provided GPOs for Mac OS X. Specifically the "Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > 802.1x Settings" and you can pick your flavor:
Enable Machine Ethernet Profile
Enable Machine Wi-Fi Profile
Enable User Ethernet Profile
Enable User Wi-Fi Profile
However, this entry would not be useful if I just show you that you can enable the GPO, perform a policy refresh and just like magic: network access.
What I've noticed from prospects or customers that are looking to test these capabilities is that they don't understand all the moving pieces that need to be in place in order for this to work.
In this post we'll use a checklist to make sure that you understand what needs to be in place to be successful.
Note: If you already have 802.1x EAP-TLS running with your Windows infrastructure today, you are very well-positioned for success.
Active Directory and Windows Services: There are several ways to accomplish this goal, but in this particular instance, because our goal is to consolidate processes, knowledge and infrastructure, we are leveraging Windows capabilities like Active Directory, AD Certificate Services and the Network Policy Service. AD Groups will be key to provide access controls; OUs will determine the scope of GPOs to be used.
Public Key Infrastructure: PKI is needed to provide the encryption, non-repudiation and authentication between the back-end infrastructure (Active Directory) and the client (Ethernet or Wifi). The key here is the certificate life-cycle management, this is where Windows PKI uses Group Policy. PKI Disclaimer: PKI is not joke. Any proper implementation needs to provide the assurances that PKI is aligned with your security policy. If your organization does not have a policy for PKI (general assurances, handling of private keys, policies, templates, Root and SubCAs) consult an expert.
A Policy/Configuration Management Engine: Group Policy provides the rules and the enforcement for configuration items and even provides certificate auto-enrollment - a way to manage the certificate lifecycle (issuance, renewal, revocation, etc); in addition, GPOs will be the way that Centrify will provide the Apple profile information.
Network Policy Service: The NPS service on Windows provides the services like Remote Authentication Dial-in User Service (RADIUS) and the policy rules to enable 802.1x. The NPS Service interacts with Active Directory to leverage groups and attributes.
802.1x-Capable Network Devices: Any modern switch or access point supports 802.1x EAP and RADIUS.
Centrify Agent for Mac OS X: This use case showcases the power of the Centrify agent. Not only it leverages its ability to integrate with AD, but to use advanced services and perform this cohesively within the MacOS platform. Key capabilities: Certificate Auto-Enrollment, System Profiles, GPO Engine.
The Lab
For AD and PKI: Modified Microsoft Test Lab Guide: Provides the corp.contoso.com domain with a running Microsoft CA. The RootCA (corp-DC1-CA) certificates are deployed using GPOs. Translation: A common Certificate Authorithy with the proper Certificate Revocation publication methods needs to be provisioned. I did not set APP1 as a SubCA.
For RADIUS and Policies: I'm piggybacking on my APP2 Windows 2012 server
Network Devices: I'm using Cisco small business (300 series) switch and a TPLink (TL-WA90x) Wireless Access Point.
Mac Client: Old Macbook running 10.7 and Centrify 5.2.1
