Background Centrify Infrastructure Service allows organizations to implement system-based and vault-based security. To maintain an adequate security posture, an on-premises or IaaS system runn...
Centrify Infrastructure Service allows organizations to implement system-based and vault-based security. To maintain an adequate security posture, an on-premises or IaaS system running on any popular cloud like AWS, Azure or GCP has to be secured throughout the lifecycle. In this article we are going to go over the steps of
Enroll a Windows system in Infrastructure Service
Apply local settings, policy or permissions
Add to sets.
To follow this lab guide, you must be very familiar with your on premises or IaaS deployment tools. We will be using AWS as an example.
We have split the orchestration building blocks into several articles for easier testing and future extensions.
These scenarios can be combined based on the organization's requirements.
A Centrify Infrastructure Services subscription enables all scenarios.
A Centrify App or Endpoint Services subscription enables the system-based scenario in zoneless mode.
Setting-up an AWS Test Lab for Centrify Provides a step-by-step guide to setup and host Active Directory in AWS, plus walks you through the process of implementing several Centrify software pieces.
What you'll need (tools/permissions)
Requirements for your on premises or IaaS infrastructure
Ability to define/modify roles in your IaaS or On Premises toolset. (e.g. AWS IAM).
Ability to launch instances and modify its configuration (e.g. AWS User Data).
Ability to host and set ACLs on a web share (e.g. AWS S3).
Ability to create a normal and secure parameters (e.g. AWS KMS + Parameter Store).
Network layout that allows communication between your Windows systems and the Centrify platform (e.g. AWS Security Groups, etc.).
Centrify Identity Platform requirements
A Centrify Infrastructure Services subscription (for this scenario).
A Centrify connector that can communicate with your Windows instances (see communications requirements). The connector is only needed if you need to reach the system (e.g. Jumpbox), in this example the connector is not required.
Ability to create an Enrollment Code in Centrify Infrastructure Service.
Optional: a privilege service set.
Communications requirements These requirements vary based on the requirements, but for the scenario illustrated here you'll need:
Your Windows system should be able to resolve all FQDNs used.
Your Windows system should be able to reach the Centrify Identity Platform via HTTPS
Register the system with Infrastructure Service
Put in place any any local settings
Set any any local policies
Add the system to a specific set
In this example:
A Windows EC2 instance is with PowerShell code in the user data field
The system retrieves information from the AWS parameter store.
The system is enrolled automatically with Centrify Infrastructure Service.
Optional: local settings and policies are put in place.
The system is added to the "AWS-EC2-Systems" set.
Methodology: We will use the Plan-Do-Check-Adjust methodology.
How will the Centrify PowerShell samples be made available? In our example we use an S3 bucket
How will parameters be distributed? How about sensitive parameters like enrollment codes or credential passwords? In our example we'll use the KMS service and AWS parameter store.
Naming convention: How will the system be named in the vault? In our example, we use the AWS Instance ID: i-xxxxxxxxxxxx.
Settings and Policies: are there any specific settings or policies to be put in place at the system level (override)? We'll cover these in the adjustments section below.
What IP Address of FQDN will be system be registered at? In this example we use the IPV4 address from the AWS metadata. However, if the system will be joined to AD and planned to be used for system-based security, ideally this will be the internal or external FQDN based on network layout or requirements.
Will the systems be part of any specific Sytem set in Infrastructure Service? We'll use a System set called AWS-EC2-Systems
What are the considerations for different OS versions (e.g. Windows Server 2012R2 vs 2016)? These instructions will be used with Windows Server versions 2012 R2 and 2016.
What are the considerations for system termination? We'll cover in the adjustments section below.
Implementation Overview (for AWS)
Create an Enrollment code in Infrastructure Service.
Create an Encryption Key in AWS.
Set up parameters (parameter store).
Host Centrify CIP samples (S3-bucket).
PowerShell script overview
I. Set-up an enrollment code
Sign-in to your Centrify instance and go to : Admin Portal > Settings > Infrastructure > Enrollment Codes
Set up the expiration, max joinable servers and owner. If you want to specify any other restrictions, do so understanding the implications. For testing ideally you want to keep things simple. When completed press Save. The code will be displayed for you. Copy it to memory.
II. Set-up an encryption key in AWS
Sign-in to your AWS console and go to the IAM Service.
Once you have the encryption key set up, you must grant a policy that allows decryption. In my environment, I have a key IAM Role called "Cenrify-IAM-Role-4EC2" and I have granted decryption rights. When systems are launched, they are added to this role that grants the system with the ability to decrypt secure string.
Return to the EC2 service.
III. Setting-up Parameters
Sign-in to your AWS console and navigate to: Services > EC2> Systems Manager Shared Resources > Parameter Store
Click on Create Parameter create the following parameters:
The working directory to download the samples e.g. c:\CentrifyTools
Set the permissions for your EC2 role (e.g. Centrify-IAM-Role-4EC2) so it can read the file (or the whole bucket). For instructions on how to grant access to an IAM role access to an S3 bucket,click here.
V. Construct the PowerShell to Onboard the System
Execution Policy and registry entries: The policy has to be set to unrestricted to allow for unsigned modules. The registry key has to be created (this is an issue with older versions of the PS samples).
Note that we are leveraging many of the AWS SSM PowerShell commands to retrieve parameters from the store; this requires the instance to be in an AWS IAM role that has read access to these parameters and can decrypt secure parameters stored in the AWS encryption service.
At this point, the system is registered in Centrify Infrastructure Service with the AWS instance ID as the name, the internal IP address as the FQDN and it is added automatically to a set called AWS-EC2 Instances.
Here are the high-level steps to start your testing.
Launch an EC2 Windows Instance.
In the configuration tab, make sure you add it to your IAM role (the one that is granted access to retrieve parameters, decrypt and read the EC2 bucket)
Paste the contents of your PowerShell script in the User Data field
Continue launching your system normally.
Open the Centrify Admin portal, and go to infrastructure (monitor enrollment, sets, etc)
1. Sign-in to the Centrify Infrastructure Service web Admin portal.
2. Go to systems, review the list (refresh).
In step 2 the system is shown as listed with the internal IPv2 address as the FQDN.
Added to set
1. Click on the set in question (e.g. AWS-EC2-Systems) review the list (refresh).
The newly-added system should be part of the set.
Privilege Session (RDP Jumpbox)
1. Make sure that there's a Centrify connector up and running that can reach the instance over RDP.
2. Sign-in to the Centrify Infrastructure Service web Admin portal.
4. Go to systems, review the list (refresh).
5.Right-click the system and attempt manual login (enter account).
You should get RDP access to the system.
Any considerations for any other building blocks you may have added.
The system has to unenroll from the Centrify Infrastructure Service (Unenroll-CIPSystem -delete $true) Note, this will delete any shared passwords under that system - see the next building-block. In addition, this will eliminate the system from the device count (licensing purposes).
Settings, Permissions or Policy overrides
The Enroll-CIPSystem commandlet supports the ability to provide any local settings,permissions or policies.
Some common settings include which connector to use, permission sets, and policies like checkout policy.
'Description': Description for the resource Add metadata to the system.
'Port': Is an integer value. Rdp port number (if not the standard TCP 3389)
'ManagementMode': 'Unknown' or 'Smb' or 'WinRMOverHttp' or 'WinRMOverHttps', 'RpcOverTcp' These are important for local account password management. More on this in the Local Password Management module.
'ManagementPort': ManagementMode port for 'WinRMOverHttp' or 'WinRMOverHttps' If using WinRM, the port is customizable. Note: there are many more settings, and they are added as new features/capabilities are added every month.
Resource Permissions Resource permissions are specified in JSON format. Permissions don't have to be put in place if the system will join a static set.