[Feature Request] Compounded LDAP queries

[q-wertz]

As far as I understand, at the moment it is not possible to compound different LDAP entries to an UID.

Is this forbidden by design?

It would be quite useful to e.g. compound prename + "." + surname from LDAP to an Matrix UID.

If you could give me a hint at which point in the source code this would have to be implemented I could give it a try.

[jdreichmann]

That is probably best done in LDAP itself - if you are using the inetOrgPerson f.ex. the full name is in the cn (common name) attribute.

[q-wertz]

Hello, thanks for the response.

That is probably best done in LDAP itself

How do you mean that? By adding an additional attribute? In many cases that is not possible, as the LDAP or AD Server is controlled by someone else...

if you are using the inetOrgPerson f.ex. the full name is in the cn (common name) attribute.

In my case the cn is a non humanfriendly random 34digit string. And my idea behind the feature request was to take e.g. the givenName and sn attributes and merge them together as Matrix UID. The problem of course then might be, that they are not necessarily distinct.

Is it usual for the matrix ID to be "non-user-friendly" and the searching for other users is done by 3PID?

[jdreichmann]

Most LDAP servers have cn as the actual common name, if you both cannot control the LDAP data layout and have non-standard content in the attributes, then yes, you would need a feature like this.

But this is more of a workaround to strange LDAP data, and ideally, you would want to convince your LDAP admin that they should put the common name in the cn field and move the unique 34digit identifier you mentioned into the fitting field, uid.

As for matrix-IDs: Ideally, both displayName and localpart of the ID are human-readable, with localpart being sth like the login-name and the displayname being the normal common name. This avoids the issue of collisions, because displayNames are allowed to be non-unique.

[q-wertz]

As far as I know the reason for not putting personal data in the cn field were privacy concerned (Germany :sweat_smile:). The uid entry is our standard login name for most of the services but should not be exposed to other users (also due to privacy concerns) which makes it unusable as a matrix-ID (because then I can get a connection between real person and uid from the matrix server)...

Sorry looks like a very specific problem from my side here... (Whereas in my understanding it is not part of the standard to restrict the cn to something user friendly, especially in large directories configuring cn as something like prename.surname will also lead to name clashes which have to be resolved by adding numbers etc.)