Genie Integration with SailPoint IdentityIQ

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.

  1. Onboarding ticket
  2. 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:

    1. Generate Authentication key: We are using this API to generate an Authentication key. Here, the generated Authentication key expires for every few minutes.
    2. Creating Work Order ticket: We are using this API to create a Work Order ticket in Genie.
    3. 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.
    4. Creating Incident ticket: We are using this API to create a Work Order ticket in Genie.
    5. 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

    1. Genie API details for creating tickets
    2. Base URL and Authentication details of the APIs
    3. Access to Genie Test Instance
    4. Database table to store the ticket details
    5. Connection details of the Database

    Now, let us discuss the use cases involved in the integration process.

    Use Cases

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

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

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

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. 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:

    SailPoint IIQ Pass Through Authentication using Active Directory – Global Catalog

    Purpose : Here, we will be discussing about the SailPoint IIQ Pass-Through Authentication with respect to custom Active Directory attribute using Global Catalog Server.

    Quick Description :

    What is Pass-Through Authentication ?

    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.

    Requirements Context :

    In a multi domain environment, it would be efficient to use global catalog because IIQ does not need to traverse through all the LDAP referrals returned for different domains during user login authentication. When using a Custom Active Directory attribute for correlation, where that attribute is not promoted to global catalog repository, then the SailPoint IIQ will be driven to a tangled state which results in Pass-Through Authentication Failure.

    In order to overcome such scenarios, we can

    Continue Reading

    SailPoint Identity Attribute – Configuration Challenges

    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:

    1. manager” is an identity attribute which refers to the manager of the employee/contractor.
    2. assistant” can be a custom attribute which refers to the assistant of the employee/contractor. Action items of an employee/contractor can be delegated to this assistant when employee/contractor is on a vacation.

    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.

    1. Finding list of identities without managers.
    2. Finding a list of identities with inactive managers.

    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.

    1. Type of attribute is “Identity“.
    2. Identity attribute is not configured to be searchable as there is no extended number that is configured on this attribute.

    Attribute population logic: The attribute is configured to fetch the assistant attribute from Active Directory application and populate the assistant attribute based on the assistant attribute from Active Directory.

    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.


    Root Cause: SailPoint uses a hibernate for object relational model. Tables in IdentityIQ database are represented by java classes in Identity IQ. In this case, spt_Identity table is represented by the class “sailpoint.object.Identity”. Objects of “sailpoint.object.Identity” class shall correspond to rows in the “spt_Identity” table.

    SailPoint has to serialize this Identity objects in the process of storing them in the tables. Non searchable attributes are all stored in an XML CLOB in spt_Identity table. As per the SailPoint’s default behavior, non-searchable attributes are going to be serialized in a recursive fashion. Following the same, serialization shall be attempted on the identity pointed by the assistant attribute.

    In the scenario mentioned above where an identity is his/her own assistant, a sub-serialization of same identity as part of assistant attribute serialization is attempted as shown in below diagram.

    Recursive Serialization of assistant attribute

    Possible Solutions: Above problem can be solved in 2 ways.

    1. 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.
    2. Using Searchable attributes.
      Avoiding the use of non-searchable attributes for identity attributes of type identity.

    Active Directory Application Configuration – Test Connection Failure in IdentityIQ 7.2

    Issue Description:

    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.

    From

    <entry key=”domainSettings”>
    <value>
    <List>
    <Map>
    <entry key=”authorizationType” value=”simple”/>
    <entry key=”domainDN” value=”DC=enhcorp,DC=com”/>
    <entry key=”password” value=”1:iIopEeOL5KrLoSjYKvh/Ww==”/>
    <entry key=”port” value=”389″/>
    <entry key=”servers”/>
    <entry key=”useSSL”>
    <value>
    <Boolean></Boolean>
    </value>
    </entry>
    <entry key=”user” value=”ENHCORP\Administrator”/>
    </Map>
    </List>
    </value>
    </entry>
    To
    <entry key=”domainSettings”>
    <value>
    <List>
    <Map>
    <entry key=”authorizationType” value=”simple”/>
    <entry key=”domainDN” value=”DC=enhcorp,DC=com”/>
    <entry key=”password” value=”1:iIopEeOL5KrLoSjYKvh/Ww==”/>
    <entry key=”port” value=”389″/>
    <entry key=”servers”>
    <value>
    <List>
    <String>172.16.153.185</String>
    </List>
    </value>
    <entry key=”useSSL”>
    <value>
    <Boolean></Boolean>
    </value>
    </entry>
    <entry key=”user” value=”ENHCORP\Administrator”/>
    </Map>
    </List>
    </value>
    </entry>

    Active Directory – Exchange Provisioning errors in Sailpoint Identity IQ

    Issue Description:

    Active Directory Provisioning along with Exchange attributes failing with below error message.

    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.
    • Launched Exchange Management Shell and observed below error messages
      • 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

        + New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft.Excha …

     

    Resolution:

    Active Directory-Direct connector reads Exchange Server attributes by connecting to the Active Directory.

    But, for provisioning any Exchange attributes, connector needs access to remote Powershell via IQService.

    Windows Remote Management (WinRM) is a feature of Windows that allows

    administrators to remotely run management scripts. WinRM Service should be running and that

    should also be set up for Remote Management using the Enable-PSRemoting -force.

     

    Enable PowerShell remoting in the domain using below cmdlet in Exchange Management Shell.

    >Enable-PSRemoting -Force

    Sailpoint IdentityIQ Pass through Authentication via Active Directory

    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 using a simple java program

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

    requirement


    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.


     

    Enabling Active directory SSL authentication

    Using JNDI we can access the active directory, but if we want to access the active directory using the secure port we need to get the certificate issued by the active directory certification services.

    The certificate helps to authenticate the server over SSL.

    SSL authentication is useful when we need to perform the administrative stuff like changing password using JNDI.

    Active directory enables us to access the server over SSL using the certificate issued by that server.

    To access the active directory using the JNDI we need to get the certificate issued by the active directory and import that into java key tool.

     

    1.     Creating and exporting certificate file

    We can export the certificate which can accept the SSL authentication in many ways. But in this article we are exporting the certificate using the internet explorer and command prompt.

    Note: to export the certificate, server should be installed with active directory certification services. Refer the following link to install the ADCS

             i.            Exporting the certificate using the internet explorer
    • Open in the internet explorer in the windows server and click on internet options
    • navigate to content and click on certificate

    1

    • In the certificates tab navigate to trusted root certificates and click on the certificate with your server name. (in this case server name is ADSERVER)

     2

    • A new popup will populate with certificate name that you have selected, in that click on details tab and select copy file option.

     

     

    3

     

    • Then new popup windows will appear, in that click next.

     

    4

     

     

    • select the option do not export private key and click next

     

    5

     

    • Select the base 64 encoded and click next.

    6

     

    • Provide the path and name to certificate.
    • Verify the options and click on finish.

    7

     

     

     

          ii.            Exporting the certificate using command prompt
    • open command prompt in your windows server
    • navigate to the folder where you want save certificate
    • enter the following command to export the certificate

    > certutil -ca.cert sslcert.cer

     

     

    2.    Importing certificate into java keytool

     

    After exporting the sslcert.cer file, copy the file into host machine installed with java.

    The following steps explains to import sslcert.cer file into java key tool in various environments

            i.            Linux
    • Open the terminal in the folder which containing the exported file
    • execute the following command

    # keytool -importcer -keystore JAVA_HOME/jre/lib/security/cacerts -file sslcert.cer

    • Default password for the keystore is: changeit
    • Enter yes to import the certificate to key store

         

         ii.            Windows
    • Open the command prompt in administrator.
    • navigate to the folder containing exported certificate file
    • Execute the following command

    > keytool -importcer -keystore JAVA_HOME/jre/lib/security/cacerts -file sslcert.cer

    • Default password for the keystore is: changeit
    • Enter yes to import the certificate to key store