Split Brain Scenario in CyberArk

In high availability clustering, split-brain is a problem scenario that can occur when one of the nodes fails. Within a CyberArk implementation with disaster recovery enabled, a split-brain condition might arise if high availability is not configured as per the recommendations.

The following presentation discusses split-brain scenario in a CyberArk implementation and how it can be resolved:

Sailpoint IIQ Activity Data Sources

Monitoring and analysis of events that occur on a system is crucial to identify threats and generate timely alerts. It is also significant to identify by whom such events were caused if it was triggered by a user. Sailpoint IdentityIQ allows us to keep track of identity activity on various targets using Activity Data Sources. When configured, this allows us to track activity like logon times, security events, or application activity among other actions.

The following presentation discusses how Activity Data Sources can be configured on IdentityIQ for basic Security Information and Event Management (SIEM) with an example use-case:

The following demonstration presents the use case for identifying activity based policy violations by setting up Activity Data Sources:

Securing IIQ SPAdmin Account Using CyberArk PAM

In an enterprise, a large number of privileged accounts are spread over various applications and systems. These accounts have higher authorizations and hence need to be handled with higher security. CyberArk‘s Privileged Account Management solution is targeted at achieving this.

In SailPoint IdentityIQ, accounts can have the highest privilege in form of the ‘System Administrator’ capability. The ‘spadmin’ account that comes out-of-the-box is configured to have this privileged access. This account, if managed by the CyberArk PAM solution, improves safety of the IdentityIQ environment.


The following presentation discusses this use case and how it can be implemented using CyberArk PAM:

The following video demonstrates the use-case in action for verifying and changing spadmin password from CyberArk and initiating privileged sessions:

SailPoint’s IdentityIQ Integration with Okta

In the world of Identity Management, securing and monitoring the access for the external users like partners, contractors and customers who have access to organizational resources have always been a challenge for many organizations. To mitigate and help the organizations to secure their resources two big Identity management products partnered together in February 2018. Okta and SailPoint announced a strategic partnership to provide an end-to-end identity for the enterprise – helping organizations balance providing simple, secure user access while meeting complex compliance and security requirements.

Benefits of the Combined Solutions

• Effectively manage user identities’ authentication, application assignments, while ensuring all governance and compliance requirements are met.

• Authenticate user access with single sign-on and multi-factor authentication.

• Ensure that for sensitive applications, only the right user has access, authorization policies are enforced, and the process is documented, timestamped and compliant.

• Automate provisioning throughout the user lifecycle by simplifying processes for creating, modifying and revoking access.

• Automate provisioning of applications adherent to corporate policies.

• Trigger provisioning workflows from authoritative sources, such as Active Directory or HR systems, to ensure consistency and increase efficiency.

Below presentation demonstrates Okta, IdentityIQ, SSO Concepts, Importance of SailPoint’s IdentityIQ integration to achieve SSO. The presentation is followed by a demo.

Okta and SailPoint IIQ Integration

Demo of SailPoint’s IIQ and Okta Integration.


Sailpoint IdentityIQ – Perform Maintenance Task

The Perform Maintenance Task in Sailpoint’s IdentityIQ plays a crucial role in ensuring that background maintenance activities are carried out periodically.

The following presentation is an attempt to deep dive into :

  • XML object structure of the Perform Maintenance Task
  • Native Java-based Sailpoint  objects associated with the Perform Maintenance Task
  • Understanding the flow of execution of the Perform Maintenance Task


Please leave your comments below

Sailpoint IdentityIQ Integration with Oracle E-Business Suite

Oracle E-Business Suite is the most comprehensive suite of integrated, global business applications that enable organizations to make better decisions, reduce costs, and increase performance. All large enterprises use ERP systems for managing and optimizing enterprise-wide business processes. ERP systems like Oracle E-Business Suite are mission-critical which processes a huge amount of business-critical data.

Oracle EBS includes the company’s enterprise resource planning (ERP) product as well as Oracle Human Resources Management System (HRMS), Oracle Financials, Oracle Order Management and customer relationship management (CRM) applications. Each application is licensed separately enabling organizations to select the combination best suited for their business processes.

The Sailpoint Oracle E-Business connector is designed to aggregate user and entitlement data from the Oracle E-Business Suite, and provision user accounts.The Oracle EBS connector only targets APPS schema tables according to Oracle standards.

Sailpoint Connector for EBS User Management Aggregates and provisions EBS user accounts along with their role and responsibility assignments. It helps EBS customers to achieve compliant user administration by enforcing the Segregation of Duties (SoD) policies in real-time during role and responsibility grants.

In this presentation, we are going to see how the Sailpoint IdentityIQ is an innovative identity Governance solution that reduces the cost and complexity of both complying with regulations and delivering access to Oracle E-Business Suite users.




The Following Demo presents the use case of  Birth Right Provisioning and Implementing Security in Oracle E-Business Suite using Role Based Access Control.


Reassignment of Employee mailbox to manager via Sailpoint’s Identity IQ

Email is the most powerful tool for enterprise level communication as it provides accountability and reliability in communication. To an organization, the emails that are received by the employees are a valuable resource. When an employee resigns or is terminated from the company, the organization might still need access to his/her mailbox. This is especially significant in sales, support and administration activities as it can impact the organization either directly or indirectly. This scenario can be addressed by allowing an authority within the organization to access the de-provisioned mailbox and is an important challenge within identity and access management. The risks and compliance guidelines associated with this approach are also factors that need to be considered.

Sailpoint’s IdentityIQ is shipped with a connector for Active Directory. This connector supports management of users, groups and mailboxes on Exchange server. However, for modifying the mailbox permissions, native rules need to be configured in order to execute the corresponding PowerShell scripts.

The following presentation introduces a scenario where handling mailbox permissions would be required. After an overview of native rules, the implementation of this use case is also discussed.

The following demo focuses on granting Exchange mailbox permissions via IdentityIQ and verifying that the changes are reflected on the mail server.

Troubleshooting the EBS Forms Launch Failure

The Forms functionality on Oracle E-Business Suite is an integral part of an organization’s ERP Solution. In situations where Forms need to be accessed from a machine running Oracle Linux 6, the default browser Konqueror does not support it.
Through the course of this blog, I will attempt to resolve this issue by using the Firefox browser.


A current release of the Firefox browser (version 58) has dropped NPAPI support which disables Forms to detect the JRE version installed on the machine.
Firefox Extended Support Release continues to offer plug-in support. End-users who need to use Forms-based content in EBS must run the Firefox Extended Support Release.
The latest version of Firefox Extended Support Release (version 52) needs the GTK 3 library which is not supported on Oracle Linux 6 (by default) to circumvent this, Firefox Extended Support Release version 49 can be installed (which uses GTK library 2).
For all Linux distributions, a tarball is offered as a download link which can be found on the official Mozilla website.


Extract the tarball into the ~ directory of the root user.
Once it has been extracted, launch Firefox by entering

The next step is to enable the libnpjp2.so plugin that allows EBS Forms to use JRE from the browser.
The Forms functionality also needs JDK version 1.8.0_102 (or above)
Get the required JDK version by downloading the rpm package from the Oracle Archives Page
Once the JDK is in place, navigate to the directory
/usr/java/jdk1.8.0_120/jre/lib/amd64/libnpjp2.so (FOR 64 Bit Version)
And ensure that the libnpjp2.so file exists in that location.

Create a Symbolic Link

Create symbolic links in 3 directories

cd /usr/lib64/mozilla/plugins
cd /usr/lib64/mozilla/plugins-wrapped
cd /etc/skel/.mozilla/plugins

by using the command

ln -s /usr/java/jdk1.8.0_102/jre/lib/amd64/libnpjp2.so
while in each of the directory

Bounce Firefox to view changes when about: plugins is entered in the address bar

Java(TM) Plug-in 1.8.0_102
Filename: libnpjp2.so The next generation Java plug-in for Mozilla browsers.

Configuring Java to allow self-signed certificates

When EBS Forms is being used in a development environment, it is essential to configure Java to accept self-signed certificates.
Due to the default security settings, Java blocks requests from domains that have self-signed certificates.

To allow a local domain to access Java, a Site Exception can be added, to do so, Java Control Panel needs to be started.
To start the control center, navigate to the /bin folder of the installed JRE version; in case of a default install it would be :


And launch the Control Panel by issuing the



Click on the Add an Exception button at the bottom and the local domain on which the EBS application is running.
Save changes and bounce the server to notice the effects.

XML Tags in Sailpoint

XML Objects:

Every object in Sailpoint is stored as an XML file. The existing XML objects can be explored from the “Debug Pages”. XML files are useful while adding new objects. This can be done using “Import from XML” under Global Settings. Any object like rules, certifications, system configurations, email templates, etc. can be created using XML.

XML Object Tags:

Each of the objects is represented by its respective XML tag and has its own structure. For example, rules are referred with the <Rule> tag, tasks with <TaskDefinition> tag, email templates with <EmailTemplate> tag.

An XML file with only one object begins and ends with a tag corresponding to that object type. However, it is a better practice to always wrap the objects with the <sailpoint> tags as this offers more flexibility. This approach also enables to import multiple objects defined in the same XML file.

For example, two XML files can be combined into a single file:


Usage of combined XML objects:

Taking the approach of using a single XML file is extremely useful for deploy-ready and stable objects. Doing this in general will reduce the modularity which raises few concerns:

  1. If an issue arises with importing one of the objects, it will halt the process of import and rest of the features would be left out
  2. As part of the development process, it would be inconvenient to import all the objects repeatedly while only one or few of them are updated.

Due to these reasons, it is better to combine tested and stable XML objects instead of objects that are still in development.

The usage of this approach can be observed in the “init.xml” file that comes with Sailpoint. This file contains all of the objects required for the basic features of the product, packaged into a single XML file.

Troubleshooting a Linux Partition with Corrupted Metadata

A corruption in the Linux file system causes the system to boot into emergency mode by default.

The following error message is displayed on boot up

Welcome to emergency mode! After logging in, type “journalctl -xb” to view system log, “systemctl reboot” to reboot, “systemctl default” or ^D to try again to boot into default mode.

Filesystems can be corrupted by

  • Hardware Errors
    • Media errors are common
    • Disks are getting bigger and bigger
  • To a much lesser degree, bugs in the filesystem

Filesystems are able to “repair” themselves since they consist of lists, links and reference counts that can be validated

  • But not all information is always recovered, inodes that do not have a parent directory is common due to the directory structure being corrupted


The OS shows the following error:

Corruption detected. Unmount and run xfs_repair.

Corruption of in-memory data detected. Shutting down filesystem(s)

Please unmount the filesystem and rectify the problem(s)


Enter lvdisplay. This command would bring up the logical volumes present in the Linux machine, the common logical volumes (assuming no changes have been made) are root, home and swap.

To mount a logical volume the command mount /dev/ol/logical_volume_name needs to be entered.

If a logical volume’s metadata is corrupted, the following error is observed after trying to mount it.

XFS(dm-2) Metadata corruption detected at xfs_inode_buf_verify 0x75/0xd0 [xfs]

For the course of this blog it is assumed that the home logical volume is corrupted, so the error is encountered when the following command is executed

mount /dev/ol/home

To fix this enter the command

xfs_repair -L /dev/mapper/ol-home

Where ol-home is the default partition created by Logical Volume Manager (LVM) on the home logical volume. To view the list of partitions the command fdisk –l can be used.

The –L option specifies Force Log Zeroing.

Forces xfs_repair to zero the log even if it is dirty (contains metadata changes).

It is important to understand that this option should be used only if data of that partition has been backed up before, using this in a mission-critical environment without prior testing would spell trouble as in certain cases, the inode tree could end up with even more corrupted metadata.

With fresh metadata, the inode tree of the filesystem is rebuilt and the /home directory can now be mounted by using:

mount dev/ol/home


The changes in the filesystem can be observed by checking the df-l

Reboot the OS for changes to show effect.