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:

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

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:

Background

Regulatory frameworks have evolved to require documented evidence of approval for development or infrastructure-related change control.  These activities usually require the exercise of elevated privileges.  Some examples of these requirements and guidelines can be found on PCI DSS, SANS Critical Security controls, ISO 27001 and others:

  doc-approvals.png

 

Centrify DirectAuthorize and DirectAudit provide end-to-end, role-based access controls for UNIX, Linux and Windows, in addition it provides mechanisms for validation and tracking of changes via ticketing or request systems.

 

Requirements

We've had customers that have two categories of requirements:

  • Tracking activities related to a particular change control or approved request
    For example: We want to track all privileged activities related to a change control in my security operations dashboard.
    We covered this on this on the original dzdo validator article.  When privileges are elevated, entries in both syslog or DirectAuthorize get created automatically.
    Using Centrify-enhanced sudo:
    $ dzdo tail /var/log/messages
    Enter the change control ticket number:1255
    

    syslog:

    Nov  7 15:04:39 engcen6 dzcheck.sample[35173]: User "dwirth@centrify.vms" will run "/usr/bin/tail /var/log/messages" as "root" with ticket number "1255"
    
    DA Console:
    DirectAudit Analyzer - dzdo.validator event.jpg
  • Implementing controls to prevent unauthorized changes
    For example:  We want to make sure that any privilege elevation is only allowed with an approved request.
    This lab covers a basic lab setup to implement this requirement.

 

Lab Diagram

dzdo-validator-lab.png 

 

What you'll need:

  • Centrify Standard Edition and a Centrify Zone with some UNIX roles defined
  • An AD-joined UNIX or Linux  system in the Centrify zone
    The system should be able to reach the ServiceNow instance directly, via proxy or via ServiceNow MIDServer.
  • A DirectAuthorize role for UNIX
  • A ServiceNow instance (Fuji release minimum) and a shared credential or token to query existing requests
    Make sure that the credential only has the minimal rights (e.g. read-only) for your requests.
  • Optional:  Centrify Privilege Service (Saas or On-Prem) to vault the SN user's credential. 

 

Use Case

  1. Privileged user obtains a change control manager approval via ServiceNow workflow request.
    The request has a change control window.  (date/time range)
  2. During the request validity timeframe, the privileged user needs to perform activities (using Centrify-ehnanced sudo) and when the commands are issued, the SN request number has to be provided.
  3. The dzdo.validator script uses the ServiceNow Perl API to validate if the request is approved or not.
    Additional validations can be added like user, time-range, etc;  these won't be covered for blog brevity.
  4. If the request is a approved, the Centrify-enhanced sudo command is allowed to execute.  If not, the user is notified.

 

Implementation  Overview

  1. Install the ServiceNow Perl API
  2. Test ServiceNow Instance connectivity
  3. Optional:  Protect the shared credential using Privilege Service
  4. Modify one of the sample scripts to work with ServiceNow Requests
  5. Modify the dzdo.validator script to call the ServiceNow Perl API script
  6. Implement the dzdo.validator via parameter or GPO
  7. Test your results

 

Install the ServiceNow Perl API

The full instructions and requirements are here:  http://wiki.servicenow.com/index.php?title=Perl_API#gsc.tab=0

  1. Make sure you have the appropriate Perl plugins  (e.g. CentOS 6.x):
    SOAP::Lite  (e.g. yum install perl-SOAP-Lite)
    Crypt::SSLeay (e.g. yum install perl-Crypt-SSLeay)
    IO::Socket::SSL ( e.g. yum install perl-IO-Socket-SSL)
    File::Basename
    MIME::Types (e.g. yum install perl-MIME-Types)
    MIME::Type
    MIME::Base64
  2. Download the Servicenow Perl API  (link to 1.01 version) to your UNIX/Linux system
  3. Unzip the file in a new folder and run the following commands:
    ## create a new folder, download and unzip
    $ mkdir SN
    $ cd SN
    $ wget http://wiki.servicenow.com/images/e/e5/ServiceNow-Perl-API.zip
    $ unzip ServiceNoW-Perl-API.zip
    ## compile the files
    $ perl Makefile.PL $ make $ make test $ make install
    Follow the prompts, once you have all the ServiceNow Perl API libraries installed to use with your scripts.

 

Testing Connectivity with your ServiceNow Instance (Sample Script)

  1. Create a new file with these contents
    # This script retrieves all the requests from your servicenow instance
    # it is used to test connectivity.
    #!/usr/bin/perl -w
    use ServiceNow; use ServiceNow::Configuration;

    # This example uses Centrify Privilege Service's AAPM capability
    # by checking-out the password from the vault at runtime, we eliminate
    # the need to use a cleartext password in this script.
    # uses cgetaccount to check out the password for your-SN-user for 3 mins.
    # Alternatively you can enable OAuth and use Tokens (recommended)

    $SN_PASSWD = `cgetaccount -s -t 3 your-SN-user`; my $CONFIG = ServiceNow::Configuration->new(); $CONFIG->setSoapEndPoint("https://your-instance.service-now.com/"); $CONFIG->setUserName("your-SN-user"); $CONFIG->setUserPassword($SN_PASSWD); my $SN = ServiceNow->new($CONFIG); my @requests = $SN->queryRequestedItem(); my $count = scalar(@requests); print "Number of requests=" . $count . "\n"; foreach my $request (@requests) { print "Request number: $request->{'number'}\n"; print "Requested by: $request->{'sys_created_by'}\n"; print "Date Created: $request->{'sys_created_on'}\n"; print "Approval Status: $request->{'approval'}\n"; print "\n"

 2. To test the script, add the execution flag and run it

$ chmod +x checksn.sh
$ ./inc2.sh
Number of requests=34
Request number: RITM0000002
Requested by: fred.luddy
Date Created: 2016-05-02 18:15:39
Approval Status: requested

Request number: RITM0000004
Requested by: fred.luddy
Date Created: 2016-09-03 17:15:39
Approval Status: requested

Request number: RITM0000005
Requested by: fred.luddy
Date Created: 2016-05-22 19:15:43
Approval Status: requested
[output truncated]

Modify the Sample Script to work with Individual Ticket Numbers

To do this, you need to change the script to require arguments and check for usage.   The modified lines would look like this:

 

#!/usr/bin/perl -w

# You're checking for arguments here.  If there are no arguments
# show the usage and exit.  E.g.  checksn RTM00005

if (@ARGV)  {

# The previous program can go here.  Make sure you modify this line
# to look like this:

my @requests = $SN->queryRequestedItem({'number'=> $0})


}  else {
          print "USAGE:  checksn [ServiceNow Request ID]\n"
}
   

Note that there's no error logic for requests that are not found.  We're going to have to add this later.

 

Modify the dzdo.validator script to to use the ServiceNow Perl API script

 

Centrify provides a sample dzdo validator script called dzcheck.sample.  This script exists under /usr/share/centrifydc/bin.

With the author's limited scripting knowledge we were able to modify it to work this way:

 

  • Initialize the proper libraries and variables
  • Retrieve the password for the ServiceNow user (your-user) and store it in SN_PASSWD
  • Connect to ServiceNow instance
  • Prompt the user for a Change Control number
  • If the number is not found, log to syslog and the user will not be allowed to run the command
  • If the number is found but the status is not approved, log to syslog and the user will not be allowed to run the command
  • If the number is found and approved, log to syslog and allow the end user to run the command.

Note that additional error logic and checks can be added.

 

#!/bin/sh /usr/share/centrifydc/perl/run
# A modified demo for Centrify-enhanced sudo (dzdo) validator 
# Modified to work with ServiceNow Requests
use strict; use lib "../perl"; use lib '/usr/share/centrifydc/perl'; use CentrifyDC::Logger; use ServiceNow; use ServiceNow::Configuration;
# Use privilege service to retrieve SN shared account password
# Alternatively, you can modify the script to use an OAuth token
my $SN_PASSWD = `cgetaccount -s -t 3 your-user`; my $dzdo_user=$ENV{DZDO_USER}; my $dzdo_command=$ENV{DZDO_COMMAND}; my $dzdo_runasuser=$ENV{DZDO_RUNASUSER}; my $CONFIG = ServiceNow::Configuration->new(); $CONFIG->setSoapEndPoint("https://your-instance.service-now.com/"); $CONFIG->setUserName("your-user"); $CONFIG->setUserPassword($SN_PASSWD); my $SN = ServiceNow->new($CONFIG); my $logger = CentrifyDC::Logger->new('dzcheck'); printf STDERR "Enter the change control ticket number: "; my $user_input=<>; my @requests = $SN->queryRequestedItem({'number' => $user_input});
# Check if request(s) exist, if not, exit (1) if (scalar(@requests)==0) { system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input"; $logger->log('INFO', "Change control ticket number: %s", $user_input); $logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not found) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input); exit 1; }
foreach my $request (@requests) { my $req_status = $request->{'approval'}; # Exit if request is not in approved status if ($req_status ne "approved") { system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input"; $logger->log('INFO', "Change control ticket number: %s", $user_input); $logger->log('INFO', "User \"%s\" will not be allowed to run \"%s\" as \"%s\" with ticket number (REASON:not approved) \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input,$req_status); exit 2; } }
# Run command and log if request is approved
system "adsendaudittrailevent", "-t", "tkt_id", "-i", "$user_input"; my $logger = CentrifyDC::Logger->new('dzcheck'); $logger->log('INFO', "Change control ticket number: %s", $user_input); $logger->log('INFO', "User \"%s\" will run \"%s\" as \"%s\" with ticket number \"%s\"", $dzdo_user, $dzdo_command, $dzdo_runasuser, $user_input); exit 0;

I've saved this script as dzcheck.snow in the same location.

 

Configure Centrify-enhanced sudo (dzdo) to use the ServiceNow Requests validator

  1. Open the /etc/centrifydc/centrifydc.conf file for editing
  2. Uncomment the dzdo.validator and set it to our scripts
    dzdo.validator: /usr/share/centrifydc/sbin/dzcheck.snow
  3.  Perform and adreload (or restart the agent)

 

Testing

We'll use a modified version of the sample script to check the requests for validity first, then we'll try to flush the cache using dzdo.

  1. Ticket does not exist  (ABC123)
    Request verification
    $ ./sncheck ABC123
    Request not found.
    $ dzdo adflush
    Enter the change control ticket number: ABC123
    Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
    
    # syslog contents
    Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: Change control ticket number: ABC123
    Sep 20 18:00:52 engcen6 dzcheck.snow[35963]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not found) "ABC123#012"
    Sep 20 18:00:52 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=35961 utc=1474412452436 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command.
  2. Ticket is not approved (RITM0010022)
    Request verification:
    $ ./sncheck RITM0010022
    number of requests=1
    Request number: RITM0010022
    Requested by: robertson.pimentel
    Date Created: 2016-09-16 16:55:06
    Approval Status: requested

    $ dzdo adflush
    Enter the change control ticket number: RITM0010022
    Sorry, user dwirth is not allowed to execute '/usr/sbin/adflush' as root on engcen6.centrify.vms.
    
    # syslog content
    Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: Change control ticket number: RITM0010022
    Sep 20 18:03:04 engcen6 dzcheck.snow[36011]: User "dwirth@centrify.vms" will not be allowed to run "/usr/sbin/adflush" as "root" with ticket number (REASON:not approved) "RITM0010022#012"
    Sep 20 18:03:04 engcen6 adclient[1526]: INFO  AUDIT_TRAIL|Centrify Suite|dzdo|1.0|1|dzdo denied|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36009 utc=1474412584884 centrifyEventID=30001 status=DENIED service=dzdo command=/usr/sbin/adflush runas=root reason=Dzdo Validator checks failed. Do not permit to continue the privileged command
  3. Ticket is approved (RITM001003)
    $ ./sncheck RITM0010003
    number of requests=1
    Request number: RITM0010003
    Requested by: diego.jimenez
    Date Created: 2016-09-11 14:57:57
    Approval Status: approved

    $ dzdo adflush
    Enter the change control ticket number: RITM0010003
    Demo Password:
    DNS cache flushed successfully.
    Authorization cache store flushed successfully.
    GC and DC caches expired successfully.
    The auditing service's name cache has been successfully flushed.
    The DirectAudit installation information cache has been successfully flushed.
    
    # syslog content Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: Change control ticket number: RITM0010003 Sep 20 18:06:22 engcen6 dzcheck.snow[36108]: User "dwirth@centrify.vms" will run "/usr/sbin/adflush" as "root" with ticket number "RITM0010003#012" Sep 20 18:06:22 engcen6 adclient[1526]: INFO AUDIT_TRAIL|Centrify Suite|dzdo|1.0|0|dzdo granted|5|user=dwirth(type:ad,dwirth@CENTRIFY.VMS) pid=36106 utc=1474412782119 centrifyEventID=30000 status=GRANTED service=dzdo command=/usr/sbin/adflush runas=root role=UNIX Sysadmin/Global env=(none)

 

Benefits if you're using DirectAudit

If you have Enterprise Edition, DirectAudit's events will contain information about the Change Control and you can now search for all activity related to an individual change control number.

ben-da.png

 

Benefits if you're using the Centrify Splunk App

The Splunk App will display reports on the reasons why the privilege elevation failed.  You can also add alerts based on this to identify any privileged user trying to fish.

ben-splunk.png

 

Improvements

This is a lab blog post, therefore this is just a simple concept, but here are the improvements I'd make:

  • Use OAth tokens for ServiceNow instead of a shared credential
    http://wiki.servicenow.com/index.php?title=OAuth_Setup#gsc.tab=0
  • Compare the date of execution with the change control date range (we only did simple checks)
  • Provide better feedback to the user interactively
  • Allow the user to create a request if it's not in the system and notify the approver (cli-driven workflow)

 

Quick Overview Video

 Notes:  ServiceNow, PCI DSS, SANS and ISO 27001 logos are registered trademarks of their respective owners.

Showing results for 
Search instead for 
Do you mean 
Labels

Community Control Panel