Background

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.

 

model.png

 

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

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.

 

Implementation

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

aws-workspaces.png

Implementation

 

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)
    simplead1.JPG
    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).
    simplead2.png
    Make sure that:
    - The connector group and the directory domain controllers can talk AD communications (DNS, Kerberos, LDAP, etc)
    - The members of the domain (including AWS WorkSpaces systems) and the connector  can talk over HTTPSgroup and TCP 8443.
    - The connector group has at least outbound HTTPS and Azure Service Bus connectivity with the Centrify Identity or Privilege Service tenant.

 

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

  1. Log in to your EC2 console console.aws.amazon.com/ec2 and launch a current Windows Server instance in the security group designated for the connectors; this instance should have at least dual core processors and 8GB of RAM.  In addition it should have outbound internet connectivity  (direct or via proxy). 
  2. With the information collected about the AWS WorkSpace directory (the IP addresses of the directory servers), open the Network control panel (ncpa.cpl) and modify the TCP/IP properties of the network card.  In IPv4, add one of the IP addresses of the directory DCs as the primary and secondary DNS server entries for the EC2 Windows instance.
    ip-conn.JPG
    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.
    aduc.JPG
  4. Stay logged in as a domain administrator.

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

  1. Sign-in to your Centrify instance as a privileged user (e.g. https://example.my.centrify.com)
  2. Go to Admin Portal > Settings > Network and click Add Centrify Connector
  3. Click on 64 bit, this will start the Connector download.
  4. When downloaded, double-click and follow the wizard for setup (you don't need mobile tools), when finished the configuration wizard starts.
  5. Provide the Centrify tenant information and credentials, then follow the wizard (you don't need the activation or deleted items option).
  6. Verify that the Centrify applet displays a succesful connection.
    successful.JPG
  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.
    root-gpo.JPG
  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.
    gpo-ex-cred.png
    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
    lisa.JPG
  4. Select your bundle > pick your product (e.g. Windows 10 Standard)
  5. WorkSpaces configuration > pick the options as needed, press Next Step
  6. Review and launch > review and press Launch.  You may have to wait up to 20 minutes at this step.
  7. In the meantime, you can download and install the WorkSpaces client.  You can obtain them from here:  https://clients.amazonworkspaces.com/
  8. Follow the instructions to install the WorkSpaces client in your platform.
  9. When the WorkSpace is available, note the registration information and register with the AWS WorkSpaces client, before connecting, continue to the next section.

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

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

 

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

  1. Connect to your WorkSpace
  2. Since the Credential Provider is disabled, you may have to re-auth after connecting.
  3. Open a command window and type gpupdate /force, then reboot the system. 
  4. After reboot, reconnect to the system and log in as the test user
  5. Browse to the location of the installation bits for the Centrify Agent for Windows and shift+right click > Run as a different user > log in with a domain privileged user
    Welcome page > press Next
    EULA page > check the box and press Next
    Destination Folder > press Next
    Ready to install > press Install
    Completed page > press finish.  This will start the configuration wizard.
    Note:  the configuration steps below can be set via Group Policy.
  6. Press Add Service, at this point, depending on the information in AD, the services are visible
  7. Select 'Centrify Identity Services Platform'  and Press OK
    id-serv.JPG
  8. Select your tenant instance
    selinst.png
  9. Multi-factor authentication on Windows login > Enable > Press Add > select your test users (e.g. diana, lisa), press Next
    mfa-set.JPG
  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
    success.png
  • 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

installWiFimobileconfig.png

 

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.

Read more...

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

Read more...

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.

Read more...

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

 

pswa8.png

Read more...

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

Read more...

How to deploy Safari extension to Mac using Centrify

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

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

 

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

 

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

 

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

 

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

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

 

 

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

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

 

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

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

 

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

How To: Configuring Confluence with a Custom SAML App

 

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

 

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

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

 

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

 

https://confluence.atlassian.com/cloud/saml-single-sign-on-873871238.html#SAMLsinglesign-on-SetupSAM...

 

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

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

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

 

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

 

Enable the FileVault encryption policy

 

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

 Policies.png

 

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

 

Enable FileVault.png 

 

 

 

 

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

 

Save the changes.

 

Enroll the Mac OS X device

 

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

Enroll with Centrify.png

 

 

 

The download of the Centrify for Mac agent will begin

 

Download begins for Centrify Agent.png

 

 

 

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

 

Install begins of Centrify Agent.png

 

 

 

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

 

 

Double click to open the package.png

 

A warning will appear regarding the software installation

 Install Centrify Agent.png

 

 

 

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

 

Click here to begin installation.png

 

 

 

Click on Install to begin the installation

Click on Install.png

 

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

 

Enter local admin password.png

 

 

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

 

 

Installation complete.png

 

 

A confirmation message will appear for the successful install

 

 

Installation confirmation.png

 

 

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

 

Enter username to enroll.png

 

 

 

Enter the password of  Centrify Directory Service or Active Directory user

 

Enter password.png

 

 

 

Click Enroll to begin the device enrollment

 

Click on Enroll.png

 

 

Enter the username and password of the local admin account

 

Enter local admin password enrolling.png

 

The device enrollment will begin

 

Device enrolling.png

 

 

Configure Safari for Single-Sign On

 

Configure Safari.png

 

 

 

The Safari Single Sign-On configuration will show as completed

Configure Safari complete.png

 

 

 

 

 

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


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

 

 

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

 

Enter FileVault password.png

 

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

 

Filevault Key.png

 

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

 

 

FileVault begin.png

 

 

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

 

Encryption end.png

 

 

 

 

Locate the recovery key

 

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

 

 

FileVault Key Admin Portal.png

 

 

 

 

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

 

Device Details Enabled.png

 

 

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

 

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

 

http://community.centrify.com/t5/TechBlog/Using-Centrify-to-Implement-FileVault-2-Disk-Encryption-on...

This technical blog post [with Videos] is intended to highlight the Centrify Identity Platform REST API Framework and its capabilities, specifically as it relates to automating the management of privileged accounts...

Read more...

[How to] Manage access to Dropbox

By Centrify Advisor I ‎06-08-2017 03:18 PM

Ensure access to Dropbox and other Apps from managed devices only

Read more...

Thank you for choosing Centrify!

 

The following is a step-by-step guide designed to help walk you through an integration of AWS to Centrify Identity Service. 

 

Install time ~ 1-3 hours

 

Requirements

  • AWS account
  • Centrify Identity Service account
  • Active Directory, LDAP or Centrify Cloud Directory
  • Windows Server for Centrify Connector (requirements below)

 

 

How to use guide

This guide is broken into two parts: (1) integrating AWS using SAML for single sign-on (Steps 1-20) and (2) enabling auto-user provisioning (Steps 21-35). The steps are sequential and recommended for a successful integration. 

 

 

Let's get started

 

1) Log into your Centrify Identity Service tenant. 

 

Screenshot 2017-06-04 17.25.08.png

 

2) Install the Centrify Connector by following this guide:

http://community.centrify.com/t5/TechBlog/How-To-Installing-Centrify-Cloud-Connector/ba-p/27840

 

3) Next, we must create roles in Centrify to contain users of AWS. Roles can contain users in Active Directory, LDAP or Centrify's Cloud Directory; and is a logical way of organizing users from your source directory to roles you've defined in AWS. A minimum of one role must be used; for the purposes of this guide, we will create a Centrify role titled 'AWS-EC2-Admins'. This role will contain all AWS administrator users within your source directory. Additional roles that correspond to AWS roles can be created similar to the example role in this guide. To create a role, navigate to 'Roles' -> 'Add Role' to continue.

 

Screenshot 2017-06-04 17.26.01.png

 

4) Name the Centrify role ‘AWS-EC2-Admins'. You can create additional Centrify roles as needed. Click ‘Save’ to proceed.

 

Screenshot 2017-06-04 17.26.37.png

 

5) Click ‘Members’ then click ‘Add’ to begin adding the appropriate active directory users or security group that contains all AWS administrator users. 

 

Tip: It’s best practice to create a security group in your source directory that contains all users you assigned to a particular AWS role. For example, if there are 5 administrator users in AWS, the same 5 users must exist as memebers to the 'AWS-EC2-Admins' role in Centrify. A 1-to-1 mapping allows Centrify the ability to authenticate a user attempting to access AWS with their source directory username/password. It also enables the administrator to create/modify/disable users access from the source directory when it comes to provisioning and de-provisioning. 

 

Screenshot 2017-06-04 17.27.18.png

 

6) Once complete, navigate to 'Apps' -> 'Add Web Apps' and searching for AWS SAML + Provisioning template. 

 

 Screenshot 2017-06-04 17.29.41.png

 

7) When the AWS application template is added, you will arrive at the following screen. Add 'Your AWS Account ID' then click on the 'Download SAML Provider Metadata Document'. 

 

Screenshot 2017-06-04 17.30.19.png

 

8) Next, navigate to 'User Access' and choose the Centrify roles you've created. In this example, I've choosen two roles - 'AWS-EC2-Admin' and 'AWS-EC2-ReadOnly', of which I created in Step 4 above. 

 

Screenshot 2017-06-04 17.30.32.png

 

9) Next, login to your AWS console with an administrator account. Navigate to your the Identity and Access Management Dashboard, then click 'Create Provider'. 

 

Screenshot 2017-06-04 17.31.06.png

 

10) Choose 'SAML' as the 'Provider Type'. Type 'Centrify' as 'Provider Name' and then upload the metadata document from Step 7 (Centrify) to AWS in the 'Metadata Document' field. Click 'Next Step' to continue. 

 

Screenshot 2017-06-04 17.31.47.png

 

11) Verify the provider information, then click 'Create' to continue. 

 

Screenshot 2017-06-04 17.31.55.png

 

12) Next, navigate to 'Roles' then click 'Create new role'. The purpose of this step is to define access policies for the different roles of users that will be using the service. 

 

Screenshot 2017-06-04 17.32.10.png

 

13) Select 'Grant Web Single Sign-On (WebSSO) access to SAML providers' option. 

 

Screenshot 2017-06-04 17.32.27.png

 

14) Verify the SAML provider (Centrify), then click 'Next Step' to continue. 

 

Screenshot 2017-06-04 17.32.38.png

 

15) Review the Role Trust policy document, then click 'Next Step' to continue. 

 

Screenshot 2017-06-04 17.32.50.png

 

16) Choose the appropriate policy name for your role. In this example, I am choosing the 'AmazonEC2FullAccess' policy for my 'AWS-EC2-Admins' role. Once choosen, click 'Next Step' to continue. 

 

Screenshot 2017-06-04 17.33.14.png

 

17) Name the role to the corresponding role name you wish to map to in Centrify (See Step 4 above). Click 'Create role' to continue. 

 

Tip: The AWS role name must match a corresponding Centrify role name for authentication/authentication from Centrify to AWS console. 

 

Screenshot 2017-06-04 17.33.38.png

 

18) You've now successfully completed a SAML integration of AWS to Centrify. Navigate to your User Portal and verify that you are able to see the AWS tile in Centrify. Click on the tile to test access to AWS. 

 

Screenshot 2017-06-04 17.35.59.png

 

19) Choose the appropriate AWS role you have been granted and click 'Sign-in'. 

 

Screenshot 2017-06-04 17.36.13.png

 

20) Verify that you are able to log into the AWS console with the appropriate access that has been granted to you. 

 

Screenshot 2017-06-04 17.36.30.png

 

*** Step 20 completes the SAML only integration of AWS. Please review the steps below which walk through how to enable provisioning. ***

 

21) To enable provisioning in Centrify, navigate to the 'Provisioning' menu in Centrify and click on the 'Enable provisioning for this application'.

 

Tip: You have the option of enabling provisioning in 'Preview Mode' or 'Live Mode'. Preview mode is a non-production sync. It is recommended that you complete the initial provisioning setup using preview mode before committing the integration in production. 

 

Screenshot 2017-06-04 17.36.58.png

 

22) Add a AWS administrator's 'Access key' and 'Secret' to the fields in Centrify. To obtain the values, navigate to 'Delete your root access keys' field in AWS and click 'Manage Security Credentials'. 

 

Screenshot 2017-06-04 17.37.39.png

 

23) Next, click 'Continue to Security Credentials'. 

 

Screenshot 2017-06-04 17.37.47.png

 

24) If you don't already have an access key, click 'Create New Access Key'. 

 

Screenshot 2017-06-04 17.37.59.png

 

25) Copy the 'Access Key' and 'Secret' from AWS to Centrify. Once complete, click 'Verify' in Centrify to continue. 

 

Screenshot 2017-06-04 17.38.55.png 

 

26) If successful, additional provisioning configurations appear in Centrify. In this section, you can choose provisioning rules such as, a deletion of a user from the source directory will disable the user's account in AWS. 

 

Screenshot 2017-06-04 17.39.22.png

 

27) Next, we must create groups in AWS for Centrify to provision users into. In AWS, navigate to 'Groups' then click 'Create New Group' to continue. 

 

Screenshot 2017-06-04 17.39.56.png

 

28) Name the group to a corresponding role you have created in Centrify (See Step 4 above). Click 'Next Step' to continue. 

 

Screenshot 2017-06-04 17.40.26.png

 

29) Choose the appropriate policy for each role. Click 'Next Step' to continue. 

 

Screenshot 2017-06-04 17.40.41.png

 

30) Finalize by clicking 'Create Group'. Create an AWS group for each corresponding AWS role you've designed in Centrify. 

 

Screenshot 2017-06-04 17.40.52.png

 

31) In Centrify, under 'Role Mapping', click 'Add'. Select the AWS role under 'Role'. Map the role to the desgination group you've created in AWS (See Step 28 above). 

 

Screenshot 2017-06-04 17.41.57.png

 

32) Complete this mapping for all Centrify roles and AWS groups you've created. See below as an example of two Centrify roles mapped to two AWS groups. Click 'Save' to continue. 

 

Screenshot 2017-06-04 17.42.12.png

 

33) To finalize the integration, navigate to 'Settings' -> 'Users' -> 'Outbound Provisioning' -> 'AWS Web Services' application, then 'Start Sync'. 

 

Screenshot 2017-06-04 17.42.28.png

 

34) For the initial integration, click 'bypass caching and re-sync all objects' option, then 'Yes' to initiate the sync. 

 

Screenshot 2017-06-04 17.42.35.png

 

35) Switch to your 'User Portal' and verify that you can log into AWS by clicking on the tile and choosing the appropriate role. 

 

Screenshot 2017-06-04 17.35.59.png

 

 

We hope this installation guide was helpful. For all other questions on how Centrify can help you consolidate user identities and solve the #1 cause of all cyber attacks, please contact us athttps://www.centrify.com/about-us/contact/

 

Thank you for choosing Centrify!

 

The following is a step-by-step guide designed to walk you through an integration of Salesforce to Centrify. The integration will allow a central directory of your choosing (e.g. Active Directory, Centrify Cloud Directory, LDAP or Google Directory) as the authentication/authorization mechanism to Salesforce. End-users will enjoy the benefit of a single sign-on login experience while administrators take advange of a single user directory to manage the lifecycle of Salesforce users from. 

 

Install time ~ 1-3 hours

 

Requirements

1) Salesforce account

2) Centrify Identity Service account

3) Active Directory, LDAP or Centrify Cloud Directory

4) Windows server for Centrify Connector (requirements below)

 

 

How to use guide

This guide is broken into two parts: (1) integrating Salesforce using SAML for single sign-on (Steps 1-16) and (2) enabling auto-user provisioning (Steps 17-30). The steps are sequential and recommended for a successful integration. 

 

 

Let's get started

 

1) Log into your Centrify Identity Service tenant. 

 

Screenshot 2017-05-30 18.33.20.png

 

 

2) Install the Centrify Connector by following this guide:

http://community.centrify.com/t5/TechBlog/How-To-Installing-Centrify-Cloud-Connector/ba-p/27840

 

3) Next, we must create roles in Centrify to contain users of Salesforce. Roles can contain users in Active Directory, LDAP or Centrify's Cloud Directory; and is a logical way of organizing users from your source directory to roles you've defined in Salesforce. A minimum of one role must be used; for the purposes of this guide, we will create a Centrify role titled 'Information Technology'. This role will contain all Salesforce administrator users within your source directory. Additional roles that correspond to Salesforce roles can be created similar to the example role in this guide. To create a role, navigate to 'Roles' -> 'Add Role' to continue.

 

Screenshot 2017-05-30 18.38.02.png

 

 

4) Name the Centrify role ‘Information Technology'. Click ‘Save’ to proceed.

 

Screenshot 2017-05-30 18.38.14.png

 

5) Click ‘Members’ then click ‘Add’ to begin adding the appropriate active directory users or security group that contains all Salesforce administrator users. 

 

Tip: It’s best practice to create a security group in your source directory that contains all users you assigned to a particular Salesforce role. For example, if there are 5 administrator users in Salesforce, the same 5 users must exist as memebers to the 'Information Technology' role in Centrify. A 1-to-1 mapping allows Centrify the ability to authenticate a user attempting to access Salesforce with their source directory username/password. It also enables the administrator to create/modify/disable users access from the source directory when it comes to provisioning and de-provisioning. 

 

Screenshot 2017-05-30 18.38.32.png

 

6) Once complete, navigate to 'Apps' -> 'Add Web Apps' and searching for Salesforce SAML + Provisioning template. 

 

5) centrify - adding salesforce app.png

 

7) When the Salesforce application template is added, you will arrive at the following screen. Minimize the following screen and open a new browser tab to log into Salesforce. Log into Salesforce with an administrator account to enable Salesforce enable SAML and provisioning. 

 

6) centrify - salesforce app.png

 

8) In Salesforce, navigate to the 'Single Sign On Settings' menu and click 'Edit'. 

 

1) salesforce - sso config.png

 

9) Click the 'SAML Enabled' checkbox and click 'Save'. 

 

2) salesforce - enable SAML.png

 

10) Next, navigate to the 'SAML Single Sign-On Settings' section and click 'New'. 

3) salesforce enable SSO.png

 

11) When clicked, you will arrive at the following screen where you will exchange configurations between Centrify and Salesforce. 

 

4) salesforce - SAML config.png

 

12) To make the configuration easier, open the Centrify and Salesforce menus side-by-side as illustrated below. 

 

7) centrify and salesforce config pages.png

 

13) Start by creating a name for the 'SAML Single Sign-On Settings' integration to Centrify. Use the picture and summary below to help guide where configurations need to be made:

 

1) Name (Salesforce): Centrify.

2) API Name (Salesforce): Centrify.

3) Entity ID (Salesforce): https://saml.salesforce.com.

4) Issuer: Copy from Centrify to Salesforce.

5) Identity Provider Certificate: Download the signing certificate from Centrify and upload to Salesforce.

6) SAML Identity Type: Click 'Assertion contains the Federation ID from the User Object' option in Salesforce. (See Step 13.2).  

7) Identity Provider URL: Copy from Centrify to Salesforce.

8) Identity Provider Logout URL: Copy from Centrify to Salesforce.

9) Customer Error URL: Copy from Centrify to Salesforce.

10) User Provisioning Enabled: Click to enable in Salesforce (Follow Step 17-30 to complete provisioning).

11) Save (Salesforce): Click in Salesforce.

12) Save (Centrify): Click in Centrify.

 

8) centrify and salesforce configs completed.png

 

13.1) When Step 13 is completed, open the 'Centrify' SAML Single Sign-On Settings profile you just created, and copy the 'Salesforce Login URL' from Salesforce to the 'Assertion Consumer Service URL' field in Centrify. 

 

9) ACS URL After.png

 

13.2) If provisioning is enabled in Step 10 above, you must choose the 'Assertion contains the Federation ID from the User Object' (See Step 6 above) within the 'SAML Single Sign-On Settings' menu in Salesforce. In doing so, you must add a 'Federation ID' value for the administrator user performing the integration. The 'Federation ID' configuration is found by navigating to 'Administration' -> 'Users' -> current administrator user enabling SAML in Salesforce. The value of should be the email address of the administrator user. 

 

If you do not wish to enable provisioning at this time, leave the default option of 'Assertion contains the User's Salesforce username' in Salesforce (See Step 6 above) and disregard the step of adding a 'Federation ID' for the administrator user. The federation ID is only needed if provisioning is enabled in Salesforce. Follow steps 14-16 in this guide to complete a SAML only integration of Salesforce to Centrify. 

 

8.1) salesforce - federation ID.png

 

14) Next, naviagate to 'User Access' and choose the Centrify role 'Information Technology' created in Step 4. You can also add other Centrify roles you created for other roles in Salesforce within this menu. 

 

10) Centrify - role assignment.png

 

15) Next, navigate to the 'Account Mapping' menu in Centrify. Verify that the default value in the 'Directory Service field name' is 'mail'. As a default, Salesforce expects an email attribute from the source directory (i.e. Active Directory) within the SAML assertion sent to Salesforce. While other settings may be used, please review the options within Salesforce before leveraging other attributes in your SAML assertion. 

 

11) centrify - account mapping.png

 

16) Once the 'Account Mapping' value is reviewed, click 'Save' to complete the integration. Switch to your 'User Portal'. You will see the Salesforce tile appear within your portal if you have a valid account in your source directory (i.e. Active Directory) and Salesforce. Click on the Salesforce tile to confirm you are able to access Salesforce from the Centrify portal. 

 

12) centrify - app in portal.png

 

*** Step 16 completes the SAML only integration of Salesforce. Please review the steps below which walk through how to enable provisioning. ***

 

17) To enable provisioning in Centrify, navigate to the 'Provisioning' menu in Centrify and click on the 'Enable provisioning for this application'. Add a Salesforce administrator's 'Username' and 'Password' to the fields in Centrify, then navigate to Salesforce to continue. 

 

Tip: You have the option of enabling provisioning in 'Preview Mode' or 'Live Mode'. Preview mode is a non-production sync. It is recommended that you complete the initial provisioning setup using preview mode before committing the integration in production. 

 

 13) centrify - enable provisioning.png

 

18) To enable the user provisioning feature in Salesforce, click 'Enable' for item 10 in Step 13 above. Additionally, when provisioning is enabled in Salesforce, a Connected App must be created. Navigate to 'App Manager' -> 'Manage Connected Apps', then click 'New Connected App'. 

 

14) salesforce - create connected app.png

 

19) Complete the following information in Salesforce as outlined below. Once complete, click 'Save' to continue. 

 

1) Basic Information

  -> Connected App Name: Centrify

  -> API Name: Centrify

  -> Contact Email: Email address of Salesforce administrator user

    

2) Enable OAuth Settings: Enabled

 

3) Callback URL: Centrify Identity Service URL

 

4) Selected OAuth Scopes: Choose the minimum required options below. 

  -> Access and manage your Chatter data (chatter_api) 

  -> Access custom permissions (custom_permissions)

  -> Access your basic information (id, profile, email, address, phone)

  -> Full access (full)

  -> Perform requests on your behalf at any time (refresh_token, offline_access)

  -> Provide access to custom applications (visualforce)

  -> Provide access to your data via the Web (web)

 

5) Require Secret for Web Server Flow: Enabled

 

15) salesforce - configuring connected app.png

 

20) The Salesforce Connected App may take several minutes to complete. As the changes take affect, the 'Consumer Key' (Item 2) and 'Consumer Secret' (Item 3) will generate and become available for you to proceed to the next step. 

 

16) salesforce - completed connected app.png

 

21) With Centrify and Salesforce opened, copy the 'Consumer Key' in Salesforce to the 'Client ID' field in Centrify. Copy the 'Consumer Secret' in Salesforce to the 'Client Secret' field in Centrify. 

 

17) centrify - client id and secret.png

 

22) To obtain your 'Security Token' in Salesforce, Salesforce recommends a reset of the security token. Click on the 'Reset Security Token' button to obtain your new security token via email. 

 

18) salesforce - reset code.png

 

23) You will obtain your new Salesforce security token via email. Copy and add to Step 24 below. 

 

 19) email reset code.png

 

24) Add the Salesforce security token to the 'Security Token' field in Centrify. Once complete, click 'Verify' to complete this step. 

 

20) centrify - security token.png

 

25) If the provisioning integration between Centrify and Salesforce is successful, additional menus will populate as shown below. You may keep the default settings or modify based on your preference. 

 

21) centrify - provisioning options.png

 

26) Under the 'Role Mapping' section, click 'Add'. This step allows you to map a Centrify role (containing users in active directory) to a 'Salesforce License', 'Salesforce Role' and 'Salesforce Profile' you've setup in Salesforce. As an example, in Steps 4-5, we created a Centrify Role titled 'Information Technology'. The role contains the administrator users in the source directory (i.e. Active Directory) that are mapped to Salesforce. While this guide illustrates mapping a single Centrify role to Salesforce, utilize the same process for mapping other Centrify roles to existing Salesforce roles to complete your integration. 

 

22) centrify - role mapping.png

 

27) Click 'Save' to continue. 

 

23) centrify - completed role mapping.png

 

28) Next, navigate to 'Settings' -> 'Users' -> 'Outbound Provisioning' -> 'Salesforce' and click 'Start Sync'. An initial sync is required for any new application integrated with Centrify that is enabled with provisioning. 

 

24) centrify - start sync.png

 

29) Click 'bypass caching and re-sync all objects'. This setting allows for an immediate sync of Salesforce to Centrify versus waiting for a periodic sync that Centrify performs automatically. 

 

25) centrify - bypass sync.png

 

30) Switch to your 'User Portal' and verify that you can log into Salesforce when clicking on the Salesforce tile. 

 

26) centrify - app in portal.png

 

We hope this installation guide was helpful. For all other questions on how Centrify can help you consolidate user identities and solve the #1 cause of all cyber attacks, please contact us at https://www.centrify.com/about-us/contact/

A short step by step configuration guide on how to configure the Fortinet FW with Centrify for SSO using RADIUS

Read more...

This Cheat Sheet should be used with Centrify Mac Agent version 5.2.4 and higher.

 

The Centrify Mac Diagnostic Tool location:
/Library/Application Support/Centrify/MacDiagnosticTool.app

  

 

Centrify Agent

 

To join the domain in Auto Zone:
sudo /usr/local/sbin/adjoin --user domain_admin_username --workstation domain.com

 

To join the domain in Zone mode:
sudo /usr/local/sbin/adjoin --user domain_admin_username --zone zonename domain.com

 

To leave the domain and disable the computer object:
sudo /usr/local/sbin/adleave --user domain_admin_username 

 

To leave the domain and remove the computer object:
sudo /usr/local/sbin/adleave --user domain_admin_username --remove

 

To leave the domain and leave the computer object untouched in Active Directory:
sudo /usr/local/sbin/adleave --user domain_admin_username --remove

 

To print information for the domain:
/usr/local/bin/adinfo

 

To print network diagnostic information for the domain:
sudo /usr/local/bin/adinfo --diag

 

To view licensing mode:

/usr/local/sbin/adlicense

 

To enable licensed features:

sudo /usr/local/sbin/adlicense --licensed

 

To look up an Active Directory user's information:

/usr/local/bin/adquery user -A username

 

To look up an Active Directory computer's information:

/usr/local/bin/adquery user -A computername$

 

To look up an Active Directory computer's Manager (managedBy attribute used with FileVault policy):

 

/usr/local/bin/adquery user -b managedBy computername$

 

To look up an Active Directory group's information:

/usr/local/bin/adquery group -A groupname

 

To change the currently logged in user's Active Directory password:

/usr/local/bin/adpasswd

 

To change an Active Directory user's password:

/usr/local/bin/adpasswd --adminuser domain_admin_username username@domain.com

 

To flush the Mac agent cache (Active Directory users will need to login again to cache their credentials after this is ran):

sudo /usr/local/sbin/adflush

 

The location of the Centrify configuration file:
/etc/centrifydc/centrifydc.conf

 

The location of Centrify Kerberos tools:
/usr/local/share/centrifydc/kerberos/bin/

 

To restart the Mac agent:
sudo /usr/local/share/centrifydc/bin/centrifydc restart 


 

To turn on logging:
sudo/usr/local/share/centrifydc/bin/cdcdebug on

 

To turn off logging:
sudo/usr/local/share/centrifydc/bin/cdcdebug off 

 

To clear out the current log file:

sudo/usr/local/share/centrifydc/bin/addebug clear


Log file location:
/var/log/centrifydc.log

 

To uninstall the Mac agent:
sudo /usr/local/share/centrifydc/bin/uninstall.sh

 

To uninstall silently:
sudo /usr/local/share/centrifydc/bin/uninstall.sh --std-suite

 

 

Group Policy

 

To force group policy updates for both user and machine policies:
/usr/local/bin/adgpupdate

 

To update group policy for user policies only:
/usr/local/bin/adgpupdate --target User

 

To update group policy for machine policies only:
/usr/local/bin/adgpupdate --target Computer

 

To view the curent set group policies:

/usr/local/bin/adgpresult

 

To view the curent set user group policies:

/usr/local/bin/adgpresult --user username

 

To view the curent set machine group policies:

/usr/local/bin/adgpresult --machine

 

The location of computer group policy reports:
/var/centrifydc/reg/machine/gp.report 

 

The location of the user group policy reports:
/var/centrifydc/reg/user/username/gp.report  

 

The location of login scripts:
/var/centrifydc/loginscripts/machine
/var/centrifydc/loginscripts/user/username

/var/centrifydc/scripts/additional/login
/var/centrifydc/scripts/additional/logout

 

To retrieve machine certificates:
sudo /usr/local/share/centrifydc/sbin/adcert --machine --keychain

 

To retrieve user certificates:
/usr/local/share/centrifydc/sbin/adcert --user --keychain

 

The location of machine certificates:
/var/centrify/net/certs

 

The location of user certificates:
~/.centrify

/Users/username/.centrify

 

 

Directory Services

 

To see if the machine is joined to the domain using the Apple plugin:
/usr/sbin/dsconfigad –show

 

To unbind from the domain using the Apple plugin:

sudo /usr/sbin/dsconfigad –remove -username domain_admin_username

 

To list all of the users in the Directory Service and in Active Directory for the zone:
/usr/bin/dscl /Search -list /Users

 

To list only the Active Directory users enabled for the zone:
/usr/bin/dscl /CentrifyDC -list /Users

 

To display detailed information about the specified Active Directory user:
/usr/bin/dscl /CentrifyDC -read /Users/username

 

To list all of the groups in the DirectoryService and in Active Directory for the zone:
/usr/bin/dscl /Search -list /Groups


 

To list only the Active Directory groups enabled for the zone:
/usr/bin/dscl /CentrifyDC -list /Groups

 

Command to display detailed informationa bout the specified Active Directory group name:
/usr/bin/dscl /CentrifyDC -read /Groups/groupname

  

 

FileVault

 

To see if FileVault is enabled:

/usr/bin/fdesetup status

 

To list FileVault enabled users:

/usr/bin/fdesetup list

 

To disable FileVault:

sudo /usr/bin/fdesetup disable

 

To add a local or mobile account to the FileVault user list:

sudo /usr/bin/fdesetup add -usertoadd username

 

 

Smart Card

 

To see if smart card support is enabled: 
/usr/local/bin/sctool --status

 

To enable smart card support: 
/usr/local/bin/sctool --enable

 

To disable smart card support: 
/usr/local/bin/sctool --disable

 

To dump out all the certificates and Active Directory information present on the smart card:

/usr/local/bin/sctool --dump

 

To get a new kerberos ticket: 

/usr/local/bin/sctool --pkinit

 

Related Articles:

 

A Centrify Server Suite Cheat Sheet

Centrify for Google Chromebook Single Sign-On Configuration Guide

 

Google G Suite has become one of the most popular on-demand business software in the market and your organization took the plunge to migrate to Google G Suite. You need to assign licenses to your end users automatically, and give them single sign-on. You’re worried about Chrome Book device management and BYOD, and how to manage all that for on-premises apps and cloud apps, too. You’ve got a few questions, and are looking for answers. Without SSO user productivity is greatly affected, without Multi Factor Authentication the risk of exposing inappropriate access increases and without automated account provisioning / de-provisioning IT has to manage all accounts manually.

 

Fortunately, Centrify Identity Service (CIS) provides a solution. CIS for Google G Suite offers a complete, robust, and easy-to-use Active Directory (AD) or CIS Cloud Directory integration with Google G Suite, providing a seamless authentication experience for Google G Suite users and an easy to use intuitive Administrative interface for IT staff to automate the process of on- and off-boarding employees with day one productivity.

With CIS you can ensure that users have seamless access via single sign-on (SSO) and that their Google G Suite accounts are created, updated, and deactivated on an integrated cycle with the rest of the systems in IT.

 

Centrify Identity Service enables integration with any web application that also enables administrators to:

  • SSO via SAML or CIS form fill to all Google G Suite: Gmail, Docs, Sites, Calendar, Analytics, etc.
  • Provide secure SSO with Active Directory integration
  • Automatically provision/de-provision users & apps by Active Directory group
  • Demonstrate compliance through usage auditing
  • Increase application ROI with seat-utilization reporting

Secure Application Access via MFA from unauthorized systems or locations

Read more...

Centrify Identity Service now includes a turnkey Munki solution for application management for managed Macs delivering a best in class user experience without any setup or configuration hassle.

Read more...

Thank you for choosing Centrify!

 

The following is a step-by-step guide designed to help walk you through an installation of the Centrify Connector. The Centrify Connector is a lightweight application that provides the following services: 

  • Active Directory/LDAP Proxy
  • Application Gateway 
  • RADIUS Server
  • Web Server (IWA)

 

