This article is the third part of a series to show how to integrate Symantec VIP with the Centrify Identity Platform. The first part of this series discussed the value of this integration and walked through the end user experience at a high level. The second part of the series covered the pre-requisites, architecture, and setting up the Symantec VIP solution to act as the RADIUS server for this integration. Please review parts I and II before you read this article to get the full context of the integration and the value it provides to the business.


To review the first article in the series you can view it here.
To review the second article in this series you can go here.


Part III will cover the following:

  • Setting up Centrify Identity Platform to act as the RADIUS client to the Symantec Enterprise Gateway RADIUS server.
  • Testing the MFA at portal login to ensure it uses Symantec VIP


  • This posting is provided "AS IS" with no warranties and confers no rights.
  • This is a lab entry. It is only meant to show the reader one method for this integration and to provide an informal how-to guide on setting it up.
  • It's not meant for production design and does not address things like high availability and separation of duties.
  • Production designs require planning for people, process and technology.
  • Symantec VIP is a registered trademark of Symantec.
  • The versions of software used in this guide are supported as of 2018. There is no guarantee that future versions of the software released by the vendors will be compatible for this integration. Its always best practice to validate new versions of the software through official support channels.


  • Please review the pre-requisites in part II of this blog series here

This article focuses on the configuration of Symantec VIP to provide MFA (multi-factor authentication) for the Centrify platform policies and assumes that you have familiarity with Symantec VIP Access manager and the Centrify Identity platform. The article does not go into detail on how to set up the Centrify platform or Symantec VIP because there is a lot of documentation publicly available that covers these topics. This article also assumes that you read parts I and II of this series.

Let's get started by presenting the same diagram we showed you in part II as a refresher. We are going to be configuring the Centrify side of the diagram in this article.


Step 1

  • Let's set up the Centrify portal side of the integration. This step is assuming you have valid Centrify tenant created and you have already installed a Centrify connector that has a line of sight to your Symantec Enterprise Gateway server. Refer back to the architecture diagram above to see what I mean. 
  • Create a test Authentication profile that is going to use a 3rd party RADIUS server for authentication.Screenshot 2018-05-21 22.12.13.png


Step 2

  • Give the authentication profile a name and select 3rd party RADIUS authentication as one of the challenges. Configure the profile to challenge for the VIP token first and the password 2nd to prevent account lockouts.


Screenshot 2018-05-21 22.12.43.png


Step 3


  • Next, create a connection to the Symantec RADIUS validation server that we will be fulfilling the authentication request. You can do this under the Authentication section in Settings as shown below.



Screenshot 2018-05-21 22.13.57.png



Step 4

  • Give the RADIUS server a name and enter in the hostname or IP address of the Symantec Enterprise Gateway (which is going to be listening for RADIUS connections)
  • Specify the RADIUS port that the RADIUS server is listening on and input the server secret that was used in the Symantec Enterprise gateway configuration
  • Select a user identifier attribute of EmailAddress. The user identifier attribute is what enables Symantec Enterprise Gateway to look up your user to validate that they are entering the right code. So this setting is important to ensure the lookup occurs accurately. In my case, my user attribute mapped to my Symantec VIP service is my email address in my Active Directory.
  • Note: You can use other user attributes and you can configure Symantec Enterprise Gateway to look up an attribute in AD directly. These alternate configuration options are not covered in this blog but there is some flexibility in how you perform the user mapping between the 2 solutions. 


radius server settings Screenshot 2018-05-21 22.14.33.png




At this point, you have created a Centrify authentication profile that will use a 3rd party RADIUS server (i.e. Symantec Enterprise Gateway) and you have also created a 3rd party RADIUS server connection (also Symantec Enterprise Gateway) that is listening for RADIUS authentication requests on the port that we specified. Next, we will create the Centrify authentication policy that will generate the authentication request when we want to use Symantec VIP for authentication. 


Step 5


  • Create a new policy that will challenge the user with the new authentication profile we created.
  • Under Core Services, create a new policy and under policy settings, apply the policy to a test role in your environment. The members of this test role should have a Symantec VIP token available and registered in the VIP Access manager service. An example policy is shown below:



 policy settings Screenshot 2018-05-21 22.16.38.png



 Step 6


  • Next, under the same policy, find the “Login Policies” section as shown below.
  • You have the option of configuring a login policy for login to the Centrify portal, UNIX and Windows Servers, and Windows Workstations.
  • We will configure the login policy for the Centrify Portal as an example. Simply enable authentication policy controls and define the Default Profile as the VIP authentication profile that we created earlier.
  • NOTE: The Authentication Rules can further define when the user will be challenged using situational awareness. This is also known as adaptive authentication. You can use static rules (i.e. the user is not coming from my corporate IP) or you can use dynamic risk scores (i.e. the user is coming from the right IP and the same machine we registered with the user, but he is logging into an application he has never used before) to adaptively challenge the user for MFA. This is the real power of using the Centrify platform to drive the policy with a 3rd party MFA provider.  


Screenshot 2018-05-21 22.17.37.png


Step 7


  • Configure the User security policy to enable 3rd party RADIUS authentication as an available option for the users that this policy applies to. 
  • With this setting, you are telling Centrify that the specific users that this policy applies to are allowed to use the 3rd party RADIUS authentication server (Symantec VIP in this case). This ensures that not everyone is driven to this authentication server if they don't need to be. 


Screenshot 2018-05-21 22.19.17.png




Ok, that's it! Now you should be ready to test. Get your Symantec VIP token out and go to the Centrify portal login page and login with your test user.


portal login Screenshot 2018-05-21 22.25.17.png


Press Next and you should see the option to login with the Symantec VIP authenticator. Enter the passcode displayed by the Symantec VIP authenticator token.

 symantec vip IMG_0004.pngvip code entry Screenshot 2018-05-21 22.25.43.png


Press Next and you will now be challenged for a password (since this is the order that we set in our authentication profile above).


password entry Screenshot 2018-05-21 22.26.08.png


Press Next after entering your password and voila! If everything worked, you should now be logged into the Centrify portal and you were able to authenticate with the Symantec VIP token for MFA. Now you can go about using single sign on to your corporate applications or go into the Administration section to manage your privileged identity management systems and resources.


infrastructure homepage Screenshot 2018-05-21 22.27.07.png





Thanks for following along with this three-part blog series. To recap, this blog series walked through the process of using the Centrify Identity platform to drive the authentication policy that leveraged the Symantec VIP infrastructure for MFA. The benefit of this integration is that if you are a Symantec VIP customer, you can maximize your existing Symantec VIP tokens for MFA to provide identity assurance to applications and infrastructure by driving the policy through the Centrify identity platform. This allows you to use a common set of security policy to provide MFA for web applications, server login, workstation login, privilege elevation, password checkout, and much more. It also allows you to take advantage of the Centrify platform without having to rip and replace your existing MFA provider. I hope this blog was helpful. 

How to configure SSO for Inormatica Intelligent Cloud Services using SAML...


Learn the basic of Microsoft Red Forest and how Centrify can be used to provide a more effective security strategy.


We will cover how to secure FortiGate Administrator access using Centrify MFA. We will be using an Active Directory user that is federated to Centrify to log in to a FortiGate as an Admin user and prompted for MFA at both CLI and Web GUI login.


As customers move more and more to the cloud, many customers are leveraging AWS Workspaces as a Desktop as a Service Solution (DaaS) to provide end users access to corporate resources at any time from any where.  Given Workspaces are available to anyone, from anywhere, a key consideration to moving to AWS Workspaces, is of course Security. 


AWS Workspaces can be configured to require Multi-Factor Authentication (MFA) to add a layer of protection to a user name and password (the first “factor”) by requiring users to enter an authentication code (the second factor), which can be provided by a virtual or hardware MFA solution.


There are two ways to do this.  


Option 1) Use Centrify Endpoint Services.  @Robertson in this article covered how to use the Centrify agent to enforce strong workspace level security with Centrify's Endpoint Services solution to deliver:

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

This is the most secure option.


Option 2) Use Centrify's MFA service with AWS Radius support to require MFA before accessing AWS Workspaces


In this howto, we will focus on option 2.  





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.

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:



Log into Centrify cloud tenant with an administrator account. Navigate to Settings > Authentication > RADIUS Connections. Under Clients tab, click Add.








In the RADIUS Client Settings window, enter a name, internal IP address of FortiGate and create a client secret. Save settings.











Navigate to Settings > Network > Centrify Connectors, double click connectors that you would like to accept RADIUS connections for VPN authentication from FortiGate, navigate to RADIUS section and click check box to enable incoming RADIUS connections. Save settings.












Navigate to Settings > Authentication > Authentication Profiles. Click Add Profile to create a new profile for VPN MFA.











For challenge 1, select Password. For challenge 2, select what you would like to use for authentication challenge.













Navigate to Core Services > Policies to modify current policy or add a new one. Under User Security Policies > RADIUS, need to set “Allow RADIUS connections” to Yes and check the box for “Require authentication challenge”, select VPN authentication profile you created earlier.











Now we will go over configuration on the FortiGate firewall. Log into FortiGate with an admin account. Navigate to users and device > RADIUS servers, click create new button to add a new entry.













Enter name, IP address of server running Centrify Cloud Connector and server secret.












Test to verify successful communication, click test connectivity button, enter a valid username and password to run test.












You should see successful result if settings are correct and RADIUS communication isn’t blocked. If not, check basic network communications between Centrify server running Cloud Connector and the FortiGate. Verify that firewalls are not blocking port 1812 used for RADIUS connections.










Next, we will create a RADIUS VPN user group. Navigate to User & Device > User Groups and click Create New. Give it a name and select Centrify RADIUS server under “Remote groups”.











If you don’t already have a client to site IPsec VPN profile setup, navigate to VPN > IPsec Wizard, select Remote Access and complete steps in wizard. Select RADIUS VPN user group when going through steps.










When a VPN user authenticates using FortiClient, they will be prompted for MFA.




First enter username and password.







Now prompted for second form of authentication.











On Centrify portal as an admin user, you can view Core Services > Reports > Built in Reports > Security and run the “MFA Events – Last 30 days” to verify and troubleshoot RADIUS authentication.





Added tip 4/5/2018:


It's best to match remote authentication timeout on FortiGate with timeout set in RADIUS server settings on Centrify. The default timeout on FortiGate is 5 seconds so we will increase to 60 to match Centrify.


Commands to run on FortiGate to accomplish this:


#config system global

#set remoteauthtimeout 60




How to secure shared web accounts

By Centrify Advisor IV ‎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.


Developer Portal

The solutions above address the challenge from the point of view of an infrastructure lead specifically focusing on systems.  Although in this article we don't cover this in depth, it should be known that everything in the Centrify Identity Platform uses REST APIs.


The Developer Reference pages here:  are another resource in your arsenal.


The resource management API, specifically the /Servermanage/CheckoutPassword API provides the capability of password checkouts.  This reference provides the folllowing code samples:

  • cURL
  • Node JS
  • Ruby
  • JavaScript
  • Python
  • PHP
  • Java
  • C# and 
  • Go




PowerShell Sample Pages in GitHub

Many of the CIP methods are already available in PowerShell using the samples posted in Github.



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 6 hours ago

Note: With the Centrify-Idaptive spin-out, the Self-Service and MDM Enrollment capabilities will continue to be supported by Idaptive.  For more info about the split see the FAQ here:  this article is left here for historic purposes.



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.


Notes (November 2017)

This implementation example will be left in this blog for historical reasons.  Turns out that back in 2017 when this lab was set up, we did not realize that there was loss of functionality related to some of the drivers loaded by the PCoIP Credential Provider (including copy/paste and printer redirection).  This is obviously not acceptable.  We are working with Amazon and once they have an SDK and an integration path, we'll do it like we've done with others (e.g. McAfee).  In the meantime, the recommended configuration is to use RADIUS.  @Fel did a post documenting the methodology and it's here:


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.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel