Are you looking for some data that just isn’t covered in the stock reports?

 

You’ve come to the right place!  In this blog, I want to show you some of the basics of writing your own custom reports.

Read more...

How to create a custom Centrify login URL

By Centrify Advisor III a month ago - last edited a month ago

custom login screen.png

Using a custom Centrify login URL offers a number of benefits, inlcuding branded login screen, Integrated Windows Authentication, and being able to log in using your short name or samAccountName. This article will walk you through configuring your custom login URL for your Centrify tenant.

 

1. Log into your Centrify Admin Portal.

2. In the left column, navigate to Settings > Customization > Tenant URLs, then click on the Add button.

AddTenantURL.png

3. Enter your preferred unique name that is not used by another Centrify customer, then press Save. For example https://yourcompany.my.centrify.com

custom name.png

 

Once this is complete, you can log into the Centrify portal with your custom login URL.

Centrify User Portal: https://yourcompany.my.centrify.com

Centrify Admin Portal: https://yourcompany.my.centrify.com/manage

 

 

This article discusses the different approaches to populate information into the Centrify Privilege Service vault.  The stage in process of implementing a PIM solution dictates many of the strategies to be used.  At the time of this writing, we are looking at version 17.8, but as you know, releases come every month, therefore, the strategies discussed in this post are subject to change as more capabilities, system types or accounts are added.

 

We will be focusing on the Linux CLI toolset and the PowerShell Samples.

 

The Lifecycle

A Shared Account strategy is part of what's needed to continuously overcome the challenges around PIM.  These bullets correspond to where many of our prospects or customers are:

  • Brand new to a shared account strategy.
  • No shared account solution, but a very mature process.
  • Migrating from an existing shared account solution.
  • Optimizing the day-today-operations of an existing shared account strategy.
  • Adjusting strategies (e.g. favored shared account, over least privilege).

 

Two Types of Activities

I think we can easily condense the strategies into two categories: population and onboarding:

  1. Population activities happen when the shared account strategy is brand new, or a migration is in place (maybe switching solutions or going through M&A activities).
  2. Onboarding activities relate to the orchestration and automation of the regular IT operations (adding systems, accounts, domains, databases, etc).
    strats.PNG

As of this writing, the tools included with privilege service are:

  • Wizard - manual way of onboarding resources and accounts (out of scope for this article).
  • Import - CSV import for systems and local accounts.
  • Discovery - AD-based for Windows or Linux computers, Scheduled Tasks, Services and their corresponding identities
    (will be briefly mentioned, but covered in depth in a different article).
  • CLI Tools for Linux - cenroll & csetaccount, included with Identity Broker.
  • PowerShell Samples for Windows(tm) - available at your request.
  • REST API - Learn all about them here (out of scope for this article).

 

The Import Tool

This tool is useful if you're populating a new vault, or if you have a CSV of  the sytsems and accounts that you want to onboard. The import tool is tied to the job system.

csv.PNG 

  • Name - name of the system in privilege service.
  • FQDN - fully qualified domain name (resolvable) or IP address for the system. If using IP, can't use for zone-role workflow.  
  • ComputerClass  - the type of system.  As of this writing:  UNIX, Windows, Generic SSH, CheckPointGAiA, IBM System i, Juniper , Cisco IOS, Cisco NX-OS, & HP NonStop.  This can potentially change every month.
  • Description - the description of the system.
  • ProxyUser -proxy account to be used.
  • ProxyUserPassword -self-descriptive.
  • ProxyUserIsManaged - determines if the proxy account's password is managed or unmanaged by privilege service.
  • User   -  local account.
  • Password - local account password.
  • Managed - If the account is managed or unmanaged by privilege service.
  • UseProxy - if a proxy account will be used to access this system.
  • UserDescription - description of the user.  
  • Domain - if the account is joined to an AD domain, this is the domain name.  .
  • DomainOperationsEnabled - this is to set if the zone-role workflow if needed.

 

Discovery

Privilege Service provides an AD-based Discovery tool.  Discovery has the flexibility that it can be used to populate for the first time or in point occasions as well as ongoing.

scheduled.png

 

From system launch to system termination - the process

 

onboard2.png 

Enrollment Codes

Enrollment codes allow for a system to automatically be added to privilege service with access control options like owner, # of systems allowed, IP restrictions and sets.
codes.PNG
Enrollment codes are a great tool to enable automation or DevOps scenarios.

 

PowerShell Samples and Onboarding

The idea behind the PowerShell Samples is to be able to align newly-built Windows systems with the registration in the Privilege Service vault to protect shared accounts or to enable the secure access capability.  Alternatively, systems can be organized in sets.  The samples work with enrollment codes or interactively with user/password combinations.  The latter part is reserved for human interaction.

 

What you need:

  1. PKI Trust pre-requisite:
    The IWA root certificate for the service or tenant should be trusted (manually or via enterprise trust); same for the certificate used for SSL for the platform (not an issue with SaaS, but yes with customer managed if not following proper PKI practices).  This MFA-centric article, discusses the topic.
  2. Centrify Samples:  Available on github or attached to this post (see below).
  3. An administrative local Windows account to perform the system tasks.

 

PowerShell Samples in Action

Long command lines are split

 

Enrollment and onboarding a local account

# This is a sample script that runs at POST; once the system is built, 
# patched and joined to Active Directory. # The assumptions are that an enrollment code has been issued and that
# the modules can be loaded (in this case from the X:\CIP drive # and that the proper sets have been put in place.
# Loading Modules Import-Module X:\CIP\cps\Centrify.Cloud.PowerShell.CIP.psm1 Import-Module X:\CIP\cps\Centrify.IdentityPlatform.Powershell.psm1 # E.g. Enroll code, FQDN, Name, and endpoint are required, sets are optional. # Enrollment Code: B8674D29-890C-4036-AEAB-682DBEF6CA78 # FQDN or IP: member.centrify.vms # Name: member-vault # Service Address: https://vault.centrify.vms # Sets: PCI and Engineering (JSON notation, attribute Name) $enrollcode = "YADAYADA-YADA-YADA-YADA-YADAYADAYADAYA" $computer = ($(Get-WmiObject Win32_Computersystem).name
| Out-String -Stream).ToLower() $computerfqdn = [System.Net.Dns]::GetHostByName(($env:computerName)).HostName
| Out-String -Stream $sets = "Engineering, PCI" $sets_json = "[ { 'Name': 'Engineering' }, { 'Name': 'PCI' }]" $vault = 'https://vault.centrify.vms' Enroll-CIPSystem -EnrollCode $enrollcode -FQDN $computerfqdn
-ResourceName $computer -Endpoint $vault -Sets $sets_json # Onboard the Local Administrator account. # This is a placeholder. Good script here:
# https://gallery.technet.microsoft.com/Reset-Local-Administrator-e3023c3a # Return the temporary random password to $localpasswd, this will be rotated
# automatically.
$localpwd = 'R@nd0mG%$56bagethatWILLC6ng3soon' $accountname = 'Administrator' Set-CIPAccount -AccountName $accountname -AccountPassword $localpwd
-isManaged $true # Set Centrify Vault Metadata in the Description of the AD Computer Object $joined = (Get-Date).DateTime | Out-String -Stream $desc = "Sets: $sets. Enrolled to CPS on $joined." Set-ADComputer $computer -Description $Desc

 

PowerShell Samples Usage

1. First, import modules
What's needed: path to the PowerShell modules

Import-Module C:\[insert-path-here]\Centrify.IdentityPlatform.Powershell.psm1
Import-Module C:\[insert-path-here]\Centrify.Cloud.PowerShell.psm1

2. Enroll a system
What's needed: An enrollment code, the name, the FQDN or IP and the endpoint 
(tenant URL). Enroll-CIPSystem -EnrollCode [code] -FQDN [fqdn/ip] -ResourceName [system-name]
-Endpoint [https://your-url-here] Example: Enroll-CIPSystem -EnrollCode "B8674D29-890C-4036-AEAB-682DBEF6CA78"
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
-Endpoint 'https://vault.centrify.vms' What happens when a system is enrolled? 1. The system is added to CPS. 2. A service account is created in CIP with the default suffix. 3. The system is added to a built-in role called "Centrify Agent Computers." 4. The service account is added with the grant, view, edit and delete"
permissions at the system level. Note that you can add a system to a set.
Another example: Adding a system to the Engineering and PCI Sets: Enroll-CIPSystem -EnrollCode "B8674D29-890C-4036-AEAB-682DBEF6CA78"
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
-Endpoint 'https://vault.centrify.vms'
-Sets "[ { 'Name': 'Engineering' }, { 'Name': 'PCI' }]" 3. Unenroll a system What's needed: an administrative account. Examples: Unenroll-CIPSystem -Delete $true
# proper way to leave CIP this will remove the service account. Unenroll-CIPSystem -cleanupOnly
#cleans locally in the system, equivalent to a forced adleave. 4. Vault an account What's needed: resource/domain/database, account name, password and if it's
managed or not; if other system, database or domain, the system must
be authorized to add accounts in the resource. Examples # Sets the local account opieadmin as managed Set-CIPAccount -AccountName 'opieadmin' -AccountPassword 'ThisStringwillChangeS00n!'
-isManaged $true # Sets the remote account testuser in the system engcen6 as unmanaged Set-CIPAccount -resourceName 'engcen6' -AccountName 'testuser'
-AccountPassword 'SecretsAreToBeProtected!' -isManaged $false What happens when a system is enrolled? 1. The account is added under the resource in question. 2. The system that performed the addition, is added with all account
permissions except portal login. 5. Check-out a password What's needed: credential type, name and checkout lifetime. If other system,
database or domain, the system must be authorized to view the top level resource
and view+checkout at the account level. Examples: Get-CIPAccount -AccountName 'opieadmin' -lifetime 2 Get-CIPAccount -domainName "example.com" -AccountName "your-user" -lifetime 2 Get-CIPAccount -databaseName "db-name" -AccountName "your-db-account" -lifetime 2 Other Commandlets: - Remove-CIPAccount - removes a system/domain/database account. - Centrify-GetAccountID - gets the unique identifier for an account.

 

Linux Client CLI Tools

The help topic contains all the commands included with the client. Let's focus on the same sequence above, but for Linux.

What you need:

  1. PKI Trust pre-requisite
    The IWA root certificate for the service or tenant should be trusted (manually or via enterprise trust); same for the certificate used for SSL for the platform (not an issue with SaaS, but yes with customer managed if not following proper PKI practices).  This MFA-centric article, discusses the topic.
  2. CentrifyCC bits
    These can be obtained from the Infrastructure > Linux Agent section of the Admin Portal, from the Centrify Repo, or distributed via RPM.
  3. Sudo or superuser-like privileges.

 

CLI in Action

Enrollment with cenroll

# E.g. Enroll code, FQDN, Name, and endpoint are required, sets are optional.
# Enrollment Code: B8674D29-890C-4036-AEAB-682DBEF6CA78
# FQDN or IP: centos7.centrify.vms
# Name: centos7-v
# Service Address:  https://vault.centrify.vms
# Sets:  PCI and Engineering 

$ sudo cenroll --tenant vault.centrify.vms 
--code B8674D29-890C-4036-AEAB-682DBEF6CA78 --verbose --features all
--agentauth identity-broker-users --name centos7
--address centos7.centrify.vms --resource-set PCI, Engineering Enrolling in Centrify identity platform https://vault.centrify.vms/
using enrollment code... Feature enabled: Application-to-Application Password Management Feature enabled: Centrify Agent Authentication Starting Centrify agent... Centrify agent started. [output truncated]

 

Adding account passwords to the vault with csetaccount

# Set the account password to something random 
# Send it as a parameter for csetaccount using the --stdin option
# Always clean-up.

# Creating random string
sudo cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1 
> /tmp/temp.file # Changing account password sudo yes `cat /tmp/temp.file` | passwd root # Vaulting the credential sudo csetaccount --verbose --managed=true --stdin root < /tmp/temp.file verbose: setting account through cclient # Housekeeping sudo rm -f /tmp/temp.file

 

The account and password are onboarded under the system in question.

acct.PNG

 

The system rotates the password immediately.

rotate.PNG

The system can read and delete the password (ready for the EoL use case).
perm.PNG

 

Deleting an account and unenrolling a system

# Deleting an account from the vault
$ sudo cdelaccount --silent root

# Unenrolling a system (e.g. prior to decommision or termination) using the 
# system account $ sudo cunenroll --delete --machine

The Linux agent allows for the onboarding of database (Oracle, SQL Server) or Active Directory domain retrieval for CLI or machine to machine scenarios (see cgetaccount).

 

AWS and GCP Automation

In AWS and GCP, the lifecycle (launch instance/terminate instance) can be automated using the methods above and Centrify has provided some assets also available via GitHub.

 

Below are the variables that require information (to vault systems automatically):

# Specify the customer tenant URL to enroll in cenroll CLI
TENANT_URL= 

# Specify the enrollment code to use in cenroll CLI
ENROLLMENT_CODE=

# Specify the roles to grant "AgentAuth" right in cenroll CLI
AGENT_AUTH_ROLES=

# Specify the features to enable in cenroll CLI
FEATURES="aapm,agentauth"

# Specify the type of network address. Possible values:
# "PublicIP" (default), "PrivateIP" or "HostName"
NETWORK_ADDR_TYPE="PublicIP"

# Specify the prefix of the login name to use for this computer in the Centrify
# identity platform. The format is <prefix>-<AWS instance ID>.
COMPUTER_NAME_PREFIX="aws"

Conclusion

Expect the methods to continue to evolve, just like the system types and capabilities are added monthly.

 

We want to hear from you

What can we improve?  Always use the comments or leverage the idea exchange and community.

In this post, I cover some of the key audit events Centrify captures, where one can find them if they want to send these logs to SIEMs and other tools.

Read more...

In this article, we outline the steps to create the pre-requisite building-blocks of a test lab for Centrify Privilege Service customer-managed on-premises deployments.


Overview

  • Setup Active Directory, DNS and Certificate Services
  • Setup a Management Server (consoles)
  • Setup Shared Storage  and Disks
        - Using FreeNAS
        - Using Microsoft File and Storage Services
        - Using NetApp Ontap
        - Formatting Disks
  • Configuring Cluster Nodes
  • Set up a Windows Cluster
  • Configure Connector Systems
  • Request an SSL Certificate (with the private key)
  • Download Centrify Privilege Service

 

Proposed Lab Diagram

lab.png

I - Setting-up Active Directory and Basic Services
(with DNS and Certificate Services) and adding domain-joined systems

This is considered baseline infrastructure (and knowledge).  We will defer this section to other resources:

II - Your Management Server

Typically you should not be running software in domain controllers or critical servers; however in Windows you need to have a management server; ideally a secure workstation.  The administrative consoles required are:

  • Active Directory Users and Computers - used to perform AD operations.
  • DNS Management - used in this lab to create/delete a CNAME record.
  • Failover Cluster Manager - used for Windows Clustering operations.
    To install the 3 consoles above with PowerShell
    Install-WindowsFeature RSAT-DNS, RSAT-ADDS-Tools, RSAT-Clustering, GPMC
  • Centrify Access Manager - used to manage Centrify zone data in Active Directory.
  • Centrify Audit Analyzer - used to review SSH or Windows recorded sessions.
  • Group Policy Management - used to set up any relevant policies.

III - Setting-up Shared Storage

  iscsi.pngYou need either a real NAS/SAN setup, or you can build it using iSCSI. 

Sample PowerShell (for the Windows setup)

# Housekeeping
Import-Module -Name ServerManager

# Installing features (e.g. File and Storage Services, iSCSI and Clustering console)
Install-WindowsFeature FS-iSCSITarget-Server, iSCSITarget-VSS-VDS
Install-WindowsFeature RSAT-Clustering

# Create iSCSI Virtual Disks (e.g. disk path c:\CPS)
Import-Module -Name iSCSITarget
New-IscsiVirtualDisk -UseFixed -Path c:\CPS\cps-data.vhdx -Size 10GB
New-IscsiVirtualDisk -UseFixed -Path c:\CPS\cps-witness.vhdx -Size 520MB 

# Create iSCSI Targets (e.g. 2-node cluster with 192.168.81.21 and 22)
New-IscsiServerTarget -TargetName cps-target -InitiatorId IPAddress:192.168.81.21, IPAddress:192.168.81.22

# Associate Disks with Target (e.g. disk path c:\CPS)
Add-IscsiVirtualDiskTargetMapping -TargetName cps-target -Path c:\CPS\cps-data.vhdx
Add-IscsiVirtualDiskTargetMapping -TargetName cps-target -Path c:\CPS\cps-witness.vhdx

 

The setup consists in 2 disks:

- A data disk that will contain the Privilege Service database; the capacity has to be set based on the nature of your lab environment.  The 100GB size has been chosen arbitrarily The data disk is formatted with NTFS and has two folders:

  • cps-db:  the folder designated for the database.
  • backups: the folder designated for backups.

- A witness disk that will support the Windows Failover Cluster in establishing quorum.

This disk only needs to be formatted using NTFS.

 

Warning:  Although you will be setting online, formatting and configuring the logical drives in one system, it's possible that the drive letters get changed after the Windows Cluster is set up.  Keep this in mind.

 

IV - Cluster Nodes

diskman.png

Note:  At the time of this writing, the cluster nodes must run Windows Server 2012 R2.

  1. Log on to the first node using a domain user with local administrative rights.
  2. Install the Windows Failover Cluster Feature (and management tools).
    Install-WindowsFeature Failover-Clustering, RSAT-Clustering
  3. Run a Windows Update
    (this is to make sure your system is up-to-date).
    Reboot if needed.
  4. Open the iSCSI initiator application (answer Yes when prompted to start the service automatically).
  5. Type the name of the system hosting your shared storage (e.g. freenas) and press connect.
  6. Open Disk Management (you should see the two disks);
  7. Right-click the first disk (on the left square), select Online (repeat for the second disk).
  8. Right-click the first disk (on the left square), select Initialize Disk;  Press OK.
  9. Right-click the first disk and select New Simple Volume.  Follow the wizard and:
    Format: NTFS (quick format).
    Size: Maximum
    Volume Label:  cps-disk
    Drive Letter: E:\
  10. Right-click the second disk and select New Simple Volume.  Follow the wizard and:
    Format: NTFS (quick format).
    Size: Maximum.
    Volume Label:  cps-witness.
    Drive Letter: F:\
  11. Open Windows Explorer and in drive E:\ create two folders:  cps-db and backups.
  12. Log on to the 2nd cluster and repeat steps 1-4; repeat until all cluster members have confirmed iSCSI service automatic startup and verified access to the shared disks.

V - Setting-up a Windows Cluster

  1. Sign-in to one of your cluster nodes, and open Windows Service Failover Cluster  (as an Administrative Account).
  2. Select Create Cluster on the right Actions pane.  This starts the Create Cluster Wizard:
    - Before you begin:  Press next.
    - Select servers:  press Browse and select the cluster nodes; after these nodes are verified, press next.
    At this point, you may have to run the validation tests on the cluster.  Make sure you address any issues in this process.
    - Access point for administering cluster:  type the planned name for the cluster (e.g. cpsha) and IP address.
    - Confirmation:  make sure the "add all eligible storage to the cluster'  check is set and press Next.
    - Press finish when complete.
  3. In your newly created cluster, navigate to Storage > Disks.  Inspect the cluster Disks.  Make sure the large capacity disk continues to be the E:\ drive.  If this is not the case, in the bottom pane, right-click and select Change Drive Letter
    drive.png

VI - Centrify Connector Systems

Connectors can run on any current Windows 64-bit system.

  1. Sign-in to Windows with an administrative account.
  2. Run Windows Update.
  3. Reboot if necessary.

VII - Requesting an SSL Certificate (with the private key)

Before you request the certificate to be used for privilege service, you must know the service address (FQDN to be used).  For example:  safe.example.com;  When requesting your SSL cert, make sure you add the Subject Alternative Names/DNS entries for the service name, and servicename+zso (if planning SmartCard or YubiKey authentication).

safecert.png
The request process varies depending  on what Certification Authority is being used.

Here are some useful links:

 

VIII - Download Centrify Privilege Service

  1. Log on to the Customer Support Site.
  2. Navigate to downloads.
  3. Add your code to Privilege Service On-Premises.
  4. Download (version 17.7 and above).

 

Videos

Storage


Consoles

SSL Certificate

Windows Cluster

 

Summary

Putting-it all together, this is what you should have so far:

  • A Windows cluster with no roles (ideally 3 nodes to maintain HA while maintaining one node).
  • The cluster has connected to shared storage:
    E:\ for CPS database.
    F:\ for the cluster witness.
  • At leatst 2 domain-joined Windows systems that will act as Centrify Connectors.
  • A utility server with the required consoles (ADUC, Failover Clustering, DNS Management, etc).
  • Centrify Privilege Service 17.7 (and above) downloaded.
  • A PFX file for the x.509 SSL certificate and the service name in the SAN (e.g. safe.example.com).
  • A network accessible location with all the files (installation bits, setup keys and SSL certificate).
    files.png
  • A PFX file for the x.509 SSL certificate and the service name in the SAN (e.g. safe.example.com).

 

Privilege Service On Premises -  High Availability - Where to next?

CoreOS Container Linux identities can be vaulted in stored in the Centrify Infrastructure Service Shared Account Password Management.

Read more...

This article belongs to a series of blog posts related to the customer-managed version of Centrify Privilege Service. In this particular entry we center the discussion around strategies for Disaster Recovery.  If this is the first article you are reading, I recommend you go to the High Availability with Windows Server Failover Clustering post.

 

A quick primer on Disaster Recovery

 Based on Wikipedia's definition, Disaster recovery (DR) involves a set of policies, tools and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster.

 

DR differs from high-availability on one fundamental aspect: in a disaster, depending on the environment, type of issue and recovery strategies, there's a high-probability of data loss. For example, if the suitable recovery is either from a backup or a low latency replicated file, the data loss is in the gap between backup and restoration (or replication and recovery). A lot of the strategies are situation-dependent; perhaps a natural disaster has left the main site unable to function, and the DR systems take over while the other site is brought back on line.

When breaking-down any security controls there are preventive, detective and corrective controls:

 

Preventive Controls - High-availability mechanisms

See these posts that discuss topics around HA, backups and replication.

Detective Controls 

Privilege Service can be monitored via application monitoring, Windows Cluster Service events and connector monitoring.

Corrective Controls 

This is the core of this blog post. We will try to describe the people-process-technology needs for effective disaster recovery of privilege service.

dr.png

 

Recoverability

Security practitioners agree that that in DR scenarios some infrastructure systems may not be recoverable at its full capacity because of the circumstance or because of the infrastructure design of the disaster recovery site. Rarely the DR site has the same specs of the real data center site (with the exception of ISPs or Public Cloud providers).

Finally, your disaster recovery strategy has to align with the business continuity plan and have clear point and time objectives.   Success in DR scenarios are dependent on having clear recovery point and time goals,  planning, policy, procedures and having well-trained people who have practiced recovery.

 

Planning for Disaster Recovery

Here are some discussion and planning topics:


- Do you understand the DR site connectivity and infrastructure?
- Is Active Directory present in the DR site?
- Is DNS present in the DR site?
These are basic questions. A baseline infrastructure is needed for the recovery to work.

 

- Are there any core infrastructure components (like core switches, routers, systems, databases, secrets) that are crucial in a DR scenario?
If you answer yes to this question, you should have a sealed envelope (or other electronic means) to get access to key credentials. This is because the vault needs storage, network, AD and DNS to work; but depending on the disaster recovery strategy, you may need credentials to get to the point of recovering the vault.

 

- Do you have a stand-by server or remote cluster pre-staged in the DR site?
This will speed-up the recovery. Once Storage, Network, Active Directory and DNS are up and running, CPS recovery can commence.

 

- Do you have the right people in place, with clear instructions on how to communicate and coordinate during the recovery? Are the designated leads familiar and capable of restoring Privilege Service?
This topic should be self-evident. DR exercises can flush out issues in these areas.

- Data layer - what's the strategy? backups vs. replicated database file?  How frequently backups are made and replicated to the DR site (or the how frequently the database file copy is replicated)
This consideration is all about speed of recovery.

 

- Is the cluster configuration file available?
This is quite important.  If you need to restore from backup or create your additional node, the configuration file has crucial information required during recovery.

 

- How the system is being used?
In environments where secure session access is more prevalent than password checkouts, there will be less data loss because the passwords are mostly unknown (except when break glass is needed).

 

In this exercise

  1. We have a stand-by Server in our DR site.
    Strategies may vary - you may need a cluster, but you can have a "single master" with your secrets to support the recovery effort This system may be part of the cluster (if it spans multiple sites), or simply a single-master server that has been configured to participate in the current installation (by using the configuration file).
  2. Choose your strategy based on your environment (or scenario)
    E.g. restore from backup or restore from file.
  3. Perform the recovery
  4. Test your results.
  5. Adjust any changes (generate report, update accounts)

 

Setting-up a Stand-by Recovery Server

  1. Install Windows Server 2012 R2 based on your corporate image.
  2. Configure the logical disks to match the original installation and create the folder structure.
  3. Set-up Centrify Privilege Service. 
  4. Configure Privilege Service with the cluster configuration file.
    clconf.png
  5. Optional:  Add to Windows Clustering.

 

Restoring from Backup

Restoring from backup is quite simple with CPS, the only consideration is data loss. This is dependent on how the system is used and the backup frequency.  Time to recovery is dependent solely dependencies (such as storage, network and systems for recovery) and on how familiar the tech leads are with the restore process.

 

What you need

  • backup files
  • configuration file (if no stand-by system is available)
  • access to DNS system
  1. Log in to your DR Windows 2012 R2 system (with administrative credentials)
  2. Make sure the system has the same logical letter layout as the cluster nodes (e.g. if the database was configured with the e:\cps-db folder, this must be consistent).
  3. Optional: If you don't have a stand-by system, read the section above.
  4. In DNS, set up a CNAME record for the CPS service address (e.g. vault.example.com) and point to your recovery server.
    cname.png
  5. Start the web and database Service (set to manual given that WSFC controls this normally).
    Start-Service W3SVC
    Start-Service cisdb-pgsql
  6. Run the restore program using the backup files.
On the scripts folder, type:
$ .\pg_restore.ps1  -SourceDir e:\backups -initdb -verbose


restore.PNG

Now it's time to verify that the system can authenticate local (Centrify Directory users), followed by adding Connectors.

 

Restoring from Replicated Database file  (or orphaned file)

The consideration continues to be data loss. However, in this case, depending on the latency and replication frequency, this may be a very close copy of what was in production before the disaster struck.  The database engine and transaction logs will take care of the integrity of the data.

 

What you need

  • replicated file (or left-behind database)
  • configuration file (if no stand-by system is available)
  • access to DNS system
  1. Log in to your DR Windows 2012 R2 system (with administrative credentials)
  2. Make sure the system has the same logical letter layout as the cluster nodes (e.g. if the database was configured with the e:\cps-db folder, this must be consistent).
  3. Copy the replicated file to the destination that is expected based on the installation (e.g. E:\cps-db).
    files.PNG
  4. Optional:See the previous sections.
  5. In DNS, set up a CNAME record for the CPS service address (e.g. vault.example.com) and point to your recovery server
  6. Start the web and database Service (set to manual given that WSFC controls this normally - you may have to adjust depending on the length of the disaster).
  7. Verify that the system is working as expected

Restoring Normal Operations

The prescription of this section is dependent on the circumstance.

  • If the main site is unrecoverable, then you must plan to complete the cluster and add connectors to service the remaining sites.
  • If the main site is recoverable, then this depends on how you used the system.  If you had checkouts of accounts, those would have been rotated after use; those passwords will need to be updated once the original CPS cluster is back online.
  • Once everything is ready to resume normal operations, delete the CNAME record created during recovery and set the services to  manual (if they were changed).

Centrify Connectors and Disaster Recovery

Centrify connectors provide many services and for CPS they are absolutely needed, this means that you should have either connectors in your DR site (even if they are underutilized) or have the ability to spin them really quickly after the CPS server infrastructure is back up again.

 

Videos (wip)

 

 

Privilege Service On Premises -  High Availability and Disaster Recovery - Where to next?

Starting with version 17.7 of Centrify Privilege Service (customer managed/on premises), the standalone option has been removed and only highly-available configurations leveraging Windows Server Failover Clustering are supported.

 

This blog covers the process of upgrading Centrify Privilege Service while maintaining high-availability.

 

The Upgrade Process

 

upg-pro.png Cluster Upgrade Requirements

  • As of this writing, CPS On-Premises runs on Windows Server 2012 R2.
  • The upgrade requires at least 2 nodes, and ideally 3 nodes (to have at least a 2-node cluster when an upgrade is in progress).
  • Access and administrative rights to the Windows Cluster.
  • Centrify Privilege Service software (the version to upgrade to).
  • Administrative rights in the cluster nodes to perform the upgrade.

 Connector Upgrade Requirements

  • Connectors can run on Windows Server 2012R2 and up.
  • Since connectors are highly-available by default, all you have to worry about is having multiple systems servicing important sites or identify any subnets, systems, databases or domains that are serviced by an individual connector. 
    For those, a maintenance window is required.
  • Another consideration for the upgrade is current sessions when SSH or RDP and other dedicated connectors like for AD or LDAP Proxying and RADIUS.

 Steps Overview

 A. Cluster Node Maintenance Mode

  1. Log in to your Windows Server Failover Cluster console system.
  2. Open Failover Cluster Manager and connect to your cluster.
  3. Review the current Role owner.
    verif.png
  4. Review any issues with the cluster.
    Check the cluster events (or your SIEM console).  It's not a good idea to ride unhealthy clusters.
  5. Set your passive node in maintenance.  Nodes > [nodename] > Pause > Drain Roles
    drain.PNG

B. Running Privilege Service Upgrade (or System Patching)

  1. Log in to your cluster node (the one that was put on maintenance).
  2. Run the Centrify Privilege Service setup program (or other maintenance like Windows or hardware patching).
    For CPS upgrade, expect to do this process at least twice.  During upgrade, the setup program will attempt to talk to the active node.
  3. For CPS upgrade: Answer the PowerShell prompt.
    prompt.png
    Note:  There are really only two options:  Y or N.  The default is N because you have to repeat the upgrade for all nodes until you reach the last one.

C. Reviewing IIS Application Pool Status  (only if using early access or prerelease)

  1. Open IIS Manager
  2. Navigate to Application pools and verify that the Centrify app pool is running.
    pool.png
  3. If it's stopped, start it.  If all of them are stopped and you get a Windows Process Activation error, you may have to reboot due to Windows Update dependency issue.

D. Getting the node system back in service

  1. Log in to your Windows Server Failover Cluster console system.
  2. Open Failover Cluster Manager and connect to your cluster
  3. Resume your recently upgraded node  (Cluster > Nodes > [node] > Resume > Do not Fail Roles Back)
    failback.PNG
  4. Transfer the CPS Role ownership to the recently-upgraded node.
    move.png
  5. Monitor the Cluster transfer, IIS Service and Database Service (for example, the database service on node1).
    Get-Service cisdb-pgsql -ComputerName node1.example.vms
    

F. Verifying functionality

  1. Log on to privilege service
  2. In the upper right corner icon (your name is displayed), select About.
    m4.png
    This should reflect the new upgrade version.
  3. If this was the first node, repeat the same process from A to F until  you are done with all nodes.

 

Upgrading the Centrify Connector Infrastructure
Connectors provide CPS with the ability to reach systems, domains, databases, public/private clouds and offer an array of services including session and audit capture.  Connectors can be upgraded manually or automatically.  The options are outlined below:

 conn-upgrd.png

 

Connector Planning Topics

  • What are the capabilities of the existing connectors, what AD or LDAP domains do they serve, are they at the same version level?
  • Are there any subnets, systems, databases or domains that are only being serviced by only one connector?
    subnetmap.PNG
    Based on the screen shot above, looks like this subnet is under-served (only one connector).  Time to plan for a maintenance window, or add another connector to provide high-availability.
  • For IaaS (like Azure, AWS or Google Cloud):  Are there any Centrify connectors that may not have persistent connectivity to the server nodes?

 

Video - Upgrading a 3-Node Cluster and 2 Connectors
(17 min)

Privilege Service On Premises -  High Availablility - Where to next?

This article belongs to a series of blogs on the Customer-managed version of Privilege Service (now part of Centrify Infrastructure Services).  The topic is high-availability and in customer managed deployments, the Windows Server Failover Service (WSFC) is the key enabler for this capability.  In this article we'll discuss and demo some of the failover tests in a lab environment to illustrate.  If you're looking to create a similar test scenario, check out the previous article in the series: Installing Centrify Privilege Service + High-Availability with Windows Failover Clustering.

 

Success Criteria

High-availability is all about business continuity in case of known risks like software or hardware issues.  The goal of any computer system is to aim for 100% uptime, but from a mathematical standpoint this is impossible, however it's quite clear that a system that holds passwords should provide not only high-availability capabilities, but also recoverability and disaster recovery.   The focus of this lab is to work on the HA scenarios. 

This all starts with an impact assessment of the information system to the organization's business continuity.  The CIA rating (confidentiality-integrity-availability) will indicate importance when the last number is significant.  For this lab, we've come up with the

 

Simple Test Form

tests.PNG

Test Environment

lab.png

 

Windows Failover Clustering - Dependencies and Policies 101

Each "Role" in a Windows Server Failover cluster has dependencies.  The CPS generic script (iis_pgsql_cluster) has the following dependencies: network, storage (designated disk), role DNS name, the IIS service and the Centrify Identity Platform Database (cisdb-pgsql).
dep-rep.png

For more information about dependencies, please review some other examples from Microsoft TechNet articles:

https://support.microsoft.com/en-us/help/835185/windows-failover-cluster-resource-dependencies-in-sq...

 

The behavior of the roles in the cluster and its dependencies is highly customizable in WSFC; however, when performing this type of testing it's important o understand if the system is responding according to policy.  For example, let's explore the failover policy for the Centrify Privilege Service role (as configured by default in a 3-node cluster).
vault-poliy.png
This means that the cluster will not restart if it fails "n-1" times.  In this case, this is a 3-node cluster.  After, 2 failures, the cluster needs to be restarted manually, and if it's within the 6 hour interval, each failure will make it stay down.

In addition, you can have a "preferred"  active node (perhaps one that has more resources).  Let's now inspect the policy for the Centrify generic script:

iis-pgsql.png

This means that within a 15 minute period, on IIS or PostgreSQL failure, the first failure will restart the corresponding service, the second failure within the period will force a node transfer from active (2nd failure) to the next best node.

The same policies exist at the disk, network and server name.

 

Finally, the reason for this explanation has to do with the evaluation of your tests.  For example, if I was testing HA failure of a service component (like the database), an excerpt of my testing looks like this:

 

Time Action Expected Result Results
T1:00 Stop the cisdb-pgsql service. Owner: node-1
The service will restart in the same node.
Up to T1:15, another failure of the web service or database will trigger a node change.
PASS
T1:05 Stop the World Wide
Web Publishing
Service.
Owner: node-2
The 'vault' role will be moved to the best possible node due to policy.
PASS

 

The other reason why we're covering this is to encourage critical thinking.  The policy settings for a lab or demo environment are very different than a production system, and the input goes directly to IT or security operations, in addition operator actions well-documented (as process), as well as trained technical personnel.

 

Testing Cadence (generic)

  1. Note the details about the test (time, current node in WSFC and in CPS, service status, etc)
  2. Have an understanding of the policy and expected results based on timing and environment.
  3. Cause the test failure
  4. Record the results.  Any deviation from expected results needs to be investigated.

 

Privilege Service HA Testing (videos)

Administrative

  • Maintaining HA when putting an active node in maintenance mode (paused).
  • Maintaining HA while the database is being backed-up.
  • Maintaining HA during Centrify Privilege Service Upgrade (shutdown the active node during upgrade).
  • Maintaining HA during Centrify Connector Upgrade.

Software

  • Stop the World Wide Web Publishing Service - based on rules, the service is restarted.
  • Stop the Centrify Identity Platform Database - based on rules and timing, the active node is transferred.

 Hardware

  • Simulate a Network Card failure (in this environment, also causes a Storage failure due to iSCSI)
  • Poweroff a CPS Service Active Node

Privilege Service On Premises -  High Availablility - Where to next?

As some of you know, Privilege Service (now part of Infrastructure Services) was designed as an Infrastructure-as-a-Service (IaaS) solution, and after it's relase and due to customer demand, we released a "customer-managed" version designed to be deployed and operated in an on-premises setting.

The goal of the lab is set-up the building-blocks to test the high availability capabilities of Privilege Service by leveraging Windows Server Failover Clustering (WSFC).

 

Lab Design

 

lab.png 

 

The design of this lab is based on the following test scenarios:

  • Administrative Failover (upgrades, patches, etc).
  • System, Network or Storage failure.
  • Connector Failover Strategy.
  • Disaster Recovery (backup/restore, orphaned or replicated database).

 

Process Overview

 installcps.png

 What's required

Summarized Windows Failover Clustering requirements
Detailed requirements here:  https://technet.microsoft.com/en-us/library/jj612869(v=ws.11).aspx

  • Active Directory - required for management and role computer objects, delegation and name resolution (DNS).
  • Redundant Shared Storage  -  WSFC orchestrates the storage switching between active and passive nodes.
  • Redundant Network Components -  this is a requirement of any modern clustering technology (including WSFC) to provide the assurance of communications via multiple paths, backup network cards, etc. 
  • At least 3 Windows Server (2012R2) with Windows Failover Clustering and connected to the Storage and Network layers for the CPS Server and at least 2 to act as Centrify Connectors.  This will provide the assurance that even when the Windows servers are being updated (or Centrify's software) there is at least a 2-node cluster in service.
  •  A properly set-up Windows Cluster, passes all the key validation tests during cluster setup.

Note: If this will be a test lab, and data availability is not important, you can use iSCSI virtual disks and virtual network components.  Using such a configuration in a production environment does not constitute an effective availability control.

 

Centrify Privilege Service requirements

  • Have a planned hostname and URL for the service (e.g. safe.example.com).
  • A static IP address for the corresponding role in Windows Failover Clustering.
  • Obtain an x.509 SSL certificate from a public or enterprise CA with the planned name for the service.
    (If planning to use Smart Cards, make sure the service name and the servicename +zso is added in the DNS name of the x.509 certificate.  E.g.  vault.centrify.vms, vaultszo.centrify.vms).  Make sure you have the password if the cert is protected.
  • Privilege Service software - minimum version 17.7.161 with PostgreSQL back-end.
  • Windows Cluster Nodes (ideally 3, and minimally 2)
    These are Windows Server 2012 R2 with Quad Cores and 16GB of RAM.  Plan for 50-100GB for the data.
  • At least 2 Windows Servers to be used as Centrify Connectors (to maintain high-availability).
    These are current 64-bit Windows Systems with Dual Core and 8GB of RAM
  • A Windows administrator (that can add/remove systems from the domain and local admin rights).
  • You should have or be ready to install a Windows Failover Cluster (DNS name and IP address decided) (e.g. cpsha/172.16.200.20)

What you should be familiar with

  1. Understanding of TCP/IP and name resolution, plus the ability to create DNS records and verify name resolution.
  2. Understanding of Active Directory administration and privileges to create computer objects.
  3. Administrative rights and familiarity with Microsoft Management Consoles like the Failover Cluster Manager tool.
  4. Understanding of  network attached storage (e.g. iSCSI or FibreChannel) partitions, volumes, logical disks.
  5. Understanding of Public Key Infrastructure concepts.

 

Planning

  • Is the cluster ready or does it need to be created, are the name and IP address secured?
  • What will be the name of the service? (e.g. vault.example.com).
  • Have you secured a static IP address for the service name?
  • What will be the shared logical disk path for the Centrify Privilege Service database?  (e.g. E:\cps-db).
  • What will be the procedure to handle the configuration file?
    This file contains configuration, encryption and recovery data (without it, no new nodes can be added, and recovery from backup or orphaned database is impossible).
  • Is there a test plan to verify the highly available or recovery test cases?  (see subsequent post).
  • Are the ports required for CPS communication and Centrify Connectors clearly understood?
    E.g. HTTP and HTTPS (TCP 80/443), PostgreSQL (TCP/UDP 5432),  DirectConnect (TCP 30001).

 

Sample Lab Planning Notes

planning.PNG 

Block Diagram of Customer-Managed Privilege Service

cpsblock.png

 

Installation Overview

  1. Verify Pre-Requisites.
  2. First Node:  Installation and Verification.
  3. Installing Additional Nodes.
  4. Configuring Windows Failover Clustering for Centrify Privilege Service.
  5. Testing Administrative Failover.

 

Verifying Pre-Requisites
These steps are performed to make sure the Windows Failover Clustering components are ready for Centrify Privilege Service.

  1. Verify Communications with the cluster
    • Verify cluster Active Directory object (e.g. verify that the computer object in AD is alive an well).
    • Verify cluster DNS name resolution  (e.g. ping the cluster name from all systems).
    • Verify CPS port communications (e.g verify the Windows firewall and check for CPS communications).
  2. Open Windows Failover Clustering and connect to your cluster
  3. Verify Validation Report of the cluster  (Right-click Cluster > View Validation Report).
    valid.png
    What are you looking for?  Any warnings or errors in the report.  For example, the lab I'm using has a few flaws:
    Node member3.centrify.vms is reachable from Node member2.centrify.vms by only one 
    pair of network interfaces. It is possible that this network path is a single point
    of failure for communication within the cluster. Please verify that this single path
    is highly available, or consider adding additional networks to the cluster.
    There you have it.  I have only one NIC card, this is a single-point of failure.  In a truly highly-available scenario, I'd probably have a pair of NIC cards dedicated to communication and/or storage and a heartbeat interface (just to talk to the cluster), this multiplies the risk per each node added.
  4. Verify Storage Layer and Disk Layout
    • Make sure you understand the disk layout (e.g. logical letter and database and backups location); e.g. E:\cps-db and E:\backups.
      disks.PNG
    • Verify that all cluster members can own the shared storage.  (Pause each member and verify the storage switch).

 

First Node - Installation

Set all nodes but the first node to maintenance mode and secure the storage folder.

  1. Log on to your First node as a Windows Administrator (e.g. node-1).
  2. Open Failover Cluster Manager and connect to your cluster.
  3. Navigate to Cluster > Nodes and right click node-2, select  Pause > Drain Roles.
  4. Repeat for all except for the current node  (e.g. node-3, node-4 and so on).
    paused.jpg
  5. Verify that the shared disk designated for the CPS database is mounted in the current system.
    E.g. open Windows explorer and navigate to the designated drive (e.g. E:\).
  6. Optional:  If you haven't done so, create a folder for the CPS database (e.g. E:\cps-db).

Set name resolution of the service to the first node.
This step is required because during installation the setup the program will need to get a token from the web service, and it thas to be resolvable by name.  This step will be undone before the additional nodes are added.

  1. Open your DNS Management tool (e.g. DNS Manager).
  2. Create a new CNAME record in your DNS zone.  The record should be called as the service name (e.g. vault).  The CNAME should point to your node-1 system.
    cname.png
  3. Verify by pinging the service name (E.g. vault.centrify.vms) from all the systems.
    PS C:\> ping vault
    Pinging node-1.centrify.vms [192.168.81.21] with 32 bytes of data:
    Reply from 192.168.81.21: bytes=32 time<1ms TTL=128
    Reply from 192.168.81.21: bytes=32 time<1ms TTL=128
    [output truncated]

Install Privilege Service (GUI installation)

  1. Run the Privilege Service installation program, this will start the setup wizard.
  2. Welcome Page > Press Next.
  3. EULA Page > Check the box and press Next.
  4. License Information > Type the case sensitive Company Name and Key, press Next.
  5. Feature Selection page > Select "Clustered Primary" and press Next.
    primary.png
  6. Destination Folder page > Select the preferred location (typically not the shared drive, this is NOT the database path).
  7. Ready to Install page > Press Install.
  8. Completed page> Press Finish (answer YES to the UAC prompt).

Install Privilege Service (PowerShell)
This part consists in answering these questions:

[output truncated]
Centrify Identity Service setup - Host Type: Primary
Starting clustered host setup: Thu, 28 Sep 2017 06:24:56 GMT

1. What username should the initial administrator account be created with?
(default: admin@opie.demo): Sample answer: admin@example.com
Don't select a suffix that conflicts internally, and retain this name because
it's the default sysadmin.
2. Initial administrator email address? (default: opiedemo@centrify.com):
Sample answer: admin@example.com
This address will only be relevant once the system is SMTP-enabled, feel free to
use your valid business e-mail address.

3. Initial administrator password?: ******** 4. Verify administrator password?: ********
Sample answer: Use a strong password or paraphrase, plan to change after setup.

5. FQDN to be used for this service? (default: node-1.example.com):
Sample answer: safe.example.com
This is the service name. When planning, make sure you understand the needs for
the service because once installed, it will respond just to that URL over HTTPS.

6. Would you like to provide a custom host certificate, if not, one will be
generated for you? [Y/N] (default: Y):
The best answer is Y, and to provide a valid x.509 SSL certificate. Although the
auto-generated cert, may be OK for testing, use a real cert for production.

7. Does your certificate require a password? [Y/N] (default: Y): N
Sample Answer: N (if it does not require it), answer Y and provide if needed.
8. Please Select folder for the service databases
This is when you browse for the database location. This has to be in a folder
on the cluster shared storage.
db.png [output truncated]
=====================================================================================
                       Setup / recovery file creation
 Setup will now create a zip file that contains important information needed
 to configure other cluster servers or to restore the database onto new systems
             DO NOT LOSE IT. DO NOT MAKE UNSECURE COPIES
 in particular it contains non recoverable encryption keys. Centrify will not be able
 to recover backups without this file
 NOTE: The database backup tools do NOT backup it up
=====================================================================================
recovery.png Now browse for the location of this file. Secure accordingly because without it you
can't add any new nodes, restore from backup or orphaned database.

When CPS is ready, it's time to verify that it's set.

[output truncated]
Internet services successfully stopped
Stopping Postgres Service
Starting Postgres Service
Starting IIS
Attempting start...

Internet services successfully started

***************************************************************************************
   Finished! Your system is now ready to be used via: https://vault.centrify.vms
***************************************************************************************

Finishing web setup ...
Setup standalone/database host completed: Thu, 28 Sep 2017 06:41:21 GMT

 

First Node - Verification

  1. Browse to your service address (e.g. https://vault.example.com).
    Note that if you did not get a good certificate (e.g. self-signed), your browser may require an exception.
  2. Attempt to log in with the credentials from the previous step (e.g. admin@example.com).
  3. Navigate between the user and admin portals.
  4. Optionally, you can upload the configuration file (clconf.zip) as a secret.
    1. In the admin portal, go to Infrastructure > Secrets.
    2. Press Add File and Name it "CPS config file" and browse to the config file location.
    3. Press Save.
  5. Exit Privilege Service.

 

Adding Additional Nodes

  1. Sign-in to your next node (e.g. node-2) with administrative credentials.
  2. Run Privilege Service GUI Setup and this time, select Secondary Node and advance until PowerShell Configuration.
    second.png
  3. During PowerShell, you'll get asked the location of the clconfig.zip file created with the first node.
    Sample output:
    [output truncated]
    Centrify Identity Service setup - Host Type: Secondary
    Starting clustered host setup: Thu, 28 Sep 2017 05:04:15 GMT
    Stopping existing services
    Stopping IIS
    
    Attempting stop...
    
    Internet services successfully stopped
    
    Stopping existing services
    Stopping IIS
    
    Attempting stop...
    
    Internet services successfully stopped
    
    Initializing configuration for secondary server
    Ensuring VC redist is installed
    Please Select location of cluster config zip file
    This file was created in the 'config' directory of the primary server
    clconf.png
    [output truncated] Trusting CA for this Machine Setup of secondary completed: Thu, 28 Sep 2017 07:35:58 GMT
  4. Repeat the process (1-3) in all the additional nodes.
  5. When completed with all nodes, copy the configuration file to a secure thumb drive, make copies and distribute securely and delete the configuration file from the primary node.

 

Configure Windows Server Failover Cluster for Privilege Service
Get the system, cluster and DNS ready

  1. Log in to your primary server (the one that is currently running).
  2. Stop the Centrify Identity Service Database Service and the Web Server.
    Use the services applet, or PowerShell (Admin):
    Stop-Service cisdb-pgsql
    Stop-Service W3SVC
  3. Open Windows Failover Cluster and resume the nodes in maintenance (note that if you choose to fail roles back, this may shift the disks).
    happy-cluster.png
  4. Use your DNS Management tool to erase the CNAME record that was created in the previous section.  The reason for this is that the new service (a WSFC Role) will have a DNS name controlled by Windows Clustering.
    dnsdel.png
  5. Make sure that the service's DNS record vault is not resolvable by any of the systems.  If required, flush the DNS cache using the ipconfig /flushdns command.
    c:> ping vault
    Ping request could not find the host vault.  Please check the name and try again.

Installing Privilege Service as a Windows Failover Cluster Role

  1. Verify that the Centrify Identity Platform Database is stopped in the last active node.
  2. Open Failover Cluster Manager and connect to the cluster.
  3. Verify that all cluster nodes where CPS is installed are in the cluster.
  4. Right Click Roles and Select "Configure Role"; this starts the role configuration wizard.
  5. Before you begin page > press Next.
  6. Select Role page > select  Generic Script.
    gen-scr.png
  7. Generic Script info page > Type or paste the path below, then press Next.
    C:\Program Files\Centrify\Centrify Identity Platform\scripts\iis_pgsql_cluster.vbs
  8. Client Access Point page > In Name, type the shortname for the service (e.g. vault) and the IP address for the service.
    If you get an error stating that the network name is in use, this means that you have not cleaned-up DNS or the system cache.
    service.png
  9. Storage page > Check the box next-to the logical disk (this will be the same logical letter and drive that has the folder with the CPS database information).
    stor.png
    We have been consistently using the E:\ drive in this example.  Note that there are other ways to do this setup, one includes installing the cluster AFTER CPS installation, in that case, the "Cluster validation tests"  can potentially change the logical lettering of the drive.  Make sure this is kept consistent.
  10. Summary page > press Finish.
  11. Now it's time to inspect the role, and verify what is the active node.  Click on Roles and refresh.  You should see the service name and the current owner node.
  12. Use your browser to connect to the service again.  When you sign-in, go to the upper-right menu under the user name.
    verif.png

Testing an Administrative Failover

  1. On Windows failover cluster, connect to the cluster.
  2. Right-click the newly-created role (with the service name, e.g. vault) and elect Move > Best Available Node.
    This step will move the cluster ownership to another node.  Note the name.
  3. You can monitor the status of the service in the remote node (e.g. member4.centrify.vms)
    PS C:\> Get-Service cisdb-pgsql -ComputerName member4
    Status   Name               DisplayName
    ------   ----               -----------
    Running  cisdb-pgsql        Centrify Identity Service Database
    
    PS C:\> Get-Service w3svc -ComputerName member4
    Status   Name               DisplayName
    ------   ----               -----------
    Running  w3svc              World Wide Web Publishing Service
  4. Once you have confirmed the transfer was succesful, refresh your browser and confirm the  ownership.  Keep testing until all nodes are validated.
    m4.png
    At this point, after verifying administrative node change to all systems, we can add our connectors.

Adding Centrify Connectors

In this version, the Centrify Connector service cannot be used inside any of the cluster nodes.  To install a connector:

  1. Log on to a Windows 2012R2 (and up) 64 bit system.
  2. Open your browser and navigate to the service address (e.g. https://vault.example.com/manage?iwa=false)
  3. Go to Settings > Network and press Add Centrify Connector.
    For more detail on Centrify Connector setup, review this article:
    https://community.centrify.com/t5/TechBlog/How-To-Installing-the-Centrify-Connector/ba-p/27840
  4. Once your connectors are installed, you can authenticate AD users and perform CPS services like Discovery or Import.

 

Videos

 What's next:  Configuration?

The next article on this series covers failover testing, however, for some of the testing to be complete, you must configure the system to be functional (populate sytstems, etc); configuring CPS is not in the scope of this article, however, here are some configuration items (in checklist form)

  • Verify that AD users can authenticate
  • Configure SMTP, Google Maps API or Twilio Service settings.
  • Configure Policies for User Access.
  • Configure System and Account Security Settings.
  • Configure Resource Subnet Mapping.
  • Create Roles and assign administrative roles (e.g. Privilege Service User, Privilege Service Administrator).
  • Configure and run a Network Discovery.
  • Import systems, accounts via CSV import.
  • Onboard Databases and Secrets.
  • Set up Workflow.
  • Configure SSH Gateway Settings.

 

Privilege Service On Premises -  High Availablility - Where to next?

After Preparing for your Privilege Management Deployment with the Centrify Infrastructure Service - Part 1, you will want to configure your Active Directory connection and start considering your network environment.

 

Read more...

There are a lot of configurations that can be done before importing systems and managing accounts for Privilege Management in our Infrastructure Service. 

  

Before you get started, you will need to choose a deployment option. Centrify offers two methods that you can choose from for your organization. You can choose to use our cloud based service or to manage your own systems with our on-premises customer-managed deployment option. 

 

If you are looking to try this out for the first time, then you can sign up for a trial here - https://www.centrify.com/free-trial/

 

-If you are going with the cloud deployment option, then you will need a Centrify tenant with the Privilege Service enabled. Your organization may already have one, but if not then you will need to start a new trial using the link above.

 

-If you are going with the customer-managed deployment option, then you will need to download and install the Centrify Privilege Service. If you have not purchased this software, then you can sign up for a trial using the link above.

 

-You will want to have at least two Centrify Directory Service accounts in System Administrator Role. This is to ensure that you are not the sole owner of administrative credentials to the service, in case of emergency. Also, it is a good practice to have some backdoor accounts that are still accessible in case the Active Directory connection is unavailable.

 

 System Administrator Role Memebers.png

 

 

 

 

 

 

 

 

 

 

 

Adding Centrify Directory Users

Creating Centrify Platform Administrators

System Administrator Role Permissions

 

-You will want to have a customized login suffix. This will be a unique suffix that your users will type to login. The login suffix also tell the authentication engine which identity repository and tenant to log a user into.

 

 Login Suffix.png

 

 

 

 

 

 

 

 

 

 

 

 

 

Creating a login suffix

How to use login suffixes

 

-You will want to have a customized tenant URL configured. This URL should be easy for users at your company to remember. You can create it in your Admin Portal Settings > Customization > Login > Tenant URLs.

 

Tenant URLS.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 Tenant URLs

 

-You will want to define user security policies for login authentication to the Centrify Admin and User Portals.  You will want to determine wether additional forms of authentication, besides their passwords, will be required when users log in to the Centrify Platform. Enabling login authentication in the user security policies will allow you to set what conditions users are required to present a second or third authentication mechanism, like if they are outside of the corporate network.

 

Login Authentication User Security Policy.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Setting authentication policy controls 

Creating authentication rules

Creating authentication profiles

Authentication mechanisms

 

-If you are requiring a second or third authentication mechanism for login, then you will want to make sure that your users will be able to satisfy any authentication challenges that they are required to approve. 

 

What you need for each authentication mechanism

 

  • For SMS/text challenges, then check that the mobile attribute, specifically is set for your users in Active Directory and Centrify Directory. 

 

  • For phone call challenges, then check that any phone number attribute is set for your users in Active Directory and Centrify Directory

 

  • For email authentication mechanisms, check that the mail attribute exists and has been set for your users in Active Directory and Centrify Directory.

 

  • For RADIUS as an authentication mechanism, add the RADIUS server information, enable your Connector(s) to work as RADIUS clients, and enable the RADIUS policy. Also, the Connector(s) that you enable as RADIUS clients will need to be added to your RADIUS server  as a RADIUS client.

 

Enable 3rd Party RADIUS Authentication.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

How to configure Centrify Identity Services platform for RADIUS

Configuring Connector as a RADIUS client

Configuring the Centrify Connector for use as a RADIUS client

Configuring a RADIUS server

 

  • If using OATH for MFA, configure OATH policy

 

Allow OATH OTP Intergration.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

How to configure OATH OTP 

 

 

 

 

You can add an icon and link to your Identity Service Portal that takes you directly to the Privilege Service. 

 

 

Screen Shot 2017-09-22 at 1.24.38 PM.png

Read more...

Centrify provides secure access to servers without exposing the password for shared privileged accounts such as root, (domain) administrator, or service accounts. By default, Centrify opens a secure shell or remote desktop session to the target system through the web browser. If you are connecting from inside the network,  you can configure Centrify to use the native SSH or RDP client instead of the browser. For instructions to set this up in Centrify, go to: https://docs.centrify.com/en/centrify/adminref/index.html?version=1504972139#page/cloudhelp%2Fsvr_mg...

 

To complete this configuration for SSH this article will show you how to configure the Windows Path to locate the desired SSH client to use. Setting the path and environment variables will differ depending on the version of Windows you have on your computer. Administrator privileges are usually required to modify the path and environmental variables.

 

Windows 8 and Windows 10

  1. From the Desktop, right-click the very bottom left corner of the screen to get the Power User Task Menu.
  2. From the Power User Task Menu, click System.
     Powertaskmenu.png
  3. Click the Advanced System Settings link in the left column. Note: In Windows 10, you may need to scroll down to the Related settings section and click the System info link. In the System window that opens, click the Advanced system settings link in the left column.
  4. In the System Properties window, click on the Advanced tab, then click the Environment Variables button near the bottom of that tab.
  5. In the Environment Variables window (pictured below), highlight the Path variable in the "System variables" section and click the Edit button. Modify the path line by appending the path to the SSH client to the end. Each different directory is separated with a semicolon as shown below. See the example below in red.

C:\Windows\System32;C:\Windows;C:\Program Files;C:\Program Files (x86)\Centrify\Centrify PuTTY\

 

windowspath.png

 

Windows 7, Windows Server 2008 and Windows Server 2012

  1. From the Desktop, right-click the Computer icon and select Properties. (For Windows Server 2012 and up, right-click on the icon labeled This PC.) If you don't have a Computer icon on your desktop, click the Start button, right-click the Computer or This PC option in the Start Menu, and select Properties
  2. Click the Advanced System Settings link in the left column.
  3. In the System Properties window, click on the Advanced tab, then click the Environment Variables button near the bottom of that tab.
  4. In the Environment Variables window (pictured below), highlight the Path variable in the "System variables" section and click the Edit button. Modify the path line by appending the path to the SSH client to the end. Each different directory is separated with a semicolon as shown below. See the example below in red.

    C:\Windows\System32;C:\Windows;C:\Program Files;C:\Program Files (x86)\Centrify\Centrify PuTTY\

windowspath.png

 

 

As part of the security toolbox, we must deal with shared credentials, more specifically passwords.  Many of you know how Infrastructure Services can secure credentials, however, a lot of work is going on to enhance the DevOps or automation use cases.  In this article we'll explore the options available to retrieve passwords from the CLI using Centrify, how it works, how it's secured and how programs or scripts to retrieve them.

Using shared passwords in CLI scenarios while maintaining assurance

Passwords have been hard to get rid of, unfortunately, even with old technologies like Kerberos and PKI we must accommodate for the need to securely retrieve credentials.  However, at the same time we need to maintain assurance and enforce principles like:

  • Try to eliminate passwords
  • Limit lateral movement
  • Just in time/just enough access/privileges
  • Identity Assurance
  • Monitoring and Auditing
  • Policy enforcement, etc

The maturity model illustrates this best:

maturity model.png 

Eliminate Passwords

Centrify eliminates passwords in this use case by relying on PKI credentials; the process happens during enrollment when a system is onboarded by an authorized party.  The enrollment process looks like this:

pkitrust.png

Each system is represented by a service account in Centrify Infrastructure Service.  Please note that in order to modify the PKI settings on a system, you must have administrative rights (you you require privileged access on the client side), plus you must have either an enrollment code or a user credential of a user that can enroll a system into Centrify Infrastructure Services. 

 

In Linux, this is implemented with the cenroll command.  If ther's a manual enrollment, we also ask for MFA based on authentication profiles like here (enrolls a system called centos7 to a vault.centrify.vms using the admin@opie.demo credential and enables all features):

sudo cenroll --tenant vault.centrify.vms --user admin@opie.demo 
--verbose --features all --agentauth identity-broker-users
--name centos7 --address centos7.centrify.vms

mfa-cenroll.JPG 

If an Enrollment code is available, you can use it (the most common way of doing this, especially for automation), here's how it looks on Windows, with a code (enrolls a system called member-vault using an enrollment code):

Enroll-CIPSystem -EnrollCode "THISIS-WHERE-YOUR-CODE-GOES"  
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
-Endpoint 'https://vault.centrify.vms'

code-ps.JPG

 
Access Control, Entitlements and Visibility
Centrify relies heavily on role-based access, but this is an interesting use case because it's highly-related to automation.  In this scenario, most likely a system will be built, and as part of the on-boarding it will automatically enroll to the Centrify platform.  Centrify includes a built-in group called:  Centrify Agent Computers;  by default, this group has visibility to systems, domains and databases.

cac-view.JPG

As a best practice, don't overload the Centrify Agent Computers built-in group.  Just use it for visibility purposes.  Create sets and other roles, and leverage those instead.

Permissions

For accounts, there are several entitlements

account-pers-aug-2017.JPG
This means that you need View+Check out at the account level to check out a password.  This is a mechanism for least access and limiting lateral movement.

 

Policy Enforcement and Monitoring

The most common password checkout policies (like multi-checkout or lifetime) are geared towards interactive use, but for machine communications, Centrify offers the ability to override the checkout lifetime settings at the account level.

 acct-override.JPG

 

A great policy that can be implemented is the use of internal/external, datetime or even Risk.  This can be applied at the account level.

 

Monitoring

Because a compromised system, although with limited access is still a potential "stakeout" point, monitoring service account checkouts outside the applicable time or at a rate that is out of the blue, the monitoring and alerting capabilites of CIP provide several tools like:  Dashboards, Reports or the ability to send events to a security operations or SIEM tool.

monit.JPG 

 

Deployment Utilities

  • Enrollment codes:  allow Centrify clients to enroll the platform automatically.  The benefit of codes is that you can add restrictions (like how many times or from which networks they can be used) or organizational options like sets or RBAC.
  • Sets:  Sets are collections of objects in CPS; they allow for dynamic or static membership as well as controlling permissions.
  • Packages:  The CLI toolkits are delivered as part of the Centrify clients for Linux or Windows.
  • Policy overrides:  Password lifetime overrides allow for different policies at the parent or account levels.  This is useful when you need policies for human beings vs. machines.

 

Implementations

The Centrify Agent for Linux, leverages the cgetaccount command (checking out the opieadmin local account password from as system called engcen6 for 5 minutes).

nix-checkout.JPG 

Here's more info about cgetaccount.

Here's how it looks in PowerShell  (checking out the sa SQL server account from the database enterprise for 2 minutes)

 ps-checkout.JPG

 

Note that these examples are interactive checkouts.  Ideally, a script or program would call this command to retrieve the password string and use it or assign it to a variable; as you can also see, the option to specify the checkout lifetime is available.

Futures

This is an area of a lot of interest for Centrify.  Stay tuned.

Background

Early adopters of shared account password management  (SAPM) solutions have discovered that a single strategy (e.g. password-driven) does not provide the assurance for modern IT infrastructure.  Despite the quick way some audit comments can be mitigated with a shared password solution, when you explore the modern enterprise, there are many issues and opportunities for improvement.  In this article, we'll discuss the challenges with vaults, and how with Centrify we can either compensate, enhance or consolidate security capabilities.

The idea is to explore each topic, and propose and demonstrate a scenario, provide recommendations and use an example with Centrify Infrastructure Services. 

 

You can also use this series to explore the capabilities of Centrify Privilege Service (a.k.a Centrify's vault)

 

The Traditional Password-Driven PIM Design and its Challenges

challenges-vaults.png

The illustration above provides a generic diagram for a password-driven PIM design; the whole premise of this design was that if you can control access to the password of a shared privileged account, provide secure access services (like terminal/desktop transport, auditing and recording) all via the vault and centralize access via a portal, then the issue could be resolved.  In time, many issues were observed:

  • "Productivity-driven" abuse:  when vault users suddenly "camp" (check out credentials for a long time), lobby for multi-checkouts, "try to go around" the vault when they can.
  • Deferment of identity or privilege consolidation:   very prevalent on the UNIX/Linux world, suddenly it was OK to continue with identity duplication in /etc/passwd, /etc/group accounts as well as managing and maintaining sudoers file configurations.  This was also influenced by the advent of DevOps solutions that make configuration management much easier.
  • Challenges for security practicioners:  Due to all the moving parts, it is hard to prove the effectiveness of these controls; there are many moving parts, and not enough compensating controls at each critical area.
  • Identity duplication:  The "vault" over time became another identity silo, especially if the design implied that all the local passwords for privileged accounts (e.g. root, administrator, etc) along with the user's "administrative, or -a" account was also living there.  This means that rather than eliminate the problem of "too many passwords" we decided to embrace it and get a tool to manage the issue.
  • Did not solve the issues faced by most enterprises:  Modern enterprises need flexibility and productivity, there are challenges with Filers, client-server applications, high-frequency transaction and other scenarios where this solution set does not provide a solution or simply does not scale well.  There are enterprises that have solved the problem of centralization, but simply chose the wrong infrastructure; and they want to come to Active Directory for more than just authentication.
  • Did not survive the test of time:  Although credential password management is one of the fundamental tools to mitigate security breaches, the goal is to achieve security assurance as threats evolve as well.  A key example is that this model does not solve issues like PTH in Windows or works well in multi-private/public cloud scenarios.
  • It's not really protecting the target systems:  This is perhaps the biggest flaw of this design.  All it's doing it's securing a privileged account password; if the system is compromised, there's no active software locally to provide assurance.

 

Framework

These articles will cover how Centrify Infrastructure Services addresses many of the issues outlined above, from identity consolidation to auditing and monitoring, across different platforms, however we'll do it maintaining our Identity Maturity model:

maturity model.png

 Series Content

  • Identity consolidation as a way to avoid vault-bypassing and to maintain assurance
    • Maintains productivity
    • Promotes centralized administration
    • Eliminates friction to adopt other identity-driven controls (like MFA or Risk-based access control)
    • Maintains flexibility for different types of enterprise challenges and apps
  • MFA across multiple contexts and use cases to provide identity assurance
    • At login (portal and system)
    • When using a shared account with secure access
    • When checking-ount a password 
    • When elevating privileges
    • When accessing a legacy platform
  • Securing the target systems with Centrify Zones
    • Using Centrify Local Account Management as a temporary phase
    • On the target system (UNIX, Linux or Windows)
    • Enforcing least access and least privilege
    • Embracing temporary access controls
  • Demonstrating the efectiveness of the controls
    • Monitoring (easy security operations integrations)
    • Attestation (portal, system)
    • Auditability and reportability (portal, systems)
  • Automation, DevOps and Operations
    • Components required
    • How processes are affected
    • Using an ITSM Solution to consolidate access requests

Combining Shared Accounts with Least Privilege

 

Article format

In each article, we'll try to define a challenge and illustrate the different ways Centrify can compenate or enhance the challenged caused by the Password-driven design.  We'll try to use existing articles when possible to reference past Tech Blogs.  As we add articles to this series, we'll list them below.

 

Articles

Integrating Active Directory with the Centrify Identity Platform allows you log into the Centrify Admin Portal with domain credentails. This article will walk you through the integration and System Administrator role assignment.

 

1. Integrate Active Directory with the Centrify Identitly Platform

Install the Centrify Connector on a 64-bit Windows member server. See instructions. Once the Centrify Connector has been installed, all domain users will now be able to log into the Centrify User Portal with domain credentials. To grant permissions to log into the Admin Portal, you will need to add the domain user(s) or group(s) to the System Adminstrator role or any other role with administrative rights.

 

2. Add domain user(s) or group(s) to the System Adminstrator role

a) In the Centrify Admin Portal, go to the left column and navigate to Core Services > Roles.

roles.png

b) Click on the System Administrator role. 

c) Select Members then click Add and search for your desired domain user(s) and/or group(s) that you want to grant administrative rights to the Centrify Admin Portal.

members.png

Now you can log in with your domain credentials to the Centrify Admin Portal.

Ever want to generate a report for the status of particular local accounts?  Need to know  when a password is due back from a CheckOut.  Here is a quick report to have in your back pocket.  Plus you will learn how easy it is to customize reports as well.

Read more...

Your Centrify Privilege Service (CPS) deployment could go a lot smoother with this checklist. This checklist is a high overview of the necesarry tasks to prepare, deploy, configure, and validate a CPS environment.

Read more...

You may be familliar with storing shared account passwords and how to retreive them via password checkouts using Centrify Privilege Service (CPS).  But did you know that in addition to storing passwords, you can now also store secrets such as API keys/tokens and encryption keys within CPS?  This short article will describe how you can store these secrets and make them available for use, while ensuring their security using role-based access control and multifactor authentication.secret1.jpg

 

 

 

 

Read more...

This technical blog post [with Videos] is intended to highlight the Centrify Identity Platform REST API Framework and its capabilities, specifically as it relates to automating the management of privileged accounts...

Read more...

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

In a previous article titled "How to Use DirectControl to Facilitate Kerberos-based Oracle SSO on Unix and Linux", we discussed how the Centrify DirectControl agent can be leveraged to allow Active Directory users to authenticate to an Oracle database seemlessly and securely without having to enter their username and password. Unfortunately, allowing AD-based Single Sign-On for end users is only half of the battle for Oracle-related accounts.

 

By default, there are over 28 predefined accounts (administrative & non-administrative) and several, additional schema accounts created during an Oracle database installation. Only a few of these accounts are addressed during the Oracle installer and let you update the password; most of the others are automatically expired and locked. This leaves the Oracle DBA to manage those accounts and come up with a strategy for properly securing the passwords.

 

The Centrify Privilege Service (CPS) is an Enterprise access management and password service that can group databases and secure internal database accounts for both Oracle and SQL Server databases. In this article, we'll see how we can add an Oracle database to CPS, add accounts (managed & non-managed), and then create sets of databases in order to implement additional access control over these accounts.

 

Requirements

  • Oracle 11g or 12c Database software installed and functioning properly on a Centrify-supported Linux server (The Centrify Server Suite agent, DirectControl, doesn't need to be installed)
  • The latest instance of Centrify Privilege Service, deployed either as a cloud-integrated component to the Centrify Identity Service (CIS) or as a standalone service deployed on-premises. This article uses the CIS cloud-integrated deployment option.
  • The accounts you manage must be configured to include the CREATE SESSION privilege
  • Management of the password for the SYS account is not supported by the Centrify Privilege Service because it requires a physical password file.
  • You must install the ODP.NET client library on the same machine where the Centrify Connector is installed. You can download the Oracle ODP.NET managed driver (ODP.NET_Managed_ODAC12cR4.zip) from the Oracle downloads website or here. If you download and install the library after you install the Centrify Connector, you should restart the Connector before adding the database to CPS. If a newer version of the client library is available, keep in mind that only the baseline version (12.1.0.2.4) and the latest version available are supported.
  • Centrify Privilege Service can manage the account password for standalone Oracle server. However, the Centrify Privilege Service does not synchronize managed passwords across computers in a cluster at this time.

 

Step 1 - Decide which Oracle Accounts to Add to CPS

Typically, the SYSTEM administrative account is the first account that DBA's like to protect the password for; this is because it is used the most often. However, there are many additional accounts, both administrative and non-administrative, that may be in scope for your requirements.

 

A simple question that you can ask is, "what type of functionality will I need to enable as part of my Oracle database installation?". You can then select the associated administrative accounts and use those and the intiial accounts to add into CPS for management.

 

You will then need to decide which of those accounts that you would like CPS to manage. Having a "managed" account means that CPS will securely vault the password, set it to a random, secure string, and then rotate it whenever the password is checked back in or whenever it is forced to rotate.

 

Step 2 - Add an Oracle Database(s) to CPS

  • Authenticate to your CPS tenant as a user with the sysadmin administrative right
  • Select the Databases tab; then click Add Database to open the Add Database Wizard
  • Type a unique name to identify the database, select the type of database service you are adding, and specify the fully-qualified DNS host name or IP address, and click Next.

AddDatabase.jpg

 

 

NOTE: If the database type is Oracle, you must also specify a database service name and the accounts you add must be Oracle database accounts. Optionally, you can also type a longer description for the database. For example, you might want to make note of the applications the database supports or the physical location of the server, then click Next to continue.

 

  • Add a user name and password for an account used to access the database and specify whether the password for the account is managed by the privilege service, then click Next.
  • Select Verify Database Settings to test access to the database using the account information provided, then click Finish. If the database and account settings are successfully verified, click Close.

 

NOTE: If there’s an error, test network connectivity and verify that the user name and password you provided are valid for the database you are attempting to add. If verification fails, close the error message, deselect the Verify Database Settings option, then click Finish to add the database and close the Add Database Wizard. You can only deselect the Verify Database Settings option if the password for the account is unmanaged. If the password for an account is managed, the database account must be verified to ensure the correct password is stored by the privilege service.

 

Step 3 - Add the Database(s) to a CPS Set (optional)

If you would like to group databases together by environment or application, for example, then you might choose to create a CPS Set for the database(s). This would then allow you to apply specific policies to the CPS Set. For example, you might want to have your internal DBA's to have access to the Oracle accounts on Production databases while external consultants might only have access to the same accounts on non-Production databases. You could then decide to implement strong authentication controls for the external DBA consultants.

 

To create a new static Set, simply select the Sets tab next to Databases, name the Set, and then add the Database members to the Set. Once the Set is created and membership defined, you then select the Users or Groups of Users that you want to add Set and Member Permissions for.

 

Step 4 - Set the Permissions (& Additional Options) for Database Resources & Accounts

Once your database(s) and associated accounts are added to CPS, you will need to set permissions on both. You can also choose to enable Access Request/Workflow and set Password Checkout policies for the particular user accounts.

 

In the screenshot below, user dwirth has full access to the SYSTEM account for this database resource:

 

Account_Perms.jpg

 

Step 5 - Test the Password Checkout for an Oracle Account

Once you have verified that CPS can properly communicate to the Oracle database(s), the final step is to simply confirm that you can checkout the password for one of the Oracle accounts that you have added.

 

From the Resources tab, rt-click on the database resource, select Account Actions, and then choose to Checkout the password. If you have enabled Workflow for this database resource, then the "Request Checkout" option should be listed for users who initiate a password checkout session:

 

PW_CheckOut.jpg

 

NOTE: You can also initiate an account password checkout from the Accounts tab. Just choose Database Accounts as the seach criteria, rt-click on the account, and choose Checkout. If you have been given the proper account permission, you can also rotate the password.

 

NOTE: If you don't want CPS to manage a particular account when adding accounts to a database resource, then simply leave that box unchecked in the Add Database Wizard. While the password will stay statically defined to whatever you set it to, you can still use the Workflow and Policy controls to further secure the access to that account password.

 

Summary

As you've seen from this article, there are many pre-defined Oracle accounts that also need to be properly addressed in order to secure identities across your Oracle installations. Leaving these types of shared access account passwords unprotected will increase the chances that someone will eventually hijack the account password and use it for malicious intent.

 

Using your existing CPS tenant, whether it be deployed on-premises or integrated into CIS, you can quickly and efficiently secure the passwords for these accounts.

 

So you're already managing user accounts in Active Directory - but what about those pesky system accounts you're still managing in /etc/passwd?  Wouldn't it be great to manage them with Centrify too?  In this article we'll demonstrate how to securely manage local accounts using a comination of Centrify Server Suite and Centrify Privilege Service.  

 

Read more...

Here's a quick report that can give you a list of resources in the Privilege Service. This is handy if you've run the Discovery tool and now want to print out your list of discovered resources. 

 

Read more...

The Centrify Privileged Identity Management solution provides a set of controls for Google Compute Engine Linux VM Instances to support Enterprise integrated identity and access management functions. This solution enables organizations to consolidate identities, enforce cross-platform least privilege access and control shared accounts, while securing remote access and auditing all privileged sessions.

              

This guide will show how to setup and configure Active Directory based identity and access controls as well as privilege management for Linux VM Instances running on Google Cloud Platform. It will also show how to take over password management for local root accounts as well as to provide secure remote access to these Linux VM Instances.

Read more...

Security Kaizen - Part III: Web Apps, Mobile/Mac and MFA

Part I | Part II | Part III | Part IV

In the first two articles of this series we have discussed some metrics that can help security analysts in the evaluation of their access and privilege management models in a Centrify deployment using Server Suite.

 

The whole premise is to treat the process of limiting access/privileges as a subject of a continuous improvement cycle where we apply root-cause analysis and implement improvements to the security posture of the organization. 

 

In this third iterationid-service.PNG we're going to shift gears to other areas of the Centrify world and we'll focus on web applications.  In this entry we'll focus on Centrify Identity Service.  CIS  is a best-of-breed Identity as a Service solution that provides simple federated SSO, self-service, mobile device/application/container management and much more. What you'll see below is included with the product in the form of reports and dashboards;  in addition to these capabilities, we have released an analytics engine that is a companion to CIS.  Read all about it here.

 

With CIS, we're going to discuss these dimensions:  Apps, Users (including admin users), Roles, MFA and Mobile.

 

Application Dimension

When dealing with Applications, one of the most common goals in the context of access management is to consolidate application authentication patterns.  The principle is to move away from local user/password repositories because this is one less point of risk and compliance enforcement.  For each user/password app, security analysts must worry about alignment with policy, roles/rights, mitigation for advanced threats, attestation, etc.  

If an application is using a modern approach (like federation) is easier to provide the assurance of compliance and this also makes the application much more portable.

 

Total Deployed Apps

The first place to start is to identify your application real-estate.  Understanding how many applications are deployed in your environment is the first place.

select count (*) from application; 

Apps not in use

Another great piece of information is to find out what applications are not in use.  If an app is published and has no audience, perhaps this needs to be reconsidered.  This can be found under Reports > Applications > Unused Web Apps

usused apps.png 

% of Apps using Federation

As stated above, the goal is to eliminate user/password applications.  You can create a ratio of total apps that support federation / total apps; this will give you a good target percentage; since some apps are kept due to legacy and political reasons, each app move to modern patters may be a project or a program in itself.

As an example, you can modify one of the built-in reports to obtain the SAML-capable apps from the existing installation:

select ID AS _ID, DisplayName, WebAppType, Category, Description 
from Application
where WebAppType='Saml'
order by AppTypeDisplayName, Category, DisplayName

saml-apps.png

Unique application launches and App launch events

app-launch-events.pngapplaunches.png

Although these are operational metrics, they are correlated with user activity and roles (see below);  For example in the pics above I've drilled on App launches related to the Amazon root account and the IAM federated app.  This is because those apps are use by very high-privileged users.

 

Most Commonly Used Apps

This can be generated as a report;  commonly used apps may indicate heavy line-of-business apps and is an indicator of potentially-sensitive information.
apps.PNG

Look at the Top apps in this example:  Salesforce (sales/customer data); Office 365 (all kinds of data), Workday (employee data).

 

There are multiple areas to focus on apps (including mobile) but let's focus on the CIS user view.

 

User Dimension

Users in Identity Service can have assigned applications, provisioned applications and roles.  Roles may be used for application access (RBAC) and for privileges in the platform.   

 

Assigned Apps (user)

assigned-applications.png

The goal continues to be the least access principle and we want to make sure that users only have access to the apps that they need. 

 

Provisioned Apps (user)

provisioned-applications.png

Provisioned apps allow for just-in-time provisioning (or de-provisioning) of users and if supported, role assignments.

Notice how you can also identify anomalies.

 

Roles Assigned (and Entitlements)

role-user-view.png 

Note how a role also provides the user with privileges in the platform.

 

User Logins vs. User Failed Logins

logins.png

failed-logins.png

It's always important to review this type of activity, however Identity Service provides an additional dimension - geo-location;  this provides better intelligence for security operation decision.

failed-login-map.png

Any failure attempts in geographies that the enterprise does not have a presence should be flagged or subject to additional scrutiny.

 

Administrative User

 

Application Changes

Administrative users may change apps, roles and settings in the overall platform.  Typically, when apps are being deployed, there are many changes being logged, but once an application is stable, it should be "locked"  and the changes should only be under approval by change control committee unless there's emergency changes needed.

 

app changes.png

 

Role Changes

Activities in this area depend on the RBAC model implemented.  If administrators make membership changes directly on the Identity Service roles, then activity will reflect natural business operations;however, if using the target groups (e.g. AD security groups), then the changes to roles should be minimal.

role-changes.png

 

Challenges and  Multi-factor Authentication

 

MFA is a key part of Identity service and the metrics around this capability can be very useful to understand user behavior and potential threats.  Identity Service supports different types of authentication profiles that may include Smart Card/YubiKey/OATH as MFA methods and SMS, phone factor, and e-mail as step-up methods; it can also support RADIUS challenges to accommodate for legacy tokens like RSA SecurID, Vasco or Symantec.

 

Successful and Failed Challenges

faild-logins.png

A challenge happens when MfA is invoked, therefore a failed challenge is a causal factor behind failed logins.

 

Challenges and Authentication Events

chall-type.png

Pay special attention to failed challenges;  these are instances in which an MFA  (or step-up) mechanism has been invoked but it hasn't been satisfied.  Repeated attempts are subject to security alarms.

 

Authentication Events - Pattern

auth-events.png

Authentication patterns are relatively predictable in some organizations (this depends on their timezone footprint), this means that you should understand a normal ratio (e.g. failed challenges/total challenges) over certain periods of time (after all, users miss challenges), but any spike, especially outside normal hours should be a subject of additional investigation.  Notice the change on the wave pattern once we hit Saturday (18).

 

 

Mobile

Stats around mobile could be geared towards maintaining device conformance to a standard (e.g. minimum version for iOS shall be v10), understanding the make-up of the devices and making sure that capabilities that are compensating controls for data protection or leakage are deployed.

 

Enrolled Device Compliance

dev-comp.png

In this metric it's important to understand what are the key components of device alignment with policy.   As new mobile devices and OSs are deployed, capabilities may evolve or can be superseded for better ones.  User intervention is also a challenge when it comes to mobile devices, however, organizations can have stronger policy in corporate-owned devices vs. devices brought by the end-user (BYOD).

 

Device Status

 

status-dev.png

A large percentage of unreachable devices may mean that if you're using self-service enrollment, you may be allowing too many of them.   For example, a limit of 2 devices is preferable than 5 (default).

 

Device Real Estate

dev-realestate.png

This pie chart provides the answer to a key question - how many devices are out there and what's the make-up. 

dev-os.png

Identity service provides a set of policies that provide the assurance that users can't enroll older devices that may not be subject to manufacturer updates that are vulnerable to risks. 

 

Resources

Background

ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  This is the fourth article in the series.  We have covered  ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and setting-up and configuring Centrify App Request;  in this post we'll discuss the steps to set up Centrify Privilege Access Request to leverage the Service Catalog to request login or password checkout of resource accounts in Centrify Privilege Service.

 

About Centrify Privilege Service (CPS)

CPS is a privileged identity management solution that focuses on shared secrets on UNIX, Linux, Windows, Network devices, AD domains, Oracle or SQL databases and more.  The approach is different than Server Suite that is focused on the principle of least privilege.  Privilege Service provides a built-in access request system with single and multi-level approvals.

checkout.PNG

 

Privilege Service's Workflow  vs.  ServiceNow Self-Service

We often get questions about what solution to use for self-service and approvals for application or privilege requests.  The answer is quite simple:  if you already have all your requests in ServiceNow, you should continue to do so, this helps standardization and a unified user experience.  The Centrify workflow engine is designed to meet the basic needs for Centrify products and ServiceNow is a full-fledged Service Management solution.

 

We'll continue to use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology and assumes you have working knowledge of Identity Service and ServiceNow.

 

What you'll need

  • A SaaS instance of Centrify Privilege Service with UNIX, Linux, Windows or Network Devices configured.
    Note:  You can use an on-premises instance as well, provided that the network (e.g. publicly-facing) and name resolution (publicly-resolvable) aspects of the design are taken care of.
  • A ServiceNow Instance that allows you to install apps  (non-developer) with federated access to your Privilege Service instance.  For details on how to set up SAML federation with the Multi-provider SSO, click here or review the links below.
  • Administrative accounts on both systems

 

Planning

During planning, discuss with your infrastructure, operations and security teams about these topics:

  • Will you have a single approval or multiple approval groups per resource?
    Depending on the resource(s) in question you may have a single group or multiple groups approve.  You may also use a default approval group. 
  • How will the workflow be designed?
    This topic is very organization-dependent.  Some organizations may chose to have automatic approvals for certain systems and human approvals when the systems host sensitive data or are subject to strong security policy or regulations like SOx, PCI, HIPAA and others.
  • Have you identified a Default Approval Group in ServiceNow?
    If you chose to have a single group approve all privileged requests.
  • Have you created a CIS role and policy set for the servicenow service account?
    The servicenow account in Identity Service requires at a minimum the "Privilege Management" right, in addition, a policy that allows for username/password is required since the REST calls used by the app can't answer multi-factor authentication requests.
  • Will you have SLAs tied to your application requests?
    Although not in the scope of this post, SN offers a lot of flexibility when designing workflows including expiring worfkow requests when they are not approved within a defined duration.

 

Implementation

Overview

  • Create an Identity Service user (the service account that SN will use to authenticate and perform actions)
  • Create an Identity Service role with the minimum rights (the role that will be assigned to the service account)
  • Create an Identity Service Policy to allow user/password login
  • Download and Install Centrify Privilege Access Request app from the ServiceNow App Store
  • Configure the Centrify Privilege Access Request app

Create a Service Account

For this integration, you'll need a service account (you should know how to create users to follow this article).  To practice least privilege, this account needs to belong to a role with the Privilege Management right.   This is to be able grant login or password checkout rights on the accounts on each system.  Centrify Directory users are created under Admin Portal > Users

sn-create-serviceuser.png

When creating the user, be mindful of options that can cause an outage (like password expiration), and practice proper rotation and complexity based on your internal policy.

 

Create a Role with the minimum rights

To create a role, you have to go to the Admin Portal > Roles and Press Add role.  In the  members tab, add the newly-created account and in the Administrative rights tab, select the privilege management right.

 

privman.png 

Once completed, press the save button.

 

Create Policy to allow user/password login

This step may require you to create an Authentication profile that only asks for password (Admin Portal > Settings > Authentication > Authentication profiles).   The reason being is that Identity Service will (by default) ask for a step-up method for any unknown connections. 

 

  1. Log on to the Admin Portal with an administrative account
  2. Go to Policies > New Policy
  3. In Policy Settings, scroll down and select the "Specified roles" radio button
  4. Press Add and browse for the role created in the previous step.
  5. On the left pane expand User Security Policies > Login Authentication and select Yes to enable.
  6. Under default profile (used if no conditions matched) select your Auth profile that only challenges for password.
  7. Press Save
  8. In an incognito window for your browser, try to log in to the service with the newly-created account.  You should only be prompted for username and then password.

policy-summary.png

Important:  Make sure that the policy only applies to the members of the role created for this integration.

 

Download and Install the Privilege Access Request App from the ServiceNow Store

  1. Go to the ServiceNow app store and search for Centrify.
    priv-req.PNG
  2. Click on the Centrify Privileged Request App
  3. Click "Get" to make the Centrify Privileged Request app available for your ServiceNow instances.
  4. Go to the ServiceNow instance, select System Applications > Applications > Downloads to locate the app then click Install to install it.

Configure the Centrify Privileged Access Request app

There are three configuration tasks required.  Properties, API Sync and Accounts.  The third category is only needed if you are using individual groups as approvers for each resource's account.
Properties
  1. In the application pane (left) navigate to Centrify Privilege Request > Properties.  Populate these three fields
    Centrify Cloud Tenant URL:  the URL for your identity service tenant.  (e.g. https://your-tenant.my.centrify.com)
    Centrify Cloud Service Account: the account you created in previous steps
    Centrify Cloud Service Account Password:  the strong password you created for the user
    sn-app-access-conf1.png 
  2. Default Approval Group (Optional):  now you have a decision to make based on the planning above.  Populate the "Default Approval Group" if you decided to use a single ServiceNow group to approve all privilege requests.  You have to find the group in ServiceNow (System Security > Groups; find the group, right-click it and "Copy sys_id" and paste it on the Default Approval Group.  If you are planning to have approval groups per App, then you leave the field empty and press Save.

API Sync

  1. Go to Centrify Privilege Request > Customize API Sync
  2. Set the Active checkbox
  3. Select an appropriate interval based on your SLAs (e.g. 1 hour)
  4. Press Save and then Execute Now.
    api-sync.png
    This process will synchronize the Resources (systems) and accounts available in Privilege Service

Accounts
If you set up a "Default Approval Group" you can skip this part.  At this point you have to have a list of all the apps and the corresponding approval groups.  For example, the root account in the CentOS system called engcen7 will be approved by the Team Development Code Reviewers group included with the sample data of the ServiceNow instance and the canned workflow for software.

root-apprv.png 

 
Verification

To verify the functionality of the app, you'll have to run through the workflow of the apps (or independent apps) based on the approval group defined.  For example, in my scenario I chose to have independent approval groups.  My requester wants to checkout the "api-key" resource under the azure-rh1 resource and the self-service request is automatically approved based on existing ServiceNow rules.

 flow.png

 

Once the request is approved the app will provide the requester access to the type of request (login for SSH or RDP access) or checkout (for password reveal or clipboard copy).  In order to get access to the system or retrieve the password, the requester must switch over to privilege manager and find the system in the resources list or in their favorites.  For login they can use the PuTTY or web client and to check-out the password, they can use the system resource on privilege manager or the mobile app.

 

Documented Approvals

Security analysts and auditors may require reports of who has been requesting and approving apps, this is easily accessible using the service catalog requests or under the Centrify Privilege Request Access approvals or the Dashboard section.

requests.PNG

 

Improvements

Since this app focuses on ServiceNow approvals, the enhancements are around workflow design.  For example, you can have multi-approval groups, you can set timers for SLAs, etc.   However, there are other things that you can customize including the Dashboards and the appearance and location of the Centrify items in the Service Catalog.

helsinki.PNG 

Centrify & ServiceNow Resources

There are multiple resources available in the documentation and tech blogs:

[How to] create and publish a new username/password app for Cloudera Manager.

Read more...

Here is a quick primer on the security risks associated stale Window Service Account Passwords and how Centrify’s new "multiplex account” feature helps…  Towards the end is an embedded YouTube video demo showing the feature in action. 

mitigate_map.png

 

 

 

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard
User Kudos Count
4
3
1

Community Control Panel