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.

Rule Library in SailPoint IdentityIQ

Rule is an XML object with fully programmable java-based implementation hooks (Bean Shell). Rules can capture pieces of business-logic.SailPoint IdentityIQ is very much Rule-Driven, and thus very flexible.

Rules can reference other Rules! Helpful with creating Rule Libraries.

Rule Libraries are collections of methods that have been grouped together and stored in IdentityIQ as a Rule object. They contain a set of related but unconnected methods that can be invoked directly by workflow steps or other rules.

Continue reading

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.

Requirements Gathering for an IDM Solution

Requirements Gathering

Understanding the AS-IS and TO BE states of the enterprise IT infrastructure is the most important key to achieve success for any Identity management. Approaching such challenge with a wonderful questionnaire would lead to a win-win situation for both the customer as well as the implementer.

At ENH iSecure, we face the challenge of requirements gathering with a strong questionnaire that helps us understand the requirements of the customer very easily. The following list comprises of some important questions during the initial requirement gathering which are part of the questionnaire:

Identity Vault establishment:

Identity vault establishment is the first step of any Identity management implementation. It involves creating a central identity store which shall be the heart of the implementation. As part of the identity vault establishment and future management, we would put up the following questions to the customer:

Initial Creation of Identity vault:

1. What are the sources that help us create the identity vault?
They can be delimited files present at the Unix location or active directory or a HRMS.
2. Are these sources distributed across multiple applications? In case they do find all the applications across which the trusted sources are distributed.

Regarding the Identity vault maintenance:

1. Are there any specific organizational requirements regarding updation of identity vault? Sometimes it is possible that such updations happen at a specific date to match the server loads and burst in server loads because of sudden peaks in usage. For example, Universities which admit many students at spring or fall.
2. How often would we want the incremental updations to happen to the identity vault? How often are complete updations expected?

Information related users:

1. What are the various types of people whom the identity management solutions monitors? For example, employees, contractors, rehires, customers and any other types of users.
2. What are the various operations that could happen to the users of the identity management system? For example, promotion or termination of employees could be operation on the user. Expiry of contract for contractors could be a situation.
3. Identity management solutions maintains users in various states. For examples most of the identity management solutions have an active, disabled or terminated states for users. How are these states expected to change with respect to various actions on the users?

Provisioning related information:

1. What are the various target applications that are present in the IT infrastructure that need to be monitored by the solution?
2. How does the communication to the applications from the identity management solutions happen? Is there a bus service that is running that needs to be passed through or can they be directly communicate to?
3. Are there any rare applications for which we do not have any prebuilt connectors to work with? In such cases we need to develop connectors for communication to happen.
4. What are the various accounts and privileges to be provided to various kinds of users with different attribute values?
5. In case there is any change is user attributes or state of the user , how to deal with the transition to new state of user? For example, in rehire kind of scenario, we temporarily disable the users. Also in case there is a state change, all the accounts that need to provisioned in the state have to be provisioned.

Requests based provisioning:

1. Is there a requirement for users to request various accounts or privileges in various applications? What are the various resources that a particular kind of user can request and what is it that they can’t request?
2. How should the various requests be processed? Is there any complex approval process that is involved? For example sometimes it is required that IT Admin as well the manager are expected to approve provisioning an account.