Problems with Provisioning

This section describes problems that relate to all provisioning services like policy execution, privilege resolution, consistency checks and approval workflows used with DirX Identity and how to solve them.

Approval does not Work

Indication:

Approval does not work.Entries with title UNDER CONSTRUCTION exist in the top level folder under Provisioning → Approval Workflows → Monitoring.
Note: this topic is only valid for the approval engine up to DirX Identity V7.0.

Reason:

One or more login or configuration parameters might be incorrect or the approval engine could be configured to another domain.

Solution:

Perform the following checks:

  • Check the 'LDAP Parameters' section in the file server.xml in the folder:_
    install_path_\web\approvalEngine\WEB-INF.

  • Check especially root, host, port and user.

  • If parameters are not correct, correct it and restart Tomcat.

If login still not works:

  • Open the file password.properties in the folder:_
    install_path_\web\approvalEngine\WEB-INF.

  • Replace the encrypted password value behind 'ldap=' by the correct password of the technical user to log in (normally the DomainAdmin).

  • Restart Tomcat.

  • Check, that the file contains an encrypted value again (the server reads the clear text password and encrypts it immediately).

Changed Rules for Attributes

Indication:

You changed rules for attribute creation, for example to create attributes for a new or changed account.Now the attributes of many of these objects are not correctly built.

Solution:

Write a consistency rule in Java or JavaScript that adapts the values of all objects according to your new rule.

Consistency Check Workflow is Aborted due to OutOfMemoryError

Indication:

A Consistency Check Workflow is aborted due to OutOfMemoryError.

Solution:

If a Consistency Check Workflow is aborted due to OutOfMemoryError perform the following steps to solve the problem:

  • Increase the maximum virtual memory for the ServiceAgent:
    Edit the file MetaRoleServiceAgent.bat (on Windows systems) or MetaRoleServiceAgent.sh (on Linux systems) and increase the default setting -Xmx512m to a higher value.The maximum value depends on the system architecture (32bit/64bit) and OS, the system’s total memory, and the memory requirements of the other processes being run on the system.On a 32bit Windows system, there is an upper limit of about 1500m through 1600m.

  • Reduce the setting of the Object Cache MRU Size (cache.mru.size):
    Reducing the Object Cache MRU Size considerable (for example. to a value of 10) may help in such a situation.This will give the garbage collector access to objects that may be required in a later stage of the resolution process.So we gain stability at the cost of a lower performance, since those objects are restored from LDAP when requested again.

See "Using the Maintenance Workflows" → "Understanding the Tcl-based Maintenance Workflows" → "Consistency Check Workflow" → "Service Agent Configuration File" and "Consistency Check Workflow Optimization" in the DirX Identity Application Development Guide for details.

Enabling Deleted Users

Indication:

A user that is already in the TBDEL state is enabled again.All accounts are already in the DELETED state.When enabling the user again, account creation is not possible because the already deleted account is there.Other problems might also result from this situation.

Reason:

DirX Identity distinguishes clearly between the state TBDEL and DISABLED.The state DISABLED should be used for:

  • Temporarily disabling a user.

  • Setting a time period after the user has left the company to ensure that it is possible to enable the user again if necessary.

The state TBDEL is a final state that should not be used to enable the user again after some waiting time.

Solution:

If you 'redefine' these states in your project, you might run into a lot of problems.We strongly recommend using the DirX Identity states as originally intended.This strategy also guarantees upward compatibility.See the chapter "Managing States" in the DirX Identity Provisioning Guide for more information.

Incorrect Approval Behavior

Note: this issue is only valid for the approval engine supported with pre V8.0 versions.

Indication:

The approval process does not work correctly after configuration changes.

Reason:

When you modify an existing object description or add new ones, for example, by creating a new target system, please make sure to that the Approval Engine services read the changed data.

Solution:

The usual way to achieve this is to restart the appropriate Tomcat Web server(s).

Incorrect Privilege Resolution

Indication:

If a group contains more than one value for a privilege parameter, the privilege resolution does not assign this group.

Reason:

If the attribute is defined as single value, but keeps more than one attribute value, the privilege resolution takes only the first value and performs the resolution based on this data.

Solution:

Check for all parameters that the definition for the attribute in the Groups.xml file is set to multi value.If not, change it.

Invalid Query Reference

Indication:

The LDAP server returns the message

Invalid query reference; LDAP server is unwilling to perform

while DirX Identity-related services (privilege resolution, consistency check, policy execution) are working.

Reason:

If paging is used, each request for an additional page contains a cookie. Obviously consecutive page requests need longer than the configured paging timeout. The searches as well as the necessary calculation of for example attribute values consume too much time for a page of user entries.

Solution:

  1. Check the LDAP audit of the server for long lasting searches.These are mainly caused by attributes that have not got an index.Check the filter of such searches whether all attributes are indexed correctly.Check also all other methods that are described in the section titled "Tuning the Provisioning System" in chapter titled "Managing the Provisioning System" in the Provisioning Administration Guide.

  2. Check if you use long lasting JavaScript routines for attributes when creating an account.Try to use as many naming rules as possible (naming rules are handled directly in Java code which is definitely much faster than JavaScript).

  3. Increase the paging timeout at LDAP server side (default is 5 minutes); for example, to 10 minutes.

  4. Change the limits of the corresponding workflows.Decrease the LDAP Page Size stepwise to values like 100, 50, 10. Note that the corresponding parameter name in the policy execution workflow is User LDAP Size.

  5. If all actions taken do not help, inform technical support about the problem.

Old Values in Membership Attributes

Indication:

The membership attributes still contain the old values if you changed the 'Referenced Property' attribute of a target system (see the 'Advanced' tab of a target system object).

Reason:

There are the following restrictions:

  • The Service Agent adapts the membership attributes when this attribute is changed:

  • The old value is deleted from the membership attributes.

  • The new value is added to the membership attributes.

  • If the cn or dn is used as 'Referenced Property' attribute, changes of the cn or dn attriute via "Move Object" or other pure LDAP operations do not result in membership changes because these operations are not handled by the services (they are not able to detect the change).

  • Nested groups are currently not supported.

Solution:

Respect the restrictions above.

Server Admin and Using SSL to Provisioning Database

Indication:

You use SSL to Provisioning Database and want to log in Server Admin.The log in does not work because authentication is made against the user store.

Reason:

SSL in Server Admin login authentication is not supported yet.

Web Center or Java-based Server not Working Correctly

Indication:

You cannot login to the Web Center or your Java-based Server does not work correctly (errors during startup).

Reason:

The Web Center and / or the Java-based Server are not configured to the correct domain.

Solution:

  1. Check the Web Center configuration in the file install_path\web\webCenter\WEB-INF\web.xml:

    Check the parameters in the <!-- Ldap parameters --> section, especially the host, port, ssl, user, baseDN and anyone values.

  2. Check the Java-based Server configuration in the files install_path\ids-j-domain-Sn\bin\bindcredentials.xml and install_path\ids-j-domain-Sn\bindprofiles\private\domain.xml:

    Check the following parameters: host, port, ssl, user, baseDN and domain values.

  3. If the parameters are not correct, you have the following options:

    • Run the Configuration (on Windows from Start → DirX Identity Vx.x → Configuration).

      Set the options Java-based Server Configuration and Web Center Configuration.

      Set all relevant attributes especially the required Domain parameter and run the configuration.

      Your Web Center and your Java-based Server will be re-configured.

    • Edit the files by hand:

      • Shut down the Java-based Server and the Web Center (Tomcat).

      • Edit the above checked files and set the correct parameters.You must also edit the corresponding password files (see the parameter in these files).Set the passwords in clear text.The services will encrypt the values during startup.

      • Start the Web Center (Tomcat) and the Java-based Server.

Cleanup Rule for Imported SharePoint Group Members

Indication:

A customer-defined validation cleanup rule with the purpose of deleting imported SharePoint group members from a group because those members shall not be members in DirX Identity does not work and instead logs Imported member "cn=*user_name,cn=users,cn=domain" *is not affected by Accept/Cleanup rules.

Reason:

The cleanup rule’s search base and filter were defined to search for users, but the Policy Agent’s rule processing coding expects account objects to be found with the defined search, not with user objects.For a SharePoint target system, the accounts are those in the related peer target system.

Solution:

Even though the members of SharePoint groups in Identity consist of user DNs, not account DNs, as is usually the case, the search base and filter in the cleanup rule must be defined to search for the accounts in the related peer target system, not for the users.

Inconsistent Group Membership

Indication:

The group membership attributes dxrGroupMemberOK and dxrGroupMemberImported hold the same value.

Reason:

If many realtime workflows for the same account or group are running in parallel, then there might be situations that one realtime workflow (on its way back to synchronize the Identity Store) already collects membership attribute values from the Connected System that the other realtime workflow just created.This situation results in creating members in the dxrGroupMemberImported attribute whereas the second realtime workflow created the same value in dxrGroupMemeberOk.

Solution:

The situation described above is not really critical. The next time when the realtime workflow synchronizes that account or group the membership attributes are updated correctly.

Nevertheless, in order to avoid confusion (because next update on the account or group may happen only in the far future) a consistency rule ResolveInconsistentGroupMembership is provided that will drop these inconsistencies.

This rule is executed by the workflow “Connectivity Configuration data / Workflows / Default / Identity Store / ResolveInconsistentGroupMembership”. We recommend you to create a schedule for that workflow (for example running the workflow once a day).