[Labs] Setting-up an AWS Test Lab for Centrify

By Centrify Guru I on ‎04-19-2017 10:02 PM - last edited 3 weeks ago

The goal of this article is to set up the building-blocks to test Centrify Server Suite and Privilege Service in an AWS environment.  This article is the foundation for several how to guides in development.

 

Audience:  Technical leads  looking to test capabilities in a lab environment.

Knowledge level:  You must be familiar with AWS, Linux , Windows, TCP/IP, Domain Name System and with basic Centrify product capabilities.

 

Levels

  1. Standard Edition Level - allows you to complete labs related to Centrify DirectControl
  2. Privilege Service Level - allows you to complete labs related to Privilege Service

 

Basic AWS Setup

The basic steps to set up an AWS Playground lab are:

  1. Sign Up for AWS

  2. Create an IAM User (optional)

  3. Create a Key Pair

  4. Create a Virtual Private Cloud (VPC)

  5. Create a Security Group

Once you have this set-up, we can talk about some planning scenarios.

 

Planning to modify your Security Rules

  1. In this playground, here's the connectivity you'll need:
    • RDP from your client to your Windows systems
    • SSH from your client to your Linux instances
    • You need your instances to talk to each other via AD ports and others (to simplify things, you can allow any traffic between your EC2 instances).
      sec-rules.png

Create an S3 Bucket

Official instructions here: http://docs.aws.amazon.com/AmazonS3/latest/UG/CreatingaBucket.html

  1. Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/.
  2. Click Create Bucket.
  3. In the Create Bucket dialog box, in the Bucket Name box, type a name for your bucket (nmust be unique)
  4. In the Region box, click the region where you want the bucket to reside.
  5. Optional - Enable logging.
  6. Click Create.

 

Sanity Check # 1
At this point, you should have:

  • At this point you should have several credentials:
    • An amazon account (your root account) that has all the rights to your AWS account - this account is your email account.
    • If you created an IAM user, you should have that credential too.
  • An AWS key-pair that allows you to SSH into Linux instances using the ec2-user or decrypt Windows Administrator passwords.
  • You have created a virtual private cloud (VPC)
  • You have configured a security group that allows you to access the AWS EC2 instances/services  and communications between them.  You'll be using this security group for all newly-created EC2 instances.
  • You have an S3 bucket that you can use later to host files.

 

Active Directory in AWS

Active Directory in AWS (or other clouds) can be deployed in different ways.  This all boils down to the connectivity between corporate and AWS.  If there's a dedicated VPN, provided that DNS and Security rules are well-designed, you an either extend or duplicate your AD infrastructure in AWS.

For more information:  http://docs.aws.amazon.com/quickstart/latest/active-directory-ds/architecture.html

 

multi.png

This article is not concerned with that.  If you are doing a lab, most likely you'll be using the scenario where AD is run in AWS (hosted by you in EC2 instances) or hosted by AWS (SimpleAD or AWS Directory Service).

 

1. Setting-up Active Directory in AWS

Hosting your own Active Directory Domain Controller in an AWS EC2 Instance

There are many resources like the official recipe from Amazon here: http://docs.aws.amazon.com/quickstart/latest/active-directory-ds/step1.html, however for a small lab, I recommend that you have the following:

  • One VPC
  • One EC2 Instance running your domain controller and DNS (you could also leverage Route53)
  • One EC2 Instance running your member server (e.g. APP1 or MEMBER)

For setup, you can can reuse the instructions from the Microsoft Test Lab Guides to onboard a DC1 and APP1 servers.

 

2. Configuring Microsoft DNS with a  Forwarder

If you are managing your own DC running Microsoft DNS, as a measure, you may want to add the Amazon-provided DNS servers as forwarders.  This will ensure public name resolution to AD clients.

On your DC, in an administrative powershell, run this command:

Set-DnsServerForwarder -IPAddress "w.x.y.z" -PassThru

Where w.x.y.z is your Amazon-provided DNS server IP address.
forwarder.png

 

Using an Amazon-hosted option

Simple AD:  http://docs.aws.amazon.com/directoryservice/latest/admin-guide/cloud_setup_tutorial.html

Active Directory:  http://docs.aws.amazon.com/directoryservice/latest/admin-guide/create_directory.html

 

Note that whether you set up your own, or are using a hosted option, you should have the domain name,  IP address(es) for the domain controller(s) and an admin credential.  The addresses are needed for the next step, and the credential is needed to manage AD with tools like AD Users and Groups.

 

3. Modify DHCP Option Sets to align with your new DNS

 Without properly functioning DNS, there is no Active Directory functionality.  DHCP option sets in AWS make your life very easy and you don't need to add Route53 (AWS's DNS Service) complexity.

 

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.

  2. In the navigation pane, choose DHCP Options Sets.

  3. Select Create DHCP Options Sets.

  4. Add the options for your domain name and DNS Servers (your DC and the Amazon-provided DNS).  In the name tag, provide a descriptive name, domain name servers, type the IP address of the DC(s) and an Amazon-provided DNS, and the AD domain name in the domain name.
    opt-set-pic.PNG

  5. Press Yes, Create
  6. In the navigation pane, choose Your VPCs.

  7. Select the VPC(s) for your lab, and select Edit DHCP Options Set from the Actions list.

  8. In the DHCP Options Set list, select the set you created  from the list, and then choose Save
    opt-sets.PNG

 

Sanity Check # 2
At this point, you should have:

  • A running your domain controller managed by you or hosted Active Directory and you should be able to connect to it as an administrative user.
  • Your domain controller should be running Microsoft DNS hosting the AD records.  Write down the IP address and domain name.
  • DNS resolution in your subnets, when you launch an EC2 instance and you ping your DC by name, it should be resolvable as well as public FQDNs.
    scriptx.png

 

Centrify Standard Edition Lab Setup - Member Server

The member server will be running the Active Directory and Centrify tools.  In addition, we can use the server as a Centrify Connector and DirectAudit Infrastructure.  This post will focus on AD and Centrify tools:

  • DirectManage Access Manager - GUI tool manipulate Centrify data in AD
  • DirectManage PowerShell - Use PowerShell commandlets to manage Centrify data in AD
  • GPMC Extensions - configure and enforce Group Policies in UNIX, Linux and Mac systems
  • Centrify PuTTY - Leverage Kerberos with PuTTY
  • Licensing Service - A required component for Centrify Standard Edition 2017 and above
  • Report Services - Generate and customize attestation reports

Add Windows Features

  1. Launch a Windows Server (2012R2 or 2016) and log in as the local administrator.
  2. Make sure the system can ping the domain controller by name.
  3. Run PowerShell as Administrator and join the domain
    Add-Computer -DomainName domain.name -Credential administrator@domain.name
    Provide the credentials and reboot.
  4. Sign-in to your member server as your domain administrator account, re-launch PowerShell as administrator and add the Group Policy Management, DNS and Active Directory management tools.
    Add-WindowsFeature GPMC, RSAT-DNS-Server, RSAT-ADDS

 

Install Centrify Standard Edition Tools

  1.  Download Centrify Standard Edition 2017 (or Enterprise to use later)
    https://www.centrify.com/support/customer-support-portal/download-center/
  2. Unzip the file, navigate to the DirectManage folder and run Setup.  These are the components you're adding
    comp.png
  3. Follow the prompts.  You may have to follow the instructions to set up Report Services.  For more information go here:
    http://community.centrify.com/t5/TechBlog/LABS-Setup-and-test-the-Centrify-Reports-feature-of-Server...

 Initialize Centrify Standard Edition

  1. Double-click the Access Manager icon, this will start the setup wizard
  2. Welcome page - press next
  3. User Credentials - press next (unless you're not using a privileged user)
  4. Deployment Structure - Check the box > generate default deployment structure
  5. Choose container - Browse - Select your domain and press OK.
  6. License Container - should be set to  [your domain]/Centrify/Licenses and press Next
    You'll be informed that the container will be set as read only for all users.  Press Yes.
  7. Install License Keys - Type your centrify license key and press add, then press next
  8. Default Zone Container - Should be set to [your domain]/Centrify/Zones, press next
  9. Delegate Permission - Uncheck the box (we aren't placing systems in the default computers container)
  10. Notification Handler - Should be unchcecked, press next
  11. Summary - press next
  12. Competing Page -  press Finish.  Access Manager will open.  Close it.

Initializing Access Manager, has deployed the Centrify recommended OU structure.  This is where the objects will reside for Centrify-related data.
oustruc.png

For more information about this OU structure, check out @Fabrice's article here:
http://community.centrify.com/t5/TechBlog/Best-practice-Active-Directory-OU-structure/ba-p/21470

 

At this point you should have the base configuration to perform the Standard Edition labs.

 

Sanity Check # 3

At this point, you should:

  • Have a domain-joined Windows Server and you should be able to log in with domain users.
  • The system should have the GPMC and RSAT ADDS tools
  • The system should have Centrify DirectManage Access Manager, PowerShell, PuTTY and Centrify Report Services
  • In Active Directory, you have laid-out the Centrify-recommended OU structure.

 

Set-up a Cast of Characters and Implement a basic Access and Privilege Model

Users, Groups and Roles

  • ad-admin - your AD Domain Administrator
  • cps-admin (privilege service) - is your
  • Lisa  -  Linux Administrator (will be a member of AWS Windows Administrator)
  • Maggie  - Windows Administrator (will be an AWS Linux Administrators)
  • Bart  - Security Officer (will be an AWS Security Analyst)
  • Homer  - An auditor (will be a Mixed Auditor)
  • ad-joiner - Service account for automated joins
  • centrify.reports - Service account for Report Services

Groups

  • Unix-Users - Catch-all group for all UNIX users (unix-users);  maggie, bart and homer are members.

Sample User Creation Script

Write-Host "Creating Users..."  -ForegroundColor red -BackgroundColor white
$ou = New-ADOrganizationalUnit -Name AWSDemo -Path "dc=example,dc=com" -ProtectedFromAccidentalDeletion $false
$oupath = (Get-ADOrganizationalUnit -Filter 'Name -like "AWSDemo"').DistinguishedName 
$passwd = (ConvertTo-SecureString "AWSPlayGround2017!@" -AsPlainText -force)
New-ADUser -Name "Lisa" -SamAccountName lisa -AccountPassword $passwd  -Description "Linux Administrator" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Bart" -SamAccountName bart -AccountPassword $passwd  -Description "Security Officer" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Maggie" -SamAccountName maggie -AccountPassword $passwd  -Description "Windows Administrator" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADUser -Name "Homer" -SamAccountName homer -AccountPassword $passwd  -Description "Auditor (Cross-platform)" -ChangePasswordAtLogon $false -Path $oupath -Enabled $true 
New-ADGroup -Name "unix-users" -GroupCategory Security -GroupScope Global -Path $oupath
Get-ADGroup unix-users | Add-ADGroupMember -Members Lisa, Bart, Maggie, Homer
Write-Host "User creation completed."  -ForegroundColor red -BackgroundColor white

 This script creates our cast of AD users and a group inside the AWSDemo OU.  Make sure you change the text in red to fit your environment.

script0.png

Create and Configure a Centrify Zone

Our zone name will be AWS, and it will have a very simple set up.  All users will be UNIX-enabled and there will be three roles:  A UNIX Sysadmin role, a Windows Sysadmin role and a regular UNIX user role.

 

Zone Creation and User UNIX-enablement

$zone = New-CdmZone -Name AWS -Container "CN=Zones,OU=UNIX,DC=centrify,DC=vms"
Write-Host "Unix-Enabling Users..."  -ForegroundColor red -BackgroundColor white
New-CdmUserProfile -Zone $zone –User lisa@example.com -login lisa -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User bart@example.com -login bart -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User maggie@example.com -login maggie -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmUserProfile -Zone $zone –User homer@example.com -login homer -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
Write-Host "Unix-enabling complete." -ForegroundColor red -BackgroundColor white

 This script creates the AWS zone and enables our users 

script1.png 
UNIX and Windows Admin Roles + Assignments

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Run any command as root" -Pattern "*" -MatchPath "*" -Authentication user 
$cmd2 = Get-CdmPamRight -Zone $zone -Name "login-all" 
$role1 = New-CdmRole -Zone $zone -Name "UNIX Sysadmin" -UnixSysRights login, ssologin, nondzsh, visible -HasRescueRight $true -AuditLevel possible

Add-CdmCommandRight -Right $cmd1  -Role $role1 
Add-CdmPamRight  -Right $cmd2 -Role $role1 

New-CdmRoleAssignment -Zone $zone -Role $role1 -TrusteeType ADUser  -ADTrustee (Get-ADUser -Filter 'Name -like "lisa"')

$desktop1 = New-CdmDesktopRight -Zone $zone -Name "Admin Desktop" -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true
$role2 = New-CdmRole -Zone $zone -Name "Windows Admin" -WinSysRights console, remote -AuditLevel possible

Add-CdmDesktopRight -Role $role2 -Right $desktop1
New-CdmRoleAssignment -Zone $zone -Role $role2 -TrusteeType ADUser  -ADTrustee (Get-ADUser -Filter 'Name -like "maggie"')

New-CdmRoleAssignment -Zone $zone -Role (Get-CdmRole -Zone $zone -Name "UNIX Login") TrusteeType ADGroup  -ADTrustee (Get-ADGroup -Filter 'Name -like "unix-users"')

This script creates the roles and assigns them to the proper users/groups

script2.pngscript3.png

 

 

Install Centrify DirectControl and run adcheck

  1. Launch a new EC2 Linux instance (e.g. Amazon Linux)
  2. Log in as ec2-user
  3. Run sudo vi /etc/yum.repos.d/centrify.repo and populate it with:
    [centrify]
    name=centrify
    baseurl=https://username:password@repo.centrify.com/rpm-redhat/
    enabled=1
    repo_gpgcheck=1
    gpgcheck=1
    gpgkey=https://downloads.centrify.com/products/RPM-GPG-KEY-centrify
    make sure you substitute the user/password with your own (this is in the repo page of the Download Center)
  4. Install CentrifyDC
    sudo yum install CentrifyDC
    answer any prompts that come up.
  5. Run adcheck and correct any errors
    $ adcheck awsrealm.centrifying.net
    OSCHK    : Verify that this is a supported OS                          : Pass
    PATCH    : Linux patch check                                           : Pass
    PERL     : Verify perl is present and is a good version                : Pass
    SAMBA    : Inspecting Samba installation                               : Pass
    SPACECHK : Check if there is enough disk space in /var /usr /tmp       : Pass
    HOSTNAME : Verify hostname setting                                     : Warning
             : Computer name should not be localhost or
             : localhost.localdomain. You may edit /etc/hosts or your
             : DNS server to set your hostname correctly or you must
             : use the --name option when running adjoin.
    
    NSHOSTS  : Check hosts line in /etc/nsswitch.conf                      : Pass
    DNSPROBE : Probe DNS server 172.31.26.75                               : Pass
    DNSPROBE : Probe DNS server 172.31.38.176                              : Warning
             : This DNS server does not respond to requests. This is a serious problem
    
    DNSCHECK : Analyze basic health of DNS servers                         : Warning
             : One or more DNS servers are dead or marginal.
             : Check the following IP addresses in /etc/resolv.conf.
             :
             : The following table lists the state of all configured
             : DNS servers.
             :  172.31.26.75 (ip-172-31-26-75.us-west-2.compute.internal): OK
             :  172.31.38.176 (unknown): dead
             : Only one good DNS server was found
             : You might be able to continue but it is likely that you
             : will have problems.
             : Add more good DNS servers into /etc/resolv.conf.
    
    WHATSSH  : Is this an SSH that DirectControl works well with           : Pass
    SSH      : SSHD version and configuration                              : Pass
    DOMNAME  : Check that the domain name is reasonable                    : Pass
    ADDC     : Find domain controllers in DNS                              : Pass
    ADDNS    : DNS lookup of DC dc1.awsrealm.centrifying.net               : Pass
    ADPORT   : Port scan of DC dc1.awsrealm.centrifying.net 172.31.26.75   : Pass
    ADDC     : Check Domain Controllers                                    : Pass
    ADDNS    : DNS lookup of DC dc1.awsrealm.centrifying.net               : Pass
    GCPORT   : Port scan of GC dc1.awsrealm.centrifying.net 172.31.26.75   : Pass
    ADGC     : Check Global Catalog servers                                : Pass
    DCUP     : Check for operational DCs in awsrealm.centrifying.net       : Pass
    SITEUP   : Check DCs for awsrealm.centrifying.net in our site          : Pass
    DNSSYM   : Check DNS server symmetry                                   : Pass
    ADSITE   : Check that this machine's subnet is in a site known by AD   : Pass
    GSITE    : See if we think this is the correct site                    : Pass
    TIME     : Check clock synchronization                                 : Pass
    ADSYNC   : Check domains all synchronized                              : Pass
    3 warnings were encountered during check. We recommend checking these before proceeding
    

Make sure you correct any major errors outlined by adcheck.  The key here will be name resolution and connectivity with your domain controllers; if you laid-out your security rules correctly and have DNS set to resolve AD records, you should be fine. 

 

Modify default AWS EC2 SSH Server Settings

By default, OpenSSH in AWS EC2 is not configured to allow password authentication.  Although with Centrify the underlying authentication uses Kerberos to talk to DCs, ultimately the user must be allowed to type their password in an SSH session.

  1. Sign-in to your EC2 instance with the ec2-user
  2. Modify the /etc/ssh/sshd_config file and set these directives (e.g. usin vi - sudo vi /etc/ssh/sshd_config)
    PasswordAuthentication yes
    # PasswordAuthentication no 
  3. Save the file.
  4. Restart the SSH server
    sudo service sshd restart

Join your EC2 Linux instance to Active Directory Manually

$ sudo adjoin -z AWS -c "ou=servers,ou=centrify" -n demo3 -u admin awsrealm.centrifying.net
admin@AWSREALM.CENTRIFYING.NET's password:
Using domain controller: dc1.awsrealm.centrifying.net writable=true
Join to domain:awsrealm.centrifying.net, zone:AWS successful

Centrify DirectControl started.
Initializing cache
.
You have successfully joined the Active Directory domain: awsrealm.centrifying.net
in the Centrify DirectControl zone: CN=AWS,CN=Zones,OU=Centrify,DC=awsrealm,DC=centrifying,DC=net


You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operation.  Failure to do so may result in
login problems for AD users.

 

Verify your UNIX Access and Privilege model

  1. Connect to your Linux system using SSH (e.g. PuTTY or ssh), log in as one of your AD users (e.g. lisa)
    login as: lisa
    Server refused our key
    lisa@172.31.44.61's password:
    Created home directory
    
           __|  __|_  )
           _|  (     /   Amazon Linux AMI
          ___|\___|___|
    
    https://aws.amazon.com/amazon-linux-ami/2017.03-release-notes/
    2 package(s) needed for security, out of 2 available
    Run "sudo yum update" to apply all updates.
  2.  Verify lisa's role using Centrify-enhance sudo
    1. $ dzinfo --role
      User: lisa
      Forced into restricted environment: No
      Centrify MFA Service authentication: Supported
      
        Role Name        Avail Restricted Env
        ---------------  ----- --------------
        UNIX             Yes   None
        Sysadmin/AWS
      

     Now you can logout Lisa.

  3. Reconnect again, and try to log in with Homer, then verify his role
    login as: homer
    Created home directory
    $ dzinfo --roles
    User: homer
    Forced into restricted environment: No
    Centrify MFA Service authentication: Supported
    
      Role Name        Avail Restricted Env
      ---------------  ----- --------------
      UNIX Login/AWS   Yes   None
    
    Note the different role for Homer.
  4. Close the session.  You have now verified your Linux access model.

Join your EC2 Windows member to the Centrify Zone

Grant your test users remote desktop access

  1. In your member server, right-click the start menu and select Run
  2. Type compmgmt.msc and press enter
  3. Navigate to Local Users and Groups > Groups and double-click Remote Desktop Users
  4. Press Add.  Now add the test users (or a group) you want to have RDP access.  E.g. (maggie)
  5. Press OK.

Install the Centrify Agent for Windows

  1. Open Windows Explorer and navigate to the folder with the Centrify Server Suite bits.
  2. Browse to the > Agent and run Centrify Agent for Windows64.exe (press Yes to the UAC prompt)
    • Welcome Page > Press Next
    • EULA Page > check the box and press Next
    • Custom Setup Page > Select only the Access Components
      dzwin-comp.png
      (This is unless you are planning or have added DirectAudit)
    • Components Page > Next
    • Confirmation Page > Install
    • Completed Page > Make sure the "Run Agent Configuration Wizard" is checked, press Finish
  3. Now you'll configure the Agent to join your zone.  
    • Configuration Page > Press Next
    • (Optional) Associate DirectAudit Installation > Select your Installation
    • Join to a Zone > Select the zone you created earlier (AWS) and Press Next
      Note, you may be asked to add the Domain Administrators to the Login role.  You must do this, otherwise the only user that will be able to sign-in will be maggie (in this example).
    • Configuration completed, Press Finish.
  4. If asked to restart, press Yes when you are ready.

Verify your Windows Access and Privilege model

  1. Sign-in to your Windows system as a member of the Domain Admins group
  2. Right click start and run mstsc -v member -w:800 -h:600 (this launches an RDP session)
  3. Attempt to log in with maggie  (she should be able to log in) 
  4. Open the Windows systray and right-click the Centrify icon > Authorization Center and click on the Effective roles tab
    maggie.png
  5. Note Maggie's current roles in the AWS zone.  Logoff.
  6. Repeat step 2, and now try to log in with Bart.  The result should be:
    bart.png
    This is because Bart has not been assigned a role that allows for Windows access.

  7. Press OK and close.  At this point, you have tested the access model on Windows.

 

 

Sanity Check # 4 

At this point you should have

  • Centrify tools installed in your member server (e.g. DirectManage)
  • You have a domain-joined Amazon linux instance 
  • In the Centrify zone, you have a linux instance and your Windows member server
    state.png
  • You have tested your access and privilege model in both Linux and Windows platforms.

MILESTONE:  Now you have a system that you can use for sanity checks and to generate some of the tools required for the Standard Edition AWS labs.  This is the state of your lab:

 

statepoint5.png

 

Privilege Service Lab Setup - Centrify Tenant and Connector 

Obtain a Privilege Service Tenant

  1. Get Centrify Privilege Service
    https://www.centrify.com/free-trial/privilege-service-form/
    Once your tenant is approved, you'll receive an email with your URL, credential and one-time link.  When you click on it, you will be logged-in.  Make sure you change your password.
  2. Once your tenant is set up, open its URL from the browser in your EC2 Windows instance (member server)
    Note that you may have to relax the IE ESC settings on Windows or download an alternative browser like Chrome or Firefox.  E.g. https://your-tenant.my.centrify.com/manage
  3. Navigate to Settings > Network and click "Add Centrify Connector";  this will download the Connector bits.
  4. Double-click the Connector zip file, and run the included setup file, this will start the wizard
    - Welcome Page - press next
    - EULA Page - check the box and press next
    - Custom Setup - only install the Centrify Connector
    - Ready to install - press next.  When complete, press Finish.  This will launch the configuration Wizard.
  5. In the Configuration Wizard:
    - Welcome Page - press next
    - Centrify Connector Configuration - provide your admin account name and password
    - Connector Configuration - Optional: check the box in the domain (you may not be able to if you're using a managed AD.
    - Connection test - should be successful if your instance is allowed to go out to the Internet, press Next
    - Configuring connector - Next and then Finish.
  6. Once completed, the Settings > Network > Centrify Connectors should display your aws connector:
    connect.png

Configure Resource Subnet Mapping
This step is very important, especially if you're using the Privilege Service tenant in other environments like local VMs.

  1. Log in to privilege manager (https://your-tenant.my.centrify.com/resources)
  2. Go to Settings click on Resource Subnet Mapping and Press Add
  3. Type the CDIR for your AWS Subnet (repeat if you have many - e.g. 172.31.0.0/16
  4. Select "Choose" and check the box next to your AWS Windows Server running the Centrify Connector.
    ccsubnet.png
  5. Press Save.

 

Sanity Check # 5
At this point, you should:

  • Have a Privilege Service tenant and you should know its URL, an admin user and password.
  • Have a privilege service should ready to authenticate your AD users (see below) and to provide password and session services for your AWS subnet.

MILESTONE: You should be ready to perform the AWS Privilege Service Labs, and this should be the state of your lab.

 state-with-bucket.png

 

Related Articles
Creating a Kerberos Keytab for DirectControl joins/unjoins: 
http://community.centrify.com/t5/TechBlog/DevOps-Creating-a-Kerberos-Keytab-to-Automate-DirectContro...

Using AWS OpsWorks (Chef 12) to deploy Centrify DirectControl on EC2 Linux instances: http://community.centrify.com/t5/TechBlog/Labs-Using-AWS-OpsWorks-Chef-12-to-deploy-Centrify-DirectC...

Background

This is the the second lab in the series around Strong Authentication.  In the previous lab we focused on StrongAuth for Windows access and privilege elevation with YubiKey.

We will be focusing on UNIX/Linux system access leveraging strong authentication to Windows (or Mac) systems via smart card or YubiKey.  Centrify Server suite allows definitions of roles that only allow non-password authentication to be enforced.   YubiKeys are full-fledged personal identity verification (PIV) cards that work very well with AD and Certificate Services.

 

Challenges

  • Recent advanced threats leverage the collection of passwords and poor security practices to exploit systems.
  • The variability (heterogeneity) of systems (Windows, UNIX, Linux, Macs) poses a big challenge for organizations
  • The proliferation of "best of breed" solutions promotes IT fragmentation and limits organizational flexibility.
  • The "jumpbox" or proxy approach combined with additional controls like workflow can help as long as connections are centralized, however many organizations are getting audit comments due to circunvention of these mechanisms.
  • Although there are different multifactor providers in the market and most of them provide Pluggable Authentication Modules for their solutions, the implementation requires a high-degree of expertise and translating the capability to hundreds or thousands of servers with heterogeneous OSs can be quite complex.

Opportunities

Although Centrify can accommodate the "jump box and shared account" model using Centrify Privilege Service, organizations should complement their security strategy with the least access model:

  • Users shall only access the systems they need to based on business need-to-know with strong authentication
  • Users shall be limited to the minimum privileges required for their functions:  this is accomplished by providing users roles with the rights that they need.
  • Rights shall be assigned and limited to the business function with a privilege elevation mechanism (e.g. sudo) that has the flexibility to provide strong authentication.
  • In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.
  • Active Directory and Centrify provide a stack that can secure systems and eliminates complexity across the different UNIX/Linux platforms

Lab Goals

  • Limit privileged users to a subset of UNIX/Linux systems based on their needs (AD and Centrify Zones enable this)
  • Require strong authentication for local or remote (SSH) access  (this is enabled by Centrify DirectAuthorize)
  • Require strong authentication on privilege elevation if needed (OTP, SMS, E-mail, phonefactor, etc)
  • Reproduce privileged sessions (session capture, transcription, replay).

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016 (DirectControl)
  • One or two UNIX/Linux systems with Centrify DirectControl and Centrify-Enhanced OpenSSH
    Because we will be relying on SSO, Centrify OpenSSH comes compiled with Centrify methods that simplify the process in simple and complex AD environments.
  • For SSO to work, the system has to be resolvable by name (shortname or FQDN) by the Kerberized clients.
  • SSH client that supports SSO; e.g. stock PuTTY (GSSAPI) or Centrify-enhanced (Kerberos)
  • Access to Centrify Standard Edition (evaluation or licensed)
  • Yubikey PIV Manager  (download link)
  • Yubikey 4, NANO or NEO
  • You need working knowledge of Active Directory and Centrify Zones

 Tip:  To set up a base configuration, you can build on the Microsoft Test Lab Guide or use the Announcement Post.

 

Scenario Description: 

We will use the Yubikey/Smart Card with the Certificate provisioned to the user in the base lab.  With Centrify Access Manager, we will create a role that allows her to access a system (locally and via SSH) and we will prove:

  • That the user can only log in to her Windows station with her Smart Card/YubiKey
  • That the user cannot sign-in to UNIX/Linux system locally or remotely (via SSH) with a password
  • That the user is only allowed to log in remotely via SSH to UNIX/Linux systems  via SSO (Kerberos or GSSAPI)
  • That these rights can be assigned to groups of systems, or groups of users in a temporary or permanent basis
  • Minimal to zero configuration at the system level.  Once the system is joined to AD, the security measures should just work.

Note:  We will not focus on privilege elevation.  We have covered this exhaustively, including with MFA/2FA in previous labs.

 

Centrify Setup

In this instance we are setting up a Web Admin role that contains the pre-defined "login-all" PAM right.  We are not breaking down the rights to prove that we can stop the user from logging in via console or via SSH with a password. 

The privileged user assigned the role must have authenticated with her YubiKey or SmartCard to obtain a Kerberos TGT from Active Directory, subsequently, Centrify DirectAuthorize will be in charge of denying access to the user if they don't use SSO for access (via Kerberos or GSSAPI).  All we're going to need is a zone and a role. 

 

To set up using PowerShell

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

$user = Get-ADUser -Identity Maggie.Simpson  # substitute for your test user
$cont = "cn=zones,ou=unix,dc=centrify,dc=vms"  # substitute for your container DN
$zone = New-CdmZone -Name "Yubikey-Demo" -Container $cont

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Edit http config file" -Pattern "vi /etc/httpd/conf/httpd.conf" -Authentication none
$cmd2 = New-CdmCommandRight -Zone $zone -Name "Httpd service control" -Pattern "service httpd*"
$cmd3 = Get-CdmPamRight -Zone $zone -Name "login-all"

$role = New-CdmRole -Zone $zone -Name "UNIX Webadmin - StrongAuth" -UnixSysRights ssologin, nondzsh, visible

Add-CdmCommandRight -Right $cmd1 –Role $role
Add-CdmCommandRight -Right $cmd2 –Role $role
Add-CdmPamRight  -Right $cmd3 –Role $role

New-CdmUserProfile -Zone $zone –User $user –login $user.SamAccountName -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"
New-CdmRoleAssignment -Zone $zone -Role $role -TrusteeType ADUser -ADTrustee $user | Out-Null

To perform the steps for the script above manually

Create, Configure and Assign the Demo role

 In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role

  1. Name:  UNIX WebAdmin - StrongAuth
    System Rights:
    - Non-password (SSO) login is allowed  (checked)
    - Login with non-Restricted shell (checked)
  2. Create two UNIX commands.  
    Since this will be our "Web Admin" we'll allow the role to manipulate the httpd daemon and edit the config file for the Apache server.  The commands are:
    Glob expression vi /etc/httpd/conf/httpd.conf from the standard user path /usr/bin no reauthentication required.
    Glob expression service httpd* from the standard system path /usr/sbin no reauthentication required.
  3. Add the rights to the role.  Right click the "UNIX WebAdmin - StrongAuth"  role and select "Add Right"
  4. The role is ready to be assigned.  Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
  5. Press the Add AD account > type the name of your test user, select it and press OK.

    Note: This is a permanent direct assignment to a user principal at the zone level.  This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

 Install DirectControl and join the system to the Centrify Zone

  1. Use your preferred software distribution method to copy the Centrify software
    In my case I already have a local repo for RHEL and derivatives.  (Read how to set up here)
  2. Log in to your UNIX/Linux system and use your favorite package manager to install Centrify DirectControl and Centrify-enhanced OpenSSH
    $ sudo yum install CentrifyDC CentrifyDC-openssh
    [truncated]
    Installed:
      CentrifyDC.x86_64 0:5.3.0-213   CentrifyDC-openssh.x86_64 0:7.1p1-5.3.0.208
    Complete!
  3. Now Join the Centrify zone and you'll be ready for testing.  Use the adjoin command and an authorized user:
    $ sudo adjoin -z Yubikey-Demo -c "ou=servers,ou=unix" -u dwirth centrify.vms
    [sudo] password for centrifying:
    dwirth@CENTRIFY.VMS's password:
    Using domain controller: dc.centrify.vms writable=true
    Join to domain:centrify.vms, zone:Yubikey-Demo successful
    
    Centrify DirectControl started.
    [truncated]
    
  4. If your system was not resolvable by Windows DNS, you can use the addns command to register automatically with dynamic updates (if your DNS zone allows):
    $ sudo /usr/sbin/addns --update --machine
    Updating both HOST and PTR record for: centos67.centrify.vms
    Deleting old reverse lookup records for centos67.centrify.vms on 192.168.81.10.
    No old reverse records deleted because no host records found for centos67.centrify.vms on 192.168.81.10.
    
  5. Verify that your users are correctly UNIX-enabled and with the expected rights (use adquery user and dzinfo)
    $ adquery user maggie.simpson
    maggie.simpson:x:1040191002:1040191002:Maggie Simpson:/home/maggie.simpson:/bin/bash
    
    $ sudo  dzinfo maggie.simpson --roles
    User: maggie.simpson
    Forced into restricted environment: No
    Centrify Cloud Authentication: Supported
    
      Role Name        Avail Restricted Env
      ---------------  ----- --------------
      UNIX Webadmin -  Yes   None
      StrongAuth/Yubi
      key-Demo
    
        Effective rights:
            Non password login
            Allow normal shell
            Visible
    
        Centrify Cloud Authentication:
            Not Required
    
        Audit level:
            AuditIfPossible
    
        Always permit login:
            false
    
    All set on the Centrify side.

Configure your Test user for Smart Card Authentication

  1. In ADUC, find and double-click the test user.
  2. Account Tab > Account Options > Check the box for "Smart Card is required for interactive logon"
  3. Press OK. You are ready to start testing.

 

Test Plan:

  1. Try to access the system with any other AD user than test user - expected result:  Access Denied
    This is because users need to be explicitly be granted access a UNIX identity and a Centrify role in the zone for the computer.
    login as: dwirth
    -----------------------------------------------------------------
    CENTRIFY DEMO -
    -----------------------------------------------------------------
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    -----------------------------------------------------------------
    Using keyboard-interactive authentication.
    Password:
    Access denied
    Using keyboard-interactive authentication.

  2. Try to access the system with your test user (Maggie) with her password (Console or SSH) - expected result:  Access Denied
    This is because the test user was defined with "Smart card required for interactive logon"
    login as: maggie.simpson
    -----------------------------------------------------------------
    CENTRIFY DEMO -
    -----------------------------------------------------------------
    WARNING: This is a PRIVATE system exclusively for Centrify demos
    Your actions will be monitored and recorded.
    -----------------------------------------------------------------
    Using keyboard-interactive authentication.
    Demo Password:
    Using keyboard-interactive authentication.
    Account cannot be accessed at this time.
    Please contact your system administrator.
    
  3. Log in to Windows system (you are forced to smartcard login) - Launch PuTTY (configured for SSO)
    Expected result:  Access Granted

 Video

Other considerations:

  • When forcing stong authentication, you must have a plan for other shared non-human accounts.  This is where Centrify Privilege Service shines.
  • Don't underestimate the need for good process around the lifecycle of PKI and smart cards.  PKI is serious business.

Background

This is the first lab in the series around Strong Authentication (series link).  We will be focusing on Windows systems and providing strong authentication for privileged users using Yubikeys.   Yubikeys are full-fledged personal identity verification (PIV) cards that work very well with Active Directory Certificate Services and Centrify software for UNIX, Linux and Windows.

 

The challenges

  • The Windows security model lends itself for organizations to grant additional privileges to users by way of the local Administrators group.  In Active Directory environments organizations struggle with excessive memberships on privileged groups like Domain Admins.
  • In Active Directory, a common mitigation strategy is to provision each privileged user an "administrative" account (e.g. joe/joe-a).  This strategy can be supplemented by having the "-a" account password stored securely.
  • Unfortunately, advanced attacks like password mining, pass-the-hash and others have become more ubiquitous, this makes a member of a privileged group ("-a" or not) more susceptible to exposure.
  • The "dual account" model is often paired with PSM (jumpbox) to provide session brokering and recording.  Unfortunately, this model can be circumvented by bypassing the jumpbox, and since the "-a" account is very powerful, that means that the privileged user can go anywhere.

The opportunity

Although Centrify can accommodate the "dual account" model using Centrify Privilege Service, ideally organizations would implement the least privilege model:

  • Users shall only access the systems they need to based on business need-to-know with strong authentication
  • Users shall be limited to the minimum privileges required for their functions:  this is accomplished by providing users roles with the rights that they need.
  • Rights shall be assigned in the context of applications, desktops and network rights.  Strong authentication shall be required when using privilege elevation.
  • In sensitive systems, access and privilege elevation shall be supplemented with session capture and replay.

Lab Goals

  • Limit privileged users to a subset of Windows systems based on their needs (AD and Centrify Zones enable this)
  • Require strong authentication for console or remote (RDP) access  (this is supported natively by Windows)
  • Require strong authentication on Privilege Elevation (applications/desktops)  (DirectAuthorize is Smart Card ready)
  • Reproduce privileged sessions (session capture, transcription, replay).

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016
  • Access to Centrify Standard Edition (evaluation or licensed)
  • Yubikey PIV Manager  (download link)
  • Yubikey 4, NANO or NEO
  • You need working knowledge of Active Directory and Centrify Zones

 Tip:  To set up a base configuration, you can build on the Microsoft Test Lab Guide or use the Announcement Post.

 

Scenario Description: 

We'll use the smart card user certificate provisioned to your test user's Yubikey.  In Active Directory we'll require smart card authentication for the user (this also be implemented in a subset of systems using Group Policy).

We will grant the test user a Centrify DirectAuthorize role that allows her to:

  • Run Disk Management as the local administrator and will require strong authentication to be launched
  • Use an administrative desktop  (as local administrator) and requires strong authentication to be launched

 

Complete the Base Lab Setup

The base lab set up is in the announcement post:

http://community.centrify.com/t5/Community-Tech-Blog/Labs-New-Series-Strong-Authentication-using-Cen...

 

Centrify Setup for Windows Access and Privilege Elevation

To set up using PowerShell

Import-Module ActiveDirectory
Import-Module Centrify.DirectControl.PowerShell
$user = Get-ADUser -Identity Lisa.Simpson # substitute for your user
$cont = "cn=zones,ou=unix,dc=centrify,dc=vms" # substitute for your container DN
$zone = New-CdmZone -Name "Yubikey-Demo" -Container $cont

$criteria1 = New-CdmMatchCriteria -Description "Disk Management - Direct" -FileType "msc" -FileName "diskmgmt.msc" -Argument " "   -Path "C:\Windows\System32\"
$criteria2 = New-CdmMatchCriteria -Description "Disk Management - MMC" -FileType "exe" -FileName "mmc.exe" -Argument "C:\Windows\system32\diskmgmt.msc"  -Path "C:\Windows\System32\"
$cmd1 = New-CdmApplicationRight -Zone $zone -Name "Disk Management Combo" -MatchCriteria @($criteria1, $criteria2) -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true
$desktop1 = New-CdmDesktopRight -Zone $zone -Name "Admin Desktop" -RunasSelfGroups "Builtin\Administrators" -RequirePassword $true

$role = New-CdmRole -Zone $zone -Name "Demo Role" -WinSysRights remote
Add-CdmApplicationRight -Right $cmd1 -Role $role
Add-CdmDesktopRight -Right $desktop1 -Role $role

New-CdmRoleAssignment -Zone $zone -Role $role -TrusteeType ADUser -ADTrustee $user | Out-Null

To perform the steps for the script above manually

Create the Zone

  1. Open Access Manager and right-click Zones > Create New Zone
    Name:  Yubikey-Demo
    Container:  Browse to your container.
  2. Press Next and Finish

Create the Disk Management Application

  1. Launch Disk Management (e.g. Start > Run > diskmgmt.msc)
  2. Open Access Manager > Open they Yubikey-Demo zone > Authorization > Windows Right Definitions > Right Click Applications > New Windows Application
    Name: Disk Management ComboMatch Criteria:  Press Add > Import Process and Select Disk Management and Press OK

    Press Add > Import File > Browse to c:\Windows\System32 and select diskmgmt.msc, press OK.
    This will add another way to launch the application.
    RunAs:  Self with added group privileges > Press Add Builtin Groups > Select Administrators, press OK and check the box for Authentication Required and press OK.

Create the Admin Desktop Right

  1. In Access Manager > Open they Yubikey-Demo zone > Authorization > Windows Right Definitions > Right Click Desktops > New Windows Desktop
    Name: Admin Desktop
    Runas:  Press Add Builtin Groups > Select Administrators, press OK and check the box for Authentication Required and press OK.

Create, Configure and Assign the Demo role

 In Access Manager > Open they Yubikey-Demo zone > Authorization > Right Click Role Definitions > Select Add Role

  1. Name:  Demo Role
    System Rights:  "Remote Login is allowed"  <  this will allow the user only to access via RDP
  2. Press OK and right-click the newly created role and select "Add Right"
  3. The role is ready to be assigned.  Now press OK and right-click the Authorization > Role Assignments > Select Assign Role
  4. Press the Add AD account > type the name of your test user, select it and press OK.

    Note: This is a permanent direct assignment to a user principal at the zone level.  This is not the best practice, typically you grant role assignments temporarily (for attestation), in a subset of systems and to AD groups for better administration.

 Install DirectAuthorize for Windows and join the system to the Centrify Zone

  1. In your domain-joined test systems, browse to the path for the Centrify Standard Edition software.
  2. Go to  Agent > and Run "Centrify Windows Agent.exe"
  3. Follow the Wizard, you will select the "Access" components.  If you have DirectAudit, also select Audit.
  4. When the installation ends, you need to configure the client to join your desired zone.
  5. The system will ask to reboot when complete.

Important Notes:

  • When a Windows system is added to the Centrify Zone, the security model changes.
  • In order to access a Centrified Windows system, users must be explicitly granted logon rights.  This means that even Domain Admins won't be able to access those sytsems.
  • The type of access is based on the Windows setup (Remote/Log on Locally) and the Centrify Role definition (Console/Remote)
  • When adding your first system to a zone, you will have an opportunity to explicitly add Domain Admins, otherwise you may completely lock the system

Configure your Test user for Smart Card Authentication

  1. In ADUC, find and double-click the test user.
  2. Account Tab > Account Options > Check the box for "Smart Card is required for interactive logon"
  3. Press OK. You are ready to start testing.

 

Test Plan:

  1. Try to access the system with any other AD user than test user - expected result:  Access Denied
    This is because users need to be explicitly be granted access using a Centrify role.

  2. Try to access the system with Lisa with her password - expected result:  Access Denied
    This is because the test user was defined with "Smart card required for interactive logon"
  3. Try to access the system via the console with Smart Card - expected result:  Access Denied
    This is because the role created in Centrify does not grant console login.
  4. Try to access the system via RDP with smart card PIN - expected result:  Access Granted
  5. Try to run application "disk management" normally - expected result:  Error: "You don't have access rights to logical Disk Manager on [Server]"

    This is because when the user launches the app, they are doing so without any privileges.
  6. Launching App or Privileged Desktop:
    Right click App > Run with Privilege >  Challenge with Password - Expected result:  Access Denied

    Right click App > Run with Privilege >  Challenge with smart card PIN- Expected result:  Access Granted

 Video Playlist

Announcing a new series!!!

 

I recently got some YubiKeys from HQ (thanks @Peter) and since they provide all-in-one smart card (PIV) and OTP (OATH) capabilities plus they work great with Centrify products. 

 

Here are the series links:

Part 1: Securing Windows Server Access and Privilege Escalation with Centrify, Active Directory and ...

Part 2: Securing local and remote access to UNIX/Linux with Centrify, Active Directory and YubiKey

Part 3: Using SmartCard (or YubiKey) to secure Apps, Shared Secrets an Sessions with CIS and CPS

 

 

About the Series

This new series showcases our  MFA Everywhere initiative and we'll be posting a series of HOWTO labs to cover several scenarios:

Strong Authentication (PKI) Smart Card / Yubikey

  • Leverage what you have:  Active Directory, Microsoft CA, Group Policies
  • Enforcing Smart Card access to UNIX/Linux/Mac systems  (Windows systems support this natively)
  • Use DirectAuthorize roles to limit access to strongly authenticated sessions

Strong Authentication for Windows Privilege Elevation

  • Applications
  • Desktops

We already covered Access and Privilege Elevation For UNIX/Linux using Centrify MFA here:  http://community.centrify.com/t5/Community-Tech-Blog/LABS-Setting-up-the-MFA-for-Servers-feature-of-...

 

Strong Authentication (Smartcard/Yubikey) & OATH OTP access

  • IdP Portal Access
  • OnPrem or SaaS Application Access
  • Privilege Portal Access
  • Privilege Password Manager  (Shared Account Password Manager)
  • Privilege Session Manager (Jump Box)

 Here's a quick overview/demo

 

Lab - Base Setup

The base setup is the pre-requisite for all the Yubikey/SmartCard related labs.

 

What you'll need

  • Active Directory with Certificate Services
  • A domain joined member server with Centrify Server Suite 2016
    • .NET 3.x features enabled
    • Feature RSAT:  Active Directory, Group Policy Management and Certificate Services tools
  • One or two UNIX/Linux systems with Centrify Standard Edition 2016  (5.3+)  (if testing UNIX/Linux)
  • Access to Centrify Standard Edition installation files (evaluation or licensed)
  • Yubikey PIV Manager  (download link)
  • Yubikey 4, NANO or NEO
  • You need working knowledge of Active Directory and Centrify Zones

 Tip:  To set up a base configuration, you can build on the Microsoft Test Lab Guide.

 

Create Test Users and AD Group

On the member server

  1. Open Active Directory Users and Computers and navigate to your desired OU
  2. Right click and select New > User  and follow the wizard until the user is created.
  3. Right click the newly-created user and select properties.  In the general tab, update the Email to match the user principal name.
    e.g. user@corp.contoso.com and press OK.
  4. Right click the OU and select New > Group and make it a Global/Security group.  Call it "Smart Card Users"
  5. Right click the Group, select properties, go to the Members tab, press Add and add the user created in step 2.
  6. On the member server, grant the group or user the ability to log on remotely. 
    Computer > Properties > Remote Settings > Remote Desktop > Select Users  > Add > [select user or group] press OK twice.

Certificate Services

Modify the Smart Card User template

  1. Open the Certification Authority console  (Start > Search > Certification Authority)
    If you get an error, retarget the console to the appropriate server (e.g. DC1)
  2. On the left pane, right click "Certificate Templates" and select Manage.  This will open the Certificate Templates console.
  3. In the template list, right-click the SmartCard User template and select "Duplicate Template"
  4. In the General tab, give the template a descriptive name.  I used "Smart card User V2"  (this is the display name, the actual template name is SmartcardUserV2)
  5. Click on the Security tab, press Add, select the newly-created Smart Card Users group, check the Enroll and Autoenroll boxes, then press OK and close the Certificate Templates console.

Publish the Newly-Created Template

  1. In the Certification Authorities console, on the left pane, right click "Certificate Templates" and select New > Certificate Template to Issue
  2. Select the newly-created version of the Smart Card User template  (e.g. Smart Card User v2) and press OK.

Provision the Smart Card User Certificate into your Yubikey

  1. Log on to your member system with the test user.
  2. Open the Yubikey PIV manager tool with the Test User  (shift+right click > run as different user)
  3. If you're using a VM, connect the Yubikey to your virtual machine.
    Note:  If you're using VMWare, you need to add the parameter below for the Yubikey to be available to your VM.
    usb.generic.allowHID = "TRUE"
    This step is performed by editing the .vmx file and editing it with your current text editor while the VM is off.
  4. Initialize the Yubikey if brand new.  Do not forget the PIN.
  5. In Yubikey PIV manager, press Certificates > Generate New Key and make sure you type the Certificate Template name (not the display name) and press OK.
  6. Type the PIN when challenged, and select your existing CA.  In my case I use the non HTTP link and press OK

  7. To test the smart card authentication, either lock your screen or logoff.  If you can unlock or login successfully, you should be ready for the next steps.

 

Lab Verification Video

Background

This is the fifth and final article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to integrate your Linux and Windows systems to Centrify zones in AWS Active Directory for the purposes of authentication and privilege management.

 

In this article we'll discuss how to use Centrify Privilege Service to provide shared account password management, privilege session management plus recording and strong access controls.  Here are the detailed goals:

  • To provide a redundant secure point of access for AWS-hosted systems
  • To provide password lifecycle services:  request-approve-check-out-check-in-rotate-auto/rotate
  • To provide temporary access (sessions and password checkouts)
  • To provide application to application password management capabilities
  • To provide advanced jumpbox access to SSH and RDP systems in AWS
  • To be able to proctor SSH and RDP sessions in real time
  • To be able to review session transcription and provide session replay (DVR)
  • To provide advanced access controls like strong authentication, time-fencing, geo-fencing and more
  • To continue to leverage Active Directory or use other identity schemes(LDAP, Google Directory, Social Identity, Centrify Cloud Directory or even a SAML IdP as the identity source)
  • Minimize exposure by eliminating the need for elastic IPs (publicly facing)

Centrify Privilege Service Architecture

I've written about CPS in the community before, for some features and demos review this article: 
http://community.centrify.com/t5/Centrify-Server-Suite/What-s-Centrify-Privilege-Service-CPS/td-p/21...

In summary, it is a SaaS-based Password Manager and Jump Box (in Gartner speak, provides SAPM, PSM and AAPM), however it uses the assets of identity service:  Federation, Workflow, AD-Bridge, Multifactor Authentication and more.  CPS has a connector-based architecture like this:

 

This means that there are several ways to use Privilege Service in IaaS scenarios.  However, I will focus on this type of design:

The benefit oft his design is that it allows flexibility. Here are some highlights:

  • The single source of identity continues to be the on-premises Active Directory.  AD Principals (like groups) can be used to control entitlements like who can access the management portal, check out passwords, modify resources, etc.
  • Allows for connected or disconnected AWS connectivity.  Cloud Connectors in AWS act as jumpboxes, regardless of the EC2 scheme (domain-joined or not) the connectivity is centralized.
  • Advanced Controls like
    • Step-up authentication:  Centrify MFA, OATH OTP, Phone factor, SMS, Email, PKI/Smartcard
    • Allow access only from corporate network: Users must be on-premises to access AWS assets
    • Geo-fencing:  access can be limited to only corporate locations.
    • Workflow:  Resource and password check-outs can use an access request system (Centrify or ServiceNOW)
    • Temporary access control.
  • Time-to-Market:  Password and session access can be deployed in minutes by launching an instance and deploying a cloud connector.  The same goes for internal datacenters.

We'll discuss some planning and provide some implementation/verification videos:

 

Planning

Stakeholders:   Infrastructure Lead, Directory Services Lead, Security lead, AWS SME, UNIX/Linux or Windows image lead, Database (SQL Server) SME etc.

 

Discussion topics:

  • What are the systems that need to be accessed?
    The answer to this question has implications for AWS security groups.  For example, the security group where Cloud Connectors will be residing must be able to establish connections over port 22 (SSH) and 3389 (RDP).
  • What are the user populations that need access to AWS systems?
    This determines the identity stores.  User populations can be full-time employees, contractors, vendors, etc.  Depending on the existing strategy, maybe not all users have AD accounts, this is where identity flexibility of CPS becomes handy.  Some examples:
    - Temporary contractors may be provisioned in the Centrify Cloud Directory instead of AD.
    - Perhaps ADFS has been implemented or partners need access, in that case CPS can be the service provider in a federation relationship.
  • What are the groups that should manage the system?  what are their entitlements?
    The answer to this question has directory service and functional implications.
  • What are the security controls to be put in place?  (strong auth, geo-fencing, time-based controls, workflow/approvals)
    The data classification of the systems determines the controls that should be in place.  The most basic could be that all AWS access must be generated from the corporate IP range, and access to the portal requires strong authentication.
  • Password Management lifecycle questions:
    Should approvals be required for password checkouts?  Should multiple password check-outs allowed? should passwords be rotated in a specific interval?  Should password health be monitored? should password be allowed from mobile devices? Should passwords for temporary systems be managed?  Should active directory account passwords be managed?
  • Password Storage
    Should the Centrify Secure Storage be used or is a physical or virtual HSM (Safenet SecureKey) available?
  • Will AAPM or self-registration be needed?
    The answer to this question has implications for AWS images or DevOps.  Centrify provides a Linux package (CLI toolkit); this allows for automation and automatic system registration.
  • Monitoring and Reporting
    What events should be sent to log aggregation (SIEM) platforms?  What reports should be generated and who are the consumers of these reports?
  • Attestation
    What is the process of validating that certain privileged users should have (or continue to have) access to certain resources?
  • Session Recording
    What is the data retention policy for audited sessions?  How many concurrent sessions (SSH/RDP) can be expected?
    These topics are covered in depth in Chapter 2 of the DirectAudit Administrator's guide

 

Implementation

In this example, I will use an AWS environment with Active Directory to:

  • Add a cloud connector for privilege service session management
  • Manually register some EC2 Linux and Windows systems for jumpbox accesss
  • Manually manage the password of a local Linux, Windows and Active Directory domain account.
  • Use two AD groups:  AWS-CPS-Full Access and AWS-CPS-Read-only access. Members of the 2nd group must request access for password checkouts or proxied sessions.
  • Enforce Strong Authentication.
  • Using the CLI toolkit for CLI password checkouts and manual/automtatic resource and account registration.

Moderation note:  Due to the blog's 20K character limitation, videos will be used.

 

Requirements for this Lab

  • An AWS instance with Active Directory (managed by you or hosted by Amazon)
    • Two AD groups:  AWS-CPS-FullControl & AWS-CPS-Limited
    • A Domain Administrator to authorize the cloud connector
    • Outbound Internet connectivity via single-attached Elastic IP or Internet gateway (preferred)
  • From Centrify you'll need:
    • A Centrify Privilege Service evaluation or production tenant with sysadmin-like credentials.
    • The Installation bits for Centrify DirectAudit
  • A domain-joined system for:
    a) Centrify Cloud Connector (although not recommended, this can be the DC if running a simple lab).  Cloud connectors require outbound HTTPS connectivity and to act as jumpboxes for Linux and Windows systems, they should have connectivity over TCP ports 22 and 3389  (or your custom ports if changed).
    b) DirectAudit components:  this will be the not recommended all-in one scenario (Database/Collector/Agent). 
  • Test Linux and Windows EC2 instances.
  • Optional:  An Android/iOS mobile device for Touch/OTP MFA or a Yubikey 4 or NEO for OATH OTP

 

Requirements Verification

Installing a Cloud Connector

Installing DirectAudit

Configuring Roles for CPS Access

Configuring Workflow and Approvals

Using the CLI Tookit (AAPM)

Managing Active Directory Domain Account Passwords

Session Management, Proctoring, Capture and Replay

Dashboards and Reports

Advanced Controls (Policies, Authentication Profiles, Strong Authentication)

 

Adjustments

Some of the adjustments that can be made include:

  1. Password storage:  HSM or Secure Centrify Storage
  2. Different directory sources for different user populations
  3. Smart Card Authentication
  4. Bulk import of systems
  5. CLI tookit baked into master AWS EC2 Linux instance.
  6. Use of PowerShell to automatically register Windows accounts
  7. Limited visibility of resources using the Privilege Portal login right.

 

End of Series - Conclusion

This ends the series on AWS and hopefully you've seen how the Centrify product lines:  Server Suite, Privilege Service and Identity Service work together to secure your AWS environments while balancing operational efficiency and productivity.  

 

Related Articles

Part I: Securing AWS Series Overview

Part II: Securing the Amazon AWS Root Account with Centrify Identity Service and Active Directory

Part III: Securing Amazon IAM using Centrify Identity Service and Active Directory

Part IV: Securing AWS EC2 Linux instances with Centrify Server Suite and Active Directory

Part V: Securing AWS EC2 Session Access (Jumpbox) and Passwords using Centrify Privilege Service

Background

This is the fourth article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure Amazon Identity and Access Management (IAM)  by leveraging Centrify Identity Service and your on-premises Active Directory.

In this article we'll discuss how to use Centrify Server Suite to secure your AWS Server instances by leveraging Active Directory (in AWS, on-premises or a mixed environment).  The drivers behind this are:

  • To continue to leverage Active Directory as the source of identity and privileges
  • To eliminate the reliance on SSH keys or fragmented identities
  • To provide a tried and true privileged elevation mechanism (sudo) without the inconveniences of sudoers files
  • To be able to deploy additional controls such as time-fencing and multi-factor authentication for linux
  • To be able to quickly attest who can access systems, their roles, privileges and how the privileges were granted
  • To enforce the principle of separation of duties

Active Directory and AWS

The prescriptions outlined on this article depend on how your Active Directory AWS strategy is designed.  It's even possible that there's no AD in your AWS deployment today, in that case you'd benefit from looking at the next entry in the series (that focuses on session brokering and password management).  Assuming you are using AD in AWS, here are some of the models we've seen with our customers:

 

AWS-CSS-connected model.png

The Connected Model

This model implements some degree of permanent connectivity between AWS and your on-premises infrastructure (e.g. Amazon DirectConnnect, Firewall ACLs, VPNs/Tunneling, etc); the end result in the Active Directory layer is that the following models can be implemented:

  • Account-resource model:  With accounts living on-premises and a resource domain existing in AWS (for example, with a one-way trust).
  • Extended model:  Domain controllers extend to AWS (writable or read-only).

The connected model allows for organizations to extend their AD and Centrify deployments and treat AWS as another site.  As far as Centrify goes, it's like adding another branch or site.

 

The implications of this model are permanent connectivity (and costs), plus the need to implement the network and security components prior to the AWS deployment.  Once it is in place, the administration is simplified.

 

 AWS-CSS-disconnected model.png

The Disconnected Model

This model uses the opposite approach.  It treats AWS as a disconnected entity.  Users connect to AWS through the Internet.  Directory services are separated.

 

In this scenario, independent AD forests exist on premise and in AWS.  The benefits of this model are:

  • Faster-to-production because there's no need to wait for dedicated connectivity to be set up.
  • No need to architect a security model around AD.

The obvious drawback of this model is dual administration.

 

Commonalities and Customer Inquiries

When communicating with prospects and customers on the field, these are the commonalities that I have observed:

 

  • They want to extend the Centrify Server Suite benefits to these environments
  • They have questions about their AD architecture (the two models below hint at how things would be designed and managed)
  • They have questions about the instance lifecycle:
    • How can I automate Centrify client deployment?
    • How can I automate AD joins when systems are launched?
    • How can I automate AD leaves when systems are terminated?
  • They have questions about management frameworks  (e.g. Scripts, DevOps, Amazon OpsWorks)
  • They want to automate privileged operation leveraging PowerShell
  • They want to deploy additional controls (like multifactor authentication or time-bounding)
  • They have miscellaneous questions about pre-validation and the use of DirectAudit (session capture and replay)

 

Fortunately the building-blocks for all the questions asked above are scattered in the Tech Blogs and the Centrify Knowledgebase.  Instead of using the Plan-Do-Check-Adjust model in this article (because of the combination of scenarios), I will speak about each bullet-point individually.

 

Extending Centrify Server Suite to Amazon Web Services

This one is straightforward.  CSS requires Active Directory and there are several avenues that you can use.  This all depends on the access and privilege model to be implemented. 

  • If status-quo will be maintained and the same user population retains the same rights to AWS
    • You may only need to create a child zone or a computer role in your existing zone structure.
    • Active Directory design principles are maintained: 
      - AD Sites and Services (subnets/sites) need to be created and maintained. 
      - Global Catalog location needs to be accounted for, especially if Universal or nested groups are used.
    • If RODCs are in use, adjust your instance provisioning model based on the prescriptions of the Server Suite planning guide (pg. 205).
  • If there's a different access model being implemented
    • If there will be a completely new governance model within the same forest, then a parallel zone may need to be created and delegated to the proper group.
    • If a brand-new forest with a 1-way trust is created, then a zone in the resource domain will have to be created and principals from the trusted domain have to be added to provisioning and role-granting groups.

EC2 Instance Lifecycle

The EC2 lifecycle (Launch, Stop, Terminate) has implications depending on the use cases.  In permanent environments, systems are expected to be there for a long time;  in elastic environments systems may be alive for a few weeks while an app is tested, or may be scaled-up or down depending on load or business seasonality.

Aspect that require planning include naming conventions, properly deprovisioning systems and using the analyze wizard to make sure things are tidy.  Some resources:

Deploying the Centrify Software and Joining (or leaving) AD automatically

Deployment depends on the approach.  I've seen customers that bake the software into their private AMIs (this allows for them to test and validate any corporate software) or I've seen the use of repositories and configuration management software.  The guidance here is consistent:  If you want the system to participate in your AD, you must align your hostname with your naming convention,  specify the domain name, and automate the AD join (using a krb5.conf file and a service account keytab).

Baking the software and utilities to an image makes things more predictable; however using a DevOps framework is the way of the future (given the testing orientation). 

AWS-CSS-sequence.png

 

This article shows how to create these building blocks: [HOWTO] Use Centrify Tools for Public/Private Cloud Automation Activities

The Termination sequence is relatively the same:  retrieve utility files, run kinit and instead of adjoin, run "adleave --remove" this will remove the computer from AD and Centrify, freeing-up the license.

 

DevOps Frameworks

Amazon AWS provides a great set of tools based on Chef (OpsWorks).  If you choose to use this framework, you need to have your recipes and underlying infrastructure in place (e.g. an APT/YUM repo, or Chef infrastructure) to host the dependencies.  If you are looking at the DirectControl, DirectAudit or CLI toolkit as an app, you have to sequence the triggering of the script based on your design (e.g. user-data, setup/configure/deploy/undeploy/shutdown). 

 

Here are some avenues:

User Data field:

AWS-CSS-userdata.png

OpsWorks:

AWS-CSS-userdata.png

These articles show the same sequence using Chef or Puppet:

 

AutoScaling, OpsWorks and Automation Resources

 

Automating Access and Privilege Operations with PowerShell

Amazon AWS provides a powerful toolset that has been implemented in PowerShell.  This is very aligned with Centrify's efforts (both Centrify Suite Standard and Enterprise edition provide PowerShell management tools). 

AWS-CSS-powershell.png

The subject of PowerShell is very broad, here are a few resources:

 

Securing Windows Servers in AWS

Some of you are also using Windows servers in AWS and ask us how we can help.  The windows security model has been challenged by modern threats like PtH and the dependency on high-privileged accounts (like Administrator) and groups (like Administrators and Domain Administrators).  Centrify DirectAuthorize provides a powerful mechanism to control access and privilege elevation.

 

This article goes to length to explain the process for Windows:  http://community.centrify.com/t5/Community-Tech-Blog/HOWTO-Eliminate-the-use-the-shared-Root-UNIX-Li...

 

Automation: In Suite 2016, Centrify added the ability to join zones automatically with the dzjoin command.  This can be combined with the EC2Config tasks for your Windows based AWS systems.  The User's Guide for Windows describes dzjoin in detail.

 

Advanced Controls and Reporting

Depending on the data classification or risk profile of the systems hosted in AWS, organizations may want to deploy additional controls to provide the assurance that only authorized users are accessing these systems, in addition, these systems may be subject to attestation requirements just like on-premise systems.  We will explore other controls in part 5, however Centrify Standard Edition provides multi-factor authentication for access and privilege elevation as well as several mechanisms to obtain access data.

 

Related Articles

Part I: Securing AWS Series Overview

Part II: Securing the Amazon AWS Root Account with Centrify Identity Service and Active Directory

Part III: Securing Amazon IAM using Centrify Identity Service and Active Directory

Part IV: Securing AWS EC2 Linux instances with Centrify Server Suite and Active Directory

Part V: Securing AWS EC2 Session Access (Jumpbox) and Passwords using Centrify Privilege Service

Background

Note:  this is a companion article to the blog post titled: "[HOWTO] Orchestration Basics - Using a Chef recipe to deploy Centrify and join Active Directory";  these posts are relatively identical, the only difference is the tool.

 

In the field, we often get inquiries on deployment, governance or orchestration frameworks.  Common questions range from: how do I deploy the Centrify client?  or How do I establish an approval flow for the Access Control model that you facilitate? 

Sometimes we also hear these questions:  We use Ansible | Bladelogic | Chef | Puppet in on premise or with our IaaS (cloud) deployment, how would I go about deploying your product using those tools?

These are important questions, especially in the age of private/public clouds and elastic environments.  Some of you are adopting frameworks like OpenStack, Amazon AWS or Microsoft Azure that underneath use these toolsets.

 

At Centrify we have invested heavily through the years to make sure that the products "just work".  From a deployment perspective, we our messaging is consistent:

  • We always provide the native platform package
  • Our tools are all Kerberized  (ready for automation)
  • We also provide other tools like install.sh and Deployment manager that abstract the underlying OS package manager
  • The Centrify agent automatically maintains its configuration and the Kerberos configuration based on Active Directory, and it uses AD specs for Sites and Services, DC location, offline cache.
  • The configuration parameters can be managed by any tool, plus native Active Directory Group Policy.

In other words, Centrify software is easier to use in these scenarios than what the typical IT Infrastructure lead may think.

 

Disclaimers and Acknowledgements

  • This article provides a "quick basic configuration";  in a true deployment you have to account for high-availability, replication, security, package integrity, supported platforms, supported versions, change control, etc. 
  • All names, logos and trademarks used in this articles correspond to their existing owners.
  • We are not Puppet, Chef or Bladelogic subject-matter experts, hence the use of a stand-alone script or recipe. 
  • Puppet Master server/slaves/node architecture is outside the scope of this post
  • This would not be possible without my customers/prospects asking and the tutorials available online.  Some great resources:
    - Introduction to Puppet:  https://docs.puppetlabs.com/guides/introduction.html
    - Willams' blog post "How to install Puppet in Stand-Alone mode on CentOS7"
    - Kudos to MaestroDev for the wget Puppet extension: https://forge.puppetlabs.com/maestrodev/wget

What is required?

  • An Active Directory domain
  • A Centrify zone (optional - if using Centrify in licensed mode/privilege management)
  • A Centrify zone and a Computer Role  (optional)
  • An Active Directory service account for joins and removals, plus a keytab for the account and a usable krb5.conf file.  Read this article if you want to know how to create the service account and obtain the keytab.
  • A RHEL-based system with enough storage for the Centrify RPM packages for each platform (or just for the subset you need to support).  This system has to be set up as a YUM repository, as described in the the original orchestration article.
  • A second RHEL-derivative system to install Puppet (see below), this system must have DNS settings configured correctly.

Note:  Although it's possible for you to follow this and put together a working prototype, I strongly-encourage that you really explore the concepts  of DevOps/infrastructure as code.  The whole philosophy promotes constant improvement, this means that if you expect this to be a "set it and forget it" solution, I advise that you realign your expectations.

 

Finally, By no means what's outlined here is ready for production.  Check out the reading list below. 

 

Example Diagram

Chef Blog - Diagram.png

 

Implementation Steps

 

Planning

The goal of this lab is to be able to deploy the Centrify bits in a RedHat, CentOS, Scientific or Oracle system in a consistent way.  Also, if you know what you're doing, you can extend this to other OSs, and platforms as well.

 

The 'core' process without checking for major dependencies or issues is to:

  1. Install Centrify DirectControl
  2. Authenticate against Active Directory with an account with minimal rights
  3. Join Active Directory

Building Blocks

  • YUM Repository with Centrify RPMs (detailed instructions here)
  • AD account + keytab (steps outlined in a previous post)
  • Usable krb5.conf:  You can copy this file from any Centrified system; however, depending on where you're onboarding the system, you want to edit the file only with the DCs that are reachable to the new system.

 

Make the krb5.conf and service account keytab available to your infrastructure

In the original article, we piggy-backed on the Apache webserver as the transport for our repository.  Now we're going to create another folder for utilities (utils for short) and copy the keytab and krb5.conf file.

If you prepared this for the Chef article, you can skip to Puppet installation.

 

  1. Create a folder under /var/www/html
    $ sudo mkdir /var/www/html/centrify/utils
  2. Copy the RPMs to the folder.
    $ cd /path/to/files
    $ sudo mv krb5.conf  /var/www/html/centrify/utils
    $ sudo mv ad-joiner.keytab  /var/www/html/centrify/utils
  3. Set the proper permissions in the folder
    chmod -R ugo+rX /var/www/html/centrify/utils
  4. Verify that the files are accessible via the web server (you may have to check the firewall settings)
    utils.PNG

Install Puppet and the wget Extension

  1. Add the Puppet repository (you must find the proper repository for your RHEL version, version 7 shown)
    $ sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
  2. Install the bits
    $ yum install puppet
  3. Make sure your system's DNS settings are up to date (yes, no "localsystem.localdomain")
    Can you ping your own system by name and FQDN?
    What is the output of the hostname command?
    Run this:
    facter | grep hostname
    facter | grep fqdn
    if the output isincorrect, you must edit the /etc/hosts and /etc/resolv.conf and speak to your DNS admin to set things straight
  4. Logout and log back in to verify the ruby path
    $  sudo puppet module install maestrodev-wget
    You should be ready to get going.

Create and test your stand-alone Puppet Script

To recap, the sequence to automate Installation and joins is as follows:

  1. Retrieve a usable krb5.conf file
  2. Retrieve the keytab of a valid service account with minimum rights to join systems to the target AD OU, to the target zone (if using in zone mode) and if adding to a Computer role, with rights to add to the target AD groups.
  3. Install the Centrify Package and use the kinit tool to obtain a TGT
  4. Run adjoin with the proper options.
  5. Perform cleanup

 

Here is the Non-idenpotent Puppet Script:

 

# This stand-alone recipe will install the Centrify Agent on RHEL derivatives, 
# joins Active Directory and places the system in a Computer Role
# Notes: This recipe is not idempotent (achieving this is up to you!)

include wget

# Variables for my environment (see blog post)
# domain is the most basic parameter to join Active Directory

$adname = "centrify.vms"  
# Notice that I could not use "domain" like in the Chef example.  
# That word seems to be reserved in Puppet # In Zone Mode (licensed with UNIX identity and Access Control) the zone # parameter corresponds is where the system will be placed. Not needed # if working in workstation or express mode. $zone = "Global" # OU is where your computer object will be placed in Active Directory # your ad-joiner account should be able to join systems to this container $ou = " ou=servers,ou=unix" # A Computer role is one of the ways to group systems and define access # control. A system may be a member of multiple computer roles. # E.g. a LAMP system may be accessible by Web Admins, Developers and # DBAs with different access rights and privileges. $crole = "App Servers" # nodes are the managed system in Puppet; in a true deployment you can # apply to individual systems or collections of systems. Since this is not # idempotent, you must specify the fqdn. node "your-system-fqdn" { # Centrify's utilities are Kerberized, this means that they will use the current # user's Kerberos TGT to attempt the transaction against AD. However, in a # virgin system, there are no working krb5.conf files, therefore kinit won't know # how to find a KDC to authenticate against. This is why we need a krb5.conf # file from a working system (or that points to a reachable Domain Controller), # in the previous blog entry, we piggy-backed on an Apache Web server to # serve those files (engcen6). wget::fetch {"download a working krb5.conf": source => 'http://engcen6.centrify.vms/centrify/utils/krb5.conf', destination => '/temp/krb5.conf', timeout => 0, verbose => true, nocheckcertificate => true, before => Exec["kinit"] } # The keytab corresponds to a service account that has the minimal rights, in # this case, the rights to write a computer object in the designated container # (ou), centrify zone and the AD group that contains the "App Servers"computer # role needless to say, you need to treat this file with care and if possible, # remove when complete. wget::fetch {"download the ad-joiner keytab file": source => 'http://engcen6.centrify.vms/centrify/utils/ad-joiner.keytab', destination => '/temp/ad-joiner.keytab', timeout => 0, verbose => true, nocheckcertificate => true, before => Exec["kinit"] } # We leverage Puppet to ensure the files are present. This will be used later # to guarantee proper sequencing. file {"ad-joiner.keytab": ensure => present, path => '/temp/ad-joiner.keytab' } file {"krb5.conf": ensure => present, path => '/temp/krb5.conf' } # In this command, we authenticate against AD with the keytab of our service # account. Note that we are using the usable krb5.conf file so kinit can reach # a KDC (domain controller). The end-result is that root (or sudo) user will # have a TGT and you don't need to put keys, hashes or passwords in your # script. The before/subscribe and require Puppet directives guarantee proper # sequencing. exec {"kinit": command => "/bin/env KRB5_CONFIG=/temp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit -kt /temp/ad-joiner.keytab ad-joiner", before => Exec["adjoin"], subscribe => [ File["/temp/ad-joiner.keytab"], File["/temp/krb5.conf"], ], require => Package["CentrifyDC"], } # In a pre-requiste blog entry, I outlined how to create a YUM repository for # RHEL and derivatives. This means that you need a yum or apt repo with # the Centrify packages. Puppet will simply make sure the package is present # notice the differences, I declared this after the previous directives, when # the package is a pre-requisite. package {"CentrifyDC": ensure => 'installed', } # Finally we run adjoin. At this point we are using the variables from my # environment. Although in doing so, we broke the 'idempotent principles, I'm # certain that Puppet experts can find ways to improve on this. exec { "adjoin": command => "/usr/sbin/adjoin -z $zone -c $ou -R \"$crole\" -V $adname", require => Package["CentrifyDC"] } # In the cleanup phase, we clear the TGT and delete the utility files # Although the keytab provides very specific limited AD rights, always make # a habit of cleaning-up. exec {'kdestroy': command => '/bin/env KRB5_CONFIG=/tmp/krb5.conf /usr/share/centrifydc/kerberos/bin/kdestroy', require => Exec['adjoin'], } exec {"/bin/rm -f /temp/*": require => Exec['kdestroy'], } } # End of Script

 

 

Verify the recipe

$ sudo puppet apply centrify-build.pp
Notice: Compiled catalog for engcen7.centrify.vms in environment production in 1.77 seconds
Info: Applying configuration version '1458157258'
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Package[CentrifyDC]/ensure: created
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[krb5.conf]/ensure: created
Info: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[krb5.conf]: Scheduling refresh of Exec[kinit]
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Wget::Fetch[download a working krb5.conf]/Exec[wget-download a working krb5.conf]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[ad-joiner.keytab]/ensure: created
Info: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[ad-joiner.keytab]: Scheduling refresh of Exec[kinit]
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Wget::Fetch[download the ad-joiner keytab file]/Exec[wget-download the ad-joiner keytab file]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kinit]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kinit]: Triggered 'refresh' from 2 events
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[adjoin]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kdestroy]/returns: executed successfully
Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[/bin/rm -f /temp/*]/returns: executed successfully
Notice: Finished catalog run in 38.32 seconds

 

Verification Video

 

 

Adjustments

There are absolutely many improvements that can be made.   Here are a few that come to mind (in no specific order):

 

  • Check for Perl:  CentrifyDC requires Perl 5.8 and up.
  • Chek for DC connectivity:  You can potentially check for connectivity to KDCs prior to attempting to authenticate.
  • Inspect the name of the system:  In keeping with AD Naming conventions, we should check for length and uniqueness in the forest prior to join.
  • Check if the system is already joined or in the desired zone/forest.
  • Inspect the IP/DNS configuration:  Maybe the TCP/IP and DNS config is not right.
  • Perform a Dynamic DNS update using addns:  After join, you can use addns to get the system registered with Microsoft DNS
  • Obtain Certificates with ADCert:  If the system is used for SSL communications, you can get the cert manually using adcert.
  • Manage centrifydc.conf:  There are some basic parameters that may not be manageable via GPO (e.g. DMZ) that can be managed from there.
  • New Information:  Centrify DirectControl can provide information to Puppetregarding the AD topology.
  • Add dependent packages:  LDAP Proxy or Centrify DirectAudit/DirectSecure come to mind.
  • Most importantly:  This requires a Puppet infrastructure.  Make it as idempotent as possible!

 

Background

This is the third article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure the Amazon Root account.

In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source. 

 

About Amazon AWS Identity and Access Management (IAM)

For those who aren't familiar with Amazon IAM, it provides capabilities that allow organizations to centrally manage Users, Roles, Rights and Policies efficiently for all services (compute, storage, database, application) provided by the platform. 

 

Another Identity Silo
Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception.  Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider.
Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.  The typical tasks include user creation, credential/password/key management, password resets, group/entitlement management and attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:

 

 

Once we adopt this "dual-management" we are promoting IT fragmentation, the potential consequences are complexity, limited productivity and possible security expose.  Finally, depending on the data classification or risk profile of the assets in AWS, this identity silo is subject to the corporate security policy (password policies, user attestation reporting, least access management, etc.)

In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect. 

 

This article provides a practical example that not only meets but exceeds the best practices around Amazon AIM, eliminates dual-administration and aligns administration with internal policies.

Read more...

Background

In a previous entry, I wrote an article titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" and I described the use of Centrify Identity Platform and Active Directory  to implement enhanced security controls to protect AWS deployments.

 

In this first part, we'll address how to secure the AWS Root Account.  Amazon suggests protecting the root account with Multi-Factor Authentication, however, in this article I'm describing a strategy to not only meet but exceed the requirements to protect this account.

 

 

Enhanced Objectives

  • Eliminate sharing of the Amazon AWS root account
  • Protect the password by not exposing it to any users
  • Limit access only from the corporate network
  • Limit access to the AWS account to those with business need-to-know
  • Activate MFA with Centrify Step-Up Methods (Mobile Authenticator, Phone factor, SMS, Email, Security Question)
  • Activate MFA with Amazon's OATH-based virtual MFA

 

The Value of Centrify Identity Service

Centrify Identity Service provides a powerful policy engine that allows for the implementation of these controls, not only for the Amazon AWS app, but for any web application that has a user/password authentication pattern and uses a shared account.

 

As customary, we'll use the Plan-Do-Check-Adjust methodology.

 

Planning

Role-Based Access Control

- Should the application always be accessible by a limited group of users?

   - Should application access be governed by AD group membership or Centrify Role?

Should the application be accessible to nobody and only requested on demand?

   - Who will approve the application access request?

 

Additional Controls

  • Should the application be accessible only from the corporate network?
  • Should the application be accessible at certain times?
  • Should the application require step-up authentication.
  • What should be the step-up mechanisms? (Centrify MFA, OATH OTP, Phone factor, Email, SMS, Amazon Virtual OTP,  etc)

 

An example

Access Control will be controlled by AD group membership (e.g. AWS-Root-Users); ad-hoc access will be controlled via workflow. The app will be accessible with a step-up mechanism. The approvers will be an AD group called AWS-Root-Approvers.

 

Technical Requirements

  • Active Directory with security groups created and populated
  • Centrify Identity Service Tenant
  • A Member Server running the Centrify Cloud Connector with the AD Proxy capability enabled and connected
  • An Amazon AWS Account and a user with IAM rights to create an Identity Provider and Roles

 

Implementation

Access Control Building-Blocks

Create the AD Groups

  1. In Active Directory Users and Computers, navigate to an OU for a CIS bridged-domain.
  2. Create Two AD groups:

- AWS-Root-Users: add the permanently authorized users.

- AWS-Root-App-Approvers: add a set of users that will approve access requests (ideally not the same as above to enforce separation of duties)

 

Create the AWS Root Role

Members of this role will have permanent access to the AWS Console as root. This is controlled by AD group membership.

  1. In Cloud Manager, navigate to Role and Click Add Role
  2. Description: AWS Root
  3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

 

Create the AWS Root Approvers Role

Members of this role will be able to approve who gets to access this app. This is controlled by AD group membership.

  1. In Cloud Manager, navigate to Role and Click Add Role
  2. Description: AWS Root Approvers
  3. Members: Go to the Members section and click the Add button and browse for the "AWS-Root-Users" AD group.

 

Configuration in Identity Service

Add and Configure the AWS User/Password App

  1. In Cloud Manager, navigate to Apps > Add Web App
  2. In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS User/Password" template and click Add.
  3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
  4. Description - in this step you will change the name to something descriptive to your environment.
  5. User Access - check the box next to the role you created for this purpose (in our example AWS Root)
  6. Policy - we'll revisit this in the "Adjustments" section.
  7. Account Mapping - This is where you'll securely store the AWS credentials. Select
    a) Select "Everybody shares a single username"
    b) Populate the username with the AWS root account email address and the password with the current password.
  8. Press Save, you're ready for initial testing.

 

Verification

At this point you can sign-in to Centrify Identity Service with any user in the AWS Root CIS role or an access request can be triggered via the "Add Apps" menu of the User portal.

  1. Sign-in to the Centrify Identity Service User Portal with a user from the AWS Root Role
  2. You should see the AWS As Root App.  Click on it.
  3. This should launch a new browser tab and provide you with assisted injection of the credentials using the Centrify Browser Extension.
  4. You can also test the Access Request/Workflow capability by logging in with a user that is not entitled to the application, then click "Add App" and search for the newly-created app. 

 

 

Adjustments

Limiting Access only from the Corporate Network

This is desirable if you want to make sure users can only access the AWS console from the on-premises corporate network. The planning steps imply the addition of corporate subnets or IP addresses that are translated via NAT for outbound internet connectivity to the Centrify Identity Service Settings and using the Policy tab of the AWS Root App to enforce these controls.

 

Adding Multifactor Authentication or Other Controls

MFA is built-in to Centrify Identity Service.  All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set.

 

 

Enhancements of CIS 2016.2

Amazon AWS provides an virtual MFA capability that leverages OATH.  As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.

 

 

Video Playlist

 

 

Related Articles

Part I: Securing AWS Series Overview

Part II: Securing the Amazon AWS Root Account with Centrify Identity Service and Active Directory

Part III: Securing Amazon IAM using Centrify Identity Service and Active Directory

Part IV: Securing AWS EC2 Linux instances with Centrify Server Suite and Active Directory

Part V: Securing AWS EC2 Session Access (Jumpbox) and Passwords using Centrify Privilege Service

Background

Step-up authentication can provide additional security controls to prevent unauthorized access to systems or controlled privileged elevation.  Server Suite 2016 uses the established step-up authentication methods of Centrify Identity Service (Token via Centrify Mobile Authenticator, SMS, Phone factor, E-Mail and User-defined security question); the key differentiators are the combination of Role-Based Access Control (RBAC) with step-up authentication and context awareness (time/access/privilege).

 

To complete this lab you need:

  • Familiarity with Centrify Server Suite consoles:  Access Manager
  • Familiarity with Centrify RBAC concepts:  hierarchical zones, role definitions, role assignments
  • Familiarity with Active Directory and tools:  AD users, security groups, Active Directory Users and Comuters
  • Familiarity with TCP/IP:  ports, protocols

You don't need to be familiar with Centrify Identity Service.  We will outline the set-up steps for this configuration.

 

Planning

Potential Stakeholders

  • Centrify SME:  These users are entitled to perform management of zone operations inside Active Directory.
  • Security Lead:  The security lead can answer questions like these:
    a) What servers require step-up authentication for login?
    b) What privileged actions require step-up authentication?
    c) What servers require step-up authentication based on day/time?
  • IT/AD Infrastructure lead:   This SME will help setting up a Windows Server to act as the cloud connector

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+
  • A Centrify Identity Service tenant with at least one Cloud Connector acting as an Active Directory bridge
  • For step-up methods (user-defined security question can be used if none below are available):
    a) an iOS or Android device for token testing (optional)
    b) a mobile phone to test SMS
    c) an e-mail account
    d) a phone line for phone factor

Software as a Service (Cloud) - Quick Security/Assurance FAQ

  1. What is Centrify Identity Service (CIS)?
    CIS is an Identity as a Service (IDaaS) that provides Identity, Single Sign-On, Mobility Management, Policy and Multifactor Authentication among other capabilities. The service is "connector-based";  this means that there's a server running on premises that communicates with the service.  This is a very common architecture used by solutions like ServiceNOW or Office365.
  2. Why is a SaaS solution required to provide multi-factor authentication?
    The answer boils down to time-to-production, cost and efficiencies of a software as a service solution versus the overhead of an on-premises alternative.  Centrify is re-using their existing Identity Platform and extending it to Server Suite.
  3. What are the mechanisms that Centrify implements to provide assurance for confidentiality?
    Each tenant gets their own key and PKI Certificate Authority, this provides the assurance that:
    a) only the tenant owner can decrypt traffic that has been encrypted at rest or in transit
    b) the cloud connector will repudiate connections from any other source
    c) an additional layer of encryption is provided in addition to SSL
    The cloud service and the cloud connector must be authorized by two parties:  the tenant admin and an AD admin.
  4. What are the mechanisms that Centrify implements to provide high-availability?
    a) CIS runs on top of Microsoft Azure.  Azure provides hardware, datacenter, nearby datacenter and geographical datacenter redundancies.
    b) Centrify implements mechanisms that guarantee that upgrades don't cause downtime
    c) Cloud Connectors are constantly monitored for health and failover is automatic
    d) In the context of Server MFA, the tokens and SMS contain a code that can be used asynchronously
    e) In the context of Server MFA, roles with rescue rights are available;  this allows the bypassing of MFA in case of a disaster.
  5. Are the Cloud Connector public facing or in the DMZ?
    No.  Cloud connectors aren't required to be public facing or in your DMZ; they can be inside your private network and even can work behind a proxy server.  The cloud connectors will establish an outbound HTTPS connection.  The documentation explains target sources and destinations.
  6. Is outbound Internet access required for systems that use the MFA for servers feature?
    No.  The systems only need to talk to the on-premise cloud connector in a mutually authenticated, encrypted and configurable port, in turn the cloud connector validates if the systems are authorized for MFA and acts as a broker with our Identity Platform.
  7. What other assurance mechanisms are provided by Centrify for their Cloud Solutions?
    Certifications:  SOCII, SafeHarbor, TrustE.  Centrify is working on FedRAMP certification attainment.
  8. Where can I find more information?
    For more information:  http://www.centrify.com/support/centrify-trust/trust/

Resources

How MFA for Servers Works

Components:

Active Directory

  • Centrify Zones contain:
    - Identity data in the form of UNIX RFC2307 fields for provisioned users and groups
    - Authorization (DirectAuthorize) information:  definitions of roles and attributes, rights (commands) and role assignments.
    - Information about the Centrify Identity Service tenant if there's a registered cloud connector in AD
  • Roles can have two MFA-relevant attributes:  "require multifactor authentication" and "rescue rights";  if the first one is checked, users will be prompted to provide step-up authentication to access the system;  if the second one is checked (just like with DirectAudit) all the additional security controls will be bypassed.
  • UNIX commands that have the "require multifactor authentication"  this will prompt the user to provide their password and a step-up authentication method on privilege elevation.
  • Test AD users:  The test AD users need to be UNIX-enabled and have populated attributes like email, telephone or mobile number if email, phone factor or SMS will be requested.

Centrify Server Suite

  • These are DirectControl agents 5.3+ joined to a hierarchical zone.  These systems don't need outbound connectivity to the internet.
  • The AD computer objects need to be authorized to talk to the cloud service (via role) and they should be allowed to communicate to the cloud connector using HTTPS in the web service port (8080 is the default). 

Centrify Identity Service

  • MFA Computers Role:  This role contains the systems authorized to request MFA.  This can be individual computers or AD groups that contain the AD computer objects.  They must have the Server Login and Privilege elevation right.
  • Server Authentication and Privilege Elevation Authentication Profiles:  You can define what step-up methods are available and even if there's additional mechanisms to be used.
  • Policy:  A policy that applies to the MFA Computers role needs to be implemented.  This method should allow for Integrated Windows Authentication via Kerberos for machine-to-machine authentication

Cloud Connector

  • This is a Windows system that runs the adproxy service.  The cloud connector only requires an outbound HTTPS connection to talk to the Centrify Identity Service tenant. 
  • Web Service: The cloud connector authenticates authorized agents using Integrated Windows Authentication (SPNEGO)

 The illustration below provides an oversimplified set of steps:

Note that in case of AD connectivity failure, the centrify agent will use the AD methods (sites/services, offline cache) and it also caches the authorization data.

 

A Basic Lab Design

In my test environment I have:

Description

  1. A Centrify Identity Service tenant App Edition (or 30-day trial)
  2. An Active Directory domain (centrify.vms) with a single domain controller (dc.centrify.vms)
  3. A domain-joined server called "member" that has Access Manager installed (Suite 2016 commercial or evaluation)
    Member will also be running the Centrify Cloud Connectors
  4. A Centrify zone called global with 2 computer roles:  App Servers and Web Servers
  5. Two Linux servers.  The names may be slightly different given that I have labs in different stages.
  6. A mobile device with a phone line running iOS or Android.

 

Test Cases

Test Name

What you need

Comments

Step-up on Privilege Elevation

You need a UNIX command with the “Require MFA authentication” flag set.

 

Start with this test

 

Step-up on Server Access Elevation

You need a role with the “Require MFA Authentication” flag set.

If using SSH for testing, be mindful of SSH timeouts

Context-aware privilege elevation

You’ll need two roles:
No MFA bus hours
MFA bus hours

Variation No MFA on QA/Dev and MFA on Prod.

Privilege Elevation w/o AD

This test relies in the agent’s caching capabilities.

This is a disaster recovery use case.

Privilege Elevation with out-of-band method

You need an enrolled mobile or SMS

In cases in which you can't receive other factors

Disaster Scenario

You’ll need a role with the “Rescue Rights” checkbox set.

This should be familiar to DirectAudit testers

 

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)

I will recycle the pre-requisites video for the local account management since the steps are identical:

 

Obtain and Configure a Centrify Identity Service Tenant

  1. To obtain your Tenant
    Follow the steps here:  http://www.centrify.com/free-trial/identity-service-form/
    Follow the steps until you activate your tenant and log in with the cloud admin account for the tenant.  You have to secure those credentials.
  2. Set up a Cloud Connector (Settings > Cloud Connectors)
    You can see steps here (download-install-configure-authorize).  Other than the "next-next" steps here what needs to be understood is what is the Cloud Connector doing.  The Centrify cloud connector service runs on Windows and provides AD bridging.
    a) The CC talks to the cloud service on behalf of your servers; uses PKI for trust and non-repudiation.
    b) The CC makes outbound connections  over HTTPS that are double-encrypted (SSL + tenant key)
    c) it has to be authorized to read objects from the AD domain by a privileged AD administrator
    d) The CC needs to authenticate the systems (or group of systems) that will use step-up using SPNEGO over 8080 (default)
    Note that if your're working in an isolated lab, this port has to be open between your Linux systems and the CC.
    e) The CC will provide information to the cloud service about email, phone numbers, etc so the user can get the step-up challenge
    f) For MFA testing, you can disable all other capabilities of the CC (like LDAP bridging and App gateway) to keep configuration to a minimum.
  3. Configure Authentication Profiles (Cloud Manager > Settings > Authentication Profiles)
    You need to set up authentication profiles for both Server Access and Privilege elevation.  For this go to .  Here's what I set up for Server Access:

    What to use for Step-up:  You'll need to use your security savvy here.  The goal is to provide an additional control in case of password compromise.  You would not use email in this case because in an Exchange scenario, the password is the same for the AD user so if a threat agent compromised the user's password, they likely have access to his email.  The best course of action is something the user has like a token or his phone.  That's why I only checked those options.
  4. Set the Server Suite Authentication Profiles (Cloud Manager > Settings > Server Suite Authentication)
    Set the APs for Server Access and Privilege Elevation
  5. Create a Role that Contains your Linux Systems (Cloud Manager > Roles)
    In my case, I created an "MFA Computers" cloud role and as members I added an "MFA Computers" AD group that in turn contains my Linux systems.  This simplifies administration because if I want more Linux systems enforcing MFA, all I need to do is upgrade them to 5.3 and add them to that AD group.
  6. Policy Applied to MFA Computer with IWA  (Cloud Manager > Policies)
    We need to verify that Integrated Windows Authentication is allowed for the User Policy that applies to this role.  This will allow the servers to use Kerberos to authenticate to the web service on the cloud connector.  This is under Policy (e.g. Default Policy) > User Security Policies > Login Authentication

    Ideally, to isolate MFA testing, you will create a new Policy that applies just to the MFA computers role and you stack it higher than your deny-all policy.

Configure Access Manager for Centrify Identity Service Tenant

  1. Open Access Manager and open your Zone. 
  2. Right-click the zone and select properties, click on the Cloud tab and click Browse
    There is now a selectable cloud instance.  This is because of the cloud connector registration.
  3. Select and press OK twice.  Now you can test end-to-end connectivity using the Test Cloud Connection tool

    You have to right-click the "DirectManage Access Manager" node to expose the tool.

Verify that your Centrified Linux system is Cloud Connector-aware

You need to refresh the cache and restart the agent to reflect the AD group membership that will allow the system to interact with the cloud connector.

  1. Sign in to your system (with a user that can elevate)
  2. Run adflush --force
  3. Restart the CentrifyDC service (service centrifydc restart)
  4. Run the 'adinfo --sysinfo' cloud command to verify cloud connector awareness.
    You're all set.

 

Video Playlist

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

  • Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)
  • Control local UNIX primary or secondary groups (provision, control membership, or removal from /etc/group)
  • Use a single management framework (DirectManage GUI, PowerShell, UNIX adedit)
  • Leverage Centrify Zones, Child Zones or Computer Roles stored in Active Directory
  • Perform actions upon user creation/deletion, e.g. home directories, environment variables, password management/lifecycle.

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.

Read more...

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 access) or automatically using a Security Governance tool (at that point, a feed is inserted to the tool).

Read more...

With the end of extended support for Windows Server 2003, many organizations are exercising due diligence and upgrading Windows Active Directory systems to newer OS versions. Although this requires thorough planning by your organization, many of our prospects and customers often ask about their current AD changes and wonder about how that impacts systems running Centrify Server Suite for UNIX/Linux or Identity Service Mac Edition clients.  This article is a quick primer on what changes when the Domain Functional Level changes.  We are focusing on the jump from 2003 to 2012 as an example.

Read more...

In the original article about orchestration basics, we set up a basic implementation of YellowDog Updater Modified (YUM) for RHEL and derivatives (CentOS, Scientific, Oracle Linux, etc) in different architectures

(Intel, Power, zLinux).

 

In this second article of the series we discuss how we can use a simple (non-idempotent) Chef recipe to deploy, and join a node to Active Directory with Centrify DirectControl.

Read more...

Repositories for Yellow Dog Updater Modified (YUM) or the Advanced Package Tool (APT) are now part of every IT Infrastructure department's arsenal.  They provide foundational services for deployment and automation of software.  Centrify has traditionally shipped all the native packages for each supported platform, this means any customer (Express or Commercial) should be able to download software from the Download Center and integrate it to their existing orchestration and package management solution.

 

In many cases prospects and customers ask us how can we help integrate with their existing [Bladelogic | Satellite | Chef | Puppet | System Center | Casper |  other]; the answer is very simple:  "We give you the native package";  however, this may not be enough.  In the "Orchestration basics" series we will write a set of articles that lay the foundation for these services.  

 

We will start by teaching you how to set up your very own YUM repository to support RHEL and derivatives.  This should be good for the following platforms:  CentOS, Citrix XenServer,Oracle Linux, RHEL, Fedora and Scientific Linux on i386, x86_64, PPC, S/390x and Itanium.  We'll add other strategies like APT, HTTP and NFS as well.

Read more...

IT Professionals are often required to provide evidence of alignment with security regulations.  At Centrify, since we provide Identity and Access Management solutions, this means that providing capabilities that satisfy regulations is at the heart of many of our products;  it drives design, engineering and marketing efforts.

 

All this would be nothing if we weren't in the position to coach our customers and prospects on how we can meet or exceed their needs.  This entry is based on a template email that we developed in the New York Metro region to assist when our customers ask us how to prove Server Suite's alignment with the Sarbanes-Oxley Act. 

Read more...

Amazon AWS is quickly becoming one of the most popular options for Enterprises to extend their Data Center infrastructure out in the cloud. IaaS vendors like Amazon provide an array of services that include directory services, orchestration, automation, APIs and more.  

 

It's important to understand that flexibility can slowly become chaos, especially for enterprises that have fought hard to consolidate processes around Identity and Access Management.

 

This multi-part series discusses a basic IAM playbook that can be enabled with Centrify’s Identity Platform (Identity Service, Server Suite and Privilege Service). The principles continue to be the same: Implement Strong Access Controls using what you have: Active Directory as the Identity Store and enhance the experience and security controls leveraging Centrify Technologies.

Read more...

Organizations can always count with the reliability of IBM hardware, operating systems and utilities for mission critical applications. That’s why Centrify has invested in certifying the product lines with IBM infrastructure.

 

This post discusses the DB2 SSO Module; this plugin (like the Apache HTTP and Java plugins) leverages the Active Directory integration capabilities and robustness of the Centrify agent to provide additional value and functionality to DB2 implementations.

 

The DB2 plugin provides the following benefits:

  • No need to keep users local to the UNIX/Linux system to support DB2: When used natively, DB2 users need to have user accounts in the local /etc/passwd file. The DB2 enables AD users to access DB2 so the benefits of Unified Identity, Centralized Administration, Streamlined Authentication and Policy Enforcement are organically attained.

In practical terms: no more getting dinged by auditors when the account of a long-gone user is found active in the /etc/passwd of a DB2 system.

  • Long login names: Support for logins that are longer than 8 characters
  • Single Sign-on (SSO): Centrify enables SSO to DB2 leveraging the GSSAPI
  • Active Directory Group Support: AD group memberships can be leveraged to grant entitlements inside DB2.

 

This is one of the best Database to AD integration models out there.

 

This article covers setup, configuration and testing of the DB2 moduleon Linux 64 bit in a lab environment. We will focus on the User/Password and Group Plugin first since they enable a UNIX/Linux admin to set it up without any AD requirements.  In a follow-up post we'll cover the SSO GSSAPI plugin. 

 

Like any other DBMS, a true production implementation requires planning and understanding of the current environment.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel