You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible (or desirable) to set out a strict way which the full dn of an LDAP object maps to the structure of Entra or other backends?
For example,
LDAP DN "uid=harry.lime,ou=sales,ou=staff,dc=thirdman,dc=com"
maps to Entra user "harry.lime" in the "sales" group nested in the "staff" group? (unsure of Entra terms and structure)
The advantage would be a clear relation between the structures of different identity servers.
On the other hand, enforcing a structure might make interacting with applications which expect a particular structure difficult, or make adopting tough for orgs with an established directory.
Longer term, the mapping could be configurable.
The text was updated successfully, but these errors were encountered:
I think each user can only be in a single OU. Since users can be part of multiple Entra groups, there's no obvious way to decide which set of groups gives the canonical way to partition users so that each ends up in a single group. Because of this, the most obvious solution is to put all users in the same OU and to allow users to be members of as many groups as necessary. In other words:
Users are all part of OU=users
Groups are all part of OU=groups
Any users that directly belong to a group should be marked as a member of that group in LDAP
This is what Apricot already does.
The one aspect of Entra that isn't cleanly translated at the moment is that Entra groups can belong to other groups, while LDAP posixGroups can't. If you think it's worth adding functionality to resolve indirect membership like this into membership of the group, please could you open an issue?
Would it be possible (or desirable) to set out a strict way which the full dn of an LDAP object maps to the structure of Entra or other backends?
For example,
LDAP DN "uid=harry.lime,ou=sales,ou=staff,dc=thirdman,dc=com"
maps to Entra user "harry.lime" in the "sales" group nested in the "staff" group? (unsure of Entra terms and structure)
The advantage would be a clear relation between the structures of different identity servers.
On the other hand, enforcing a structure might make interacting with applications which expect a particular structure difficult, or make adopting tough for orgs with an established directory.
Longer term, the mapping could be configurable.
The text was updated successfully, but these errors were encountered: