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




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\




Running dainfo at command line


Signed and Sealed - "Why port 389?"

By Centrify Contributor II a week ago - last edited a week ago

"Why port 389?"


A customer recently emailed me asking a few questions about the Unix agent communication security with Active Directory


  1.  "Why does the Centrify Unix agent (adclient) communicate with Active Directory over port 389?
  2. How is this communucation secured?
  3. What are the implications to Active Directory? Specifically, how do we protect Active Directory against unsigned/unencrypted LDAP requests?"


Typically, this question tends to come from Security/Compliance and Unix teams. From their vantage, interacting with LDAP over 389 raises a flag, where traditionally communications over this port tend to be unencrypted.  If the question comes from the Active Directory team, they are usually looking for confirmation and assurance that our interactions with Active Directory align with best practices and their secrity expecations.


1) Why port 389: The short answer is that the Centrify Unix agent's approach/design is consistent with how Windows computers and services securely communicate with AD and other kerberos principals. Explained below…
2) Secure Active Directory communication: The Centrify Unix agent authenticates and encrypts all communications with Active Directory using Kerberos (GSSAPI). This is referred to as a "signed and sealed" connection. The agent encrypts its payload using a kerberos session-key before sending over the wire to Active Directory. We do not use LDAP over SSL/TLS. This approach depends on certificates (along with the certificate management headaches that come with).  
3) Rejecting unsigned/unencrypted LDAP requests: Microsoft advises we configure servers to reject Simple Authentication and Security Layer (SASL) binds that do not request signing or reject LDAP simple binds that are performed in the clear. This AD group policy configuration ensures that “non-kerberized” LDAP client requests communicate with AD over SSL/TLS (e.g. Port 636). The following Microsoft article explains further. 

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:


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


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-YADA-YADA-CODE-682DBEF6CA78"  
-FQDN 'member.centrify.vms' -ResourceName 'member-vault'
-Endpoint 'https://vault.centrify.vms'


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.


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.


For accounts, there are several entitlements

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.



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.



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.



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.



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


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)



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.


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

How to monitor your Centrify Connectors

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

We've had the request from some customers to be able to monitor the connection between the Centrify Connector and the Identity Platform in the cloud. Sometimes, due to Internet connectivity issues, the Connectors might stay "Inactive" as you can see below, even if the service is up and running.


Screen Shot 2017-09-05 at 17.37.39.png



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


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.



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.



To capture configuration changes in Centrify Access Manager to your SIEM, you will need two things on the operating system running Access Manager 

1. Your SIEM reflector to read and send the Application event viewer to your SIEM.

2. Configure the following registry setting:


- HKLM\Software\Centrify\AuditTrail\Centrify Suite.Centrify Configuration\AuditTrailTargets (Set the value to 3.)

- OR HKLM\Software\Centrify\AuditTrail\AuditTrailTargets  (Set the value to 3.) Then delete the three child keys for HKLM\Software\Centrify\AuditTrail.


This value will write events both to the local Application event log and Direct Audit database. Events such as assigning a user to a role, creating a child zone or modifying a user's POSIX information will be logged to your SIEM.


For reference, here is the guide for all events written to the Application event log as well the syslog on Linux by the DirectAudit Agent. https://docs.centrify.com/en/css/suite2017.1/centrify-audit-events-guide.pdf

Add a custom SAML script to configure where the request should be redirected base on the platform that is originating the request on SugarCRM


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.


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.


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

The Salesforce Mobile App Configuration push deployment guide is a step by step guide on how to configure a mobile app configuration schema that pushes application settings for the Salesfore1 mobile application for iOS devices during installation. With the application configuration pushed to the mobile device the user can make use of zso without having to configure any settings on the Salesforce1 mobile app


Configure SAML single sign-on login for Watchman Monitoring® with just-in-time account creation using Centrify. 



