Best practice for security questions

By Centrify Advisor III 3 weeks ago - last edited 2 weeks ago

Security questions are like a second password prompt. Just like passwords, users tend to create weak or easy to guess answers. Unlike passwords, security questions usually do not have policies to enforce complexity, uniqueness and guessability.


Here are some tips to help make your security question answers stronger:

1. Use a non-corresponding answer.

Using an answer that does not correspond to the question will make it harder for unauthorized users to guess or find your answer. For example, if the question is your first car model, answer with "blankcowblueYogurt". If the question is your mother's maiden name, don't use your mother's maiden name as the answer. Your mother's maiden name might be easily acquired through social media, social engineering, stolen records, public records, malware, easily guessed or many other methods.


2. Avoid answers that are vulnerable to social engineering.

Even if you use a non-corresponding answer to a security question, unauthorized users may still randomly attempt to use information that could be acquired through social media or social engineering such as the name of your child, pet, school, or company.


3. Follow password complexity rules for your answers.

Security questions are just like a second password. Hackers may use brute force or dictionary attacks on a security question. Following password complexity rules can help to make your security question answers more secure.


An easy to remember and yet complex answer is to use four random words like "blankcowblueYogurt".




4. Use spaces if possible.

Older generation brute force and dictionary attacks don't account for spaces. For modern tools, it can make it longer and harder to crack if there are spaces. Add a space in your answer if allowed. "blank cow blue Yogurt"  


Centrify MFA can use security questions for:

  • AD password reset / account unlock
  • Computer login (Windows / Linux / Unix)
  • Privilege elevation (Windows / Linux / Unix)
  • Remote access through Centrify's password vault.
  • Password checkout for shared privileged accounts.
  • AWS Workspaces
  • Horizon View
  • Accessing a web application
  • Accessing the Centrify User and Admin Portals. 
  • VPN access

Centrify users can set up their security question(s) through the Account tab in the Centrify User portal.

[HOWTO] Automate Reporting & Analytics Using External Provider Tools {Google}

By Centrify on ‎12-31-2017 02:42 PM - last edited 2 weeks ago

Through exposed Centrify APIs we're able to send our data to wherever it needs to go


OAuth 2.0 is the industry-standard protocol for authorization...


Employee on-boarding, transitions and departures often require manual and time consuming user administration tasks performed between HR and IT. Generally, identity originates in the HRIS system when the candidate becomes an employee. Coordinate between HR to IT is done such that, IT can create accounts for the new hire in Active Directory and every application required for their job. Similarly, during a transitin or departure, HR coordinates with IT to modify or disable access in Active Directory and every application. 


With an integration to Centrify, Workday can serve as the master employee database within the enterprise. New hires, transitions and departures are managed by HR within the HR system while Centrify automatically provisions or de-provisions accounts into Active Directory and downstream productivity applications. Specific benefits include: 


  • Automatic provisioning of new hires in Workday to Active Directory.
  • Randomly generated Active Directory password automatically emailed to new hire.
  • Automatic account updates (e.g. promotions, department changes) of employees in Workday to Active Directory.
  • Automatic disablement of users in Active Directory when terminated in Workday.

Here is a demo video of how the integration can help streamline user administration in your enterprise: 



See this work within your environment by registering for a free 30 day trial here.

custom login screen.png

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


1. Log into your Centrify Admin Portal.

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


3. Enter your preferred unique name that is not used by another Centrify customer, then press Save. For example

custom name.png


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

Centrify User Portal:

Centrify Admin Portal:



How to secure shared web accounts

By Centrify Advisor III ‎10-24-2017 09:39 AM

Securing shared web accounts such as the firewall web administration console's default admin account, AWS management console's root account, corporate FedEx account, or company social media accounts (eg. Twitter, Facebook) helps to meet regulatory compliance, improve security, prevent insider attacks, and deny access to former employees. Centrify can secure your shared web accounts by

  • Providing login access to shared web accounts to assigned users without exposing the password to users.
  • Limiting access to only specific users or group.
  • Requiring multi-factor authentication or blocking access based on time, location, device or user behavior.
  • Switching to SAML authentication


Provide login access without exposing the password

1. In the Centrify Web Portal console, select Apps in the left column, then click on the Add Web Apps button.

Add web apps.png

2. Search then add your web app. If you cannot find your web app, go to the Custom tab, scroll down until you see User-Password, click on the Add button next to it, then click Close.

custom user-password.png

3. Complete the required configurations for Applications Settings and Description.

4. Go to Account Mapping and select Everybody shares a single user name. Enter the shared username and password and press Save.

shared password.png

When you update the password in this setting, it updates the password for everyone without the need to tell users what the new password is, and minimizes password exposure risk.

5. Configure User Access and press Save. Assigned users can access the shared account from the Centrify User Portal, by clicking on the app icon without entering the shared username and password.


If your website is not in the Centrify app catalog and it does not work out of the box with the custom User-Password template, you can try using:

  • Infinite Apps to add sites that have additional login fields such as department or company ID.
  • Custom > Browser Extension for sites that have the username and password fields on different pages.


Limiting access to only specific users or group

In the Centrify Admin Portal, create a custom role in Roles (eg. DevOps, IT security, HR, Finance...) then assign the role to your web application. You can also assign the web app to roles by configuring User Access.


Assigning the web app to a role, enforced role-based access control to your shared password. Users not in the assigned role will not see the web application in the Centrify User Portal. Each role should see a different set of web applications.

different user portal view.png


Blocking access or require multi-factor authentication base on:

 Switch to SAML authentication

Take advantage of SAML authentication if the web application supports it. SAML offers many security benefits including:

  • Not storing or using a password to authenticate to prevent passwords from being compromised by malware, WiFi vulnerabilities, or attacks on the web application.
  • Logging in as yourself to provide better accountability to help track who logged in when, and who made what changes.
  • Not having to manage password changes. 

Other topics to consider:

Securing local or default administrator accounts on servers and network appliances.

Role-based access to the Centrify Identity Platform can be applied to help meet regulatory compliance and improve security by:

  • Customizing which web applications are displayed in the Centrify User Portal
  • Limiting access to privileged account passwords
  • And granting different levels of administrative rights to the Centrify Identity Platform

Roles in Centrify can be composed of users, groups and other Centrify roles from

To create and configure a Role in Centrify

1. Log into the Centrify Admin Portal, go to the left column and navigate to Core Services > Roles. 


2. Click on the Add Role button.

3. Enter a name for the Role.

4. Select Members, then click the Add button.

5. Enter keywords in the search field to display the desired user or group.

Adding users.png 

6. Select the desired user or group and click Add.

7. Select Administrative Rights to add Admin Portal rights to the role.

8. Select Assigned Applications to assign web applications to the role. 




Categories and Tags

By Centrify on ‎10-16-2017 07:09 PM

In the last post I mentioned naming conventions, which is a great way to organize your work and ensure you are doing the right thing. Another item you can do to make your administrative tasks easier is to use Application Categories, as well as to teach end users how to use tags to organize their own views.


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


Sample Data Suggestions for Centrify's Core Services

By Centrify on ‎10-06-2017 12:21 PM - last edited ‎10-09-2017 04:36 PM

When Centrify built its Infrastructure Services product, implementation engineers came across many things that made it far easier to get the job done in the field. Through this field tested experience, Centrify built a script for that solution to automatically build sample OU's, groups, and content in Active Directory to make it far easier to manage the Centrify solution.


In our App Management solution however, there is a lot of flexibility on how you might build things, and sample data doesn't exist in this area. Because of this fact, this article will offer a few suggestions on sample data and practices which may make your experience with the Centrify solutions easier.


Sample Roles

In order to set up roles, it is good to understand the components of a role in the system. Within each role you have four key elements where you can specify data, or select options. Those elements are:


  1. Description - This is where you name your role, and describe it's function.
  2. Members - This is where you add users or groups to your role for whom the role has an effect.
  3. Administrative Rights - This is an optional selection, but where you can define what rights the role grants in the system.
  4. Assigned Applications - This is the Core of App management, where you assign apps to the role for users to use.


Here are some suggestions for each of these elements to help you make the system easier to use, as well as to better document your system for new users.



In the description section, there are a few things you should know. In the current version of the Centrify solution at the time this article was written, version 17.8.169 is the current version of the cloud solution. In this version and older, you cannot rename roles. In future yet to be released versions, you CAN rename a role. This is an important feature for a few reasons.


The first reason why this is important is simply for your ongoing maintenance. You may change a role periodically and not want to change all the elements of a role. As systems evolve, this is only natural. But there is another reason which is confirmed in one service, and possible in others.


The second reason is that when you federate systems, such as Centrify with your AWS environment, you will discover that you may need to select a role from within the external solution and add OUR role to their role. AWS actually has a system limitation (again, at the time of this writing), where the Centrify Role cannot have any spaces in the name. So in the event that you walk through the step by step procedure for creating the integration into another system, and you do all the member, admin rights, and assigned apps, only to find out later that the name doesn't fit the naming convention, you can at least change that in the upcoming version.


Naming Roles

Now, on to a documentation point regarding the Description Element. Naming your roles effectively will make your life a LOT easier when you implement the Centrify Solution. It is pretty clear that you can pick descriptive names, but an enhancement to this is to actually categorize your roles ahead of time. This can be a department, capability, or right the role grants to users. Now getting to how to name a role based on apps is not too hard, but let's put that off to later. The first way to identify the categories for your roles has to do with the Administrative Rights you may use with each role.


When you first build your roles, I would suggest you consider creating one role for each administrative right, just so you can put a user in that role and test out exactly how each one functions. Many are obvious, so this may become redundant. However, if you look at all the administrative rights, they actually group into a set of categories Naturally. Here are those categories starting from the top of the list when you open the dialog box to select:


  1. Device Management - There are 3 Administrative rights associated with Device Management, and define how users can interact with the Device Management features of the product.
    1. All
    2. Enroll on Behalf of Others
    3. Limited
  2. Privilege Service - There are four Administrative Rights related to Privilege Services, and these actually describe the levels of access and views into the Privilege Service.
    1. Administrator
    2. Power User
    3. User
    4. User Portal Access
  3. System Management - There are 8 Administrative Rights that focus on Systems Management. These Administrative rights are intended to control how users can administer the system and it's capabilities.
    1. Applications
    2. Federation
    3. Linux System Enrollment
    4. RADIUS
    5. Register Connector
    6. Reports
    7. Roles
    8. Users


Description Field

Now you will note, I didn't explain any of these features. This is because it is already very well documented in our help system. My recommendation to you is to have you actually leverage that help system when filling in the Description field in the Description element of the role.


Description Field Populated.png 


Administrative Rights

To get this description, you would have to click on the Administrative Rights item on the left, and hit the Learn More, as you can see below:

Description Field Image.png

That will launch you into the help system, where you will find all of the descriptions for each Administrative Right:

Administrative Rights.png

Just copy the text from under the "Associated permissions" column, and paste it into the description field of the Description Element. This will create a tool tip float as well that will allow you to float over the role in the "Roles" menu, where you see all your created roles, and you can then read the complete description when it pops up for each documented role.

Sample Roles.png


In the next article, I will complete the discussion on Roles, and then move on to other naming elements, and also using Categories and Tags.


By default, Centrify automatically populates the username field with the User Principal Name for SAML web logins. However some web logins use first name space last name (eg. John Smith) instead of the full UPN format (eg. 


To configure your web app in Centrify to autopopulate with the user's first name (space) last name:

1. Edit your web app and go to Account Mapping.

2. Select Use Account Mapping Script and enter the following into the script field:


LoginUser.Username = LoginUser.FirstName + " " + LoginUser.LastName;



3. Press Save.



Related articles:

How to configure Centrify to use short name or samAccountName for web application login

Custom Web App template for OpenID Connect allows you to easily connect to MuleSoft...


mulesoft banner.png


Screenshot 2017-09-28 16.47.36.png


Custom Web App template for SAML allows you to easilly connect to Pivotal Cloud Foundry...


Screenshot 2017-09-27 19.04.54.png


Often times we get asked by our customers how to get a list of SNC enabled users in SAP ABAP for licensing purposes. Here is a command that can be used to retrieve such list.




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



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


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-WHERE-YOUR-CODE-GOES"  
-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.

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


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. 


[Labs] Using Centrify MFA to secure AWS WorkSpaces with Simple AD

By Centrify Guru I on ‎07-08-2017 09:30 PM - last edited Wednesday


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.



Applies to:  Centrify Agent for Windows 2017.1 to 2017.3 and AWS Workspaces Client

Last verified:  February 2018


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 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.
  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:
  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 > specify a privileged account  (This is because the user assigned to the workspace will not be able to install correctly)
    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:



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.


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


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




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), 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 “sudo /tmp/”, 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 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.

Showing results for 
Search instead for 
Do you mean 

Community Control Panel