Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional user id field #13

Open
jceb opened this issue Dec 11, 2015 · 1 comment
Open

Additional user id field #13

jceb opened this issue Dec 11, 2015 · 1 comment

Comments

@jceb
Copy link

jceb commented Dec 11, 2015

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:

  1. 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.
  2. 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.
@it25fg
Copy link
Contributor

it25fg commented Dec 14, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants