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

[How To] - Installing Centrify Connector

By Centrify Contributor III Friday - last edited yesterday

 Thank you for choosing Centrify!

 

The purpose of this guide is to help walk you through an installation of the Centrify Connector. The Centrify Connector is a feature rich lightweight application that provides the following services:

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

 

Server hardware requirements

The Centrify Connector is installed on a Windows computer to establish the communications link between the Centrify Identity platform and Active Directory domain controller.

 

If you are referencing accounts in an Active Directory tree or forest, the cloud 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. 

 

This computer must be in your internal network and meet or exceed the following requirements:

  • Windows Server 2008 R2 or newer (64-bit only) with 8 GB of memory, of which 4 GB should be available for Centrify Connector cache functions.
  • Has Internet access so that it can access the Centrify Identity Services platform.
  • Has 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 it isn’t already installed, the installer installs it for you.
  • Be a server or server-like computer that is always running and accessible.

 

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-04-21 14.52.00.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 proxy server, add those 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 Centrify Connector requires read permissions to the Deleted Objects container in active directory. This permission is required for the auto de-provisioning feature to appropriately delete/disable users from applications when deleted or disabled in active directory. If you are using an account that has read permissions to the Deleted Objects container, such as a user with Domain Admin and/or Enterprise Admin level permissions to the domain, the Connector will inherit the permissions of the account automatically. Click ‘Next’ to continue.

 

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, you can specify alternate 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 Centrify Connector connection to your Centrify Identity Service tenant has appeared and the connection was successful - designated by statues of ‘Active’. If you have multiple Centrify Connectors, you will see each instance of those connections listed in this menu. 

 

23 - cloud connector confirmation.png

 

We hope you found this guide helpful. Feel free to post questions in this thread or contact Centrify for additional information. 

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 an end-to-end guide for integrating Concur with the Centrify Identity Service platform. The integration helps to eliminate identity silos with administrators having to manage user's access across multiple systems and end users having to remember multiple usernames and passwords. The integration allows administrators to manage user's access from one common directory (i.e. Active Directory), including inheritance of your active directory group policies to secure access to Concur. End users enjoy the benefit of single sign-on to Concur, leveraging a credential they already know and use on a daily basis - their active directory credentials. 

 

Install time ~ 1-3 hours

 

Requirements

1) Concur account

2) Centrify Identity Service account

3) Active Directory

4) 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 an end-to-end guide for integrating Zendesk with the Centrify Identity Service platform. The integration helps to eliminate identity silos with administrators having to manage user's access across multiple systems and end users having to remember multiple usernames and passwords. The integration allows administrators to manage user's access from one common directory (i.e. Active Directory), including inheritance of your active directory group policies to secure access to Zendesk. End users enjoy the benefit of single sign-on to Zendesk, leveraging a credential they already know and use on a daily basis - their active directory credentials. 

 

Install time ~ 1-3 hours

 

Requirements

1) Zendesk account

2) Centrify Identity Service account

3) Active Directory

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

[HOWTO] Setting-up the ServiceNow Centrify Privilege Access Request App

By Centrify Guru I on ‎02-13-2017 09:54 PM - last edited a week ago

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:

This article will show you how to only allow access to a web application from a device that has been enrolled into Centrify's MDM. Please note these instructions may change in the future.

 

Enroll your device into Centrify MDM

 

Configure your web application

1. Log into the Centrify Admin Portal.

2. Edit your web application and select Policy from the left column.

 

Restrict to managed devices.png

 

3. In the right pane, select the checkbox to "Use script to specify login authentication rules (configured rules are ignored)"then click on the Load Sample button. A new window will appear.

 

use script policy.png

 

4. Select the option "require strong auth for unmanaged devices.js"then click on the Load button.

 

script sample.png

 

5. In the policy script, change the value for policy.RequiredLevel  to 0. This will deny access from devices that are not managed by Centrify.

 

 edit policy script.png

 

6. Select a Default Profile to Always Allow or a predefined authentication profile to perform multi-factor authentication to access the web application. This determins if the user is logging in from a managed device. Press Save when your configuration is complete.

 

default profile.png

 

To restrict web application access based on time, location, or other device conditions:

See instructions.

[How to] create and publish a new username/password app for Cloudera Manager.

Read more...

[How To] Basic Windows MFA with Centrify Identity Service Guide

By Centrify Contributor III on ‎01-20-2017 09:09 AM - last edited ‎01-23-2017 10:26 AM

Thank you for choosing Centrify!

 

Centrify would like to share another feature: multi-factor authentication on Windows workstation login. With the Centrify Identity Service solution, you can enforce multi-factor authentication to users attempting to access Windows workstations, with 2-factor options such as telephone call, email and Centrify's mobile authenticator (TOTP) utility. The solution works in both an online and offline mode, so workstations disconnected from the internet are also able to authenticate with multi-factor authentication to their machine. 

 

This guide is a basic demonstration of how to setup multi-factor authentication for the following use cases. 

 

   - MFA at interative login

   - MFA on RDP access

   - MFA on screen saver unlock

   - MFA in offline mode

 

Configuration time ~ 1 hour

 

Requirements

1) Centrify Identity Service license

2) Domain joined Windows machine

 

Lets get started!

 

1) Logged in as administrator to your Centrify Identity Service console, start by creating a Centrify role. This role will contain the Windows workstations you want to enforce multi-factor authentication on.

 

1 - create centrify role.png

 

