Re: [Labs] Securing Windows Servers with Centrify Infrastructure Service - Local Password Management

[Labs] Securing Windows Servers with Centrify Infrastructure Service - Local Password Management

By Centrify Guru I a month ago - last edited 2 weeks ago


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 the Windows instance to a system set.
  • Create a local user and secure the credential password in Infrastructure Service

 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.


Note:  To keep blog posts manageable, we are focusing on the planning and adjustments for local account password management.  For the planning/adjustment topics related to enrollment, please review this article:

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

The article above is a pre-requisite for this session.


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 (from the enrollment lab)
    • 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).
    • 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 enrollment + local account management scenario 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.
    • Your Windows system should allow remote management using at least one management mode (see section below).
      RPC over TCP - TCP 135 inbound to the target managed Windows system.
    • If you're using WinRM over HTTPS, a PKI relationship must exist between the Centrify Connector and the target Windows system.

About Infrastructure Services Management Modes

The management mode is the protocol used between the Centrify Infrastructure Service (via a Centrify connector) to perform password management tasks like rotation of local account passwords. The current supported modes are:  Auto-Detect, RPC over TCP, SMB, WinRM over https, WinRM over http and Disabled/Not Detected.mgmt-mode.PNGIt's important to understand the expectations here:  each management mode requires planning. 

The key is to be able to perform password management operations while maintaining the correct security posture based on your environment risk assessment.  We will dedicate a full article to management modes, but to simplify our planning, we will be using RPC over TCP and here are the planning considerations:

  • We need this to work with the current version of Windows Server (2016) and due to some out of the box behavior changes (see references below).
  • We will add a firewall rule and a GPO enable management of the target
  • Windows system and the Centrify Connector and any managed local accounts.
  • Any local accounts that will be managed will be added to the Remote Management users local security group.



  • All enrollment-related activities (enrollment, settings, policies, permissions and sets)
  • Create a local account.
  • Configure the system according to our management mode strategy.
  • Register the account with Infrastructure Service and set the password under management.

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 and added to  set called  "AWS-EC2-Systems"
  • The system creates a local account called AWS-WinAdmin, adds it to the local Administrators and Remote Management Users.
  • The system adds the temporary password of the local credential to Infrastructure Service.
  • Infrastructure Service rotates the password.

Methodology:  We will use the Plan-Do-Check-Adjust methodology.





Planning Topics

Note:  To keep the blog post manageable, any of the planning topics around enrollment are removed.  Reference the pre-requisite module for these 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.
  • Will a new or an existing account be taken under management?
    In our example we will create a new account called AWS-WinAdmin.  This is not to interfere with the AWS bootstrap of the local default Administrator account.
  • What are the considerations for the target operating system version (e.g. Windows Server 2016)?
    In our example, we are doing the following:
    • Setting the account as a member of the local administrators and remote management users groups.
    • We will be updating the description of these groups to reflect our action.
    • We will be setting the "Network access: Restrict clients allowed to make remote calls to SAM" to the setting that allows the local Remote Management Users group via GPO update to O:BAG:BAD:(A;;RC;;;RM).
  • Naming convention:  How will the newly-created account be named?
    In our example, we use the AWS-WinAdmin name will be used with the full name "AWS WinAdmin managed by Centrify"
  • Settings and Policies:  are there any specific settings or policies to be put in place at the account level?
    We'll cover these in the adjustments section below.
  • What will be the management mode to be used?
    RPC over TCP.  We will add a Firewall Rule during setup to arrange the communication.
  • 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 centrify connector(s) that will be used for password operations during enrollment?
    We will be using the existing connector in AWS via IP delivered by parameter store.
    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)

The implementation steps from the previous module are needed.  Implement those and return here when ready.

  1. Add the additional parameters needed for this scenario
  2. Set up parameters (parameter store).
  3. Host Centrify CIP samples (S3-bucket).
  4. Update the PowerShell script

I. Adding additional parameters

The parameters highlighted in blue are from the previous enrollment module.

  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:

    workdir String The working directory to download the samples
    e.g. c:\CentrifyTools
    cipurl String URL of your Centrify Platform Instance.  E.g.
    zipkey String Name of the zipped file with the Centrify samples file in the bucket.
    e.g. CPS Powershell Samples
    s3bucket String Name of the S3 bucket containing your files.
    enrollcode Secure

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

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

    sets String

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

    cc_ip String or
    String List

    IP Address of your Centrify Connnector(s).  E.g.

II. Update PowerShell

