Problems with LDAP Servers

This section describes problems that relate to the LDAP meta directory servers used with DirX Identity and how to solve them.

"No Such Attribute or Value" Error

Indication:

While running DirX Identity services like privilege resolution or real-time workflows, the LDAP Server delivers the error message
"No such attribute or value" or "Attribut nicht vorhanden".

Reason:

This can happen during concurrent LDAP accesses.Two clients try to change the same attribute of the same entry at (almost) the same time.One service performs a delete value and add value operation where the delete <value> operation tries to delete a value that is no longer there (it was meanwhile deleted by another service).This causes the message.

Solution:

If the attribute has only a single value (regardless of its schema definition), you can switch the operation for this attribute to replace mode.Then the attribute is simply set regardless what the actual value is.Within DirX Identity, you can define this behavior per attribute in the relevant object description.

Find the relevant object description and add the definition incremental="false".This forces the services to work for this attribute in replace mode.Example:

<property name="employeeNumber" label="Employee Number" type="java.lang.String" incremental="false"/>

If this message occurs at an object that masters an attribute from another object, then the attribute definition of the mastered object is relevant and must be changed.If you master for example the attribute employeeNumber at an account object from the user object you must add incremental="false" to the user.xml to solve the problem.Be aware that there can be a hierarchy of XML definitions that inherit definitions!

Service does not Operate Properly after Directory Restore

Indication:

Operation of the whole system is not correct after a restore of the directory content.

Reason:

Exchanging directory content (restore operation for DirX Server) requires a restart of all services to guarantee correct operation.Due to various caches and local stores, the DirX Identity servers are no longer in sync.

Solution:

Perform the following steps:

  • Restart the directory server.

  • Restart all C++-based DirX Identity servers.

  • Restart all Java-based DirX Identity servers (first the servers, then the workers).

  • Restart all Tomcat servers (or restart the related applications).

"Unwilling to Perform" Error

Indication:

The LDAP server refuses a request with "Unwilling to perform".

Reason:

Unfortunately there are many reasons for this error message.A possible reason is that the client works with paging and the time between two page requests was too long.For DirX this time is set per default to 5 minutes.

The DirX Identity service agent (privilege resolution, consistency check) runs with pages of several hundred entries for optimized performance.Due to complex role structures, the resolution of hundreds of entries might reach the limit of 5 minutes.

Solution:

If this is the reason (check the LDAP auditing details), you can either

  • increase the paging timeout of the LDAP server for example to 10 minutes, or you can

  • decrease the number of entries per page in the service agent configuration.

If a Java-based application or server received the "Unwilling to Perform" error from a DirX LDAP server or reports are not sorted correctly see "Problems with LDAP Servers → DirX Directory → "Unwilling to Perfom" Error" for details.

DirX Directory

This section describes problems that relate to the DirX LDAP server.

Check-pointing does not Work

Indication:

Check-pointing does not work.

Reason:

There is no ordering matching rule for the sort attribute specified at the source side. Search request with attribute values greater or equal do not work. These search requests are essential for check-pointing operations.

Solution:

Ensure that an Ordering-Matching-Rule is specified for the sort attribute at the source side (see the input channel definition) for LDAP to LDAP workflows.

Here is an example of a schema file that extends the attribute dxmEXpersonalTitle:

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.12.2.1107.1.3.102.4.3.87
 NAME 'dxmEXpersonalTitle'
 DESC 'This is a proprietary DirX Identity attribute.
 EQUALITY caseIgnoreMatch
  ORDERING caseIgnoreOrderingMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
 SINGLE-VALUE )

The relevant line is ORDERING caseIgnoreOrderingMatch.

DIRX_LOGCFG_FILE Variable not allowed

Indication:

The system does not behave correctly.

Reason:

DirX Identity does not support the variable DIRX_LOGCFG_FILE.

Solution:

The use of this variable is not allowed.

Insufficient Size Limit for Searches

Indication:

The DirX Identity software operates incorrectly after Move Object or Copy Object operations or during provisioning operations.

Reason:

Running DirX Identity with a restricted size limit can result in incorrect behavior (for example, during rule-based searches over the whole database). This is especially a problem when the size limit is set by default to 2048.

Solution:

Workaround: Check that the search size limit for the configuration database is set to a high value (minimum is 10 000). We recommend setting an unlimited value.

If this is not possible, calculate the limit this way:

  • For a Connectivity domain, evaluate the number of configuration objects.

  • For a Provisioning domain, evaluate the maximum number of user entries in the DirX Identity domain, evaluate the maximum number of accounts for any of your target systems in the DirX Identity domain and evaluate the maximum number of privileges and other configuration objects in the DirX Identity Store.

Set the size limit (SL) to the highest number evaluated plus 20 %.

Note that the DirX Identity product will set user policies (with size limit 100000) for the subtree dxmC=DIrXmetahub (Connectivity data) and for all the Provisioning domains (Provisioning data). If you define your own limit, these limits are not changed during upgrade installation.

If you want to change the limits, use the following dirxadm modify operation to set a user policy:

For Connectivity Data:

modify / -addattr USP={USN={/dxmc=DirXmetahub},SL=-100000}

For the Provisioning Domain cn=My-Company:

modify / -addattr USP={USN={/CN=My-Company},SL=-100000}

Uninstallation and Installation

Indication:

DirX Manager, dirxcp and dirxadm no longer run after an uninstallation and subsequent installation of DirX.

Reason:

The uninstallation removed all the DirX Identity abbreviation files from the directory dirx_install_path\client\conf.

Solution:

Copy the required files from dirxmetahub_install_path\client\conf to the directory dirx_install_path\client\conf.

"Unwilling to Perform" Error

Indication:

  • Indication 1: A Java-based application or server gets an "Unwilling to perform" error message from a DirX LDAP server instance.

  • Indication 2: Reports are not sorted correctly.

Reason:

Running a Java-based application that requires server-side sorting fails because the Java library runs by default with no de-referencing. This behavior results in 'Unwilling to perform' messages. You can also see a 'Database problem detected' message in the LDAP audit.

Because DirX Identity software is intelligent enough to overcome such problems, it tries without server-side sorting. This might work but the result of a report is, for example, not sorted.

This problem applies for all supported DirX LDAP servers.

Solution:

Set derefAlias overwrite mode for the LDAP server if the deployment uses no aliases (this is the case for DirX Identity installations). Perform the following steps:

  • Use dirxcp to specify the value X for dontDerefAlias in the attribute ldapSearchSvcCtl of the ldapConfiguration subentry. The LDAP server now always uses "derefAlways" independent of the setting in the LDAP request, that is the DSA returns aliased objects (instead of the ALIAS itself) and hence avoids useless bit string computations in the DSA process.

Example dirxcp statements:

First, read the existing LDAP search service control values (ldapSearch ldapSearchSvcCtl) because you must specify all values in the modify operation:

dirxcp> search o=my-company -sub -filt ocl=ldapconfiguration -vtype subentry -attr ldapSearchSvcCtl

dirxcp displays the following sample output:

{cn=ldapConfiguration,o=My-Company
ldapSearchSvcCtl=preferChaining=T:chainingProhibited=F:localScope=F:dontUseCopy=F:dontDereferenceAlias=F:subentries=F:copyShalldo=T:priority=1:timelimit=0:sizelimit=0:scopeofreferral=0:attributesizelimit=0}

Then perform the following dirxcp (ldap binding) statement to set the derefAlias overwrite mode (dontDereferenceAlias=X):

dirxcp> modify cn=ldapConfiguration,o=My-Company -replaceattr ldapSearchSvcCtl=preferChaining=T:chainingProhibited=F:localScope=F:dontUseCopy=F:dontDereferenceAlias=X:subentries=F:copyShalldo=T:priority=1:timelimit=0:sizelimit=0:scopeofreferral=0:attributesizelimit=0

  • Restart the LDAP server so that the modification of the LDAP configuration subentry becomes effective.

  • If you want to verify your modification, check whether the LDAP server has logged the message "DerefAlias set to ALWAYS" in the file TMP/fatalLDAP of your DirX installation.

See also the general information about this error in "Problems with LDAP Servers → "Unwilling to Perform" Error".

Wrong use of DAP

Indication:

Error during schema installation (cannot connect to the directory server).

Reason:

During DirX Identity configuration, AccessControl subentries are created using dirxcp of the DirX installation via DAP.

Solution:

Make sure that dirxcp can connect to the directory server using DAP. Check the following items:

  • The address given in the environment variable DIRX_OWN_PSAP.

  • The server addresses listed in DIRX_INST_PATH/client/conf/dirxcl.cfg.