Sailpoint Identity IQ: Refresh logging through IIQ console

Sailpoint IdentityIQ uses log4j framework for logging. “log4j.properties” is the file where all the logging related properties are configured. IdentityIQ Servers would a need a refresh of the log4j configurations after anything changes to log4.properties are made.

Usually this kind of refresh is performed through UI from the debug pages in IdentityIQ. Following are the steps to follow for refreshing log4j configurations through UI.

This image has an empty alt attribute; its file name is image-3-1024x279.png
  • Click on the “Logging” option in the menu.
  • Click on “Reload Logging Configuration”

Problem context:


log4j configurations whenever there are any changes have to refreshed across all the servers present in the environment. However, when a load balancer is configured, we might not have control to access individual servers through UI, thus making the refresh of log4j configurations through UI on each server.

Possible solutions:

There are 3 possible solutions for this problem.

  1. Temporarily re-directing load-balancer traffic to only one server and refresh the configurations on the same through debug pages. This process has to be repeated across all the servers.
  2. Accessing IdentityIQ through individual server host-names or IP addresses rather than load balancer URL. This may not be quite helpful as servers are usually configured in a way that individual servers redirect us towards load balancer URL.
  3. Best way in which this could be performed is through IIQ console.
    Following are the steps to follow for the same.
    • Launch IIQ console on one of the servers
    • Modify the log4j.properties as required.
    • Refresh the log4j configurations using the command “logconfig” as shown in the below screenshot.
  • Repeat the above steps for all servers in the environments.

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.

Integrating CyberArk with SailPoint using SCIM

Privileged accounts are considered to be “keys to the kingdom” in any IT Infrastructure. Almost every cyber attack that has ever happened involved compromises at the privileged account level. PAM Solutions usually help in managing such accounts, keys or files that would lead to escalated access.

CyberArk is the global leader in PAM solutions with a holistic approach towards privileged account management. It covers not only traditional PAM problems but also extends its capabilities with various features like managing hard-coded application credentials, analytics, on-demand privileges escalation and managing end-user devices like desktops.

Securing and streamlining identity and privileges data present with such solutions is of very high importance.

In the following presentation, we provide a detailed overview of CyberArk integration with SailPoint by integrating Cyberark as a SailPoint’s application.

In the following video, we provide a detailed demo of this integration.

Sailpoint IdentityIQ’s Transient workflows and their advantages

Quicklinks are usually used for faster access of specific functionalities. Often a “no delays” workflow where the start and end of the workflow happen within one single launch of quicklink shall be launched by quicklinks. Usually these kind of workflows involve custom Sailpoint forms which would not be useful once the user stops using this quick link by navigating to some other page.

Conventional workflow launches are serialized by storing the workflow cases as XML objects. This leads to many work items and workflow cases which are incomplete and hang around the Identity IQ over long run. This might lead to performance issues and unwanted data accumulated inside IIQ.

This problem could easily be solved using the transient workflows. The main feature of transient workflows is that they don’t get serialized.

Without the workflow getting serialized, we have specific advantages.

  1. Workflow cases which are inactive specific to this workflow shall not be generated.
  2. Work items that are generated do not get serialized and as a result we don’t have any unwanted work items related to this workflow in user’s inbox.

This would result in cleaner environment where we don’t have unnecessary data.

Extra perk with logging:

Workflow variables in Sailpoint are serialized in non-transient workflows. This means that we can store only the objects that Sailpoint has capability to store as XML object. Log4J loggers are very useful objects which are disqualified as workflow variables because of this restriction.

As the transient workflows do not try to serialize the objects referred by the variables, Logger objects can also be stored in the workflow variables.

This provides us the flexibility to maintain a workflow level logger variable to use your custom logging. Rather than instantiating the custom loggers whenever we require them, we can simply use the workflow variable whenever required.

Sailpoint Implementation: Referring Rule Libraries in Validation Scripts

Validation scripts are amongst the most common features while working with Sailpoint Identity IQ’s workflow forms. When we have common validation logic for multiple fields, it is always good to maintain this piece of logic in a separate rule library and call it from the validation script whenever required. This encourages modularity of the code and decreases code redundancy.

 

The way in which the name space of a validation script of a form in the workflow behaves is quite different from the rest of the workflow. Initial declaration of referenced libraries does well for referring the code in other parts of the workflow. But this does not work with validation scripts.

 

The following syntax should be used when we are using the rule referencing in validation scripts –

<ValidationScript>

<Includes>

<Reference class=”sailpoint.object.Rule” name=”Rule-Library-Name”/>

</Includes>

<Source>

// your code that calls some useful function in the rule library

</Source>

</ValidationScript>

 

 

Sailpoint – Service Now Integration

Ticketing systems form a great part of any enterprise’s IT infrastructure. Service Now is a global leader in cloud based ticketing systems and has been playing a visionary role in ITSM and ITOM.

Sailpoint integration with Service Now provides a great value when direct provisioning from Sailpoint is not possible.

It streamlines the manual provisioning by raising tickets on Service Now for provisioning. This provides a great visibility and accountability in the IT environments.

 

In the following presentation, we provide a detailed overview of Service Now integration with Sailpoint:

The following is a demo of various types of Service Now integrations that are supported by Sailpoint:

Sailpoint – Refresh Identity Cubes

In Sailpoint’s Identity IQ Refresh Identity Cubes” is one among the most important internal tasks. Refresh Identity Cubes helps in building 360 degree purview of an identity based on all the data aggregated from external sources.

The following video is an extensive discussion on various aspects of Refresh Identity Cubes.

The various aspects that are covered as part of this video are:

  1. Mechanisms to filter the identities to be considered for Refresh.
  2. Various options in the Refresh Identity Cubes.
  3. Using Multi-threading to improve the performance

 

 

 

 

Sailpoint Unix Integration

Unix is the mother of all operating systems and also is the foundation for Tim Berner Lee’s invention.

Every enterprise has a huge Unix foot print spanning across thousands of servers running various legacy applications.

As part of the mammoth task of securing the IT environments, securing the Unix servers would be the first step.

At ENH iSecure, we thrive to achieve complete and impeccable solutions leaving nothing to chance.
As a part of these efforts, we are speaking about Identity Governance in Unix with the help of Sailpoint’s IIQ.

The following is a video where we speak about governance of Unix using Sailpoint’s IIQ.

The following is a demo on Unix integration with Sailpoint.

Solving the problem with privileged ports in ODSEE instance creation

It is possible that creation of an instance in Oracle Directory Server might end up with the following error message:

port number 389 is a privileged port.

This happens because all the ports less than 1024 on Linux are treated as privileged. Most of our well know ports like 389 for the LDAP, 80 for HTTP, 443 for HTTPS reside in this range of ports.

Linux enforces that the services cannot be created at the privileged ports until and unless the privileges are escalated.

In this particular case, we can start the instance using the following command:

sudo dsadm start <path-to-instance>

The main reason for need for extra privileges when we use the privileges may be because there is a chance that the firewalls do not block traffic from these ports. Any attacker who might be interested in stealing your data over the network could be opening such ports so that he could escape firewalls. To reduce the attack surface, it is enforced that the privileged port need root access.