Architecture Diagram

 

Screenshot 2017-06-10 21.39.25.png

 

 

Hardware Requirements

 

  • Windows Server 2008 R2 (64 bit) or newer with 8 GB of memory. 
  • Internet access (outbound port 443) to reach the Centrify Identity Services platform. 
  • A 'Baltimore Cyber Trust Root CA' certificate installed in the 'Local Machine Trusted Certificate' root authorities store.
  • Microsoft .NET version 4.5 or later.

 

If you are referencing accounts in an Active Directory tree or forest, the Centrify Connector can be joined to any domain controller in the tree (it does not need to be the root). In addition, that domain controller must have two-way, transitive trust relationships with the other domain controllers. 

 

Centrify recommends at least two Centrify Connectors on separate physical servers for high availability and redunancy. Centrify Connectors work active-active, load balance and are site aware.

 

Let's Get Started

 

1) Download the Centrify Connector package by logging into your Identity Services 'Admin Portal' navigating to 'Settings' -> 'Network' -> 'Centrify Connectors' -> 'Add Centrify Connector'

 

Screenshot 2017-06-10 22.04.29.png

 

2) Click on the ’64-bit’ link to download the installation package to the server you want to install the Cloud Connector on. 

 Screenshot 2017-04-23 09.27.01.png

 

 

3) Install the Centrify Connector on the member server by double clicking on the executable file.

 

9 - installing cloud connector.png

 

4) Click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.03.18.png

 

5) Review the Centrify End User Software License and Services Agreement, accept the terms of the agreement, then click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.03.36.png

 

6) Click ‘Install’ to install the Centrify Connector on the server.

 

Screenshot 2017-04-21 15.09.00.png 

 

7) Click ‘Finish’ to complete installation of the Centrify Connector on the server.

 

Screenshot 2017-04-21 15.31.43.png

 

8) A second installation wizard will appear to initiate the connection between active directory and your Centrify Identity Service tenant. Once the window does appear, click ‘Next’ to continue.

 

Note: The second installation wizard may take up to a few minutes to appear. 

 

Screenshot 2017-04-23 09.50.29.png

 

 

9) Provide your Centrify Identity Service administrator username and password. This is the default administrator password provided during activation to your Centrify Identity Service tenant. Click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.15.16.png

 

10) If you are installing the Centrify Connector on a web proxy server, add server configurations in this window. While available as an option, a web proxy server is not required for the Centrify Connector. Click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.19.44.png

 

11) The following step is optional and is required if you want Centrify to automatically keep users in the Centrify Admin Portal current with users in Active Directory. 

 

If you are installing the Centrify Connector with an account that has 'Read' permissions to the Deleted Objects container, you can click 'Next' to continue. The Centrify Connector will inherit the permissions of the user installing the Centrify Connector during the installation.

 

If you are install the Centrify Connector with an account that does not have 'Read' permissions to the Deleted Objects container, proceed to step 12 below to provide an account that does have the permissions.

 

Screenshot 2017-04-21 15.19.28.png 

 

12) If you are installing the Centrify Connector with credentials that do not have read access to the Deleted Objects folder, and you want to take advantage of Centrify's auto provisioning feature, you can specify alternative credentials by clicking on 'Edit -> Specify alternate user credentials'. The Centrify Connector will inherit permissions of the credentials you specify in this menu or by the user installing the Centrify Connector on the server. If you specify alternative credentials, click 'OK' then 'Next' to continue. 

 

Screenshot 2017-04-21 15.19.57.png

 

13) The Centrify Connector will attempt to connect to your Centrify Identity Service tenant. When you see five successes, click ‘Next’ to continue.

 

Screenshot 2017-04-21 15.20.09.png

 

14) Click ‘Finish’ to continue.

 

Screenshot 2017-04-21 15.20.40.png

 

15) The Centrify Connector Configuration console will display upon completion of the installation. Verify the connection is successful within the ‘Status’ tab.

 

Note: You can install multiple connectors to architect high availability and redundancy in your environment. Repeat the installation steps to install additional Centrify Connectors in your environment for redundancy and high availability. Centrify Connectors work active/active, load balance authentication traffic and are sight aware. 

 

Screenshot 2017-04-23 09.57.25.png

 

 

16) The ‘Centrify Connector’ tab within the Centrify Connector Configuration console, gives you the ability to 'Start'/'Stop' the connection to your Identity Service tenant. You can also 'View Log' from the persistent outbound connection the Centrify Connector has established to your Identity Service tenant.  

 

Screenshot 2017-04-23 09.59.11.png

 

 

 

17) In Centrify, refresh the web-page and verify that the connection was successful. If you have multiple Centrify Connectors, you will see each instance of those connections listed in this menu. 

 

Screenshot 2017-06-10 22.19.09.png

 

We hope this installation guide was helpful. For all other questions on how Centrify can help you consolidate user identities and solve the #1 cause of all cyber attacks, please contact us at https://www.centrify.com/about-us/contact/

 

[How to] Centrify for Google G Suite Deployment Guide

By Centrify Advisor I on ‎04-21-2017 03:19 PM - last edited ‎04-21-2017 03:24 PM

Centrify for Google G Suite offers a complete, robust, and easy-to-use Active Directory (AD) or Centrify Cloud Directory integration with Google G Suite providing a seamless authentication experience for Google G Suite users and an easy to use intuitive Administrative interface for IT staff to automate the process of on- and off-boarding employees with day one productivity.

 

With Centrify you can ensure that users have seamless access via single sign-on (SSO) and that their Google G Suite accounts are created, updated, and deactivated on an integrated cycle with the rest of the systems in IT.

Secure access to Google G Suite from any device. Enforce and update mobile security settings, and remotely lock or wipe devices. Lock the Centrify Mobile App with a passcode or fingerprint, and prevent unauthorized users from accessing your Google data. No separate software required.

 

The Google G Suite Deployment Guide covers…

 

  • Preparing your Google G Suite and Google G Suite developer account
  • Limiting access to certain Google G Suite based on Security Group
  • Configuring automated account provisioning into Google G Suite
  • Enabling Single Sign On in Google G Suite
  • Provisioning new Users
  • Integration with Active Directory
  • Securing the Administrative Account for Google G Suite

 

Read more...

Thank you for choosing Centrify!

 

The following is a step-by-step guide designed to help walk you through an integration of Concur to Centrify Identity Service. 

 

Install time ~ 1-3 hours

 

Requirements

  • Concur account
  • Centrify Identity Service account
  • Active Directory
  • Windows Server for Centrify Connector (requirements below)

 

Let's get started

 

1) Log into your Centrify Identity Service tenant. 

 

5 - login page.png

 

2) Once logged on, you will be presented with Centrify’s configuration wizard. You can choose to use the wizard for general setup, however, for purposes of this guide, you can check the ‘Don’t show this to me again’ box and close the window. This will stop the wizard from appearing during the configuration process.

 

6 - wizard.png

 

3) Install the Centrify Connector following this guide: 

http://community.centrify.com/t5/TechBlog/How-To-Installing-Centrify-Cloud-Connector/ba-p/27840

 

 

4) Next, we must create roles in Centrify to contain the users of the Concur application. Concur has two roles a user can be assigned: (1) administrator or (2) end user. For the purposes of this guide, we will create an administrator role for all the Concur administrators and an end users role for all non-administrator users (e.g. employees of a company). To create a role, navigate to 'Roles' -> 'Add Role'. Name the role 'Concur Administrators'. 

 

Screenshot 2017-04-16 16.08.21.png

 

5) In the 'Members' tab, add the administrator users from your active directory. Members can be individual users or security groups with one or more users within the group. In this example, I've added the 'Domain Admins' group as the users who will have administrator access to Concur. 

 

Screenshot 2017-04-16 16.08.55.png

 

 

 6) Add another role for Concur end users. Add the appropriate users from active directory as members to the role. 

 

Screenshot 2017-04-16 16.09.18.pngScreenshot 2017-04-16 16.12.02.png

 

 7) Next, navigate to the 'Apps' menu, click 'Add Web Apps', then search for the 'Concur' application. Choose the 'Concur SAML + Provisioning' template by clicking 'Add'. 

 

Screenshot 2017-04-16 16.17.05.png

 

8) Within the 'Application Settings' page, you will see the 'Identity Provider Logout URL' and 'Download Signing Certificate'. To enable single sign-on for Concur, you must contact your Concur customer success manager and provide them the following two configurations from your Centrify Identity Service console. Download the Centrify certificate and provide the file and the logout Identity Provider Logout URL to Concur. Concur will enable single sign-on and apply the settings to your Concur tenant. 

 

