I want to know how to integrated hierarchical structure LDAP (user)

LDAP integration is not described in detail in the official documentation.
I looked at the post linked below and referenced it.

https://support.morpheusdata.com/s/article/Tips-for-integrating-LDAP-and-LDAPS-identity-sources?language=en_US

The LDAP hierarchical structure in my test environment is as follows.

dc=tc,dc=local
ou=ou1
ㅡㄴcn=group11
ㅡㅡㄴcn=user111
ㅡㅡㄴcn=user112
ㅡㄴcn=group12
ㅡㅡㄴcn=user121
ㅡㅡㄴcn=user122

My goal is to register all 4 users. ( usre111 , user112 , user121, user122 )

Currently, Morpheus consists of the following:
USER DN EXPRESSION : cn=$username,cn=group11,ou=ou1,dc=tc,dc=local

If I try to Login as user111, I can confirm that the login success.
And user112 in the same hierarchical structure also Login normally.

However, if the hierarchical structure is different like user121 and user122, of course, the DN is different, so the login is not possible.
How should I configure LDAP in this case? I tried adding accounts to each group for the same LDAP URL, but even in this case, a problem occurs.

Can you try as cn=$username,ou=ou1,dc=tc,dc=local ?

The following error occurs:

This is not a problem when the current LDAP registration method is a flat structure, but there seems to be a problem in the hierarchical structure. Do I have to think that it can’t be linked realistically?

If the structure differs for the binding user compared to the users using the integration to authenticate with Morpheus then you may not be able to use the LDAP integration.

Morpheus Support is a good reference for others in the future.

After all, does that mean that the hierarchy I’m proposing doesn’t work as an identity source?
Are you saying it’s impossible?

I would like to know if there is a way to interlock in a hierarchical structure other than the method I suggested.

Hope the below works in your case
dc=tc,dc=local
ou=ou1,
ㅡㄴcn=group
ㅡㅡㄴcn=bindinguser
ㅡㅡㄴcn=group11
ㅡㅡㅡㄴcn=user111
ㅡㅡㅡㄴcn=user112
ㅡㅡㄴcn=group12
ㅡㅡㅡㄴcn=user121
ㅡㅡㅡㄴcn=user122

USER DN EXPRESSION : cn=$username,cn=group,ou=ou1,dc=tc,dc=local

Thanks you for comment.
But the case you mentioned doesn’t work properly either.
It seems impossible because the hierarchical level between the newly created binding user and the existing user is different.

I am an engineer with experience developing Java based Maven projects. From the developer’s experience, it is doubtful whether it was developed to be impossible to interoperate in the hierarchy.

yes you are right, but users can login as user111,cn=group11 or user121,cn=group12 as this will map to $username

I previously tested using slapd.
For reference, the slapd service had a problem because I had to define the structure myself and it did not support the memberOf attribute required for role mapping.
So, I changed to the FreeIPA service and tested it, and the linkage was completed.

Thanks to everyone who helped

Just a note, release 6.0.1 has tweaks that make OpenLDAP functional as well! I believe this thread focused on the need to change LDAP provider in the lab.