Due the current design for the LDAP membership, it is likely that OpsManager isn't able to support most of the directory implementations (ie. RedHat 389, Oracle Directory Server, IBM Tivoli Directory Server, etc).

I believe we should state that we only support Active Directory (with some important restrictions). For example, if the groups in the directory are using a nested membership, OpsManager won't be able to detect the membership as per the Microsoft documentation in relation to the memberOf attribute

Be aware that this attribute lists the groups that contain the user in their member attribute—it does not contain the recursive list of nested predecessors. For example, if user O is a member of group C and group B and group B were nested in group A, the memberOf attribute of user O would list group C and group B, but not group A.

This attribute is not stored—it is a computed back-link attribute.

The support for memberOf like attributes in other directories is not compatible with the current implementation. For example, the memberOf overlay available for OpenLDAP, requires the attribute to be invoked from the JNDI query. I guess we should test if that overlay works with the current OpsManager version but I would say it won't work as I can't see any specific attribute specification in the LDAP search.

The OpenLDAP behaviour is usually the same for the rest of directory implementations as you can see in the on-line documentation from other directories.

Attribute specific to this Directory Server instance and version of the schema.

Operational attribute used by the directory service; returned in ldapsearch only when specifically requested.

The value of this attribute may only be modified by the server.

I suggest mentioning that the only supported directory is ActiveDirectory which is supported with limitations like the lack of nested groups support.

https://docs.opsmanager.mongodb.com/current/tutorial/configure-for-ldap-authentication/#prerequisites