Screenshot 2017-04-16 16.17.27.png

 

9) Next, open the 'User Access' tab. Select the Centrify roles you've created for Concur and click 'Save'. 

 

Screenshot 2017-04-16 16.17.38.png

 

10) When Concur has completed enabling your Concur tenant for single sign-on, log into your Centrify Identity Service user portal. Click on the Concur application tile to confirm you are able to log into Concur. 

 

Screenshot 2017-04-16 16.18.56.png

 

 

We hope this guide was helpful. If you have any questions, please use this forum thread as a resource or contact Centrify - https://www.centrify.com/about-us/contact/

 

Thank you!

Thank you for choosing Centrify!

 

The following is a step-by-step guide designed to help walk you through an integration of Zendesk with Centrify Identity Service. 

 

Install time ~ 1-3 hours

 

Requirements

  • Zendesk account
  • Centrify Identity Service account
  • Active Directory
  • Windows Server for Centrify Connector (requirements below)

 

Let's get started

 

1) Log into your Centrify Identity Service tenant. 

 

5 - login page.png

 

2) Once logged on, you will be presented with Centrify’s configuration wizard. You can choose to use the wizard for general setup, however, for purposes of this guide, you can check the ‘Don’t show this to me again’ box and close the window. This will stop the wizard from appearing during the configuration process.

 

6 - wizard.png

 

3) Install the Centrify Connector following this guide: 

http://community.centrify.com/t5/TechBlog/How-To-Installing-Centrify-Cloud-Connector/ba-p/27840 

 

4) Next, we must create roles in Centrify to contain the users of the Zendesk application. Zendesk has 3 roles (Admin, Agent and End-User) that can be leveraged. A minimum of one Centrify role must be created and mapped to a Zendesk role (See Step 32 below). For the purposes of this guide, we will create an administrators role for all the Zendesk administrators. Additional roles can be created in Centrify similarly to the administrator role done in this guide. To create a role, navigate to 'Roles' -> 'Add Role'. Name the role 'Zendesk Administrators'. 

 

Screenshot 2017-04-16 14.01.46.png

 

5) Next, navigate to the 'Members' tab and select the users that you want to grant 'Administrator' access in Zendesk. This can be individual users in active directory or a security group that contains multiple users. Search for the users or security groups and click 'Add'

 

Screenshot 2017-04-16 14.02.17.png

 

6) Next, navigate to 'Apps' menu from the navigation bar, then 'Add Web Apps'. Search for the Zendesk application and choose the 'Zendesk SAML + Provisioning' template. Click 'Add' to continue. 

 

Screenshot 2017-04-16 14.03.17.png

 

7) Click 'Yes' to continue. 

 

Screenshot 2017-04-16 14.03.24.png

 

8) Next, open a new browser tab login to Zendesk with your administrator account. Under 'Security', enable the 'Single Sign-on (SSO)' configuration, then enable 'SAML' as the protocol. 

 

Screenshot 2017-04-16 14.05.46.png

 

9) With both the Centrify 'Application Settings' page and the Zendesk 'Single sign-on (SSO)' tabs open, exchange the following configurations as illustrated below. The 'Zendesk Account Name' is your Zendesk account name which can be taken from your login URL (i.e. The 'https://centrifydemo236.zendesk.com' Zendesk tenant URL will have the account name 'centrifydemo236'). Click 'Save' in both Centrify and Zendesk once complete.  

 

Screenshot 2017-04-16 14.07.24.png

 

10) Next, navigate to the 'User Access' tab in Centrify. Select the Centrify roles you created for Zendesk in Step 24. 

 

Screenshot 2017-04-16 14.08.39.png

 

11) Next, navigate to the 'Provisioning' tab. Click 'Enable provisioning for this application' and provide an administrator (1) Username, (2) Password and (3) Redirect URL in the form fields. Click 'Verify' to complete this step. 

 

** Provisioning allows administrators to manage Zendesk users from active directory. For example, in step 15, we added the 'Domain Admins' security group as a member to the 'Zendesk Administrators' Centrify role. Adding a new hire to the 'Domain Admins' group will prompt Centrify to auto provision a Zendesk account with administrator level access. 

 

Screenshot 2017-04-16 14.11.30.png

 

12) Once verified, scroll down to the 'Role Mappings' section and click 'Add'. As the first option, choose the 'Zendesk Administrator' role created in Step 24 and map to the 'Destination Role' 'Admin' in the Zendesk application. Click 'Done' to complete. 

 

Screenshot 2017-04-16 14.11.51.png

 

13) If you have created other roles for Zendesk, repeat the step as shown for the 'Zendesk End Users' role. 

 

Screenshot 2017-04-16 14.12.06.png

 

14) Once you've mapped all roles you've created for your Zendesk users, click 'Save' to complete the provisioning configurations. 

 

Screenshot 2017-04-16 14.12.20.png

 

15) To complete the integration, navigate to 'Settings' -> 'Users' -> 'Outbound Provisioning'. Under the 'Provisioning Enabled Applications', choose the 'Zendesk' application then click on the 'Start Sync' button. 

 

Screenshot 2017-04-16 14.37.44.png

 

16) Click the 'bypass caching and re-sync all objects' then 'Yes' to initialize the first integration and sync between Centrify and Zendesk. This step may take a few minutes depending on the number of users Centrify is provisioning into Zendesk. 

 

Screenshot 2017-04-16 14.12.50.png

 

17) Once complete, navigate to your 'User Portal' and verify that you can log into the Zendesk application by clicking on the application tile. 

 

Screenshot 2017-04-16 14.14.11.png

 

We hope this guide was helpful. If you have any questions, please use this forum thread as a resource or contact Centrify - https://www.centrify.com/about-us/contact/

 

Thank you!

CIS Version 17.3 adds a new feature to specify which user name format is sent to a RADIUS server during MFA.

Works with DUO, SecurID, SecureAuth, etc. 

Read more...

One of the more anticipated features of the Centrify Identity Service 17.3 release is the ability to manage Windows 10 devices. This feature is currently in preview mode, but is available once enabled on your tenant. This post details the steps to enroll such a device into CIS. If you are interested in what administrators need to configure for Windows 10 mobile device management, please click here.

 

1. Under Settings, choose Connect to work or school.

Win10-1.png

 

2. Choose Connect

Win10-2.png

3. Enter your email address

Win10-3.png

 

4. This should locate your tenant in Centrify Identity Service. Enter your user name.

Win10-4.png

 

5. Enter your password

Win10-5.png

 

6. Choose an authentication method for multi-factor authentication

Win10-6.png

 

7. Respond to the challenge

Win10-7.png

 

8. You should see a success message, as below.

Win10-8.png

 

9. On the settings screen, you should see your work account similar to what is shown below

Win10-9.png

 

10. If you select the work account, you should see additional details similar to what is shown below

Win10-10.png

 

11. Log into your CIS tenant and select device tab. Your Windows 10 device is enrolled and should show here.

Win10-11.png

 

12. The Wipe Device and Unenroll Device actions should now be available.

Win10-12.png

 

Configuring Centrify to use the Google Authenticator to satisfy MFA challenges is a good way to give users another authentication factor. The set up is easy for end users once all of the policies are configured from an Centrify Identity Platform Administrator.

Read more...

If you are already using the Centrify Identity Service for single sign-on, then your users can easily configure automatic login for the websites that they frequent. This is very beneficial for users that are accustomed to saving credentials into their browsers, since they do not have to store the credential in the Credentials Manager or Keychain.

Read more...

Protecting Azure Infrastructure

In this series we discuss how the Centrify platform can secure infrastructure running in Microsoft Azure. For those who are not familiar with Centrify, here’s an overview of the Centrify Platform and capabilities:

centrify-platform.png 

In this first part, we’ll focus on securing access to the Azure Portal using Identity Service. 

There are two strategies that can be used:

  • Protecting shared credentials (like the original o365 or Azure subscription account)
  • Federated SSO and just-in-time provisioning (no need to deploy an ADFS infrastructure)

Both strategies can be enhanced with:

  • Workflow and Approvals
  • Policy and Multi-factor authentication (including risk-based)

 

Protecting Azure Portal Shared Credentials

Shared Credentials in Azure may be sourced from different directories, but the most common use case is the subscription account.  This is typically the e-mail address of the user started the account.  This account has all the access (typically a Subscription Manager).  If your organization is already using Office365, then this is the “@yourdomain.onmicrosoft.com” account. 
azure-users.png

In this cases, you can use the Password Wallet capabilities of Identity Service to provide fast deployment, least access management, policy controls, strong authentication, accountability and documented approvals.  Here the features that enable all these benefits:

 

  1. Turnkey App template
    azure-template.PNG
  2. Role-based Access Control (leveraging Identity Service roles and Active Directory groups)
    azure-rbac.PNG
  3. Account Mapping flexibility
    azure-acct-map.PNG
  4. Policy Engine and Multi-factor Authentication
    azure-policy.PNG
    Centrify also provides Risk-based Access Control.
  5. Workflow and Approvals (Natively or via ServiceNow™)
    azure-workflow.PNG
    azure-sn.PNG
    Centrify can do native or ServiceNow™ approvals.  For more informationa about ServiceNow integrations, visit the ServiceNow TechCenter.

 

Providing Federated Access and Just-in-time Provisioning for  Azure

Just like any other SaaS application, Azure provides federated access.  In this particular case, the same functionality used for Office365 federation, provisioning and license management.  The benefits of leveraging Identity Service is that there's no need for the additional complexities and overhead of native solutions like ADFS, plus, there's added capability like we've seen above.

 

 

Benefits of using Federation and Provisioning in Azure

Users come from AD as the identity source.  This means that any add/moves or changes will reflect in the user's ability to access the service or any entitlements.
dwirth-azure.png

AD Security groups provide 2 great benefits around entitlements and provisioning:

  • This is because direct assignment paths are not the recommended practice.
  • You can allow the provisioning of access and roles from a single AD group membership.  

apache-admin.png

 

Just-in-time Provisioning

Traditionally, Microsoft has positioned DirSync as the tool for O365 provisioning; along with ADFS these are mature and effective solutions, however, they promote fragmentation.  With Centrify, both federation, policy, workflow and provisioning settings can be managed with a single administrative experience.

advanced-prov.png

License Management

This is another component of O365 and Azure.  Centrify allows the centralization of these efforts and the allocation based on different provisioning rules.

azure-lic.png

For more information about how to leverage Identity Service for Azure or O365 federation, provisioning or license management, visit the O365 TechCenter.

 

Accountability 

Centrify provides several dimensions to measure application access or to determine assigned or provisioned apps.

This allows security operations to obtain timely information about events, plus the ability to attest application assignment or provisioning.

 

 

app-launch-events.png

dwirth-azure-2.png

 

Conclusion

Centrify Identity Service will allow you to meet or exceed the controls required to secure Azure portal access and to provide granular access werther you are leveraging the Azure's cloud directory or are federating with your existing on-premises Active Directory.

 

5-Minute Video

 

Resources and Related Links

Security Kaizen - Part III: Web Apps, Mobile/Mac and MFA

Part I | Part II | Part III | Part IV

In the first two articles of this series we have discussed some metrics that can help security analysts in the evaluation of their access and privilege management models in a Centrify deployment using Server Suite.

 

The whole premise is to treat the process of limiting access/privileges as a subject of a continuous improvement cycle where we apply root-cause analysis and implement improvements to the security posture of the organization. 

 

In this third iterationid-service.PNG we're going to shift gears to other areas of the Centrify world and we'll focus on web applications.  In this entry we'll focus on Centrify Identity Service.  CIS  is a best-of-breed Identity as a Service solution that provides simple federated SSO, self-service, mobile device/application/container management and much more. What you'll see below is included with the product in the form of reports and dashboards;  in addition to these capabilities, we have released an analytics engine that is a companion to CIS.  Read all about it here.

 

With CIS, we're going to discuss these dimensions:  Apps, Users (including admin users), Roles, MFA and Mobile.

 

Application Dimension

When dealing with Applications, one of the most common goals in the context of access management is to consolidate application authentication patterns.  The principle is to move away from local user/password repositories because this is one less point of risk and compliance enforcement.  For each user/password app, security analysts must worry about alignment with policy, roles/rights, mitigation for advanced threats, attestation, etc.  

If an application is using a modern approach (like federation) is easier to provide the assurance of compliance and this also makes the application much more portable.

 

Total Deployed Apps

The first place to start is to identify your application real-estate.  Understanding how many applications are deployed in your environment is the first place.

select count (*) from application; 

Apps not in use

Another great piece of information is to find out what applications are not in use.  If an app is published and has no audience, perhaps this needs to be reconsidered.  This can be found under Reports > Applications > Unused Web Apps

usused apps.png 

% of Apps using Federation

As stated above, the goal is to eliminate user/password applications.  You can create a ratio of total apps that support federation / total apps; this will give you a good target percentage; since some apps are kept due to legacy and political reasons, each app move to modern patters may be a project or a program in itself.

As an example, you can modify one of the built-in reports to obtain the SAML-capable apps from the existing installation:

select ID AS _ID, DisplayName, WebAppType, Category, Description 
from Application
where WebAppType='Saml'
order by AppTypeDisplayName, Category, DisplayName

saml-apps.png

Unique application launches and App launch events

app-launch-events.pngapplaunches.png

Although these are operational metrics, they are correlated with user activity and roles (see below);  For example in the pics above I've drilled on App launches related to the Amazon root account and the IAM federated app.  This is because those apps are use by very high-privileged users.

 

Most Commonly Used Apps

This can be generated as a report;  commonly used apps may indicate heavy line-of-business apps and is an indicator of potentially-sensitive information.
apps.PNG

Look at the Top apps in this example:  Salesforce (sales/customer data); Office 365 (all kinds of data), Workday (employee data).

 

There are multiple areas to focus on apps (including mobile) but let's focus on the CIS user view.

 

User Dimension

Users in Identity Service can have assigned applications, provisioned applications and roles.  Roles may be used for application access (RBAC) and for privileges in the platform.   

 

Assigned Apps (user)

assigned-applications.png

The goal continues to be the least access principle and we want to make sure that users only have access to the apps that they need. 

 

Provisioned Apps (user)

provisioned-applications.png

Provisioned apps allow for just-in-time provisioning (or de-provisioning) of users and if supported, role assignments.

Notice how you can also identify anomalies.

 

Roles Assigned (and Entitlements)

role-user-view.png 

Note how a role also provides the user with privileges in the platform.

 

User Logins vs. User Failed Logins

logins.png

failed-logins.png

It's always important to review this type of activity, however Identity Service provides an additional dimension - geo-location;  this provides better intelligence for security operation decision.

failed-login-map.png

Any failure attempts in geographies that the enterprise does not have a presence should be flagged or subject to additional scrutiny.

 

Administrative User

 

Application Changes

Administrative users may change apps, roles and settings in the overall platform.  Typically, when apps are being deployed, there are many changes being logged, but once an application is stable, it should be "locked"  and the changes should only be under approval by change control committee unless there's emergency changes needed.

 

app changes.png

 

Role Changes

Activities in this area depend on the RBAC model implemented.  If administrators make membership changes directly on the Identity Service roles, then activity will reflect natural business operations;however, if using the target groups (e.g. AD security groups), then the changes to roles should be minimal.

role-changes.png

 

Challenges and  Multi-factor Authentication

 

MFA is a key part of Identity service and the metrics around this capability can be very useful to understand user behavior and potential threats.  Identity Service supports different types of authentication profiles that may include Smart Card/YubiKey/OATH as MFA methods and SMS, phone factor, and e-mail as step-up methods; it can also support RADIUS challenges to accommodate for legacy tokens like RSA SecurID, Vasco or Symantec.

 

Successful and Failed Challenges

faild-logins.png

A challenge happens when MfA is invoked, therefore a failed challenge is a causal factor behind failed logins.

 

Challenges and Authentication Events

chall-type.png

Pay special attention to failed challenges;  these are instances in which an MFA  (or step-up) mechanism has been invoked but it hasn't been satisfied.  Repeated attempts are subject to security alarms.

 

Authentication Events - Pattern

auth-events.png

Authentication patterns are relatively predictable in some organizations (this depends on their timezone footprint), this means that you should understand a normal ratio (e.g. failed challenges/total challenges) over certain periods of time (after all, users miss challenges), but any spike, especially outside normal hours should be a subject of additional investigation.  Notice the change on the wave pattern once we hit Saturday (18).

 

 

Mobile

Stats around mobile could be geared towards maintaining device conformance to a standard (e.g. minimum version for iOS shall be v10), understanding the make-up of the devices and making sure that capabilities that are compensating controls for data protection or leakage are deployed.

 

Enrolled Device Compliance

dev-comp.png

In this metric it's important to understand what are the key components of device alignment with policy.   As new mobile devices and OSs are deployed, capabilities may evolve or can be superseded for better ones.  User intervention is also a challenge when it comes to mobile devices, however, organizations can have stronger policy in corporate-owned devices vs. devices brought by the end-user (BYOD).

 

Device Status

 

status-dev.png

A large percentage of unreachable devices may mean that if you're using self-service enrollment, you may be allowing too many of them.   For example, a limit of 2 devices is preferable than 5 (default).

 

Device Real Estate

dev-realestate.png

This pie chart provides the answer to a key question - how many devices are out there and what's the make-up. 

dev-os.png

Identity service provides a set of policies that provide the assurance that users can't enroll older devices that may not be subject to manufacturer updates that are vulnerable to risks. 

 

Resources

Background

ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  This is the fourth article in the series.  We have covered  ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and setting-up and configuring Centrify App Request;  in this post we'll discuss the steps to set up Centrify Privilege Access Request to leverage the Service Catalog to request login or password checkout of resource accounts in Centrify Privilege Service.

 

About Centrify Privilege Service (CPS)

CPS is a privileged identity management solution that focuses on shared secrets on UNIX, Linux, Windows, Network devices, AD domains, Oracle or SQL databases and more.  The approach is different than Server Suite that is focused on the principle of least privilege.  Privilege Service provides a built-in access request system with single and multi-level approvals.

checkout.PNG

 

Privilege Service's Workflow  vs.  ServiceNow Self-Service

We often get questions about what solution to use for self-service and approvals for application or privilege requests.  The answer is quite simple:  if you already have all your requests in ServiceNow, you should continue to do so, this helps standardization and a unified user experience.  The Centrify workflow engine is designed to meet the basic needs for Centrify products and ServiceNow is a full-fledged Service Management solution.

 

We'll continue to use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology and assumes you have working knowledge of Identity Service and ServiceNow.

 

What you'll need

  • A SaaS instance of Centrify Privilege Service with UNIX, Linux, Windows or Network Devices configured.
    Note:  You can use an on-premises instance as well, provided that the network (e.g. publicly-facing) and name resolution (publicly-resolvable) aspects of the design are taken care of.
  • A ServiceNow Instance that allows you to install apps  (non-developer) with federated access to your Privilege Service instance.  For details on how to set up SAML federation with the Multi-provider SSO, click here or review the links below.
  • Administrative accounts on both systems

 

Planning

During planning, discuss with your infrastructure, operations and security teams about these topics:

  • Will you have a single approval or multiple approval groups per resource?
    Depending on the resource(s) in question you may have a single group or multiple groups approve.  You may also use a default approval group. 
  • How will the workflow be designed?
    This topic is very organization-dependent.  Some organizations may chose to have automatic approvals for certain systems and human approvals when the systems host sensitive data or are subject to strong security policy or regulations like SOx, PCI, HIPAA and others.
  • Have you identified a Default Approval Group in ServiceNow?
    If you chose to have a single group approve all privileged requests.
  • Have you created a CIS role and policy set for the servicenow service account?
    The servicenow account in Identity Service requires at a minimum the "Privilege Management" right, in addition, a policy that allows for username/password is required since the REST calls used by the app can't answer multi-factor authentication requests.
  • Will you have SLAs tied to your application requests?
    Although not in the scope of this post, SN offers a lot of flexibility when designing workflows including expiring worfkow requests when they are not approved within a defined duration.

 

Implementation

Overview

  • Create an Identity Service user (the service account that SN will use to authenticate and perform actions)
  • Create an Identity Service role with the minimum rights (the role that will be assigned to the service account)
  • Create an Identity Service Policy to allow user/password login
  • Download and Install Centrify Privilege Access Request app from the ServiceNow App Store
  • Configure the Centrify Privilege Access Request app

Create a Service Account

For this integration, you'll need a service account (you should know how to create users to follow this article).  To practice least privilege, this account needs to belong to a role with the Privilege Management right.   This is to be able grant login or password checkout rights on the accounts on each system.  Centrify Directory users are created under Admin Portal > Users

sn-create-serviceuser.png

When creating the user, be mindful of options that can cause an outage (like password expiration), and practice proper rotation and complexity based on your internal policy.

 

Create a Role with the minimum rights

To create a role, you have to go to the Admin Portal > Roles and Press Add role.  In the  members tab, add the newly-created account and in the Administrative rights tab, select the privilege management right.

 

privman.png 

Once completed, press the save button.

 

Create Policy to allow user/password login

This step may require you to create an Authentication profile that only asks for password (Admin Portal > Settings > Authentication > Authentication profiles).   The reason being is that Identity Service will (by default) ask for a step-up method for any unknown connections. 

 

  1. Log on to the Admin Portal with an administrative account
  2. Go to Policies > New Policy
  3. In Policy Settings, scroll down and select the "Specified roles" radio button
  4. Press Add and browse for the role created in the previous step.
  5. On the left pane expand User Security Policies > Login Authentication and select Yes to enable.
  6. Under default profile (used if no conditions matched) select your Auth profile that only challenges for password.
  7. Press Save
  8. In an incognito window for your browser, try to log in to the service with the newly-created account.  You should only be prompted for username and then password.

policy-summary.png

Important:  Make sure that the policy only applies to the members of the role created for this integration.

 

Download and Install the Privilege Access Request App from the ServiceNow Store

  1. Go to the ServiceNow app store and search for Centrify.
    priv-req.PNG
  2. Click on the Centrify Privileged Request App
  3. Click "Get" to make the Centrify Privileged Request app available for your ServiceNow instances.
  4. Go to the ServiceNow instance, select System Applications > Applications > Downloads to locate the app then click Install to install it.

Configure the Centrify Privileged Access Request app

There are three configuration tasks required.  Properties, API Sync and Accounts.  The third category is only needed if you are using individual groups as approvers for each resource's account.
Properties
  1. In the application pane (left) navigate to Centrify Privilege Request > Properties.  Populate these three fields
    Centrify Cloud Tenant URL:  the URL for your identity service tenant.  (e.g. https://your-tenant.my.centrify.com)
    Centrify Cloud Service Account: the account you created in previous steps
    Centrify Cloud Service Account Password:  the strong password you created for the user
    sn-app-access-conf1.png 
  2. Default Approval Group (Optional):  now you have a decision to make based on the planning above.  Populate the "Default Approval Group" if you decided to use a single ServiceNow group to approve all privilege requests.  You have to find the group in ServiceNow (System Security > Groups; find the group, right-click it and "Copy sys_id" and paste it on the Default Approval Group.  If you are planning to have approval groups per App, then you leave the field empty and press Save.

API Sync

  1. Go to Centrify Privilege Request > Customize API Sync
  2. Set the Active checkbox
  3. Select an appropriate interval based on your SLAs (e.g. 1 hour)
  4. Press Save and then Execute Now.
    api-sync.png
    This process will synchronize the Resources (systems) and accounts available in Privilege Service

Accounts
If you set up a "Default Approval Group" you can skip this part.  At this point you have to have a list of all the apps and the corresponding approval groups.  For example, the root account in the CentOS system called engcen7 will be approved by the Team Development Code Reviewers group included with the sample data of the ServiceNow instance and the canned workflow for software.

root-apprv.png 

 
Verification

To verify the functionality of the app, you'll have to run through the workflow of the apps (or independent apps) based on the approval group defined.  For example, in my scenario I chose to have independent approval groups.  My requester wants to checkout the "api-key" resource under the azure-rh1 resource and the self-service request is automatically approved based on existing ServiceNow rules.

 flow.png

 

Once the request is approved the app will provide the requester access to the type of request (login for SSH or RDP access) or checkout (for password reveal or clipboard copy).  In order to get access to the system or retrieve the password, the requester must switch over to privilege manager and find the system in the resources list or in their favorites.  For login they can use the PuTTY or web client and to check-out the password, they can use the system resource on privilege manager or the mobile app.

 

Documented Approvals

Security analysts and auditors may require reports of who has been requesting and approving apps, this is easily accessible using the service catalog requests or under the Centrify Privilege Request Access approvals or the Dashboard section.

requests.PNG

 

Improvements

Since this app focuses on ServiceNow approvals, the enhancements are around workflow design.  For example, you can have multi-approval groups, you can set timers for SLAs, etc.   However, there are other things that you can customize including the Dashboards and the appearance and location of the Centrify items in the Service Catalog.

helsinki.PNG 

Centrify & ServiceNow Resources

There are multiple resources available in the documentation and tech blogs:

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel