LDAP integration is not described in detail in the official documentation.
I looked at the post linked below and referenced it.
The LDAP hierarchical structure in my test environment is as follows.
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
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
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