AWS WorkSpaces "allows customers to launch cloud-based desktops that allow end-users to access the documents, applic..." a cost effective way to manage these desktops is to use SimpleAD (an AWS-hosted Samba4-based directory that provides similar capabilities as Microsoft's Active Directory), this allows for centralized administration of users, policy enforcement, and Kerberos authentication.


Identity Assurance for Cloud-based Desktops

The goal of this article is to establish a lab to test MFA capabilities using Centrify technologies. 

As per the IAM model below, the first step is making sure that users accessing your AWS WorkSpaces are who they say they are, and with Centrify you can employ a variety of multi-factor or step-up methods.




With Centrify, organizations can secure Windows Systems by providing:

  • Access control using Centrify Zone technology
  • Strong Authentication with MFA at login, screen lockout or remote desktop
  • Privilege Elevation for application or administrative desktop

A complex requirement for some organizations is to run their own Active Directory Connector and RADIUS infrastructure (see details here) however, with the Centrify Agent for Windowsand the Endpoint capabilities of Identity Service, we can provide MFA at login and screen lockout while still using Simple AD.


In this lab, we'll use the Plan-Do-Check-Adjust methodology



Planning Topics

  • Define the Authentication Factors required for AWS WorkSpaces MFA
    These could be true 2FA (Push MFA, OATH OTP, RADIUS, etc), step-up (E-mail, Phone Factor, SMS) or Multi-Secret (security question);  this defines your authentication profiles.
  • Define the use cases that require MFA:
    • At login
    • At screen unlock  - will there be a grace period?  (e.g. do not require MFA if the screen is locked less than 10 minutes)
    • At privilege elevation (if the WorkSpace is being used as a management workstation)
  • Configure which users get challenged for MFA (e.g. will there be users excempt?)
  • Will offline passcodes codes be allowed (for requiring MFA if the WorkSpace can't connect to the Centrify service? What will be the behavior of the dialog box?
  • What is the Directory architecture?
    There are different approaches for AWS-hosted (Simple AD, Microsoft AD or even your own using EC2 instances)
    Expect this to be the most important planning topic
  • How many Centrify connectors and what services are required?

 What's required?

  • Knowledge of AWS concepts: VPCs, EC2 instaces, Security Groups, Directories and AWS WorkSpaces
  • Basic Knowledge of Centrify Identity or Privilege Service MFA
  • Identity Service or Privilege Service (SaaS) configured for MFA:
    • A Role with the Computer Login and Privilege Elevation (e.g. MFA Computers)
    • An authentication profile configured for Computer Login and Privilege Elevation
    • The AWS Workspace system has to trust the IWA root certificate for the tenant
    • A Centrify connector reachable by the AWS WorkSpace(s) VPC
  • AWS WorkSpace configured and running
    • A WorkSpaces Directory (Simple AD) and administrative credentials
      Note: any Active Directory or similar technology including Simple AD or any AWS or customer-managed Microsoft AD) will technically work as long as the communication requirements are met.
    • Your end-users must be populated in the directory with information for any MFA or step-up methods (e.g. telephone, mobile, e-mail, etc)
    • At least one Windows Server 2012 R2 and up EC2 instance in a security group that allows communication with the AWS WorkSpace Directory servers (HTTPS and TCP 8443 from the WorkSpaces systems outbound to the connector)
    • The connectors security group should have outbound HTTPS and Service Bus connectivity to the Centrify Identity or Privilege service instance.
  • Software Requirements:
    • Centrify Group Policy Extensions (available from the Server Suite installation bits)
    • Centrify Agent for Windows (tm) - available from the Server Suite installation files or the downloads section of the Admin portal for Identity Service or Privilege Service.  This post uses version 3.4.2.

In this lab, we'll run a Centrify Connector in a Windows Server joined to the AWS WorkSpaces directory, this EC2 instance is in a security group that allows IWA and AD communication with the directory service and members.  Alternatively, you could run the Centrify connector in a dedicated WorkSpace.



Lab Overview

  1. Verify pre-requisites
  2. Launch an EC2 Windows Server instance, configure DNS and install Windows tools and features (RSAT-ADDS, GPMC)
  3. Join the system to the AWS WorkSpace directory and sign-in with an administrative user
  4. Create Structure in Active Directory (OUs, users)
  5. Install a Centrify connector the EC2 Instance and download the IWA Root Certificate
  6. Download and install the Centrify Windows Group Policy Extensions
  7. Configure PKI Trust and Centrify Agent Settings via Group Policy
  8. Launch an Amazon WorkSpace and download/install the WorkSpace client
  9. Configure the WorkSpace in the directory and authorize it for MFA
  10. Connect to the WorkSpace and Install  the Centrify Agent for Windows
  11. Test your configuration


Lab Diagram




1. Verify Pre-Requisites

The most challenging part of this lab is to figure out the communication paths between the systems.  In this lab we are over-simplifying the process, but in a real deployment always use the minimum set of ports needed for functionality.


  • Communications between the AWS WorkSpace directory and your EC2 instances
    Go to AWS Console > Workspaces > Directories and expand your Directory, note the Directory ID and the IP Addresses (these are the IP addresses of your DCs and DNS servers)
    Go to AWS Console > EC2 > Instances > Security Group and select the Security Group designated for your EC2 Windows instances that will run the Centrify connector service (e.g. Connector group).
    Make sure that:
    - The connector group and the directory domain controllers can talk AD communications (DNS, Kerberos, LDAP, etc)
    - The members of the domain (including AWS WorkSpaces systems) and the connector  can talk over HTTPSgroup and TCP 8443.
    - The connector group has at least outbound HTTPS and Azure Service Bus connectivity with the Centrify Identity or Privilege Service tenant.


2. Launch an EC2 Windows Server instance, configure DNS and install Windows tools and features (RSAT-ADDS, GPMC)

  1. Log in to your EC2 console console.aws.amazon.com/ec2 and launch a current Windows Server instance in the security group designated for the connectors; this instance should have at least dual core processors and 8GB of RAM.  In addition it should have outbound internet connectivity  (direct or via proxy). 
  2. With the information collected about the AWS WorkSpace directory (the IP addresses of the directory servers), open the Network control panel (ncpa.cpl) and modify the TCP/IP properties of the network card.  In IPv4, add one of the IP addresses of the directory DCs as the primary and secondary DNS server entries for the EC2 Windows instance.
    To verify connectivity, ping the domain, you should receive a response.  Note that this can be also accomplished with a VPC option set.
  3. Open an administrative PowerShell, and add the AD remote admin tools as well as GPMC.
    Install-WindowsFeature RSAT-ADDS, GPMC

3. Join the system to the AWS WorkSpace directory and sign-in with an administrative user

  1. Join Active Directory using the System Applet or PowerShell
  2. When prompted, provide administrative credentials to the AWS WorkSpaces directory.
  3. When prompted to reboot, select yes, and reconnect to your system
  4. Sign-in with a directory privileged user (e.g. administrator)
  5. Verify that you can open the domain administrative tools like Active Directory Users and Computers (dsa.msc) and GPMC.msc

4. Create Structure in Active Directory (OUs, Users)

Note:  These steps will be described at a high-level.

  1. Open ADUC (dsa.msc)
  2. Create 2 OUs, one for the WorkSpaces computers, the other for the test Users (e.g. Staff)
  3. In the Staff OU, create your test users.  Make sure you populate the information required for your MFA challenges (e.g. email and mobile number.  I created two users: Lisa and Diana.
  4. Stay logged in as a domain administrator.

5. Install a Centrify connector the EC2 Instance and download the IWA Root Certificate
Note: for detailed steps to install a Centrify connector.  Check out this help article.

  1. Sign-in to your Centrify instance as a privileged user (e.g. https://example.my.centrify.com)
  2. Go to Admin Portal > Settings > Network and click Add Centrify Connector
  3. Click on 64 bit, this will start the Connector download.
  4. When downloaded, double-click and follow the wizard for setup (you don't need mobile tools), when finished the configuration wizard starts.
  5. Provide the Centrify tenant information and credentials, then follow the wizard (you don't need the activation or deleted items option).
  6. Verify that the Centrify applet displays a succesful connection.
  7. Go back to the Centrify Admin portal and under Settings > Network  >  Centrify iwaroot.pngConnector, press refresh on your browser.  You should see the newly-installed connector on the list, double click it and go to IWA Service, then click on the "Download IWA root CA Certificate" link, this will download the tenant's Integrated Windows Authentication certificate.  This is required for the client to communicate to the service.

6. Download and install the Centrify Agent and the  Centrify Windows Group Policy Extensions

  1. In the Centrify Identity or Privilege Service, go to the Admin Portal
  2. Click the administrator's name on the upper right corner and select Downloads and click Centrify Agents
  3. Download the Centrify Agent for Windows and the Centrify Windows Group Policy Extensions
  4. Double-click the Centrify Windows Group Policy Extensions and follow the wizard until the installation is complete.

7. Configure PKI Trust and Centrify Agent Settings via Group Policy

In this section, we'll distribute the IWA trust root certificate from the tenant using GPOs; we will import the GPO templates for the Centrify Agent for Windows.


  1. Open GPMC and expand your forest/domain
  2. Right click the WorkSpaces OU and select "Create a GPO in this domain and link it here" and give it a name
  3. Right-click the newly-created GPO and select Edit, this opens GP Editor.
  4. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities and right click the white space in the right pane, select Import
  5. In the Wizard, press next and then press browse to the location of the IWA Trust certificate from the previous section.  Once completed, you'll have the certificate for the tenant in this store.
  6. Now, navigate to the Configuration > Policies > Centrify Settings
  7. Right-click Centrify Settings and select Add Remove Templates, then press Add
  8. Select centrify_windows_settings, press Open, then Press OK.
  9. Expand Centrify Settings > Windows Settings , you should have 2 sections:  Common and MFA Settings
  10. Expand MFA Settings and on the right side, double-click "Specify credential providers to exclude from the logon screen" and enable the policy.  In the box, add this string:  {003D4E42-9B59-4818-9352-17B3F5D4ACAF}, to the beginning of the list (note the comma separator at the end).  This will exclude the credential provider installed with AWS WorkSpaces.
    Note: this step alters the connectivity behavior of the AWS WorkSpaces under that OU.  This means that the Windows Credential provider will be displayed after connecting to the WorkSpace.
  11. Leave GP Editor open, we'll return to it to make some tweaks.

8. Launch an Amazon WorkSpace and Download/Install the AWS WorkSpaces client

  1. Go to your AWS Console > WorkSpaces > WorkSpaces > Launch WorkSpaces
  2. Select a Directory:  pick the directory you are working with and press Next Step.
  3. Identity Users > select search for users (e.g. Lisa or Diana), check the box and Press Next Step
  4. Select your bundle > pick your product (e.g. Windows 10 Standard)
  5. WorkSpaces configuration > pick the options as needed, press Next Step
  6. Review and launch > review and press Launch.  You may have to wait up to 20 minutes at this step.
  7. In the meantime, you can download and install the WorkSpaces client.  You can obtain them from here:  https://clients.amazonworkspaces.com/
  8. Follow the instructions to install the WorkSpaces client in your platform.
  9. When the WorkSpace is available, note the registration information and register with the AWS WorkSpaces client, before connecting, continue to the next section.

9. Configure the WorkSpace in the directory and authorize it for MFA

  1. Monitor the WorkSpaces until the system is listed as available.
  2. In your connector Windows system, open ADUC (dsa.msc)
  3. Go to the computers container, you should have a new system aside from the connector (e.g. IP-C0A8F12F)
  4. Move the computer object to the WorkSpaces OU.  (Note, this can be automated)
    This will ensure that the GPO will apply to the WorkSpace.
  5. Now, sign-in to Identity or Privilege Service > Admin Portal > Core Services > Roles > [select your role; e.g. MFA Computers] > Members > Add > Check computers and search for the system name, when you find it check it and press Add, then Save.
    Now the system is authorized to do MFA requests.  The next step is to connect to our WorkSpace, and install the Centrify Agent for Windows.


10. Connect to the WorkSpace, Refresh GPOs, Restart and Install  the Centrify Agent for Windows

  1. Connect to your WorkSpace
  2. Since the Credential Provider is disabled, you may have to re-auth after connecting.
  3. Open a command window and type gpupdate /force, then reboot the system. 
  4. After reboot, reconnect to the system and log in as the test user
  5. Browse to the location of the installation bits for the Centrify Agent for Windows and shift+right click > Run as a different user > log in with a domain privileged user
    Welcome page > press Next
    EULA page > check the box and press Next
    Destination Folder > press Next
    Ready to install > press Install
    Completed page > press finish.  This will start the configuration wizard.
    Note:  the configuration steps below can be set via Group Policy.
  6. Press Add Service, at this point, depending on the information in AD, the services are visible
  7. Select 'Centrify Identity Services Platform'  and Press OK
  8. Select your tenant instance
  9. Multi-factor authentication on Windows login > Enable > Press Add > select your test users (e.g. diana, lisa), press Next
  10. The platform will attempt to enroll the system.  If the IWA Root Certificate for the Centrify tenant was installed succesfully via GPO refresh, this should be fine; if not, an error indicating this will be displayed.  You can, alternatively import the IWA root certificate manually into the trusted root certification authorities for the system.
  11. The installation will prompt to reboot.  Reconnect to start testing.


Checking Functionality (Testing)

Here's a quick test matrix:

  • Verify MFA at login
  • Verify MFA at screen unlock
  • Verify no MFA challenge if screen unlock is under defined grace period
  • Verify MFA with offline code if connector(s) are not available


Adjusting (Improvements)

Here are the potential improvements for this setup:

  • Add additional Centrify Connectors for High-Availability
  • Use WorkSpaces Application Manager to deploy Centrify Agent for Windows (tm) automatically
  • Use Group Policy to define which users are required multifactor
  • Use Group Policy to define if MFA will be required during Windows unlock.


Video Playlist

 Other Resources



Step 1. Use Apple Configurator 2 to create the desired WiFi setting, then export the profile.

1. Launch Apple Configurator and select File > New Profile.

2. Enter a display name for the profile in General. 

3. In the left column, select WiFi, click the Configure button, then enter your WiFi settings.

4. Once you have completed your configuration, go to File > Save.


Step 2. Upload the saved mobileconfig profile into your domain controller: \\yourdomain\SYSVOL\yourdomain\mobileconfig Create this directory if it does not exist.


Step 3. Specify the profile in one of the following GPO settings to apply the WiFi settings:

  • Computer Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings > Install MobileConfig Profiles or
  • User Configuration > Policies > Centrify Settings > Mac OS X Settings > Custom Settings > Install MobileConfig Profiles



For more details on computer configuration or user configuration.


Other settings to consider:



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.


This tech blog explains how an Administrator can extend Active Directory to include Exchange server specific Active Directory Attributes, to use some additional Exchange specific features with Office 365, even though Exchange server is not/was not installed on premise.


Use case is to find out the most launched application ( last 30 days) and within that find the Person who used/launched  that application with existing tools. 

Prerequisites   :           

  1. Need to have Analytics Entitlement.
  1. If you do not see one please request one from your account representative.

[HowTo] - ServiceNow for Automated DirectAuthorize Validation

By Centrify on ‎06-30-2017 02:05 AM - last edited ‎08-11-2017 06:47 AM



This technical blog post [with Video] serves as a follow-up to a previous lab "Integrating ServiceNow Approvals to Centrify-enhanced sudo using the dzdo validator."


Device is enrolled in External MDM 

Application's like  "ServiceNow" are managed by Centify Identity Service

Users want to use Native "Servicenow" application on their Mobile Devices and achieve SSO


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.


This article explains how to log out of CIS using an API command. Additionally two ways are shown to meet this goal.

The first obtaining the content of the cookie of the internet browser and the second using the application Postman.


Talking about our supported local clients for remote sessions, one of the quetions I often get back is, "What about PowerShell?".  In this post I will demonstrate how to launch PowerShell sessions from the Centrify cloud platform using PowerShell Web Access (PSWA).




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






In this article, I'll discuss the methods that I use to capture and troubleshoot a new custom User-Name Password Application.


How to deploy Safari extension to Mac using Centrify

By Centrify Advisor III on ‎06-14-2017 01:43 AM - last edited ‎06-14-2017 01:37 PM

**Disclaimer: The deployment will depend on the version of macOS/Mac OSX and safari and might not work in later version**


Please find the below steps in making use of Centrify Group policy and apple script (scripts are provided as a sample and you can modify it to fit your environment need):


1. Use “Computer Configuration > Centrify Settings > Common UNIX Settings > Copy Files” Group Policy to copy over the centrify.safariextz(at the time of written, it is of version 1.150.17052 and please replace the newest if there is any), safari-ext.sh and safari.scpt to the following location on Mac: /tmp/


2. Please set the file permissions to 0755 and the owner UID and GID to 0.


3. Please also check the box for “Copy as binary” in the GP.

Screen Shot 2017-06-14 at 4.22.56 PM.png



4. Use “Computer Configuration > Centrify Settings > Common UNIX Settings > Specify command to run” Group Policy in order to run the safari-ext.sh: “sudo /tmp/safari-ext.sh”, it is used to enable the GUI scripting for applescript.

Screen Shot 2017-06-14 at 4.24.53 PM.png


5. Use “Computer Configuration > Centrify Settings > Mac OS X Settings > Scripts(Login/Logout) > Specify multiple login scripts” Group Policy in machine level for the script safari-ext2.sh. It is used to run the applescript.

Screen Shot 2017-06-14 at 4.24.19 PM.png


6. Once done configuring the 3 GPs mentioned above, please run adgpupdate as the AD user, then the extension will be installed at next user login session.

How To: Configuring Confluence with a Custom SAML App


The following is a description on how to configure  Confluence (Cloud) with Centrify via SAML:


  • Centrify Configuration:
  • Confluence Configuration:
    • Navigate to the SAML configuration within Confluence, found under "User Management."
      • Choose "SAML single sign-on" Under "Authentication Method"
      • Under "Identity Provider Entity ID" copy and paste the "Issuer" URL from the Application Settings page in the App Config within The Centrify Identity Portal.
        • To get this value, navigate to To get the value, navigate to Admin Portal > Apps > Confluence SAML App > Application Settings, and copy the URL under "Issuer."
      • Under "Identity Provider SSO URL" copy and paste the "Identity Provider Sign-in URL" from the Application Settings page in the App Config within The Centrify Identity Portal.
        • To get the value, navigate to Admin Portal > Apps > Confluence SAML App > Application Settings > Identity Provider Info > and copy the "Identity Provider Sign-in URL"
      • Under the "Public x509 Certificate" copy/paste the value of the "Signing Certificate" from the Application Settings page in the App Config within The Centrify Identity Portal
        • To get the value, navigate to Admin Portal > Apps > Confluence SAML App > Application Settings > Identity Provider Info > "Download Signing Certificate".  After downloading the .cer file, open it up in a text editor application.  The certificate starts with ----BEGIN CERTIFICATE and ends with ----END CERTIFICATE----.  Copy all of the text in the file.

This completes the configuration of Confluence in both the Centrify Admin Portal, and the Confluence Portal.  After performing the steps above, you're ready to test your configuration.  Log into the user portal with a confluence user, and launch the app.  


For more information regarding the Confluence configuration, please see here:




As always, let us know if you were successful in configuring Confluence for SAML by commenting below.

FileVault 2 allows encryption of an entire drive to keep data secure. The Centrify Identity Service, Mac Edition gives you the ability to enable FileVault 2. This feature is enabled in a policy for enrolled Mac OS X devices.

Enabling FileValut 2 encryption using a policy at the Admin portal does not require a user to manage the computer object in Active Directory. It also does not require a mobile account to be created.


The below steps will show you how to enable the FileVault encryption policy, enroll the Mac OS X device and locate the recovery key.


Enable the FileVault encryption policy


To enable the FileVault encryption policy, go to the Centrify Admin Portal > Policies > Default Policy



In the Default Policy, go to Mobile Device Policies > OS X Settings > Security and privacy settings


Enable FileVault.png 





Note: If you select Permit one-time display of recovery key on user’s Mac device, admin users see their recovery key the first time they log in after you enable the FileVault encryption policy. This is the only time users see the recovery key. 


Save the changes.


Enroll the Mac OS X device


On the Mac OS device, log into the Centrify User Portal. You will be prompted to enroll the device

Enroll with Centrify.png




The download of the Centrify for Mac agent will begin


Download begins for Centrify Agent.png




On the Mac system, log in as the local admin and install the Centrify for Mac agent by double clicking on the .dmg file


Install begins of Centrify Agent.png




Double click on CIS-Mac-Agent.pkg file to open the installation package



Double click to open the package.png


A warning will appear regarding the software installation

 Install Centrify Agent.png




At the Welcome page, click on 'Continue' to begin the installation


Click here to begin installation.png




Click on Install to begin the installation

Click on Install.png


Enter username and password of the local admin account to install the software


Enter local admin password.png



The installation will complete. Click on 'Launch Centrify Agent' to begin the device enrollment.



Installation complete.png



A confirmation message will appear for the successful install



Installation confirmation.png



Enter the Centrify Directory Service or Active Directory username of the user that you would like to enroll the device for


Enter username to enroll.png




Enter the password of  Centrify Directory Service or Active Directory user


Enter password.png




Click Enroll to begin the device enrollment


Click on Enroll.png



Enter the username and password of the local admin account


Enter local admin password enrolling.png


The device enrollment will begin


Device enrolling.png



Configure Safari for Single-Sign On


Configure Safari.png




The Safari Single Sign-On configuration will show as completed

Configure Safari complete.png






FileVault encryption is applied to enrolled devices when an administrator logs in. Encryption begins when the device is reset following an administrator log in. Only OS X users with administrative privileges can encrypt an enrolled device.

Refer to https://support.apple.com/en-us/HT204837 for more information about FileVault.



3) Wait about 15 minutes and log out as the local admin. You will then receive a prompt to enter the FileVault password


Enter FileVault password.png


If you have enabled "Permit one-time display of recovery key on user’s Mac device", you will receive a prompt showing the recovery key


Filevault Key.png


After reaching the desktop as the local admin, go to Finder > System Preferences > Security & Privacy. Got to the FileVault tab and the FileVault encryption will show as encrypting



FileVault begin.png



When the encryption has ended, the status will show as finished


Encryption end.png





Locate the recovery key


After the FileVault encryption policy is pushed and an enrolled device’s FileVault is turned on, you can retrieve the recovery key by selecting Show FileVault Recovery Key from the device’s action menu in Admin Portal. Please allow up to 12 hours for the key to appear at the Admin Portal.



FileVault Key Admin Portal.png





The device details should will show that File Vault 2 is enabled


Device Details Enabled.png



This confirms FileVault 2 has been enabled using the Centirfy Identity Service Admin Portal on a Mac OS X device.


You can also enable FileVault 2 using Group Policies. Please see the below article:



This article is the first of a multipart series. Part I will cover the following:

  • The effect the current threat landscape is having on the business
  • Why access control is not enough
  • The benefit provided by active log monitoring solutions
  • How SIEMs help.

Showing results for 
Search instead for 
Do you mean 

Community Control Panel