Idea ID: 2702884

SMAX OPB change for LDAP compatibility without “Simple Paged Results Control”

Status : Waiting for Votes
Waiting for Votes
See status update history
over 1 year ago

We are a partner involved in a big client migration to SMAX.

Some weeks ago, we found a problem with the integration with their LDAP. Their LDAP does not support “Simple Paged Results Control“.
We know, their LDAP is not in the Matrix support compatibility for SMAX, but we found a workaround that is working perfectly and SMAX works with LDAP that is not supporting “Simple Page Results Control”.

My idea is to create a configuration file in OPB, so the client can have the possibility to change the value of the parameter "1.2.840.113556.1.4.319 / pagedResultsControl" to false.

It’s only to change a specific parameter in the “OPB” (On Premise Bridge) tool, in a specific java file.
It’s a Boolean parameter. We've changed it, compiled and LDAP is working correctly.

Below, I detail the change needed:

The file `ldap-domain.jar` is the one which has to be changed:

user@machine:/opt/MicroFocus/OPB/product/domain/ldap-domain/lib# ls -lrtha ldap-domain.jar*
-rwxrwxr-x 1 root root 47K Jul 29 21:30 ldap-domain.jar.original
-rw-r--r-- 1 root root 53K Oct 15 09:30 ldap-domain.jar

The class is `AbstractLdapConnector`, in the `convertSearchRequest` method, the original line is:

pagedResultsImpl.setCritical(true);


With the value set to true, OPB marks the query extension control as critical, and the ldap says 'unavailableCriticalExtension', and the query return 0 results.

The OPB log shows:

INFO: MessageType : SEARCH_REQUEST
Message ID : -1
SearchRequest
baseDn : 'ou=users,dc=XXXXX,dc=YYYY,dc=ZZ'
filter : '(&(uid=*))'
scope : whole subtree
typesOnly : false
Size Limit : 2147483647
Time Limit : 180000
Deref Aliases : deref Always
attributes : 'uid', 'mail', 'givenName', 'cn', 'modifyTimestamp', 'createTimestamp', 'userAccountControl'
org.apache.directory.api.ldap.model.message.SearchRequestImpl@780b5df8 Paged Search Control
oid : 1.2.840.113556.1.4.319
critical : true
size : '1000'
cookie : ''

We can change the behaviour of the query modifying the line (obviously we've to compile and replace the jar file):

pagedResultsImpl.setCritical(false);

And now it works with their LDAP product and SMAX:

Message ID : -1
SearchRequest
baseDn : 'ou=users,dc=XXXX,dc=YYY,dc=ZZ'
filter : '(uid=*)'
scope : whole subtree
typesOnly : false
Size Limit : 2147483647
Time Limit : 180000
Deref Aliases : deref Always
attributes : 'uid', 'mail', 'givenName', 'cn', 'modifyTimestamp', 'createTimestamp', 'userAccountControl'
org.apache.directory.api.ldap.model.message.SearchRequestImpl@10f48dc9 Paged Search Control
oid : 1.2.840.113556.1.4.319
critical : false
size : '1000'
cookie : ''

 

INFO: LdapSyncTask: Get data from ldap cost 17342ms. Config page size:1000. Config bulk size:1000. Actual bulk size:60. Rest Records size:785

Now the OPB gives the data to SMAX in 60 portions of 1000 users (almost 60.000 users).

With a little more coding, we can add this parameter to be read in execution time in the `ldap.conf` file, modifying the `LdapConfigurationFacade.java`.

Kind Regards.

 

Tags:

Labels:

SMAX
Parents
  • Facing that exact same issue currently with a large corporate Microfocus SaaS customer. Telling them to replace their corporate LDAP server solution is not an option.

    Please make this option configurable (just a switch in the ldap-domain configuration file would be enough).

Comment
  • Facing that exact same issue currently with a large corporate Microfocus SaaS customer. Telling them to replace their corporate LDAP server solution is not an option.

    Please make this option configurable (just a switch in the ldap-domain configuration file would be enough).

Children
No Data