On Sun, 2013-11-03 at 18:40 +0100, Jonas Smedegaard wrote:
> Quoting Simo (2013-11-03 18:02:56)
> > On Sun, 2013-11-03 at 13:38 +0100, Jonas Smedegaard wrote:
> > > Quoting Petter Reinholdtsen (2013-11-03 09:49:24)
> > > > [Lorenzo]
> > > >> For these reasons I think it's not necessary to put LDAP in the
> > > >> freedombox. Maybe I'm overlooking something (maybe some critical
> > > >> daemon is incompatible with SASL?). I hope what I wrote can be of
> > > >> help in the design, I'm curious to hear what are the other
> > > >> opinions on this topic.
> > > >
> > > > The reason I believe it is a good idea to have LDAP on the
> > > > freedombox, is that it reduces the number of user databases on the
> > > > system. Some web service systems, like owncloud and ejabberd,
> > > > have their own user databases while also supporting LDAP as their
> > > > user database backend. Several, or perhaps most, do not use
> > > > /etc/passwd as their user database. So we can either maintain
> > > > several user databases specific to a lot of the services we want
> > > > to set up in the Freedombox, or we can maintain one in LDAP and
> > > > hook the services up to LDAP to use one common user database
> > > > instead. I prefer the latter.
> > >
> > > Ok. Makes good sense to mandate use of shared auth mechanism. Not
> > > convinced LDAP is the ideal for that, though.
> > >
> > > Beware that simply "supports LDAP" may not tell the full story: Some
> > > applications integrate with LDAP only by optional lookups of LDAP
> > > records, while maintaining its user data in a custom database anyway
> > > (i.e. not writing back to LDAP).
> > >
> > > If LDAP is used only for readonly user/group data, not for sharing
> > > other user data and not updated from the applications, then it might
> > > be safer to write a script exporting POSIX info to those
> > > applications needing a custom format (e.g. as a cron job or added as
> > > hooks to e.g. change of password.
> > >
> > > Ejabberd, specifically, _does_ support POSIX getent. That's the
> > > very reason I suggested to use that daemon: I have experience using
> > > it in production, because it fits my requirements of using that
> > > simple shared auth mechanism.
> > It would help to avoid confusing identity store with authentication or
> > authorization mechanisms.
> Please elaborate on the differences.
You seemed to mix authenticating against an LDAP server and using it as
an identity store. Although both functions are supported by LDAP servers
it is not always the case that both are used by a system.
For example many enterprise systems use an LDAP directory to hold user
information but then use Kerberos for authentication and authorization
is enforced on clients based on policies pushed via files or other
I was just cautioning that trying to lump all uses together was not
productive for the discussion.
> > > Hint for someone wanting to help: Above has to potentially low
> > > hanging fruits:
> > >
> > > * collect concrete data on which applications support which shared
> > > mechanisms for user/group management, and whether the support is
> > > readonly or read/write.
> > Read Only is the most sensible, you do not want random apps to be able
> > to write to an identity store, or you open up your flank for
> > privileges escalations.
> > > * document how to make prosody use getent.
> > the nsswitch interface (which is what you refer to with getent) is
> > pluggable, so LDAP would fit in quite easily, there are a number of
> > tools that provide plugins for all sort of identity stores.
> Petter suggests that FreedomBox use LDAP.
> I suggest to try keep it simpler. Yes, LDAP supports nsswitch, but that
> does not help keep the actual software stack simpler.
I tend to agree, given the freedombox is a simple standalone machine by
nature, it makes little sense to use something complex like LDAP, one
more thing that can break and cause issues, and I said this as a fervent
LDAP proponent in the enterprise and everyday user and developer :)