2) Add the workstations you want to enforce multi-factor authentication on by searching for the resource and clicking 'Add'. 

 

2 - adding desktop.png

 

3) Under 'Administrative Rights', assign the Centrify role the "Computer Login and Privilege Elevation" right. This allows the service to deliver a multi-factor authentication profile (created in the next step), to the workstations you've added to the role.  

 

3 - administrative right.png

 

4) Next, create an 'Authentication Profiles' that contains the available factors that are appropriate for users to authenticate with. 

 

3.1 - authentication profile.png

 

5) Assign the 'Authentication Profile' to the 'Login Authentication Profile' and 'Privilege Elevation Authentication Profile' fields. 

 

 

3.1 - authentication enforcement.png

 

6) Next, download the Centrify agent from the 'Downloads' dropdown within the Centrify Administrator's portal. 

 

4 - downloads.png

 

7) Download the 'Centrify Agent for Windows' .msi file. 

 

5 - download agent.png

 

8) Install the Centrify agent on each workstation you would like to enforce multi-factor authentication on. Note: The workstation must exist within a Centrify role for the Centrify Identity Service solution to deliver the multi-factor authentication profile to the machine (refer to step 2). 

 

6 - install 1.png

 

9) Review and accept the Centrify End-User License Agreement.

 

7 - install 2 eula.png

 

10) The Centrify agent can be enabled with 'Audit'; a feature that allows for recording of sessions for future playback. If you have purchased the audit feature, you can enable this feature in addition to the default 'Access' option. If you do not have the audit feature, keep the default settings and click 'Next'. 

 

8 - install 3.png

 

11) Once the installation is completed in step 10, click 'Next' to continue setup of the agent on the workstation/server. 

 

9 - install 4.png

 

12) The following step is applicable if you are using Centrify Server Suite, designed for securing privileges and requiring multi-factor authentication at server logins or privilege elevation. If you are a Server Suite user, the following post will guide you through configurations at this step http://community.centrify.com/t5/TechBlog/HowTo-Configuring-MFA-for-Windows-Login/ba-p/26126

 

For purposes of this guide, keep the default settings by leaving the 'Join to a Zone' unchecked and click 'Next' to continue.  

 

10 - install 5.png

 

13) Ensure that the 'Enable multi-factor authentication on Windows login' is selected. You also have the option of enforcing multi-factor authentication for all active directory users or selectd active directory users logging into the machine. Click 'Next' to continue. 

 

11 - install 6.png

 

14) Click 'Finish' to complete the installation and setup. 

 

12 - install 7.png

 

15) A restart is required to complete installation and setup of the service. 

 

13 - install 8.png

 

16) Upon restart, login to the workstation. During login, you will now see a drop down with the multi-factor authentication options required for login. Login to the machine with one of the factors. 

 

Note: The user must have the available attributes in their user profile for the option to be available to them during login. For example, if a user does not have a telephone number in their active directory profile, and the telephone number is selected as one of the available factors, the telephone option will not be displayed to the user in the drop down. 

 

14 - login MFA.png

 

17) After logging into the workstation, 'Setup Centrify Offline Passcode' will display. This allows a user to successfully authenticate, with multi-factor authentication, to the workstation when the machine is offline. Click on the 'Click here to create your offline passcode'. 

 

 

15 - offline mode.png

 

18) Click 'Next' to setup offline mode. 

 

16 - offline mode setup.png

 

19) The Centrify mobile application can be leveraged for the creation of a passcode for offline mode. More generally, you can use utilities that supports OATH to also setup your passcode using existing utilities of preference in your organization. Examples of such utilities are the Centrify mobile app and Google Authenticator. 

 

17 - offline code setup.png

 

20) Click 'Finish' to complete the offline passcode setup. 

 

18 - offline code finish.png

 

21) Test the offline mode by taking the workstation offline and using the offline passcode to log back into the machine. 

 

19 - offline mode login.png

 

The following guide is intended to demonstrate the steps required for enforcing multi-factor authentication on Windows workstations using the Centrify Identity Service solution. Centrify strongly encourages deployment and administrative guides along with testing the solution prior to enterprise deployments.

 

We hope this guide was helpful and welcome questions you may have in this thread. 

 

Thanks!

 

This article will help you configure single sign-on from Centrify Identity Service to Splunk Cloud.

Read more...

Want to configure wireless settings for your users without having to manually touch each device? With the Centrify Identity Service, WiFi settings can be pushed to Mac, iOS, and Android mobile devices using policy.

Read more...

Introduction

This article is an attempt to provide the background information, tools and mechanisms to spot and correct Public Key Infrastructure-related issues for those who are setting-up Centrify Multi-factor Authentication or trying to enroll Identity Broker clients.

 

Background

Public Key Infrastructure is at the heart of how many Internet and corporate infrastructure services are secured today and Centrify has always provided ways to make PKI simpler for organizations.  A big example is adcert, this tool provides support for enterprise trust and auto-enrollment for Microsoft Certification Authority for UNIX, Linux and Mac. 

 

After the introduction of Identity Service and Privilege Service and the advent of high-profile data breaches and industry guidance like PCI 3.2 Data Security Standard (Requirement 8, Sections 3, 10, 11 & 12), many organizations are rushing to implement Multi-factor Authentication.   Another big milestone is the popularity of hybrid clouds;  Centrify has introduced a new capability called Identity Broker, this new Linux Agent allows organizations to "enroll" in Centrify Privilege Service and to "bridge" multi-source enterprise directories like Active Directory, LDAP, Google Directory and Centrify directory.

 

All these scenarios make use of Public Key Infrastructure to establish the assurance that clients are talking to the right entity (non-repudiation) and encryption in transit is enforced.  An important point to understand about every Centrify SaaS or on premises tenant is that it has an internal certification authority that is used for multiple uses including encryption, non-repudiation, mobile management and authentication.

 

PKI Trust and Multi-factor Authentication

With Centrify Identity Service and Privilege Service, it's possible for current users of Centrify Express or Centrify Standard Edition to implement MFA in a very quick and effective way; supporting both modern and legacy-based (RADIUS) solutions.  In the platform's 16.10 release, Centrify proactively deprecated Integrated Windows Authentication (SPNEGO) over HTTP to exclusively use HTTPS.  

Before release 16.10, Centrify announced the deprecation of IWA over HTTPBefore release 16.10, Centrify announced the deprecation of IWA over HTTP

The implication for users is that any interaction that used IWA (SPNEGO) required PKI trust in the authentication framework for MFA negotiation.

 

This means that framework after 16.10 looks like this:

mfa model.png

As you can see from the framework above, there are 3 ways you can make sure the PKI requirements are satisfied:

  • Enterprise Trust:  This is the preferred method. Ideally, an organization has a properly-implemented PKI trust capability. Unfortunately, this is relatively obscure especially in the mid-market.  A great benefit to organizations using Microsoft PKI is that Centrify DirectControl agents will take care of the enterprise trust automatically by bundling the Root and Intermediate CAs into the proper UNIX or Linux bundle.
  • Public Trust:  This was a bit expensive a while back, but the easiest way to make sure that PKI trust works out of the box is to use certificates issued by a public vendor like Verisign or GoDaddy.
  • Tenant Trust:  Each Centrify tenant will automatically create IWA certificates for all the Centrify connectors in the deployment.  This means that customers can either manually, with DevOps or with Microsoft GPOs can set up a trust chain.  This can be automated but requires a bit of work.
    The tentant will give you the option to download the IWA root certificate or the connector's host certificateThe tentant will give you the option to download the IWA root certificate or the connector's host certificate

How to determine if your UNIX/Linux system is ready for MFA

Centrify provides a tool (adcdiag) that will allow users to spot issues with the MFA configuration.   For example, in a Centrified system with an AD environment with Microsoft PKI, the root CA certificate is automatically downloaded to the /var/centrify/net/certs folder and appended to the bundle corresponding to the platform.  

Here's a sample output from a Centrified system with Enterprise Trust:

adcdiag-explained.png

This output is favorable because DirectControl (adclient) is making sure a lot of the moving parts are in place including making sure that any root or intermediate CA certificates are in the trust chain.  The reason why this "just works" is because a few seconds after joining AD, and if the system is allowed to certificate auto-enrollment, the client will make sure all the proper certs are provisioned to the system and the CA bundle is updated.  This makes this process work like plug and play. 

 

In cases when there is no trust, then the ca-bundle has to be updated with the IWA trust certificate from the tenant.  When you run the adcdiag, several checks will fail including this one:

cntrcfg.png

 If you inspect the file referenced by adcdiag, there will be the following information in this section: 

"Error setting certificate verify locations" and this will point to the CA bundle for the platform (e.g. /etc/pki/tls/certs/ca-bundle.crt).  There are several ways to solve this issue:

  • Enterprise:  Appending the root CA certificate in PEM format to the CA bundle file
  • Public:  Making sure the CA bundle is up-to date
  • Tenant:  Appending the IWA root ca in PEM format to the CA bundle file.

 

Fixing MFA CA Trust issues in UNIX/Linux platforms

You'll need to know:

  1. How to get the certificate in question
  2. The encoding of the certificate you're receiving
  3. The location of the bundle for the operating system in question
  4. For large production deployments, you'll need to use a viable distribution method

 

Scenario

adcdiag failed in a CentOS 6 system.  The issue is with the /etc/pki/tls/certs/ca-bundle.crt.  I am working with a SaaS instance of Identity Service.

Locate the IWA Cert and Determine the Encoding

  1. In Admin Portal > Settings > Network > Centrify Connectors > click the connector > IWA Service  and click "Download your IWA root CA certificate"
    iwa.png
  2. Locate the file and try to open it with a text editor.  If the text reads "--- begin certificate"  you are dealing with a usable certificate.
  3. Save the file and transfer it to your target system (e.g. IWACert.crt)

Append the certificate to the CA bundle

  1. In the target system, concatenate the contents of the certificate file to the platform CA bundle.  E.g.
    $ sudo cat /home/user/IWACert.crt >> /etc/pki/tls/certs/ca-bundle.crt
    Note:  there are OS utilities like "update-ca-trust" that perform this step the correct way.  This is for illustration only.
  2. Re-run adcdiag and verify the results.

Enterprise Environments

As you can see, the steps above won't scale in a large environment.  This is why the preferred method is to have enterprise trust in place.  Other ways to distribute certificate settings include scripts, DevOps solutions like Chef or Puppet and in Microsoft PKI scenarios, you can use Group Policy.

 

How to determine if your Windows system is ready for MFA

Windows systems may be easier to work with when it comes to Enterprise Trust but  you have to be skillful to troubleshoot as well. 

 

Windows Tools

  • Certificates MMC snap-in:  This allows you to review all certificate store.
    Note that you have to be a local administrator to view the computer certificate store and that Centrify will add certificates in the local store of systems running the Connector.
    Make sure you review the Enterprise Trust certs in that scenario.Make sure you review the Enterprise Trust certs in that scenario.
  • Certutil:  This is one of the most powerful tools around "certutil -viewstore root" will display the trusted root CAs.

 

Centrify Access Manager

This Microsoft management console provides the capability to perform an end-to-end testing in scenarios where DirectAuthorize Roles are being used for MFA.  You'll need to be at least on version 2016.
am-test.png

This option is under right-click Direct Manage Access Manager > Test Centrify Cloud Connection.

 

Diagnostics and Centrify Logger Service

 

The DirectAuthorize applet provides a "troubleshooting" tab that enables advanced capabilities like Diagnostics or Log inspection.

 

The diagnostics functon has been enhanced to help identify or troubleshoot issues with Identity Platform, this functionality is available if you are running version 3.4 (suite 2017) and above,:
dzwin-diag.png

 

The Centrify logger service is installed with Centrify Server suite.  You can add it to the Centrify Agent for Windows(tm) for advanced troubleshooting capabilities.
dzwin-logger.png

 

Identifying Issues

The Centrify Agent for Windows will provide you visual feedback when there's a PKI-related issue (see below) but internally it's checking the Certificates directory under \ProgramData\Centrify\DirectAuthorize for the binary blob that represents the tenant's certificate.

dzwin-error.png

 In this case, the same solutiona applies, but in this case, we're placing the certificate in the trust store for Windows.

cert-import.png

Like we discussed before, in large Enterprises, ideally Enterprise or Public trust is set up with automation tools or Group Policy.

Microsoft provides a great article on the topic:  https://technet.microsoft.com/en-us/library/cc772491(v=ws.11).aspx

 

 Bottom-line:  When attempting to configure MFA, don't forget this checklist:

  • Is there a PKI trust between the system and the Centrify service?
  • Can the system authenticate via Kerberos?  (is it joined to the domain natively (Windows) or via Centrify (UNIX/Linux))
  • Is the machine added to a Centrify role that allows for Computer Login?
  • Are all the ports required for communication cleared  (8443 or custom)?

 

PKI Trust and Identity Broker

Identity Broker is Centrify's newest capability that allows for multi-directory authentication in private or public clouds.

IB also requires trust for operations like enrollment. 

 

Identifying issues with cdebug

Depending on the state of the Linux system (if the ca-bundle is non-existent, modified or outdated) the enrollment operation will fail.  Let's look at a failed enrollment log using two PuTTY windows.

 

Window 1:  /usr/share/centrifycc/bin/cdebug on
Window 1:  tail /var/centrify/centrifycc.log -f

Window 2: cenroll -t tenant.my.centrify.com -c [code] -F all -l Identity-Broker-Users
Window 2: Failed to initialize connection to Centrify identity platform: Failed to connect to Centrify identity platform
Window 1:
Dec 17 18:16:07 engcen6 cenroll[9201]: DEBUG <centrify/cloud.post> Failed
to post HTTP request: Post https://tenant.my.centrify.com/health/ping:
x509: certificate signed by unknown authority

 This can be further verified with the cURL command:

$ curl https://tenant.my.centrify.com
$ curl: (77) Problem with the SSL CA cert (path? access rights?)

Remediation

In this particular case, my tenant is on-premises Privilege Service, so I  can follow the instructions on this KB:

KB-7973: How to configure Linux machine trusted certificate chain to perform enrollment for Centrify...

The steps are very similar to the ones outlined above.  The strategy depends on the use case Enterprise, Public or Tenant trust is being used.

 

When trying to enroll, the output is very different:

Verbose: Platform detected: centos_6_6_standard
Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy...
Enrolling in Centrify identity platform https://bootcamp.my.centrify.com/ using registration code...

Starting Centrify agent...
Centrify agent started.
Verbose: Trying to connect to Centrify identity platform [https://tenant.my.centrify.com/] without a proxy...

Feature enabled: Application-to-Application Password Management
Feature enabled: Centrify Agent Authentication

Verbose: Restarting Centrify agent after enabled features...

You have successfully enrolled in Centrify identity platform: https://tenant.my.centrify.com/

You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operations. Failure to do so may result in
login problems for cloud users.

 

Constant Improvement

At Centrify capabilities change to provide ease of use and supportability.  We hope this article can help you anticipate issues with your testing or setup.  Ultimately, at the enterprise level, PKI is a vital capability that has to be taken seriously and designed to balance the people-process-technology triad. 

If you're an existing Centrify customer, you may have seen recent news about the capability to support Multifactor Authentication at Windows Login. This article explains how to set this feature up in your Centrify Server Suite and Centrify Identity Service environment. 

Read more...

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 third article in the series.  We have covered  ServiceNow federation using Multi-provider SSO, setting-up automatic provisioning with the Centrify Identity Service App and in this post we'll discuss the steps to set up Centrify App Access ServiceNow to add workflow and approvals to Centrify Identity Service applications.

 

Centrify's Access Request vs. ServiceNow Workflow

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 Centrify Identity Service Instance with some published apps assigned to roles
  • 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 application?
    Depending on the application(s) in question you may have a single group or multiple groups approve.  Or have approval groups per app as well.
  • How will the workflow be designed?
    This topic is very organization-dependent.  Some organizations may chose to have automatic approvals for simple apps and human approvals when the apps require a license or will add access to sensitive data.
  • Have you identified a Default Approval Group in ServiceNow?
    If you chose to have a single group approve access to all apps.
  • Have you mapped all Apps to ServiceNow groups for the purposes of approval?
    E.g. the "twitter" app is approved by the Social Media group;  the "O365"  app is approved by the manager and then the security department.
  • 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 "Role Management" and "Application Management" rights, 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
  • Create an Identity Service role with the minimum rights
  • Create an Identity Service Policy to allow user/password login
  • Download and Install Centrify App Access from the ServiceNow App Store
  • Configure Centrify App Access

Create an Identity Service user

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 two rights:  Application Management and Role Management.   This is to be able to modify role membership and application attributes.

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 an Identity Service role with the minimum rights

When you create the role, grant the two rights illustrated below and add the previously-created user to this role.

sn-svc-acc-rights.png

 

Create an Identity Service Policy to allow user/password login

This step may require you to create an Authentication profile that only asks for password (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 Identity Service 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 Identity Service App from the ServiceNow App Store

  1. Go to the ServiceNow app store and search for Centrify.
    sn-app-access.PNG
  2. Click on Centrify App Access
  3. Click "Get" to make the Centrify Identity Service 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 Centrify App Access

There are three configuration tasks required.  Properties, API Sync and Applications.  The third category is only needed if you are using individual groups as approvers for each app.
Properties
  1. In the application pane (left) navigate to Centrify App Access > 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 application 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 App Access > 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.
    sn-api-sync.png
    This process will synchronize the CIS Apps and Roles available with ServiceNow.

Applications
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 "Amazon as root" app will be approved by the Software group included with the sample data of the ServiceNow instance and the canned workflow for software.
sn-req-approval.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 (Stewie) will request the app and this request has to be approved by ITIL user.

 

sn-app-workflow3.png

Once the request is approved (and the underlying task) the app will perform the provisioning of the role that grants access to the application and the icon will show up automatically.

 

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 App Access approvals section.

 

Improvements

Background

ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  In this post we'll discuss how to use Centrify Identity Service to secure ServiceNow by using the Multi-provider SSO plugin.  In subsequent posts we'll discuss provisioning, protecting shared credentials, using the Centrify ServiceNow store apps.

 

Why secure ServiceNow with Federated SSO?

There are multiple security and operations-related reasons to implement federated identity and SSO for ServiceNow.  A key reason is related to the fact that SN is a SaaS platform, this means that the enterprise is extended and information is accesible outside the enterprise datacenter.  Using federated SSO, allows the use for on-premises identity and access control to secure assets outside the enterprise.  This provides the assurance that only authorized internal users can access those assets.  Another reason is usability with SSO there's no need to duplicate passwords; finally there is the gains in operational efficiency by using a process (like adding a user to an AD group to provision access) or simply disabling the AD user account will disable access to ServiceNow automatically.

 

We'll use the Plan-Do (Implement)-Check (Test)-Adjust (Enhance) methodology:

 

What you'll need

  • A Centrify Identity Service Instance
  • A ServiceNow Instance or a Developer Instance (Fuji, Geneva or Helsinki)
  • Administrative accounts on both systems

Planning

Here are some planning topics for your ServiceNow/Centrify Identity Service Integration

  • What are the user populations that will have access to ServiceNow?  (e.g. AD, LDAP, Google Directory, etc.)
  • What will be the uniquely-identifying field to be used with the SAML assertion?
  • What will be the name for the CIS Role?  (e.g. SN Users)
  • Is the Multi-provider SSO plugin activated in the instance?
  • Will you use the Centrify-provided x.509 certificate?
  • Will the assertion be encrypted?
  • Will provisioning be used?  Are the SN groups created?
  • Will the MPSSO with Centrify be set as default?  Will passwords be eliminated?
  • Will ServiceNow be accessible from inside or outside the enterprise?  Will time or geo-fencing mechanisms will be implemented
  • Should ServiceNow access be protected with multi-factor authentication?

 

Implementation

Overview
These are the high-level steps to configure Centrify Identity Service as a provider for SSO.

  • In Identity Service: Create a Centrify Role that will be assigned the Centrify App
  • In ServiceNow - Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin.
  • In Identity Service - Onboard  the  "ServiceNow - SAML + Provisioning"  template
  • In ServiceNow - Import the x.509 Certificate for the SAML assertion
  • In ServiceNow - Set-up, configure and enable the Identity Provider
  • In Identity Service - Configure the ServiceNow App

Create a CIS role with the ServiceNow users

  1. Log in to the Centrify Identity Service Admin Portal with a user with at least role management rights.
  2. Go to Roles > Add Role; in the Description tab, give it a name.
    sn-role.png
  3. In the Members tab, select the users from the target directory or directories, then press Save

 

Activate the "Integration - Multiple Provides Single Sign-On Installer" plugin

  1. Log into your ServiceNow instance with an administrative user
  2. In the Application Navigator (left pane), use the search feature and type "Plugins", this filters System Definition and click Plugins.
  3. Now in the right pane, next to System Plugins, in Name type  "Integration - Multiple"
  4. Click on "Integration - Multiple Provides Single Sign-On Installer"  (should be set as inactive, if it's not, skip to the next section)
  5. Under Related Links, Click "Activate/Upgrade" and Click Activate
    sn-activate.png
  6. After activation, the "Multi-Provider SSO" Application will be activated in ServiceNow.  This app contains these sections:  Getting Started, Identity Providers, Federations and Administration.
    sn-mp-sso.png

 

Onboard the  "ServiceNow - SAML + Provisioning"  template

  1. Sign-in to Identity Service with a user that at least has the Application Management right.
  2. In the Ad0min Portal go to  Apps > Add Web App, then search for "ServiceNow SAML + Provisioning"
    sn-cis-apps.png
  3. Click the Add button, confirm your selection and close the Add Web Apps window.
  4. In Identity Service, you'll be placed on the Application Settings tab for the ServiceNow app template, scroll down and click on Download Signing certificate
    sn-down-cert.png
  5. Open a text editor in your platform (Notepad, TextEdit or Vi) and open the downloaded file.  Copy the contents to memory.
    (Note:  the contents should be a PEM-encoded certificate)

 

Import the Certificate to the Multi-Provider SSO via x.509 Admin Module

  1. In ServiceNow > Multi-Provider SSO > Administration > x509 certs
  2. New Cert > Give it a unique name
  3. Format > PEM
  4. PEM Certificate >  paste the contents of memory loaded in the previous section
    sn-x509.png
  5. Press Save.

 

Configure the Identity Provider

  1. In ServiceNow > Multi-Provider SSO > Identity Providers
  2. Select New > SAML2 Update 1 > and when the "Import Identity Provider Metadata" pop-up comes up, select Cancel.
  3. At this point, you can use the table on this page to configure the settings.  This is because it depends on your directory source and optional settings.  Here's the configuration for a now decommissioned demo environment:
    sn-config.png
    Notes: 
    - The look and feel of the multi-provider SSO plugin varies between SN versions Fuji, Geneva and Helsinki.
    - The identity provider has to be set to Active and default if you want Service-Provider initiated to be possible.
    - The "Failed Requirement Redirect" is set to the same value as the "Identity Provider AuthnRequest."
    - The location of the x.509 certificate options varies.  You may have to press save to see the option in some versions of ServiceNow.
    - The default field option for the Identity Provider is email.  Modify this setting based on your planning and identity source field mappings.
  4. Once finished, press Save

 

Enable Multi-Provider SSO

  1. In the Multi-Provider SSO app , select the Properties module
  2. Check the "Yes"  box under "Enable multiple provider SSO"
    sn-enable.png
  3. Press Save.  This completes the ServiceNow set-up for SSO.

 

Configure the ServiceNow App in Identity Service

  1. In Identity Service, go back to ServiceNow > Application Settings
  2. If you haven't, type in the instance ID under "Your ServiceNow instance name", then click on User Access
  3. Check the box next to the Centrify Role that was created in the planning phase.  Click on Account Mapping
  4. Because in this example, we're using Active Directory as the user source, we are going to use "samaccountname"
    Note:  that's is the "username" field in Active Directory, therefore, the user ID in ServiceNow must match for each user.
    This is one way to do it, there is flexibility here.  Other common deployments use the email field.
    sn-mappings.png
  5. Testing your work in the Advanced page
    Use the test button with some users in the target role to make sure that the assertion will be correct.
    sn-testing.png

 

Testing

For testing, all you need to do is create an Active Directory Identity Service user and match the User ID in ServiceNow with the user's AD login name (samaccountname) and set it to active. 
sn-lisa.png
Since this will be an SSO user, there's no need to give it a password.  At this point you are set to perform Identity-provider or Service-provider initiated tests.

  • Identity-provider initiated login
    Log in as your AD user, to the Identity Service User Portal.  You should see the user's assigned apps including ServiceNow
    lisa-portal.png
  • Service-provider initiated login
    Go to your instance URL and select external login.  When you type-in the username, you'll either be re-directed to your Identity Service portal for authentication, or if you have a current session (or Kerberos ticket and IWA enabled), you'll be placed in the app.
    sn-ext-login.png

    Note that this behavior can be modified if the SN multi-provider SSO is set as default.

 

Enhancing the Implementation

There are several areas for enhancement, but these come to mind:

  • Enable Provisioning (next blog post)
  • Enable multi-factor authentication
  • Protect shared accounts
  • Enable workflow and approvals

Centrify-ServiceNow Resources

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

I was recently reading an article about AWS security blunders.  The article takes a very common-sense approach to what can be applied on any Public or Private Cloud.   

 

My personal observation is that many of the challenges on any public cloud relate to the complexities of extending enterprise capability out to a public cloud and Identity and Access Management is as the heart of it. Starting with the Amazon Account and IAM, these could potentially be managed in parallel from the current IT infrastructure; this slowly becomes a management nightmare while increasing security exposure.  

 

The good news is that at Centrify we provide products and capabilities to meet and exceed the Access Control requirements for AWS around IaaS and our platform is uniquely positioned to help you today.

 

plaform.png

 

Leverage your Identity and Access Management to secure your AWS IaaS

In the article, blunders like “not knowing who is in charge of security” typically happen due to infrastructure duplication and fragmentation.  Since everything starts with Identity, at Centrify we allow you to integrate Amazon’s Identity and Access Management (IAM) with your existing directory (Active Directory or LDAP) leveraging SAML or the Native APIs.

aws.png 

To address the issue of “giving away too many privileges” & “not taking root seriously”  securing the Amazon Account and Implementing Amazon IAM are key areas and quick wins that can be accomplished with minimal effort using Centrify’s Identity Platform. 

Here are a few Tech Blogs that cover this topic:

 gears.png

 

The article also mentions challenges with Passwords and Keys (“relying too much on passwords” & “exposed secrets and keys”).  Passwords exist in web apps, Linux and Windows servers and even within scripts (a very insecure habit).  A big benefit of the Centrify Identity Platform is that you can implement Shared Password capabilities for web apps (password walleting), and vaulting of Windows, Linux and other systems.

 

See a technical showcase on CPS here:  http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...

 

AWS and the Identity Challenge

A common strategy is to implement or extend Active Directory to AWS.  This will eliminate the need to rely on keys.  With products with our Centrify Server Suite, an access control and privilege management model can be implemented quickly and it provides a single-pane of glass that can provide security and visibility across Windows and Linux systems in AWS.  Learn more here:

http://community.centrify.com/t5/Community-Tech-Blog/A-Playbook-to-secure-your-Amazon-AWS-Infrastruc...

 

However, this does require either the implementation of AD in the cloud (new forest) or the extension by implementing a site-to-site VPN and using either a 1-way trust or an RODC setup.  Although these are great best practices for the enterprise, they come with cost and complexity when working with public clouds.

 

Exciting New Alternatives to Secure Extend your Enterprise Identity to AWS

With our November release of the Identity Platform, we are providing two exciting capabilities:

 

a) Centrify Agent for Windows:  Extends our award-wining Windows PIM capabilities to Identity Service or Privilege Service customers looking to secure Windows systems on console login, RDP or screen unlock.

methods.PNG

The back-end services supported are MFA methods like Mobile Authenticator, Yubikey, OATH Token or even your legacy tokens via RADIUS (e.g. SecurID, Vasco, Symantec), plus step-up methods like Phone Factor, SMS, or E-mail.

To see an article that covers this new capability, click here:  http://community.centrify.com/t5/Community-Tech-Blog/AWS-Shared-Responsibility-Login-MFA-for-Windows...

 

This new capability provides security mechanisms for organizations using Windows systems as AWS jumpboxes or that simply it is required based on the system's risk profile.

 

b) New Platform Agent for Linux -  an alternative way to provide Authentication and AAPM services for Linux systems in private or public clouds like AWS.  It’s a brand-new, “lightweight” Centrify agent.

This client works with the identity platform.  Linux systems are “enrolled” to our service and we act as an Identity Broker for your enterprise AD or LDAP-based identities.

 

The convenience of the new agent lies in its simplicity and low overhead.  Since newer workloads don’t require legacy support for NIS-like services this makes the footprint very small and the infrastructure requirements minimal in comparison of deploying a full AD forest or LDAP tree, and simpler than alternatives like one-way trusts or RODCs.   Simply drop a Centrify connector in your AWS (or other) cloud and that’s it.  Connector to cloud and agent to connector (or cloud) only requires HTTPS connectivity.  Enrollment can be fully automated using codes.

 

Here's a quick demo

 

 

The architecture of Centrify Privilege Service for AWS (or any public loud) is quite simple.  The Centrify connector talks to our service over HTTPS and extends cross-platform services like federation, policy, MFA, shared account password management, privilege session brokering, application-to-application password management and more.

 

The huge benefit is the service's identity flexibility.  Regardless of your identity source (traditional LDAP or AD), modern (Google Directory, Federated Identity, Centrify Cloud Directory) you can extend application access and PIM services.  All you need is the Centrify connector where you want those services available. 

 

 agent.png

 

In conclusion, regardless of your Public cloud, you will find that with Centrify you can meet or exceed your security requirements PLUS you can balance value and functionality, keeping capability fragmentation at bay.

Background

Amazon AWS is at the heart of many of our customers workloads.  Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.

 

This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.  

 

About the Shared Responsibility Model

The concept is very straightforward.  Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
aws-shared-responsibility.png

Amazon AWS Defines a "Shared Responsibility" model that has the following scope

  • Infrastructure Services: Controls that apply to IaaS services like EC2, VPCs and Block Storage.
  • Container Services: Controls that apply to PaaS services like RDS Database, EMR MapReduce or Elastic Beanstalk
  • Abstracted Services: Controls that apply to Services like S3 Storage, SES SMTP, etc.

 In this article we'll focus on how to use Centrify Identity Service (or Privilege Service) to secure the Amazon Account.

 

What's the Amazon account?

The amazon account (or Amazon root account) holds the keys to the AWS Kingdom.  This is the first account set up, most likely used to set up billing, IAM roles and groups, keys, etc.

 

What constitutes a bad practice?

If your organization is sharing the Amazon account with several members of your IT staff and you're not adding additional controls around it, you are going against several security best practices.  

 

What is Amazon's guideline?

Amazon's guidelines are simple:

  • Limit access and usage of the Amazon account
  • Add multi-factor authentication
  • Implement Amazon's Identity and Access Management groups

The basic guideline is to implement a model of least privilege access.   At Centrify that's what we have traditionally preached in the context of Operating Systems and Apps.   Additional complexity is added depending on your AWS deployment model.  This is an except from the AWS Security Best Practices document (August 2016, Pg 16).

 

amazon-root.PNG

 

How can Centrify help?

Centrify Identity Service (and Privilege Serivce) provide a simple-to-use federation engine that allows the implementation of Amazon IAM without the overhead of federation services.  In addition, it provides a powerful policy and multi-factor authentication engine that allows the deployment of controls to secure the account.

 

Enhancements since the previous entry

Last year when I wrote the original post, I outlined how to implement MFA to secure the root account.  The Amazon AWS (User/Password) app is deployed leveraging the password wallet built-in to the platform.  Since the password is securely replayed, users just click on the app link, they don't rely on shared credentials.

 

A big benefit of our approach was flexibility.  In addition to Smart Card or Yubikey for pre-authentication, you could use the Centrify Mobile Authenticator and individual OATH codes for each user, you could use Phone factor, e-mail, SMS and security question as step-up authentication when the application is lauched.  

 

Enhancements since last year

  • Radius Client as MFA - this means that you can use your legacy (or modern) tokens (RSA SecurID, Vasco, Symatntec, DUO, Microsoft) via our platform
  • Workflow and approvals - this means that you can use our existing access request or external worklow like our ServiceNow App Access app for governance and documented approvals
    sn-amazon.PNG
  • Policy at the application level - this was just released, and as announced by @Friedsam this weekend, 16.10 provides application granularity.
    add-policy.png

Example

With Centrify assets, you can deploy controls that limit access to users that have been explicity approved access to the application, and to use the Amazon account they must use multi-factor authentication, only from inside the corporate network and during business hours.  You can have different combinations of controls on different environments (accounts).

 

Conclusion

With Centrify Identity Platform (Identity Service and Privilege Service) not only you can meet, but exceed the Shared Responsibility of securing your  Amazon account. 

 

Demo

In this demo, we implement three controls:

- Documented Approvals (with ServiceNow)

- Secure the shared password (not available/visible)

- Multi-factor Authentication

 

 

 

Related Articles

AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA

AWS Shared Responsibility - Securing Amazon RDS Instances

AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker

 

Centrify Identity Service and MFA for VMware Horizon View 7

By Centrify Contributor III on ‎10-13-2016 04:58 AM - last edited ‎10-14-2016 11:41 AM

Steps for configuring MFA with RADIUS in VMware Horizon View 7 and Centrify Identity Service

 

Read more...

How can Centrify Identity Service and it's Managed Service Provider functionality enable complex organizations (e.g. multi-national conglomerates, goverments, university systems, large religious institions, et cetera) work in concert to deliver a cost-effetive, secure, and cohesive web access management and mobile strategy?

 

Centrify Identity Service with its Managed Service Provider (MSP) functionality provides a cohesive and cost-effective web/mobile access management strategy for large conglomerates, governments, university systems, and other large institutions comprised of diversified business units. Centrify Identity Service MSP provides these organizations a dedicated Managed Service Provider (MSP) tenant operated within the Centrify Identity Service cloud. This MSP tenant serves "meta-layer” enabling a conglomerate’s central shared services Central-IT division to quickly initialize a dedicated and full featured Centrify Identity Service tenant on behalf of a business unit requiring autonomous control over web access control service and/or enterprise mobile management service. For the conglomerate’s Central-IT division, this turnkey offering enables them to offer their internal customers (e.g. other business units) a compelling option for web access control and enterprise mobile management that offers numerous technical and IT business management advantages:
  1. addresses the need of certain business that might need separate/independent control over their respective implementation;
  2. simultaneously promotes consistency and adoption of internal technical standards;
  3. encourages licenses/subscriptions consolidation across disparate vendors which in turn gives volume leverage; 
  4. provides Central-IT visibility into service consumption which in turn simplifies internal chargeback; 
  5. curtails unnecessary and duplicative on-prem web access and mobile infrastructure; and 
  6. facilitates internal identity federation across business units
Read more...

Centrify's cloud platform, the Identity Service, can be configured to allow users to unlock their Active Directory accounts from the User Portal. The user is able to unlock their account without any administrator interaction, thus relieving the tasks that your system administrators and helpdesk team performs.

Read more...

Quick and easy LDAP server installation including importing user entries.

Read more...

How can Centrify Identity Service and it's Managed Service Provider functionality enable complex organizations (e.g. multi-national conglomerates, goverments, university systems, large religious institions, et cetera) work in concert to deliver a cost-effetive, secure, and cohesive web access management and mobile strategy?

 

Centrify Identity Service with its Managed Service Provider (MSP) functionality provides a cohesive and cost-effective web/mobile access management strategy for large conglomerates, governments, university systems, and other large institutions comprised of diversified business units. Centrify Identity Service MSP provides these organizations a dedicated Managed Service Provider (MSP) tenant operated within the Centrify Identity Service cloud. This MSP tenant serves "meta-layer” enabling a conglomerate’s central shared services Central-IT division to quickly initialize a dedicated and full featured Centrify Identity Service tenant on behalf of a business unit requiring autonomous control over web access control service and/or enterprise mobile management service. For the conglomerate’s Central-IT division, this turnkey offering enables them to offer their internal customers (e.g. other business units) a compelling option for web access control and enterprise mobile management that offers numerous technical and IT business management advantages:
  1. addresses the need of certain business that might need separate/independent control over their respective implementation;
  2. simultaneously promotes consistency and adoption of internal technical standards;
  3. encourages licenses/subscriptions consolidation across disparate vendors which in turn gives volume leverage; 
  4. provides Central-IT visibility into service consumption which in turn simplifies internal chargeback; 
  5. curtails unnecessary and duplicative on-prem web access and mobile infrastructure; and 
  6. facilitates internal identity federation across business units

 

Read more...

Si su empresa tiene contemplado migrar su correo a Office 365 o si es un cliente actual de Office 365 y está sufriendo con los problemas de sincronización de usuarios, este artículo es para usted.

Read more...

Add an LDAP server for users to access the Centrify Portal in a few simple steps.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels
Leaderboard

Community Control Panel