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

Background

ServiceNow is a very popular IT Service Management solution that includes capabilities like workflow and approvals, asset management, discovery, orchestration and more.  In the previous article, I outlined the steps to set federation with ServiceNow using Multi-Provider SSO.  In subsequent posts we'll discuss how to add ServiceNow workflow and approvals to apps and shared accounts using the Centrify ServiceNow store apps.

 

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

 

What you'll need

  • A Centrify Identity Service Instance with some published apps
  • A ServiceNow Instance that allows you to install apps from the ServiceNow app store
  • Administrative accounts on both systems

 

Planning

During planning, discuss with your Infrastructure, Operations and Security teams about these topics:

  • What are the source directories for SN users?
    It's possible that there will be AD, LDAP or other directories involved, based on user populations this adds complexity.
  • Will role mapping be used?
    This feature allows the provisioning of the user's ServiceNow role in addition to account creation
  • Are the target Roles created in ServiceNow?
    ServiceNow has several canned groups, however it's possible that your organization needs custom roles for different entitlements.
  • Are the source groups created in the corresponding source Directories?
    Group management simplifies the provisioning on each target Directory.  For example, adding a user to an AD group can simplify the provisioning process.
  • Are the Centrify Roles created based on the information gathered?
    sn-cis-roles.PNG
  • Is the UserID field correctly identified for mapping?  Will any transformations be needed?
    In some implementations it's preferred to use the email address as the unique identifier.
  • What will be the provisioning behavior? Overwrite existing entries or leave as is?
    Sometimes this may or may not be desirable.
  • What will be the deprovisioning behavior? Disable or Delete the user?
    In instances in which important data is left behind on systems, it's better to disable the account instead of deleting it.
  • What will be the behavior when users are removed from a ServiceNow group?
    Users may change functions, therefore this behavior has to be defined beforehand.

 

Implementation

Overview

  • Download and Install the Identity Service App from the ServiceNow App Store
  • Update the State field in the ServiceNow User Role Table
  • Create a ServiceNow User and Assign it a special role
  • Configure Provisioning on the Centrify ServiceNow App

Download and Install the Identity Service App from the ServiceNow App Store

  1. Go to the ServiceNow app store and search for Centrify.
  2. Click the Centrify Identity Service app.
    sn-app.PNG
  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.

Update the User Role table

  1. In the left pane, search for Tables and select System Definition > Tables
  2. In the tables lab, make sure the Go to picker says name, and search for sys_user_has_role
  3. In the User Role table, click the State field, scroll down to choices and press New.
  4. Add a new field with Label Inactive and Value inactive, then press Update.
    sn-state-inactive.PNG

Create a ServiceNow User and Assign Role

You need to create a service account that will be assigned one of the roles created by the Identity Service app.  This role contains all the entitlements needed for provisioining.

  1. In the left pane, go to System Security > Users and Groups > Users and press New. Then set:
    UserID: username
    Email: username@domain.com
    Active: checked
    Password: type a complex password
    Other fields: are optional
    Press Submit when complete.
  2. Click the user you just created in the list of users.
  3. Scroll down and click Edit in the Roles section.
  4. Search for x_cenr3_centrify_u.centrify_admin and select it.
  5. Click > to add it to the Roles list.
  6. Click Save.

Configure Provisioning on the Centrify ServiceNow App

  1. Log in to Identity Service with a user with at least the Application Management right
  2. Go to Apps > ServiceNow Web - SAML + Provisioning > Provisioning
  3. Check the "Enable provisioning for this application" box. Ideally you'll start with Preview Mode
  4. Configure the connection details:
    Account Name - type the ServiceNow instance ID
    Admin Name - type the name of the previously created SN user
    Admin Password - type the password for the previously created user
    sn-verify-prov.PNG

Other Provisioning Options

The following configuration items respond to the planning section. For example, in my test environment
I've decided to have 3 distinct Identity Service roles that mapped to different ServiceNow roles:
sn-role-mappings.PNG
I chose not to delete users when they are deprovisioned (just disable them) and to do sync overwrites:
sn-prov-options.PNG

Finally, for more complex scenarios, there is the possibility to use custom scripting for transformations and other options:
sn-transform.PNG

Verification

Centrify Identity Service provides several options to verify that provisioning will work as expected.  In the previous section you saw the Preview Mode option.  Using the Admin Portal > Settings > Users > Provisioning gives you the option trigger a sync on all or an individual app.  Once you trigger the sync, you have the option to see the activity.
In my example, I added an AD User (stewie.griffin) to ServiceNow Admins role, and these are the results.

sn-track-job.PNG

Once you have determined that all the provisioning actions are working as expected, you can enable live mode and verify the results in the ServiceNow side.

 

Enhancements

There are different ways to enhance this implementation with additional controls like Multi-factor authentication, controls to have ServiceNow only accessible from inside the corporate network, geo-fencing, etc. Explore Identity Service's policy features.

 

Centrify-ServiceNow Resources

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

The Centrify Community has some great resources when it comes to IBM DB2 integration with Active Directory using Centrify. But, have you ever wanted to quickly set up DB2 in a test environment to play with these integrations? By following this article, you can!

Read more...

This article will describe how Centrify helps customers address disjointed AD and DNS namespaces to achieve Kerberos SSO.

 

Read more...

Organizations can always count with the reliability of IBM hardware, operating systems and utilities for mission critical applications. That’s why Centrify has invested in certifying the product lines with IBM infrastructure.

 

This post discusses the DB2 SSO Module; this plugin (like the Apache HTTP and Java plugins) leverages the Active Directory integration capabilities and robustness of the Centrify agent to provide additional value and functionality to DB2 implementations.

 

The DB2 plugin provides the following benefits:

  • No need to keep users local to the UNIX/Linux system to support DB2: When used natively, DB2 users need to have user accounts in the local /etc/passwd file. The DB2 enables AD users to access DB2 so the benefits of Unified Identity, Centralized Administration, Streamlined Authentication and Policy Enforcement are organically attained.

In practical terms: no more getting dinged by auditors when the account of a long-gone user is found active in the /etc/passwd of a DB2 system.

  • Long login names: Support for logins that are longer than 8 characters
  • Single Sign-on (SSO): Centrify enables SSO to DB2 leveraging the GSSAPI
  • Active Directory Group Support: AD group memberships can be leveraged to grant entitlements inside DB2.

 

This is one of the best Database to AD integration models out there.

 

This article covers setup, configuration and testing of the DB2 moduleon Linux 64 bit in a lab environment. We will focus on the User/Password and Group Plugin first since they enable a UNIX/Linux admin to set it up without any AD requirements.  In a follow-up post we'll cover the SSO GSSAPI plugin. 

 

Like any other DBMS, a true production implementation requires planning and understanding of the current environment.

Read more...

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel