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:
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.
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:
- Turnkey App template
- Role-based Access Control (leveraging Identity Service roles and Active Directory groups)
- Account Mapping flexibility
- Policy Engine and Multi-factor Authentication
Centrify also provides Risk-based Access Control.
- Workflow and Approvals (Natively or via ServiceNow™)
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.
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.
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.
This is another component of O365 and Azure. Centrify allows the centralization of these efforts and the allocation based on different provisioning rules.
For more information about how to leverage Identity Service for Azure or O365 federation, provisioning or license management, visit the O365 TechCenter.
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.
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.
Resources and Related Links
- Office365 TechCenter: http://community.centrify.com/t5/TechCenter/Office-365-TechCenter/ba-p/25846
- ServiceNow TechCenter: http://community.centrify.com/t5/TechCenter/ServiceNow-TechCenter/ba-p/26601
- Amazon AWS TechCenter: http://community.centrify.com/t5/TechCenter/AWS-TechCenter/ba-p/25847
- Risk-based Access Control: https://www.centrify.com/solutions/why-risk-based-access/
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
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?
- 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.
- 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
- Go to the ServiceNow app store and search for Centrify.
- Click the Centrify Identity Service app.
- Click Get to make the Centrify Identity Service app available for your ServiceNow instances.
- 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
- In the left pane, search for Tables and select System Definition > Tables
- In the tables lab, make sure the Go to picker says name, and search for sys_user_has_role
- In the User Role table, click the State field, scroll down to choices and press New.
- Add a new field with Label Inactive and Value inactive, then press Update.
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.
- In the left pane, go to System Security > Users and Groups > Users and press New. Then set:
Password: type a complex password
Other fields: are optional
Press Submit when complete.
- Click the user you just created in the list of users.
- Scroll down and click Edit in the Roles section.
- Search for x_cenr3_centrify_u.centrify_admin and select it.
- Click > to add it to the Roles list.
- Click Save.
Configure Provisioning on the Centrify ServiceNow App
- Log in to Identity Service with a user with at least the Application Management right
- Go to Apps > ServiceNow Web - SAML + Provisioning > Provisioning
- Check the "Enable provisioning for this application" box. Ideally you'll start with Preview Mode
- 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
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:
I chose not to delete users when they are deprovisioned (just disable them) and to do sync overwrites:
Finally, for more complex scenarios, there is the possibility to use custom scripting for transformations and other options:
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.
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.
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.
There are multiple resources available in the documentation and tech blogs:
- Identity Service ServiceNow Documentation
- How to set up ServiceNow for SSO with Identity Service and the Multi-provider SSO Plugin
- How to set up Centrify App Access for ServiceNow
- Video Centrify and ServiceNow configuration overview by @Andy-Z
- Video: ServiceNow Application Access Request Overview by @Andy-Z
- Video: ServiceNow Application Access Request Walkthrough by @Andy-Z
- Video: Centrify Privileged Access Request for ServiceNow by @Andy-Z
- [Labs] Integrating ServiceNow Approvals to Centrify-enhanced sudo using the dzdo validator
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.
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...