Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

[Labs] Securing Windows Servers with Centrify Infrastructure Service - Enrollment, Settings and Sets

11 April,19 at 11:51 AM


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.


Building Blocks
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.

 Recommended Reading

What you'll need (tools/permissions)

  1. 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.).
  2. 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.
  3. 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.





Planning Topics

  • 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)

  1. Create an Enrollment code in Infrastructure Service.
  2. Create an Encryption Key in AWS.
  3. Set up parameters (parameter store).
  4. Host Centrify CIP samples (S3-bucket).
  5. PowerShell script overview


I. Set-up an enrollment code

  1. Sign-in to your Centrify instance and go to : Admin Portal Settings Infrastructure Enrollment Codes
  2. 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

  1. Sign-in to your AWS console and go to the IAM Service.
  2. Use these instructions to create an encryption key. 
  3. 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.
  4. Return to the EC2 service.

III. Setting-up Parameters

  1. Sign-in to your AWS console and navigate to: Services > EC2Systems Manager Shared Resources Parameter Store 
  2. Click on Create Parameter  create the following parameters:
    workdirStringThe working directory to download the samples
    e.g. c:\CentrifyTools
    cipurlStringURL of your Centrify Platform Instance.  E.g.
    zipkeyStringName of the zipped file with the Centrify samples file in the bucket.
    e.g. CPS Powershell Samples
    s3bucketStringName of the S3 bucket containing your files.

    Enrollment code from the Infrastructure Services Platform
    (created in Section I).

    E.g. AABC-XYMZ-PIUYY-MM23459-AAB34


    The sets the system will be added to in JSON format
    e.g. [ { 'Name': 'SetA' }, { 'Name': 'SetB' },  { 'Name': 'SetC' } ]

  3. Now open the S3 service.

IV. Add the CIP samples to your S3 bucket

You will be performing these steps from the domain-joined Windows system hosting the file share.

  1. If you need to learn how to create S3 buckets.  Click here.
  2. Add the CIP samples (link) to your bucket.
  3. 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).
    Set-ExecutionPolicy Unrestricted -Force
    # creates registry path (fixes issue with older scripts)
    New-Item -Path HKLM:\Software\Centrify
    New-Item -Path HKLM:\Software\Centrify\Cloud
  • Obtain the first batch of parameters and variables:
    $workdir = (Get-SSMParameterValue -Name workdir).Parameters[0].Value 
    $cipurl = (Get-SSMParameterValue -Name cipurl).Parameters[0].Value
    $enrollcode = (Get-SSMParameterValue -Name enrollcode -WithDecryption $True).Parameters[0].Value
    $fqdn = Get-EC2InstanceMetadata -Category LocalIpv4
    $instid = Get-EC2InstanceMetadata -Category InstanceID
    $system_name = "awsi"+($instid).Substring($instid.Length - 11)
    $system_sets = (Get-SSMParameterValue -Name sets).Parameters[0].Value
    $s3bucket = (Get-SSMParameterValue -Name s3bucket).Parameters[0].Value
    $zipkey = (Get-SSMParameterValue -Name zipkey).Parameters[0].Value
    $samples_file = (Read-S3Object -BucketName $s3bucket -Key $zipkey -File "$workdir$zipkey")
    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.
  • Unzip the Centrify PowerShell samples
    $shell = New-Object -ComObject shell.application
    $zip = $shell.NameSpace($samples_file.FullName)
    foreach ($item in $zip.items()) 
    We are unzipping the Centrify PowerShell samples to the working directory.
  • Load the Centrify sample modules and enroll the system to CIP
    Import-Module C:\CentrifyTools\CIP\cps\Centrify.IdentityPlatform.Powershell.psm1
    Import-Module C:\CentrifyTools\CIP\cps\Centrify.Cloud.PowerShell.CIP.psm1
    Enroll-CIPSystem -EnrollCode $enrollcode -FQDN $fqdn -ResourceName $instid -Endpoint $cipurl -Sets $system_sets
    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's the final housekeeping:

    Remove-Module Centrify.IdentityPlatform.Powershell
    Remove-Module Centrify.Cloud.PowerShell.CIP
    Remove-Item C:\CentrifyTools -Recurse -Force


Testing (verifying) the implementation

Here are the high-level steps to start your testing.

  1. Launch an EC2 Windows Instance.
  2. 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)
  3. Paste the contents of your PowerShell script in the User Data field
  4. Continue launching your system normally.
  5. Open the Centrify Admin portal, and go to infrastructure  (monitor enrollment, sets, etc)

 Test Matrix

Test NameTest StepsExpected Result
System Enrollment

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.


Verification Video




Instance Termination

  • 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.


Common settings

  •   '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.

$resourcePermissions =  "[ {'Principal': 'user1@centrify-mg.test', 'PType' : 'User', 'Rights': 'Grant,Edit,Delete,ManageSession,AgentAuth,RequestCssRole'},
                             {'Principal': 'role2', 'PType': 'Role', 'Rights' : 'Edit,Delete,ManageSession'},
                             {'Principal': 'role1', 'PType': 'Role', 'Rights' : 'Grant,Edit,Delete,ManageSession'} ]"

Common Policies

Most of them self-explanatory.  Controls system-level policies (normally these are inherited from the global security settings).

  • Allow multiple checkouts - in some systems, to prevent issues this may be discouraged.
  • Default checkout time - the default is 60 minutes, however, perhaps this is needed differently depending on requirements.
  • Allow remote access - perhaps this is not a system that should be accessible from a public network.
  • Password history, cleanup and rotation - this is relevant, if this system will be ephemeral or the password is set and not rotated, these settings can be set to false.

Sample policy file and values:

    'AllowMultipleCheckouts': true,
    'DefaultCheckoutTime': 30,
    'AllowHealthCheck': true,
    'AllowRemote': true,
    'AllowPasswordHistoryCleanUp': true,
    'PasswordHistoryCleanUpDuration': 100,
    'AllowPasswordRotation': true,
    'PasswordRotateDuration': 90


  • Add logging, pauses and error handling logic  to the script.
  • Add additional settings or policy to the system (e.g. which connector, workflow-enabled, etc.) - see above.
  • Specific adjustments for Windows Server 2016.

Articles in this series

Referenced Articles: