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
When I tried to deploy plucs in an existing environment I realized that the given uids were not what I wanted to expose to the outside. The mailPrimaryAddress would be most handy to expose in my case.
From a little bit of research I'd suggest two ways of working around the issue:
plucs should provide an additional attribute that takes precedence over the default in uid. ldap_uids supports multiple values that the user can choose from. As a disadvantage comes the additional configuration effort.
If the mail domain is equivalent to the Jabber domain and mailPrimaryAddress is set properly, the following setting would allow users to log in with their mailPrimaryAddress: {"mailPrimaryAddress", "%u@%d"}. As a disadvantage come the prerequisites.
The text was updated successfully, but these errors were encountered:
Nice idea, and perhaps sometimes desirable, but...
Not using the uid as the local part of the jid would render the mod_shared_roster_ldap extension unusable because there's no way to query LDAP for group membership using only the mail address in a single query. One would lose the automatic roster management which is currently the most prominent (and user-perceivable) sign of an integrated solution. Of course, one can maintain roster groups using the mod_shared_roster extension manually, but what's the point of an LDAP integration then? It would take a little more research to get mod_shared_roster_ldap working under these conditions -- suggestions are welcome.
Nevertheless, it's nearly no effort to make ldap_uids configurable, using the sensible default that most admins will never touch. I would not consider solution (1) because it would invite all kinds of administration errors.
When I tried to deploy plucs in an existing environment I realized that the given
uid
s were not what I wanted to expose to the outside. ThemailPrimaryAddress
would be most handy to expose in my case.From a little bit of research I'd suggest two ways of working around the issue:
uid
.ldap_uids
supports multiple values that the user can choose from. As a disadvantage comes the additional configuration effort.mailPrimaryAddress
is set properly, the following setting would allow users to log in with theirmailPrimaryAddress
:{"mailPrimaryAddress", "%u@%d"}
. As a disadvantage come the prerequisites.The text was updated successfully, but these errors were encountered: