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.
There are 3 possible solutions for this problem.
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.
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.
As part of the implementation, an extended attribute is configured in the Identity Configuration for assistant attribute as follows.
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.
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.
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.
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.
Validation scripts are amongst the most common features while working with Sailpoint Identity IQ’sworkflow 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 –
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.
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.
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.