Let us have an overview on the difference between the cloud rules & connector rules
Cloud Executed rules are running in the cloud within the Identity Now tenant. Connector rules run on the virtual appliance which is on-premise inside the customer’s data center
Cloud Execution Rule :
Cloud executed rules, as the name implies, are executed within the Identity Now multi-tenant environment.
They typically have independent functions for a specific purpose. For example, calculating an Identity attribute value.
Cloud executed rules typically need to query the Identity Now data model in order to complete their work.
The rule might need to guarantee uniqueness of a value and it would generate a value and query Identity Now to determine if that value already exists.
Access to any Identity Now data is read-only and you can’t make any calls outside of Identity Now such as a REST API from another vendor service.
Because they run in a multi-tenant environment, the are put in a very restricted context and there is a great deal of scrutiny taken during the required review process for rules.
We will cover the review process that is required when a cloud-executed rules is submitted later in the presentation.
Of course, this all makes sense as you cannot allow rules to effect other tenants if they are poorly written.
You also have to restrict the rules context so they can’t access any data from another tenant and things along those lines.
Connecter Execution Rule :
Connector executed rules do not run in the cloud which is fairly obvious based on the name.
These rules instead run on the VA itself. So they are running in the customers data center and therefore they are not running side by side with services from another tenant.
They are usually extending the connector capabilities. The functions that they perform are quite complex.
They do NOT have access to the Identity Now Data Model because they are executing on a virtual appliance.
The huge difference here is that they are not subject to a review process by SailPoint. These rules can be uploaded via the REST API and are significantly easier to work with. With that said you still want these rules to be well written.
The simple fact is that the possible negative effect of a poorly written connector rule is limited because it is not running within the Identity Now tenant.
SailPoint Provides us with six APIs to perform connector rule operations mentioned below :
GET, LIST, CREATE, UPDATE, DELETE, VALIDATE are the APIs that are currently used for connector rule operations.
A token with ORG_ADMIN authority is required to perform any operation.
Rule Examples
Example usage:
Calculate complex identity attributes.
Calculate complex account attributes.
Provide connector logic
Connector rule Example – If there is a requirement to disable the account based on the number of entitlements or the account should be disabled automatically based on role revocation, this can be achieved by writing a connector rule
Cloud rule Example– This can be used for generating a unique email id which can scan the existing email id’s and generate a unique id for every joiner.
Please subscribe to our social media and stay updated with latest technology content. Thanks you.
Identity management (IDM), also known as identity and access management (IAM), ensures that authorized people and only authorized people have access to the technology resources they need to perform their job functions.
And access is managed by the user lifecycle state in IdentityNow. Identity Lifecycle State aims to automate and manage the entire digital identity lifecycle process and access throughout the organization.
Identity lifecycle is a set of stages of the identity from the creation to its deactivation or deletion. It contains a creation of an account, assignment of correct groups and permissions, setting and resetting passwords and in the end deactivation or deletion of the account.
Figure 1: Identity Lifecycle Management
Handling the unwanted identities in SailPoint increases the processing time and reduces the usability of the SailPoint tenant. To reduce the process and speed up the work, in tenant only limited and require identities we can handle, handling is easy and processing the limited identities is a less time-consuming process, so we can delete unwanted and terminated users’ identities from SailPoint.
Now, let us have a look at the SailPoint REST API’s used in the Identity deletion process. Below is the list of APIs used for Identity deletion in SailPoint IdentityNow:
Figure 2: REST APIs in PowerShell Script connecting with SailPoint IdentityNow
Authentication: This is used to create an access Token (Bearer token).
Search – Perform Search(v3 API): This is used to fetch the all “30daysPostTermination” or “terminated” lifecycle state identities.
And here, we will be using A personal access token (PAT) is a method of authenticating to an API as a user without providing a username and password.
Prerequisites for Identity deletion:
SailPoint REST API’s.
Client ID and Client Secret.
IQservice Server.
Now, let us discuss the use case of Identity deletion.
Use Case:
All the identities in the “30daysPostTermination” lifecycle state will be deleted from IdentityNow.
The deleted identities would be re-aggregated in the next aggregation cycle as “Uncorrelated accounts” in target application, and hence would not affect the new hire creation logic and the SAMAccount name would remain unique as per the requirement and the logic defined.
A PowerShell script will be developed to call the APIs to identify all the Identities in the required lifecycle state i.e. “30daysPostTermination” and will delete the accounts from the HRMS Source for all the Identities.
Figure 3: Use Case diagram.
Steps Overview as per the script:
Step1: As part of the PowerShell script first it will read the require details from property file. In property file we can maintain the ClientID, client Secret, base URL, search query, deletion limit, log file path and debug values.
Step3: Next Search API will execute and the fetch “30daysPostTermination” lifecycle state identities from SailPoint Tenant.
Step4: One by one Identities will pass to Delete API to delete from SailPoint Tenant.
Let us understand Identity Deletion by using SailPoint REST APIs, use cases and automation of the script via windows task scheduler in the following below presentation:
Advantages of Identities Deletion in SailPoint IdentityNow.
It will increase the usability of the tenant.
It decreases the aggregation and identity refresh process time.
It will fasten the backend processes and reduce the unwanted identity handling.
Reduce the burden on the tenant.
When a user got terminated or left the organization, all access will be removed, and accounts will be disabled. Now, let us go through a demo on how we can achieve identity deletion in SailPoint IdentityNow.
This blog is intended to demonstrate on automating email notifications for newly on-boarded contractors from IdentityNow. This will help in sending auto email notifications to users & their managers (if required) to reset their first password. This is enabled by running a PowerShell script in a shared folder in the IQ Service Server. In the current process, the IT help desk team needs to reach out to the user for his first login. With the help of PowerShell script, this process can be automated by sharing the password reset link automatically.
Use Case Diagram
The above diagram depicts the overall process flow of the use case with the point of initiation being the IQ Service Server following with the SMTP server.
Current IdentityNow templates don’t have email notification which will send Email ID ,password reset link and user manual to end user on his first day to instantly. To achieve this requirement, we have written PowerShell script and rule to achieve desired requirement above diagram gives the overview of how we have achieved this requirement.
From UI Request center, HR or Manager will request for an AD account depending on the license to be assigned for the user to be on-boarded.
Once request is completed Active Directory account will be created and the After create rule will be triggered. By using this rule, we are triggering PowerShell script which is placed in IQ service server for sending Email by using SMTP server containing Email Id, Password reset link & user manual. We can also edit the contents to be shared in the email based on the organization requirements.
Detailed discussion on the overall Use case, communication flow and the advantages:
Introduction to IQ Service Server
The IQ Service, also known as the Integration Service, is a native Windows service that allows Identity Now to participate in a Windows environment and access information that is only accessible via Windows APIs.
It is a lightweight service that must be installed on any supported Windows Server that has connectivity to the target systems you want to manage in Identity Now.
It also secures all incoming & outgoing communications of the server. Overall security of the solution and data integrity will be ensured even in crucial stage.
We can create several instances on the same machine as per the system requirements.
This server is primarily responsible for provisioning in AD from IdentityNow.
IQ Service Communication Flow
IdentityNow always push task to a VA cluster queue and from cluster queue, VA will pull the request based on the priority of task.
Once request is fetched by VA, VA will communicate to IQService for tasks such as aggregation, create and modify the accounts.
IQService server communicates with domain controller using LDAP/LDAPS.
IQService receives the data from domain controller and gives it back to VA (Outbound traffic).
Finally VA will give the updated results to the tenant and requests for the new task.
Rule Execution process in IdentityNow
Rule execution can be executed in 2 primary places:
Cloud Execution – These rules are executed in the IDN multi-tenant cloud.
Connector Execution– These rules are executed on the on-premise IDN virtual appliance.
Connector Rules are rules that are executed in the IdentityNow virtual appliance, and they are usually extensions of the connector itself. The rules are particular to only certain connectors since they are frequently applied to carry out complex connector-related tasks. Because these rules function within the virtual appliance, they are unable to access IdentityNow’s data model or collect data from it.
The basic logic required to initiate a PowerShell script is derived from the after-creation rule, which then transfers the majority of the subsequent events and/or modifications to the PowerShell script itself. Since this script would be stored on the client’s servers, the customer could easily modify it as needed. Since the code runs outside of the IdentityNow platform, it allows the client to add updates to the PowerShell scripted functionality without requiring SailPoint to review the code.
Demonstration of the use case in IdentityNow
Use of Powershell script in IdentityNow
The popularity of scripting languages with Object Oriented capabilities—like PowerShell is because of their simplicity and use.
These languages’ native scripts can access request and result objects more quickly and effectively.
The Utils.dll class library that is bundled with the IQ Service contains all the necessary classes to access the request and result objects. Process environment variables would be presented as inputs to the script.
The environment variables contain XML-based data. Using Utils.dll, the script creates the appropriate objects.
Once the object is modified, the script should execute the object’s xml() function to convert it to XML and then send the XML to the path mentioned in the script’s single argument.
In the event of an error, the script generates a non-zero value and logs the message in the appropriate file at the specified directory.
Before/ After Scripts for IQ Service
The IQ Service allows function customization by allowing the integration of before/after scripts developed using scripting languages such as PowerShell.
Any required tasks that cannot be automated with the current source functionalities can be automated with scripts.
Native before scripts are scripts that are called before the request is processed; native after scripts are scripts that are called after the request is processed.
The following sources support Before/After Scripts for IQ Service:
It will helps end user to get his organization email ID, password Reset Link & User manual for SailPoint as IdentityNow Default email templates don’t have this type of functionality.
We can set a customized template and add an initial login guide or any policy documents as an attachments while triggering this email.
The dependency on IT help desk team for sharing login details for the newly on-boarded contractors is reduced to a huge extent.
Contractors can login to their system almost immediately post completion of the on-boarding without having any downtime.
Before going through the Integration of Genie with SailPoint IdentityIQ, let us understand what a ticket and a ticketing system is.
What is a ticket?
A Ticket is a special record that represents an incident, request or event that requires action from the IT department. It contains the necessary details of the incident, request or event.
A ticketing system is a software platform designed to manage and track customer support requests. It streamlines the process of resolving customer issues, making it easier for businesses to provide fast and effective support.
Benefits of embracing a ticketing system in your organization:
Control High Volume of Requests from a Centralized Place – Organizations can track and manage inbound support requests with the help of a good ticketing system. The solution can be used by executives to manage support cases more efficiently while still attending to all client issues.
Combine interactions into one thread – Your team can use ticketing system to combine customer-related conversations into a single thread when offering customer care to clients via a variety of channels.
Process automation and workload management – Ticketing systems provide several potentials for automation. As an illustration, the software gathers assistance requests from several sources before automating the creation of tickets. Regardless of the help channel clients select, tickets are automatically created whenever they submit requests.
Adequate team collaboration – Ticketing systems provide a platform to the customer service representatives to collaborate among themselves in assigning tickets to senior associates in terms of P0 escalations.
About Genie:
Genie is a ticketing tool, in which there are different types of tickets such as Work Order tickets, Incident tickets, etc. SailPoint handles creation of below tickets in Genie from SailPoint.
Onboarding ticket
Exit or Off-boarding ticket
Provision failure ticket
Among the above tickets, Onboarding and Off-boarding tickets are Work Order tickets and Provision failure ticket is an Incident ticket.
Integration with SailPoint IdentityIQ:
Genie is integrated with SailPoint using REST APIs.
Below is the high-level architecture of Genie – SailPoint Integration
High level architecture
Now, let us have a look at the APIs used in the Integration process. Below is the list of APIs used for creating tickets and getting specific ticket details:
Generate Authentication key: We are using this API to generate an Authentication key. Here, the generated Authentication key expires for every few minutes.
Creating Work Order ticket: We are using this API to create a Work Order ticket in Genie.
Get specific Work Order ticket: We are using this API to Get a specific Work Order ticket details. In other words, it is used to Retrieve the Work Order ID of the submitted request.
Creating Incident ticket: We are using this API to create a Work Order ticket in Genie.
Get specific Incident ticket: We are using this API to Get a specific Incident ticket details. In other words, it is used to Retrieve the Incident number of the submitted request.
Prerequisites for integrating Genie with SailPoint:
Following are the prerequisites that are essential for integration of Genie with SailPoint IdentityIQ
Genie API details for creating tickets
Base URL and Authentication details of the APIs
Access to Genie Test Instance
Database table to store the ticket details
Connection details of the Database
Now, let us discuss the use cases involved in the integration process.
Use Cases
Onboarding Ticket Creation:
An Onboarding Work order ticket will be created in Genie from SailPoint when a new joiner joins the organization and his/her account is created in Truth Source and Active Directory applications.
The ticket contains details of the New Joiner such as Start Date, First Name, Last Name, Employee ID, Employment Type, AD ID, Domain ID, Contact Information, etc.
Onboarding ticket creation process
Success case:
Once the ticket gets created in Genie successfully, the details of the created ticket such as Work Order ID, Creation Date, Request ID and ticket summary will be added to the database table.
Failure case:
If the ticket creation fails for some reason, then an Email notification containing the New Joiner’s details, will be triggered to the respective stakeholders.
Exit or Off-boarding Ticket Creation
An Exit or Off-boarding Work order ticket will be created in Genie when HR assigns the Last working date of the user in Truth source and that Last working date is 7 days away from today’s date.
The ticket contains details of the End dated user such as Last Working Date, First Name, Last Name, Employee ID, Employment Type, AD ID, Domain ID, Contact Information, etc.
Exit ticket creation process
Success case: Once the ticket gets created in Genie successfully, the details of the created ticket such as Work Order ID, Creation Date, Request ID and ticket summary will be added to the database table. Failure case: If the ticket creation fails for some reason, then an Email notification with the End Dated user’s details, will be triggered to the respective stakeholders specifying.
Provisioning Failure (Incident Ticket)
A Provisioning Failure (Incident) ticket per application will be created if the provisioning operations failed in SailPoint in last 24 hours. In this use case, applications under consideration are Active Directory, G-Suite and OpenLDAP and operations under consideration are Create, Enable, Disable and Delete.
For example, if the Disable operation failed in Active Directory for an account, then a ticket (which will be of Incident type) will be created in Genie containing the details such as Type of operation failed and Display Name, Employee ID, email, sAMAccountName, userPrincipalName, distinguishedName, etc details of the account.
Provisioning Failure ticket creation process
Success case:
Once the ticket gets created in Genie successfully, the details of the created ticket such as Incident Number, Creation Date, Request ID and ticket summary will be added to the database table.
Failure case:
If the ticket creation fails for some reason, then an Email notification will be triggered to the respective stakeholders specifying Type of operation failed, Application name in which Provisioning failed and Display Name, Employee ID, email, etc. details of the account.
Now, let us understand the advantages of integrating a ticketing system with SailPoint IdentityIQ when compared with a traditional ITSM.
Advantages of Integrating Genie with SailPoint IdentityIQ:
In this integration, we have automated the creation of onboarding tickets for New Joiners. Whereas in traditional ITSM’s, the ticket should be created manually by the end user.
While creating tickets in Genie, SailPoint uses the data coming from Truth Source which will be updated by the HR team. Whereas in traditional ITSM’s, there is every chance that end user does not give the mandatory details required by IT team to perform necessary action on that ticket or the end user mistakenly may also enter incorrect details. So, IT team might need to contact the HR team or the end user, which is a time-consuming process.
In this integration, we will be using the details of the user as per the Truth Source application while creating the ticket. So, the IT team may not wait for the communication from the concerned team.
Whereas in traditional ITSM’s, when the ticket is created, the IT team should get certain required details from the concerned team manually. The Exit ticket will be created automatically when the end-dated user is one week away from the Last Working date, which gives the IT team ample amount of time to take necessary actions such as collection of assets and disabling of access.
In this integration, we are storing the ticket details such as Work Order ID, Incident Number, Creation Date, Request ID and Summary in the database table for all the tickets created from SailPoint. So, we can use this table’s data for auditing purposes which ensures centralized governance.
The Incident tickets are created every day (one ticket per application) from SailPoint in Genie for applications such as Active Directory, G-Suite and OpenLDAP and for operations such as Create, Enable, Disable and Delete, if the provisioning fails in these applications. The point to be noted here is, if in an application, no provisioning operations failed for that day, then no ticket will be created for that application for the particular day. But, there is every chance that, one ticket per application will be created where each ticket contains the information of all the accounts for which Provisioning failed. Using SailPoint, this is one of the critical advantages of integrating genie with SailPoint IIQ. Whereas in traditional ITSM’s, this needs to be done manually, which will be a tedious task to do.
The detailed discussion of APIs, use cases and integration approach is discussed in the following video:
Now, let us a have a demo on integration of Genie with SailPoint IdentityIQ in the following video:
Pass-Through Authentication, the user logs in to the IdentityIQ application through the normal IdentityIQ login page but the system validates the user’s credentials against an external source, “passing” the ID and password “through” to the authorizing system instead of consulting IdentityIQ’s internal records.
What is Global-Catalog server ?
The global catalog contains a partial replica of every naming context in the directory like, the schema and configuration naming contexts But, with only a small number of their attributes.
Identity attributes in SailPoint IdentityIQ are central to any implementation. They usually comprise a lot of information useful for a user’s functioning in the enterprise.
Purpose: The blog speaks about a rare way of configuring the identity attributes in SailPoint which would lead to a few challenges.
Requirements Context: By nature, a few identity attributes need to point to another identity. 2 such use-cases would be:
Any identity attribute in IdentityIQ can be configured as either searchable or non-searchable attribute. A searchable attribute has a dedicated database column for itself. In case of attributes like manager, we would ideally need a lot of filtering capability on the attributes and this makes a perfect case for being searchable attribute. A few use-cases where having manager as searchable attributes would help are.
However, usage of assistant attribute is not quite similar. Not a lot of searching/filtering would happen in a typical IAM implementation based on assistant attribute. It would be preferable to have this attribute as a non-searchable attribute.
Implementation:
As part of the implementation, an extended attribute is configured in the Identity Configuration for assistant attribute as follows.
Assistant identity attribute configuration
The following configuration details are to be observed.
Challenge faced: A specific challenge is faced when this type of configuration is used with identity attributes.
Scenario: There will be certain situations where the assistant attribute in Active Directory points to itself. For example, John.Doe’s assistant would be John.Doe himself. This configuration has lead to failure of a lot of operations/tasks due to a SailPoint behavior described below.
Possible Solutions: Above problem can be solved in 2 ways.
Adding checks to avoid self-references. Logic to populate such type of identity attribute shall include a check to avoid self-referencing of non-searchable identity attributes.
Using Searchable attributes. Avoiding the use of non-searchable attributes for identity attributes of type identity.
As part of Active Directory Application Configuration in IdentityIQ 7.2, “Test Connection” failing with below error message.
In IdentityIQ 7.2, the Active Directory connector supports multiple Active Directory (AD) forests through one application definition.
While defining the Active Directory application through the IdentityIQ user interface in version 7.2, we do not have the option to mention the server details in Domain configuration settings.
Even though we do not specify any server details, the default configuration tries to connect to “localhost“, similar to the default port configuration which is “389“.
We see the below error message when we click on the “Test Connection”
2018-09-04 05:05:12,551 ERROR http-nio-8080-exec-6 sailpoint.web.ApplicationObjectBean:2701 – Connector failed.sailpoint.connector.ConnectorException: Failed to connect to – dc=enhcorp,dc=com : Failed to connect to server:ldap
dc=enhcorp,dc=com localhost:389
Resolution:
Modify the Application xml file to include the DC servers details.
Below is the example modification.
Errors returned from IQService. Connecting to remote server win-g303o4860qk.enhcorp.com failed with the following error message: The username or password is incorrect. For more information, see the about_Remote_Troubleshooting Help topic.
Troubleshooting steps:
Verified the User/Password details by logging in to the Domain controller as Domain Admin (the user which was used in Active Directory Application Configuration)
Verified and restarted Exchange services which were failed to start by default.
Enabled logging for AD Connector and observed the below messages.
2018-08-31 02:07:09,515 DEBUG Workflow Event Thread 1 sailpoint.connector.ADLDAPConnector:3503 – 1239254649 Entering handleObjectRequest2018-08-31 02:07:10,796 ERROR Workflow Event Thread 1 sailpoint.connector.ADLDAPConnector:3380 – 1239254649 Exception occurred in handling Object Request.sailpoint.tools.GeneralException: Errors returned from IQService. Connecting to remote server win-g303o4860qk.enhcorp.com failed with the following error message: The username or password is incorrect. For more information, see the about_Remote_Troubleshooting Help topic.
VERBOSE: Connecting to WIN-G303O4860QK.enhcorp.com.New-PSSession : [win-g303o4860qk.enhcorp.com] Connecting to remote server win-g303o4860qk.enhcorp.com failed with the following error message: WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits accesses to remote computers within the same local subnet. For more information, see the about_Remote_Troubleshooting Help topic.At line:1 char:1
When working with the Cloud, organizations of any scale wish to have common credentials across on-premise applications and the cloud applications. It’s the best user experience as well as the best IT management experience. The overhead of facilitating this can be quite a large endeavor.
Sailpoint’s IIQ provides Pass-through authentication using which a Login into IdentityIQ can be done via an enterprise directory credentials or via SSO credentials.
With pass-through authentication in Sailpoint IdentityIQ, password validation takes place through Application Configured in IdenitytIQ. What this means is a simple, but effective SSO solution for the end user. The below presentation gives a quick overview of concepts of Pass Through Authentication and how it is implemented in Sailpoint IdentityIQ.
The presentation is followed by different use cases demonstrated.
Data loading into Active Directory implies creating AD Accounts and corresponding Exchange mailbox accounts using employee data existing in a database.
Java program is developed in a fashion which reads the credentials from XML, retrieves employee data from the database, creates an account with a default password in active directory and enables the account as well.
The PowerShell script is executed to create exchange accounts for all the users.
Requirement schematic
The below process flow diagram explains the requirement lucidly.
Demo
The working demo of this program is embedded.
Documentation and Code
The Documentation and Code for above demo can be downloaded from following links.