Now you have to add the additional PowerShell script code snippets for user creation, group management, firewall rules, etc.

  • Base Module - 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
  • Base Module - 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")
    # additions for local account password management
    $cc_ip = (Get-SSMParameterValue -Name cc_ip).Parameters[0].Value
    Changes: Note that the only addition in this area is the cc_ip Parameter

  • Base Module - unzip the Centrify PowerShell samples
    $shell = New-Object -ComObject shell.application
    $zip = $shell.NameSpace($samples_file.FullName)
    foreach ($item in $zip.items())
    Changes: This section stays just as the baseline module.
  • Base Module - 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
    $resourceSettings = @{}
    $resourceSettings.ManagementMode = 'RpcOverTCP'
    $resourceSettings.Connectors = $cc_ip
    Enroll-CIPSystem -EnrollCode $enrollcode -FQDN $fqdn -ResourceName $instid -Endpoint $cipurl -ResourceSettings $resourceSettings -Sets $system_sets
    Changes:  In this section,  because we plan to set our credential password to 'managed' by the vault, we need to add the management mode.  In my environment, because things are split between on premises and AWS, I'm overriding the connector to be the IP of the connector in AWS.
  • This module -   create local user, define groups for addition and set the temporary password and credential
    $local_user = 'AWS-WinAdmin'
    $local_group = 'Administrators'
    $local_rusers = 'Remote Management Users'
    $entropy = ([char[]]([char]33..[char]95) + ([char[]]([char]97..[char]126)) + 0..9 | sort {Get-Random})[0..8] -join ''
    $temp_pwd = $entropy+$instid 
    $temp_pwd_secure = $temp_pwd | ConvertTo-SecureString -asPlainText -Force
    Note that although we are adding entropy to the temporary password, this will change once it's set in Infrastructure Service.
  • This module - Update the "Network access: Restrict clients allowed to make remote calls to SAM" local GPO
    $RSAMregistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
    $RRSKey = "RestrictRemoteSam" 
    $RRSValue = "O:BAG:BAD:(A;;RC;;;RM)" 
    New-ItemProperty -Path $RSAMregistryPath -Name $RRSKey -Value $RRSValue -PropertyType String -Force
    Grants the members of "Remote Management Users" the ability to perform SAM operations. This is required for Windows Server 2016.
  • This module - Create new local user, work group memberships, add firewall rule and
    # creates new user
    New-LocalUser $local_user -Password $temp_pwd_secure -FullName ($local_user + " managed by Centrify") -Description ("Created on " + (Get-Date -Format g))

    # adds to local groups - this can be a foreach loop
    Add-LocalGroupMember -Group $local_group -Member $local_user
    $grp = (Get-LocalGroup -Name $local_group).description
    Set-LocalGroup -Name $local_group -Description (" On " + (Get-Date -Format g) + " CIP added " + $local_user)

    Add-LocalGroupMember -Group $local_rusers -Member $local_user
    $grp = (Get-LocalGroup -Name $local_rusers).description
    Set-LocalGroup -Name $local_rusers -Description (" On " + (Get-Date -Format g) + " CIP added " + $local_user)

    # sets firewall rule
    New-NetFirewallRule -DisplayName "Allow Centrify Connector SAPM/PSM" -Direction Inbound -Action Allow -RemoteAddress $cc_ip

    # vaults the credential
    Set-CIPAccount -accountName $local_user -accountPassword $temp_pwd -isManaged $true
    Note that the compensating control for the remote management GPO is as follows:
    a) nobody knows the password (only authorized users at a given time)
    b) only "remote management users" are allowed to manipulate the SAM remotely
    c) the firewall rule only allows the centrify connector(s) to get the proper network layer access.
  • Base Module - final housekeeping:

    Remove-Module Centrify.IdentityPlatform.Powershell
    Remove-Module Centrify.Cloud.PowerShell.CIP
    Remove-Item $workdir -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
Does not include the system enrollment tests (for brevity).

Test Name
Test Steps
Expected Result

Account Password


1. Sign-in to the Centrify Infrastructure Service web Admin portal.

2. Go to Accounts, review the list (refresh).

You should see a local account that corresponds to the system target.


Account Usable for Remote RDP

1. Right-click on the account and select "Login"

You should be placed on the system with the account via RDP.
Password Checkout and

1. Right-click on the account and select Checkout.

2. Use the show or clipboard functions.

The password is displayed.  Use it to log in.  You should be able to log in.
Password Rotation

1. Right-click on the account and select Rotate.

The password is Rotated.

1. Click on the account and review the Activity tab.

You should see all the activities since onboarding.



Operating System.

  • The PowerShell code above works with Windows Server 2016.  The key portion of the code is the user name creation and group manipulation.  Since the New-Local user commandlets are relativel new, to simplify things you can use the WMI provider.
    $adsi = [ADSI]"WinNT://$env:COMPUTERNAME"
    NET USER $local_user $temp_pwd /add /y /expires:never
    NET LOCALGROUP $local_group $local_user /add
    Note:  Remember to add code to document the group transactions .

Considerations for Password Management

If you plan to set t

Instance Termination and Accounts

  • Termination in on-premises environments.
    A lot of the considerations here depend on the use case.  Although we don't care about the password history for cloud instances, perhaps this is not the case for an on-premises system, especially for bare-metal systems that will be reused.  For this you have the Unenroll-CIPSystem with the CleanupOnly option.  This way the system, activity and password history will still be in the system. In this case, expect to do some manual or scripted cleanup.
  • Termination of accounts in IaaS (cloud) instances.
    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).

Account Workflow and Permission Settings

The Enroll-CIPAccount commandlet supports the ability to set workflow or permissions settings.  Below are some samples for your reference.



$workflowApprovers = " [ {'Name': 'Workflow Approvers' , 'Type' : 'Role'}]"



$accountpermission = "[ {'Principal': 'Account Managers', 'PType'  : 'Role', 'Rights': 'Owner,Manage,Delete,Login,Naked,UpdatePassword,UserPortalLogin,RotatePassword'},
                        {'Principal': 'Local Account Login', 'PType': 'Role', 'Rights' : 'View,Login'}]"


  • Add logging, pauses and error handling logic  to the script.
  • Add a foreach loop for the account group membership.

Articles in this series

Referenced Articles:

2 weeks ago

Great blog. Looking forward to reading more about the Windows management modes. Quite hard to understand the differences and implement them with the limited documentation currently available.

By Centrify Guru I
2 weeks ago - last edited 2 weeks ago



Hey, thanks for the feedback.  My apologies on behalf of the pubs team.  They are working hard to migrate all help to a new platform.  


Here's what I can offer on the topic:

The Management Mode is basically the method that the platform (via the connector) will use to perform the password management functions.


The best way to illustrate is to use an example because these things change from each version of Windows given the Credential Theft protections set by default.


One way to look at this is:  What are the network/configuration things that I need to do to allow password management while maintaining the correct security posture?  Your strategy may change depending on the Windows version.


In this particular example, there are a few things done to make sure this works well with Windows Server 2016 (given that it by default closes some default behavior from Win2008R2).  So in order for me to use the preferred method RPC over TCP I needed to make some changes:


  • LSA considerations in WS2016:  First, you'll notice this code snippet:
    $RSAMregistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
    $RRSKey = "RestrictRemoteSam" 
    $RRSValue = "O:BAG:BAD:(A;;RC;;;RM)" 
    New-ItemProperty -Path $RSAMregistryPath -Name $RRSKey -Value $RRSValue -PropertyType String -Force
    Bottomline, based on this article:
    I needed to make sure I added the security descriptors for the group I wanted to be able to do remote calls to the local SAM.  In my case, this group:  $local_rusers = 'Remote Management Users'  this correlates to what was done in the script (create a new account called AWS-WinAdmin and added to the local administrators and remote management users)  => This is a user choice based on requirements.  In my case I wanted to have a single account for both shared Admin access and remote management.  These could be split.

  • Firewall rules:  To maintain the proper security posture, a firewall rule allowing all trafic (my choice for simplification) between the system and the Centrify connector is added here:
    New-NetFirewallRule -DisplayName "Allow Centrify Connector SAPM/PSM" -Direction Inbound -Action Allow -RemoteAddress $cc_ip 

For example, as you move towards the other modes:

  • Auto-detect is for manual scenarios using the wizard.
  • Disabled/Not detected means that auto-detect was not able to do what's stated.
  • SMB is there mostly for legacy reasons.
  • WinRM over HTTPS:  As the name implies, the systems must have PKI certs deployed and trust a common PKI CA structure.  This is for the WinRM protocol to be able to work over SSL/TLS.  From a config perspective, a firewall rule activation is needed, or a port if this is going to be a non-standard dedicated one.
  • WinRM over HTTP:  Same as above but with signed/sealed traffic instead of SSL/TLS, eliminates the burden of PKI.
    Note:  A proxy account can be used for both WinRM modes.
  • RPC over TCP (recommended):  This allows you to use RPC with a limited set of ports, however, as you have seen by the new WS2016 protections, note that you have to take some things into consideration.


All these will change as we introduce more of the concept of  "local admin accounts"  to all type of resource objects.


I hope this is a good start.


P.S: I will reply in the correspondin thread, but you correctly figured out that csetaccount does not support sets in the version you are using.  Coming soon.  Smiley Very Happy





Showing results for 
Search instead for 
Do you mean 

Community Control Panel