Restrictions

This section describes the restrictions of this release of DirX.

General Restriction

This restriction relates to the use of external backup tools:
Do not use non-DirX backup tools to back up the DBAM database. Only dirxbackup performs the necessary synchronization with other DirX processes using the database. Also DirX protects its database against getting inconsistent by delay of modifications being performed while a backup is created.

Using non-DirX backup tools that access DBAM database files or devices can produce inconsistencies in the database and/or in the dirxbackup archive file. This has in particular been observed, when a Microsoft Volume Shadow Copy Service (VSS) based tool was used to create backups of the DirX DBAM Files. It has been also observed, that third party backup tools not using Microsoft Volume Shadow Copy Service (VSS) can produce inconsistencies in the database even if the DBAM database files have been explicitly excluded from the list of to be backed up files.
Also backing up the files residing within the DirX installation folder can result in problems, as the DirX processes require exclusive access to some of its file (e.g. journals).

Use non-DirX backup tools only on files outside the DirX installation and configure the backup tool such that the partition containing the DBAM files is excluded from the backup.

DAP

For DAP, the following restrictions apply:

add entry

targetSystem is not supported
the maximum number of RDNs is 24

modify entry

the maximum number of RDNs is 24

list

pagedResults is not supported

read

modifyRightsRequest and attributeSizeLimit are not supported

search

matchedValuesOnly and attributeSizeLimit are not supported

DOP

This version does not support DOP.

DirX Server

DirX server limitations

The following limitations apply:

  • The maximum PDU size for a LDAP protocol request is limited to 32MB. If the DirX LDAP server receives a larger PDU then the request is rejected with a ‘LDAP protocol error’ prior to decode the request.

  • The maximum number of RDNs within a DN in an addEntry or modDN operation is limited to 24.

  • Values of Operational Binding ID in shadow Agreements The range of Agreement IDs that a user can specify in an sob create command is limited to the range from 1 to 9999. If an agreementID exceeds this range an error is returned in the sob create operation. The DSA uses IDs greater 10000 for internal purposes, i.e. for the agreements concerning the CDT Entry.

  • The number of recurring attribute values in one directory entry is limited. The limitation is due to the maximum number of DBAM follow blocks of 8192. The maximum number of attribute values evaluates to blocksize in General device (KB) * 8192 / (raw) size of the attributevalue (KB). This limitation can be overcome by applying the attribute outsourcing feature (see chapter "1.1.2 attr (dirxadm)" in the Admin Reference Manual.

Attribute values with Distinguished Name syntax are stored separately in extra blocks if the size of the values exceeds 16k. The maximum number of values is 128 million for each attribute type.

  • The number of recurring attributes with DN Syntax (e.g. member of the group objectClass) that can be handled in one operation (transaction) is limited due to the size of the DBAM cache. See the following computation of the required DBAM cache space under worst case conditions. dirxdsa : DBAM cache requirements for large groups under worst case conditions

    1. Creation of a group; Adding member values to a group:

      The creation of a group requires for each member attribute value the creation of a pseudo object, an update of the real object block the member attribute value points to and an update of a bit string in the attribute index if the member attribute is indexed. Since the DSA performs the creation of a group in a single transaction, this may require a large amount of DBAM cache. This requirement calculates the following formula :

      DIRX_DSA_CACHE_SIZE =
  (
    (RealBlockSize+64+
     NoOfMemberValues/8192)          // Size for the group itself in KB.
  + (NoOfMemberValues/8)             // Total size for pseudo objects in KB.
                                     // 8 pseudo objects fit into a 1k block
  + (NoOfMemberValues*1)             // Total Size for attribute index bit strings
                                     // An average bit string size of 1k is assumed
                                     // But can be up to 32K.
                                     // Set to 0 if attribute is not indexed.
  + (NoOfMemberValues*RealBlockSize) // Total size for real object blocks in KB
  )*2.2/1024                         // Result in MB

      Since the DBAM cache requirement can be very large, it is recommended to create a group with a small amount of member values. Enlarge the group with additional modify operations.

      Example:
      Creation of a group with 100000 member values. The real object block size is 4K and the attribute member is indexed :

        DIRX_DSA_CACHE_SIZE = ((4+64+100000/8192)+(100000/8)+(100000*1)+(100000*4))
                         *2.2/1024 = 1101MB

      For the creation of the group a cache size of 1100MB required. The same amount is also required for adding 100000 values to an existing group.

    2. Deletion of a group; Removing member values from a group:

      The deletion of a group requires a large amount of DBAM cache if the member attribute is indexed. For each member attribute value an update of a bit string in the attribute index is required.
      For the deletion of a group or removing member values from a group the formula looks like this :

      DIRX_DSA_CACHE_SIZE =
  (
    (RealBlockSize+64+
     NoOfMemberValues/8192)          // Size for the group itself in KB.
  + (NoOfMemberValues*1)             // Total Size for attribute index bit strings
                                     // An average bit string size of 1k is assumed
                                     // but can be up to 32K.
                                     // Set to 0 if attribute is not indexed.
  )*2.2/1024                         // Result in MB

      Example : Deletion of a group with 100000 member values. The attribute member is indexed :

        DIRX_DSA_CACHE_SIZE = ((4+64+100000/8192)+(100000*1))*2.2/1024 = 215MB

      For the deletion of the group a cache size of 215MB required. The same amount of DBAM cache size is required for removing 100000 values from the group.

  • Maximum Size of one single Memory Context
    A Ctx-Hard-Limit has been introduced (controlled via env DIRX_CTX_LIMIT) that sets the max upper limit for the entire sum of all CTX memory contexts within a process.

    A Ctx-Soft-Limit has been introduced (that is 40 MB below the Hard-Limit) and returns a NULL pointer to the caller when the Soft Limit is reached. Further allocations (up to the Hard-Limit) are serviced correctly. When the Hard-Limit is reached, a permanent error CTX_ULIMIT_EXCEEDED is returned.

    A Single-CTX-Limit is introduced that controls the max size of a single memory context (CTX consists of 0-N such single contexts). The single limit is set by default to Hard-Limit/2 on 64 Bit systems.
    If this limit is reached a CTX_LIMIT_EXCEEDED error is returned.

    By setting the DIRX_CTX_LIMIT environment variable the Hard-Limit can be controlled. By setting the DIRX_CTX_LIMIT_SINGLE env variable the Single Ctx Limit can be controlled.
    The Soft-Limit cannot be set (always Hardlimit-40MB).

  • If both DIRX_CTX_LIMIT and DIRX_DSA_CACHE_SIZE are set by the user, the sum of the values cannot exceed 100% of the physical memory size.
    If none of the variables are set, the DSA calculates the CTX limit and the DBAM Cache size automatically based on the total physical memory.
    The automatic calculation allows only 80% of the physical memory to be used by the DSA and the LDAP server, 20% is left for the OS and for other applications. This 80% of memory is distributed between DSA(75%) and LDAP server(25%).
    If both DIRX_CTX_LIMIT and DIRX_DSA_CACHE_SIZE are set by the user, the sum of the values cannot exceed 100% of the physical memory size.
    If only one of the two variables is set, the other is calculated based on the previously mentioned auto-calculated memory limit for the DSA. If any of the two variables (or both) are set, the DSA will check the values against the physical memory. If the values are not suitable, the DSA will not start and an error message will be added to the fatalDSA* logfile, containing the accepted value range based on the physical memory of that server.

  • In the past an attribute with Directory String syntax could only store characters with 3 bytes or less, even if UTF-8 representation choice was configured. The DSA internally stores the normed characters of a Directory String as 16 bit number. As an UTF-8 character consisting of more than 3 bytes cannot be represented using a 16 bit number, the operation to add such data to the database was rejected. This behavior has been changed starting from version DirX Directory 9.1:
    4 bytes UTF-8 characters (e.g.: emojis) are also accepted in attributes with Directory String syntax, but only with several restrictions:

    • Only the storage and retrieval of such characters is supported within the DB (dirxbackup, dirxload, ldif_dump, dirxmodify handles 4 bytes UTF-8 characters as they were entered into the DB)

    • dirxcp and dirxadm - because of the underlying Tcl library restrictions - cannot handle 4 bytes UTF-8 characters

    • Internal storage of normed character representation remains a 16 bit number to maintain DB compatibility. Because a 4 byte UTF-8 character cannot be represented using a 16 bit number, every such character will be normalized to the '.' character (this affects sorting, indexing, filter match).

    • As a consequence, a search result may be incorrect if 4 byte UTF-8 character is present in a search filter: value<emoji-1> would match to value<emoji-2>. Because of this behavior, search filters containing 4 byte UTF-8 characters will be rejected.

    • As another consequence, two values which only differ in 4 byte UTF-8 characters cannot be added to the same attribute.

    • You cannot have two entries under the same node, where the DNs differ only in 4 bytes UTF-8 characters

    • 4 byte UTF-8 characters can only be used in a shadowing configuration, when all the servers are already updated to a SW version supporting this. Otherwise the total update will fail, shadowing will not work.

  • Maximum Number of filter items in a search operation
    A new limit has been introduced (controlled via environment variable DIRX_SEARCH_FILTER_ITEM_LIMIT) that sets the max upper limit for filter items contained in a search operation. If this environment variable is not set, the default limit value of 5000 filter items is used.
    If the filter item count exceeds the predefined limit, the DSA rejects the operation with 'unwilling to perform' error, and a diagnostic message about the limitation.

  • The maximum PDU size for an IDM message is limited to ~2GB (MAXINT value). If a DAP search result PDU grows greater than this limit, the search operation will be rejected by the DSA with 'unwilling to perform' error and additional diagnosticMessage:
    "Search result PDU size greater than 2147483647 not supported"

DirX server restrictions

The following restrictions apply:

  • ModDN operation:

    • If a ModDN operation results in adding an entry to or removing an entry from a replicated area defined in a shadowing or ldif agreement, the DSA reports an "affects multiple DSAs" error.

    • ModDN operations are rejected during a total update shadowing operation is performed. There are 2 exceptions from this rule:

      1. ModDN operations are allowed during the particular total update performed as a result of a shadow administration command (total update of the replicated area /cn=cooperatingDSAs-Subentry).

      2. ModDN operation that do only change the last RDN (newSuperior is not set) are allowed during any total update.

  • DIRX_SyncFile and shared filesystems
    The synchronization mechanism used by DirX to control access from the DSA process and/or other tools to the DBAM Database is a file named <installation path>/server/conf/.DIRX_SyncFile. This file must be located on a local file system. In case the installation path points to a shared file system perform the following procedure for the DBAM initialization:

    1. perform dbamboot: this tool will report an error, but will nevertheless create a correctly formatted .DIRX_SyncFile.

    2. copy this file to a local UFS filesystem

    3. create a symbolic link named
      <installation path>/server/conf/.DIRX_SyncFile to the copied file

  • Max number of filedescriptors for DirX processes on Unix

    In DIRX the file descriptors 0-255 are reserved for internal usage and therefore all socket descriptors are shifted beyond 255. If this is not possible the following error output is displayed on stderr:

    ### IDM-Problem (error = 11523 - Cannot shift socket beyond 255)
MoveDescriptorUp() failed in IDM_SetupActiveConnection(). Socket Closed.

    This failure occurs, if you don’t have enough descriptors available beyond 255. In order to prevent this failure, DirX binaries set the number of available filedescriptors to the value of 8192. In case the setrlimit() call fails the binary does not start and the following messages are printed to stderr:

    "Setting resource limit (NOFILE) failed!\n
Softlimit: <old> -> <new>, Hardlimit: <old> -> <new>"
"Increase the hardlimit to at least 8192 by adding
set rlim_fd_max = 8192
in /etc/system and reboot the system!\n"

    The actual limit can be checked with ulimit -n

    Starting with DirX Directory V8.4, on Linux the maximum number of filedescriptors for DirX processes is no longer restricted to 1024. The DirX sources are now compiled with increased FD_SETSIZE to 8192.

  • The following max numbers of parallel incoming LDAP connections are supported

    On LINUX:

    max 4000 LDAP Connections

    On WINDOWS:

    only limited by OS

    The limitations are due to the fact that each LDAP connection may consume 2 descriptors (1 for the frontend LDAP connection and one for the backend DAP connection to the DSA).
    A few descriptors are also consumed by the servers itself for internal communications.
    These figures describe the limits for a single ldapserver process.

  • maximumvalue of a socket descriptor: DirX cannot handle socket descriptors that exceed 65535.

  • On Linux platforms DBAM devices must be block devices. These devices can be configured using a logical volume manager, e.g. LVM under YAST on SUSE LINUX.

  • Transaction log device and DBAM Cache Size:
    The DBAM Transaction log device contains transaction logs and is always a separate raw device. See the Disc Dimensioning Guide for details. The minimum size of the transaction device is 256 MB. For best performance the size should increase with DBAM cache size and checkpoint size. As a rule of thumb multiply DBAM cache size by 2 getting the optimum size. A transaction device size of 4GB performs well even with very large DBAM cache sizes of 4GB and a lot larger.

  • Network connections:
    The server (and the client) can perform network connections either over IDM or over the SSL protected variant IDMS. DirX is prepared to work over IDM and IDMS.
    NOTE: that no interoperability tests with other vendor’s X.500 products have been performed yet over the IDM/IDMS stack.

  • Virtual list view (VLV) search operations are not supported, the associated ldapControl has been removed from the LDAP root subentry cn=ldaproot.

  • Indexing (dirxadm db attrconfig operation)

    • optread option is not supported
      This option can be specified optionally when performing the db attrconfig operation. The value has no effect how the attribute is stored in the database.

  • Shadowing and LDIF agreements

    • The consumer machine must be at least as powerful as the supplier machine.

    • Your system resources affect the maximum number of entries distributed over a total update by the DSA when performing DISP. Consider to configure total-update-by-media (CO=TRUE) for directories with a very large number (e.g. more than 1 million) of entries.

    • The number of shadowing and LDIF agreements is limited to 128.

    • Your system resources - for example main memory or disk space - limit the generation of LDIF files.
      To avoid problems when writing LDIF files enable automatic LDIF file splitting by setting the system environment variable DIRX_LDIF_SPLIT.

    • The server ignores values specified in the -validity option of the sob / lob create operations.

    • The sob / lob modify operations are not supported.

    • The MAXOSK component of the supplier policy (SUPP component of SOB-Policies attribute syntax) is not supported.

    • Specifying the value 0 or a value exceeding the available memory of your system for the MAXLOC component of the SOB-Policies attribute syntax is prohibited.

    • When performing a total update by media that is using dirxbackup to restore the data saved on the supplier DSA to the consumer DSA the following applies:

      • There is only one supplier DSA holding all master entries and all other DSAs participating in the network are consumer DSAs (contain only shadow entries).

      • The whole DIT should be shadowed on all consumer DSAs.

      • The supplier DSA and the consumer DSAs must run on the same platform.

      • The supplier and consumer DSA must have the same database configuration (DBAM profile).

      • The procedure described in chapter 10.3.2 "Performing a Total Update by Media" the Administration Guide must be followed.

    • When terminating or deleting a shadowing agreement where the option CHANGEO=TRUE (changes only configured TRUE) is configured, shadowed entries remain untouched at the consumer DSA. That is if entries are deleted on the master DSA and afterwards the shadowing agreement is re-establishing respectively re-creating those changes are not propagated to the consumer DSA.

    • If an administrator terminates a shadowing agreement where the total update has been performed by media and re-establishes the shadowing agreement a new total update is required.

    • If you perform a dirxadm sob establish operation, check the status of the corresponding agreement after about five minutes. Repeat the operation if necessary.

    • In the event that the DSA has disabled an agreement the administrator must perform a dirxadm sob enable operation after having solved the problems occurred.

    • If the number of updates exceeds your system resources, for example file size limitations (journal files) or available memory, and cannot be send to the consumer the shadowing agreement is disabled. Then the administrator must perform a total update.

    • The dirxadm sob switch operation can only be performed for all shadowing agreements and the whole DIT. In a scenario with asynchronous and synchronous shadow agreements only the latter Consumer DSA can replace the supplier.

    • If the DSA crashed while performing update operations a consumer may be out of sync and a new total update must be performed after performing the emergency switch and restarting the former supplier. This does not apply to synchronous consumer DSAs.

    • Secondary shadowing is not supported

  • Password Policy

    • The compare operation is not Password-Policy aware.

    • In a Password policy aware system only single-valued user password attributes are allowed. No considerations are done for directories or systems that allow a user to maintain multi-valued password attributes.

    • The operation to change a password that has been reset by an administrative command is a modEntry with a single change, a replace of the userPassword attribute.

    • The addEntry operation is not passwordPolicy aware, i.e. if the entry is created with an userPassword attribute, the password value is not checked against the password policy with respect to the password quality. The operational attribute pwdMustChange may be set to TRUE in order to enforce the change to an password policy conformant password value.

    • Enabling Global Password Policy State in a running system Switching to the Global Password Policy States requires to set the operational attributes to consistent values on all participating DSAs. Therefore the following steps should be performed in the given order:

      1. disable the password policy features Account lock and Password Aging: modify all related password policy subentries by setting PPMAXA=0 and PPLOCK=FALSE

      2. set the environment DIRX_GLOBAL_PPO_STATES=1 on all participating DSAs.

      3. restart the DirX service on the Supplier and on all participating Consumer hosts.

      4. terminate and re-establish the Shadow Agreements to all participating Consumer DSAs.

      5. enable the required Password Policy features. The steps a. and d. can be omitted, if neither Account Lock nor Password Aging were ever enabled in the directory service.

    • If Global Password Policy States is enabled, the DSA Audit will contain records of modify operations that are not triggered by client application requests. These records represent the modifications issued internally by the DSA in order to change the password policy related state of an entry. The modifiers name for those operations is <DSA DN> suffixed with "--PPO"

  • DSA Policies

    • If a shadow DSA is setup by media, it will that way be supplied with the DSAPolicy attribute of the root DSE. In case the Shadow DSA is setup by a total update by DISP protocol, the DSA Policy attribute must be administered explicitly at the Shadow DSA. Otherwise future bind operations between master and shadow DSA will fail. This applies only to the case, where non-default DSA Policies are used.

  • Server Side Sorting

    • The DirX DSA supports Server Side Sorting only for one attribute. This attribute must be indexed and must have an ordering matching rule. For non-reverse order sorting the INITIAL index, for reverse order sorting, the INITIAL and ANY indexes must also be configured. Attribute with string types are sorted implicitly lexicographically. Sorting in reverse order is supported. In dirxcp the server-side-sorting control is attached to a search operation by specifying the option -vsortkey <attrType> and -vtype vlv. Note that the vlv type must be specified for historical reasons and does not include the correspondent ldap control.

  • Paged Search Operations and Chaining

    • Paged searching works in general only for not-distributed directories. If the base object of the search operation is the reference or is located below the reference, then the paged search is executed by the remote DSA and the operation can perform. Otherwise, if the the base object of the search operation is situated above a reference in the DIT, the DSA returns an "unwilling to perform" error.

  • The matching rules for a given attribute must be consistent with respect to the case handling in the schema. That is, the matching rules for equality, substring and ordering must be either all ignorecase or all exactcase. The DirX DSA rejects schema entries with conflicting matching rule definitions, e.g. an attribute with DirStr Syntax cannot have an caseExactMatch equality matching rule and a caseIgnoreSubstringMatch substring matching rule. In this case an "unwilling to perform" error is returned and the Error Message is set to "Error in attributeTypes: Value=<AttributeType>; Reason=Combination of matching rules is not supported."

  • Restart after restore DB
    The dirxdsa process is restarted after a database was restored by dirxbackup -R. The watchdog processes (dirxdsas / dirxsrv.exe) will restart the service and all components will have the knowledge of the restored DB.

  • Sizes displayed by the tools dirxbackup and dbamdevinfo
    When performing the dirxbackup -T -i <archive_name> operation to display the profile info of a saved database, the tool reports device sizes for the various block types and the portion of the respective device that is used. The latter is referred to as "device range in use". The "device range in use" cannot be compared directly with device "space in use", that is part of the output of the dbamdevinfo command. The "device range in use"-size is computed based on biggest block number found in the respective device, whereas the "space in use"-size is the sum over all blocks used within a device.

  • Ldapserver from a DIRX-CL package:
    Synchronization between a remote DSA and a ldapserver that is installed from a DIRX-CL package does not work correctly: If the DSA crashes, the respective DirX Service Process (dirxdsas or dirxsrv.exe) cannot notify the remote ldapserver process. Therefore the ldap result cache may be used as long as there is no need to perform a rebind to the DSA. Advice: Do not use the ldap cache functionality on DIRX-CL package.

  • Ldap result cache restrictions
    Search Results are not cached by the ldapserver if one of the following attributes occur in the search filter or in the requested attributes list:

    • pwdExpirationWarned

    • pwdAccountLockedTime

    • pwdFailureTime

    • pwdGraceUseTime

    • pwdFailureTime

  • LDAP result cache size restriction
    The size of the LDAP result cache must not exceed 2 GB. The environment variable DIRX_WDOG_RESTART_LDAP_ON_DSA_RESTART=0 must not be set if LDAP cache is enabled.

  • On 64-bit platforms the OSI Stack is not supported. This applies to the native 64-bit applications of DirX on Windows and Linux.

  • Restriction that apply when using DNS Names in PSAP Addresses
    Using DNS-Names in PSAP addresses (NAT support) is ONLY supported if the following environment is established:

    1. all specified DNS-names must be administered in a way that the correct IP addresses are returned, i.e. both sides of a connection must be correctly administered in DNS.

    2. Multiple IP addresses may be returned by a lookup of a configured dnsName from DNS. The DirX Processes use the first address returned by the name resolver for the specified IP version.

    3. DirX must be installed and running on the IP address returned from DNS.

    4. dnsNames are only supported for IDM communication stack, not for OSI

  • Note that subschema subentries (Structure and Content Rules) are not needed.

  • RACF external authentication
    RACF external authentication works only via IPv4.

  • RPC protocol restricted to IPv4
    Internal RPC between DSA and LDAPServer process uses IPv4 stack only.
    If the IP stack for RPC connection is restricted to v6, the ldapserver won’t start, the exit code in this case is 21.

  • Progressive purge

    Some restrictions apply while progressive purge is running :

    • A normal purge (dirxadm command: db purge -pob) operation is rejected

    • A purge analyse (dirxadm command: db purge –analyse) operation is rejected

    • Post indexing (dirxadm command: db attrconfig …) operation is rejected

    • ModDN operations are rejected if a new superior of the entry is specified.

    Starting a progressive purge is being rejected if one of the following operations are running:

    • A normal purge (dirxadm command: db purge -pob) operation

    • A purge analyse (dirxadm command: db purge –analyse) operation

    • Post indexing (dirxadm command: db attrconfig …) operation

  • Dynamic groups
    dirxMemberUrl does not support host name, port number and attributes.
    Values of the attribute dirxMemberUrl must supply base-dn, scope and filter.
    In case the search base is the ROOT Dse then base-dn can be omitted.
    Extended filter match is not supported
    Phonetic matching is not supported
    Some attributes are not supported in filter items. These attributes are:

    • dirxMemberOf, dirxMember, numSubordinates, numAllSubordinates,

    • structuralObjectClass, dseType, vendorName, vendorVersion,

    • entryACI, prescriptiveACI, subtreeSpecification, subentryACI,

    • all knowledge attribute, password policy attributes and others.

    Look into the schema file created by the DSA at startup time. There is table named "Allowed index and outsourcing configuration". Each attribute with a 'G' flag specified is not allowed for dynamic group filter expressions.

  • LDAP Group Policies
    When using the ldapGroupPolicies configuration attribute to set rules for members of groups, the number of members is limited to 1 million per group. If a group contains more members the LDAP server will discard the rule. Especially when dynamic groups are involved, care must be taken to not exceed this limit by 'simple' filters that result in large member counts. The limit was introduced to avoid long startup times, as all members of LDAP group policies rules must be evaluated/read at startup time. Both, startup time and memory consumption will suffer, if the groups become large. Further, keep in mind that due to the fact that the members are read at startup time (or at time when the LUP is refreshed by an extended operation) a change of the group members after startup or refresh time is NOT automatically recognized by the server. If frequent updates are required we recommend to trigger a dynamic LDAP User and LDAP Group Policies update by a cron job or extend client software (e.g. Workflows) to perform such an update after finishing their work.

  • 2FA (Two-Factor Authentication)
    There are limitations on what characters are allowed in the dirxTOTPSecret attribute. It contains data in otpauth format. The generated otpauth is made of three parts: the naming attribute of the user, the issuer, and the TOTP secret. In the naming attribute, the special non-alpha-numeric characters are replaced by the space (" ") character. The issuer (generally the name of the organization) can only contain alpha-numeric characters and the percent ("%") sign. Special characters can be displayed in the authenticator app when using the percent notation of such characters. For more information about percent encoding visit https://datatracker.ietf.org/doc/html/rfc3986#section-2.1

LDAP Proxy

This paragraph refers to the DirX ldapserver running in LDAP proxy mode

  • SSL/TLS Client Authentication
    If the LDAP server is configured to run in proxy mode, it will support SSL/TLS client authentication (CLA) only between client and proxy, but NOT between proxy and target LDAP server. This is due to the fact that CLA requires client key material to be present at time of connection establishment, which is not the case when the proxy will connect to the target LDAP server. Therefore, only SSL/TLS server based authentication is possible.

  • Change of the Proxy Servers Configuration
    Usually the proxy reads its LDAP-configuration from the LOCAL DSA but not from any of the target servers DSAs. Thus, changes intended for the proxy must be done to this DSA and not to a backend DSA unless the proxy’s DSA is a full shadow of the backends.

  • Connection limitation
    The proxy server will open one backend connection for every frontend connection, i.e. no backend connection sharing is available, which must be considered regarding file descriptor usage. The proxy will be capable of holding up to 4000 parallel client connections on Linx. On Windows the number of available descriptors is not configurable and depends on OS and available physical memory.

  • ldap extended operations
    By design, the proxy server will not forward Ldap Extended Operations with the only exception of RFC3062. This implies that Extended Operations used for monitoring will return the information from the proxy server itself and/or the LOCAL DSA but not from any of the backend servers.

  • Proxy configuration file and UTF-8 characters
    The proxy server configuration consists of a JSON formatted file. As attribute values or distinguished names have to be specified, a UTF8 supporting editor should be used to create that configuration file. Furthermore the internal normalization of the configuration strings does not work for characters > 0x7f (multi-byte chars). Thus, if multi-byte UTF8 chars appear in the JSON file (e.g. small 0xC3 0xBC for the Latin1 ‘ü’ character, they will not match to their capitals and must therefore be configured exactly as they will appear in the LDAP protocol. E.g. let’s assume a user containing a german Umlaut ‘ü’ (e.g ‘Müller’) shall have an explicit USER-Rule in JSON, then the user-name must be specified by the following 7 bytes M0xC30xBCller. This rule will then match whenever a LDAP user will bind as ‘Müller’, but it will NOT match if the user binds as ‘MÜLLER’ due to the fact that during normalization ‘Müller’ will be transformed to M0xC30xBCller and will match the rule while ‘MÜLLER’ will transform to M0xC30x9Cller and will not match. To overcome this flaw, it is possible to create another rule (copy) where the user-name appears with the capitalized chars.

dirxload

Dirxload option -x no longer supported.
This option was intended to direct dirxload not to perform attribute indexing during the load operation. As it was up to the administrator to perform the post indexing after the load process, the attribute indexes became potentially inconsistent with the loaded data.

In the default schema of DXD 8.7 the attribute type supportedSecurityProtocols is set to multi valued. Hence, if an LDIF file is loaded with a schema entry containing the old (single-valued) definition of that attribute an error occurs during the load, i.e. changing that attributeType definition of supportedSecurityProtocols to multi-valued as the input is required.

dirxadm

The maximum number of subentries displayed by dirxadm in a search result is limited to 128.

There is a bug concerning the deletion of multiple attribute values, if the concerned attributes have a DistinguishedNameFirstComponent Equality Matching Rule. This is the case for values of the attributes UserPolicies (USP) and DSAPolicies (DSAP). As workaround you can perform the desired deletions in multiple operations, i.e. instead of

    dse modify / -rem {USP={DN1};{DN2}}

use

    dse modify / -rem {USP={DN1}} ; dse modify / -rem {USP={DN2}}

dirxcp

Certificate database files for dirxcp.

The Certificate database file is a NSS cert8.db (suitable for libldap60.so or nsldap32v60.dll).

DirX Manager

Enabling encryption with 256 bit keys for TLS/SSL

By default JAVA 8 only runs a weak-level cipher policy, ending up with using only export or 128Bit ciphers. To enable higher ciphers (like AES256) it is necessary to install a new policy package called

Java Cryptography Extension (JCE) Unlimited Strength

This package actually replaces 2 policy files in the lib/security folder of the corresponding JRE installation. After doing so it is possible to run a 256Bit AES connection from DirXManager to the ldapserver.

Please refer to the file Documentation\DirX\DirXManager\Readme.html for further information on restrictions.

The port the snmp trap view window in DirX Manager listens on incoming SNMP V2 traps cannot be configured. DirX manager is always listening on port 162.

Support of IPv6 Addresses

General Notes on IPv4 / IPv6 communication restrictions:

  1. only the IDM stack provides functionality for IPv6, the OSI stack does not.

  2. For IPv6 traffic, it is highly recommended to run all DSAs on Dual-Stack machines, i.e. machines that provide the IPv4 and the IPv6 stack, because this provides the maximum flexibility to interconnect different types of DSAs.

  3. The setting of DIRX_IP_STACK defines for which incoming traffic the DIRX servers will listen. The settings within the PSAP address defines which stack the DSA will use when he connects to other DSAs.

  4. Currently all Redhat/Suse Linux are able to run as dual stack hosts (it might be necessary to activate the IPv6 stack explicitly, but it is basically there). Windows Server and new also provide dual IP stacks. WARNING: Don’t set the DIRX_IP_STACK variable to a value that your host system does not provide! (e.g. don’t set 'all' if you only have IPv4)

  5. When IPv6 communication shall be used between two machines A and B, it must be ensured that the DNS resolver returns the IPv6 addresses of B when it is called from within A and vice versa for B (i.e. you must have a correctly configured DNS resolving that supports IPv6). If dual-stack communication shall be used DNS must return both IPv4 and IPv6 addresses of the dual-stack machines. You can check this by using the dirxhostinfo -I command.