Known Problems

This section describes known problems in this release of DirX.

DirX Server

This section describes known problems relating to the DirX server.

Logging

You should avoid high trace levels like 5, 6, 7, 8, and 9 because the server might exit when running under heavy load. You should use these trace levels only temporarily.

Context Prefix

Creating a context prefix below an already existing context prefix in the same DSA will result in erroneous behavior. It is strongly recommended to avoid this.

Aliases and the number of Subordinates

When creating aliases both, the alias object and the object referred to by the aliasedObjectName attribute of the alias result in an increment of the corresponding number of subordinates. This affects the attributes numberOfSubordinates and numberOfAllSubordinates as well as the output of the dirxadm command "db check -bs subordinate" Note that this is independent from the fact whether the aliasedObject exists or not at the time the aliasObject is created.

Switching in a Multi Consumer Environment

In a multi consumer environment one master DSA is replicating its directory data to two or more Consumer DSAs.

When performing a dirxadm sob switch operation one of the consumer DSAs becomes the new master DSA. The resulting protocol exchanges (DISP) involve the distribution of the modified cooperating DSAs Subentry (/CN=Cooperating-DSAs-Subentry) to all consumer DSAs and publishes the knowledge of the new mastership to all participating DSAs.

In the event of a communication error distributing the update of the cooperating DSA table may be incomplete: The concerned consumer DSA gets no information about the identity of the new master. Therefore this DSA does not accept changes from that new master DSA. On the other hand the former master DSA may have already switched to a consumer role. The DSAs run out of sync.

The old master DSA logs such a situation in the following exception message:

"Consumer DSA did not participate in switch!
 Agreement ID: <agreementNumber>
 Total Update required for this DSA"

This situation can be resolved by a restart of the DSA, that has missed the switch protocol exchanges.

The switch operation is rejected by the old master, if there are outstanding updates for a consumer DSA and the synchronization of these updates fails due to connection problems to that DSA.
The switch operation might be rejected by the master if there is a SOB agreement where total-update-by-media (CHANGEO=TRUE) is configured, the shadow was just loaded from a backup, and that shadow has not seen a single update at the time of switch.

Shadow/LDIF Agreements and DSA Names and PSAP addresses

This section provides information about known problems with the handling of DSA names.

Sob switch and Consumer DSA is Permanently Unavailable

If a DSA administered as a shadow consumer is permanently unavailable the respective shadow agreement is automatically disabled after the occurrence of a couple of connection errors. However, there is a special agreement with the same consumer DSA name and the replicated area set to /CN=Cooperating-DSAs-Subentry. Due to the existence of this agreement, the DSA rejects a dirxadm sob switch operation. In this case, the special agreement must be deleted manually using the dirxadm sob delete command.

Note that this situation may also occur if an incorrect (consumer) DSA name was specified while administrating the shadowing or LDIF agreement.

Backup generated by another DSA

After setting up a DSA from a backup that has been generated by another DSA and that contains shadow or LDIF agreements the DSA names occurring in these agreements do not match the local DSA’s name.

The same happens if an ldif content file from another DSA is loaded with dirxload without specifying the option -s.

In these cases, the DSA does not start after restoring such a database and there is the following record in the exception file:

"Own DSA Name:
     <DSA-DN1>
 Not found in Cooperating DSA Table:
     <Role>: <DSA-DN2>"

In order to manually delete the shadow agreement configuration perform the following steps:

  1. Start a shell / DOS-Shell

  2. Specify the value <DSA-DN2> for the system environment variable DIRX_DSA_NAME in that shell.

  3. Start the DSA the administrative mode. From the shell type
    dirxdsa -a
    As a result the DSA process (dirxdsa) starts but does not listen for protocol messages that is it can only be administered via the dirxadm tool.

  4. Use dirxadm to

    • modify the cooperating DSAs Subentry with the command:
      dirxadm> remove_knowledges

    • stop the service

  5. Terminate the shell

  6. Start the DirX Service.

PSAP Match function

When PSAP Addresses are compared, all Selectors (TSEL, SSEL and PSEL) are taken into account. On the other hand, for the communication over the IDM stack the Selectors are ignored. However, as the match function includes the selectors this may result in failures reported. Therefore the correct administration of PSAPs including the consistent naming of the selector fields is required, even if all communication is performed over IDM.

Particularly, when shadow- or ldif agreements are created, the DSA checks its Role by comparing the PSAP of the master of the cooperatingDSAsSubentry with the Value of its environment DIRX_OWN_PSAP.

Peculiarities with Alias Searching

  1. derefAlias=Never flag and sorting control

    Search requests with the serviceControl derefAlias set to "Never" cannot be sorted. Many client Applications send this derefAlias value, as Never is defined in ldap to be 0 (default).
    Sometimes it may be impossible to change the client applications in order to send the suitable derefAlias flag value. In these cases, as a workaround the respective value of the LdapSearchServiceControl (LSSC) Attribute of the LdapConfiguration Subentry may be set to 'x'. As a consequence the respective ldapserver overrules the actual value sent in the ldap search request and the search is performed as if the request included the flag derefAlias=Always.
    If there is a need to perform both, searches for Aliases (derefAlias=Never) AND searches for AliasedObjects (derefAlias=Always) multiple ldapservers using different configurations may be used.

  2. derefAlias=Never flag in the absence of Aliases

    If databases do not contain any ALIAS object, the setting of the derefAlias is ignored. As a consequence Sorting is possible even if derefAlias=Never is set.

  3. derefAlias=Never flag and search performance

    The database layout and the DirX DSAs search procedure is performance optimized for the case, that a search operation requests the dereferencing of Aliases, resulting in the return of the "aliasedObjects", i.e. a search with the derefAlias=Never flag is slower than the one with the derefAlias=Always flag.

RACF External Authentication

Documentation of RACF_LDAP_TIMEOUT: The configured RACF_LDAP_TIMEOUT is a connection timeout. It is applied to the bind operation sent to the remote RACF ldap server. In case of dynamic mapping this timeout has no effect on the remote search operation.

Status of Agreements with CHANGEO=TRUE

If a Shadowing Agreements is configured with CHANGEO=TRUE - i.e. the consumer is to be set up by media - the status of the agreement is automatically set to "disabled". This applies as well for an agreement that is created as COOPERATIVE and for an agreement that is set to COOPERATIVE with the "sob establish" operation.

Such agreements have to be enabled explicitly after the consumer has been loaded with a backup media.

Re-Establishing of Shadow Agreements

If the attempt to reestablish a shadow agreement is rejected with the error "unsupported strategy", the administrator should check the status of a special Agreement to the same consumer DSA. This special agreement has a agreement ID > 10000 and the replicated area is set to /cn=cooperating-dsas-subentry. If the state of this special agreement is "DISABLED", it must be enabled (use the sob -enable -agree 1000x dirxadm operation) prior to the establishment of the primary agreement.

QUE3 Search Engine

The QUE3 Search Engine is disabled by default, as it is not stable.

Audit files

The DSA does not start if there are 'unclosed' audit files (audit.log) from earlier versions of DirX. You must rename or delete these files.

Remaining CP DSEType for the Root DSE

If a Directory server was configured with synchronous shadowing agreements, the DSE-Type Contextprefix (CP) will remain at the root DSE even after all synchronous shadowing agreements were deleted.

the dirxadm procedure "remove_knowledges" removes all information related to shadowing agreements turns a directory database into a standalone directory. This procedure performs cleans also the root DSE.

Scheduled Shadow Agreements and sob sync/switch

When a scheduled agreement is created and established a BeginTime (BT) may be specified. In this case the agreement starts at BT with the transmission of a total update. From that time on, updates are collected in the Supplier’s journal and replicated to the consumer according to the schedule parameters UpdateInterval (UI) and WindowSize (WS).
If a "sob sync" is executed or if the synchronization of the journal is triggered implicitly by executing a sob switch operation, a Total Update is sent immediately in the context of the sync. However, the replication of updates occurs not until BT has been reached. This may lead to inconsistent data on the scheduled consumer DSA. Therefore it is important to avoid sob sync operations in case there exist scheduled agreements in the pre-active phase(the time between establish and BT). Likewise creation of scheduled agreements with a future BT should be done AFTER the switch operation, if such a switch is planned.

Uninstallation on Windows

The following error message can appear during the uninstallation on Windows:

"Could not find a valid Java virtual machine to load."

The reason for this error message can be that Java Virtual Machine (JVM) is not installed or the uninstaller couldn’t find it or the JVM’s version is incorrect. See section Uninstallation for the correct version of JVM and the instructions for the uninstallation. If this error message still appears, try the following procedures:

  1. Open the file "<dirx-inst-path>\UninstallerData\Uninstall DirX Directory.lax" and set the lax.nl.current.vm property to:
    lax.nl.current.vm=<path-to-java.exe>
    <path-to-java.exe> specifies the path to the java.exe program which can be found in the JVM installation directory. For example:
    lax.nl.current.vm=C:\\Program Files\\Java\\jre\\bin\\java.exe
    NOTE: Double backslashes must be used instead of single backslashes in the path. After making this change, it should be possible to start the uninstallation from both the Add and Remove system settings or from the command-line by executing "Uninstall DirX Directory.exe" from the <dirx-inst-path>\UninstallerData directory.

  2. Open the command-line and go to the <dirx-inst-path>\UninstallerData directory. Run the following command:
    "Uninstall DirX Directory.exe" LAX_VM <path-to-java.exe>
    <path-to-java.exe> specifies the path to the java.exe program which can be found in the JVM installation directory. For example:
    "Uninstall DirX Directory.exe" LAX_VM "C:\Program Files\Java\jre\bin\java.exe"

Modification of unreferenced attribute values with DN syntax

Due to the internal structure of the database, unreferenced attribute values with DN syntax cannot be modified if according to the matching rules the old and new values are equivalent. Note that this problem is relevant just for attributes which are not referenced (contain DN of non-existing entry).

For example, the following modifications will not be executed:

  • cn=dummy name,o=my-company → cn=dummy name,o=my-company

  • cn=dummy name,o=my-company → cn=DUMMY name,o=my-company

  • cn=dummy name,o=my-company → cn= dummy name,o=my-company

In case of similar modifications, please follow this sequence

  • remove the value (for example cn=dummy name,o=my-company)

  • execute db purge command in dirxadm

  • add the new value (cn=DUMMY name,o=my-company)

Please note that db purge requires exclusive rights to the database so other modify operations cannot be done while purge is running.

LDAP Server

There are the following known problems relating to the LDAP server:

  • The LDAP server does not start if the LDAP cache is enabled and an RPC port cannot be established.

  • The LDAP Server rejects schema modifications for objectClasses if SUP objectClasses are specified that are not defined earlier. For example, if an object class or a superior object class is defined and modified in a single operation the definition of the object class must appear before the modify operation.

  • The dirxadm ldap mib -current curr_lbinds command will return incorrect values if suspicious bind PDUs are rejected or SSL binds fails.

  • The LDAP server does not start if startTLS is configured TRUE but the OpenSSL library is not initialized. To initialize the OpenSSL library, the PSAP Self-Address (dirxldap.cfg) must contain a SSLPORT>0 definition. This does not mean that a SSL port is established (can still be 0), but initializes the OpenSSL library for usage during startTLS processing. Please note that a startTLS is performed on 'plain' connections only and does not require an established SSL port !

  • The LDAP server behaves unpredictable if other applications open the audit file/files used by the current LDAP server process. This does not apply to dirxauddecode, i.e. it is possible to evaluate the audit trail of a running LDAP server process with dirxauddecode. Perform a dirxadm audit -move operation, if the binary audit file should be examined with a third party tool. Then the LDAP server operates on a new file while the tool operates on the file detached from the LDAP server process. Do not use third party backup tools on audit file that are still in use by the server (e.g. on WINDOWS some backup tools put an exclusive lock on backup files. This will cause problems when the server tries to write or wrap around those files).

  • Audit modus "-move" vs file system space
    write (xdr_write) may result in an error if the disk space is running low. This depends on a quota, i.e. even if tools like df show a certain percentage of available space the write call may fail. Administrators that use the -move strategy have to care for enough available disk space. This applies as well to the DSA audit.

  • Audit Timers
    If DIR.X runs on a multi CPU or multi core CPU platform and more than 1 CPU is online for the DIR.X processes, the High-Resolution Timestamps (resolution < 1 usec) within the Audit (DSA+LDAP) might show incorrect values due to the fact that the Hires Times are taken directly from the CPU which is a separate counter for each CPU. These counters are not synchronized by the system by any means and can lead to situations where subsequent Timer calls are resolved from different CPUs (threads-scheduling) which in turn leads to incorrect duration values. (On single CPU machines or if only 1 CPU is online this problem does not occur). There is currently NO way to synchronize these Hires-Clocks by software and there is currently also no way to ensure that two subsequent calls for the Hires Timer are taken from the same CPU. To overcome this problem, it is recommended to set the environment DIRX_USE_WEAK_TIMER=1. This will switch the timers to a low-resolution clock (1-20 ms resolution) that ensures correct time values at the disadvantage of a lower resolution. This applies as well to the DSA audit. Per default the weak timer is used on Multi CPU machines, the high-resolution timers otherwise.

  • UserDump/Process Dump on Win64 Platform
    On Windows Platforms the Userdump tool may be used to generate a user dump of a process that shuts down with an exception or that stops responding (hangs). As an better alternative the 'procdump' tool from Microsofts Sysinternals-SuiteS. 'procdump' is currently the preferred tool.

  • LDAP server and retrieval of ldap assoc MIBs
    The retrieval of the LDAP assoc MIB is handled by the ldap listener thread. During the processing of the MIB, the listener thread is unable to accept new connections for a short period of time. Hence it is not recommended to retrieve the assoc MIB with a high frequency (more than once every minute). Also, simultaneous retrievals of the assoc MIB may result in crashing the LDAP server process. Similar problems may occur when parallel queries for the LDAP current MIBs are requested.

dirxdumplog

On Linux platforms, the logfiles processed by dirxdumplog may contain log entries where the symbolic name of the return code of a system call is wrong. This is due to diverging system error value definitions in sys/errno.h. For example a bind system call may be reported to return EPROTOTYPE instead of EADDRINUSE.

dirxmodify

Problems can occur if large schema modifications are contained within LDIF-change files. Use LDIF-content files or reduce the number of schema modifications per LDIF record.

The behavior of dirxmodify is undefined if LDIF files are processed in which records appear where the 'dn' is not the first line of the record.

dirxcp

Handling of Blanks in Filter Expressions

Applies to DAP binds only. If the filterexpression contains the OCL attribute trailing blanks lead to not recognizing the abbreviation:

search / -sub -filter {ocl=ORP && sn=foo}
Error: Abbreviation unknown - "ocl=ORP && sn=foo" : Error position: "ORP && sn=foo".

If the filteritems are specified without blanks or with in reverse order result in a successful parsing of the input.

search / -sub -filter {ocl=ORP&&sn=foo}"

or

search / -sub -filter {sn=foo && ocl=orp}"

are both working successful.

openssl command line tool

Running the public domain command 'openssl' from the DirX installation shows the warning

WARNING: can't open config file: /usr/local/ssl/openssl.cnf

The warning can be suppressed by setting the environment variable OPENSSL_CONF to a file of zero size.

on Linux:

OPENSSL_CONF=/dev/null; export OPENSSL_CONF

on Windows:

set OPENSSL_CONF=NUL

dirxsupervisor

An update installation performed on Windows will overwrite the TCL script file setup_common_data.tcl. In this file users will have changed variable values according to their needs. Therefore - in case the dirxsupervisor is used - this file has to be saved before and restored after an update installation manually. On UNIX the update installation installs the file setup_common_data.tcl from the installation set with the suffix .new.

Documentation

This section describes known problems relating to user documentation.

Administration Guide

The user interface of DirX Manager may have changed and may look different than what is described in the manual.

In chapter "14.8.1 Configuring the DirX DSA for TOTP 2FA" section "Configuring TOTP 2FA Administrator ACIs" the example describing the new ACI item for 2FA Administrator contains insufficient rights for UP (UserPolicy) component:
UP={PI={E=TRUE}, GAD=grantModify};
This should be changed to:
UP={PI={E=TRUE}, GAD=grantRead+grantModify+grantReturnDN};

Disc Dimensioning Guide

If you cannot access the dimensioning spread sheet file "dimensioningSpreadsheet.xlsx" with the Acrobat Reader file attachment tool use the file from the product DVD. The file is located on the DVD in the directory Documentation/DirX Directory.

Syntaxes and Attributes Manual

The default value for keep-line (if not specified in DSA policy or no DSA policy exists at all) is 86400 seconds (24 hour). In the Manual "1.7.14 DSA-Policies" this is erroneously described as 300 seconds (5 minutes).

In chapter "3.1.15 Attributes for LDAP Server SSL Configuration" the description of attribute supportedEncryptionStrengthExt incorrectly states, that the keyword ALL is a possible value. Keyword ALL is not supported for this attribute.

In chapter "3.1.17 Attributes of the Password Policy Subentry" the description of value 512 of pwdStorageSchemeAlgo attribute is incorrect, correctly it is:

  512 - The DSA uses the algorithm SHA-512 for hashing the user password.
        This action results in user password values starting with the tag {SHA512}.

Administration Reference

Because of the 8443 dirxhttp port caused a port collision with the default tomcat HTTPS port, the default port was changed in the documentation as well, in the "Port Numbers Specified in Configuration Files" chapter.