On 21.05.2013 12:37, Bolesław Tokarski wrote:
> Hello,
> 
> I put some time and effort creating this, please read at the very least
> introduction and suggestions.

Thanks, this was quite a detailed post and brings back memories :)

> We are using SSSD with some success now. Thanks to Timo Aaltonen's
> efforts, the packages available in Precise were working pretty well and
> were updated to the latest point releases. There is a Main Inclusion
> Request for SSSD (Bug #903752), I hope it gets included since Saucy.

Hope so.. details below

> = Authentication configuration by package =
> == sssd ==
> 
> SSSD does not provide a configuration for you aside from entries to
> /etc/nsswitch.conf and PAM. You are pretty much on your own editing
> /etc/sssd/sssd.conf yourself. Also, because you need some other backend
> too, you likely get LDAP and Kerberos backends too. This causes you to
> have 3 authentication modules in PAM and 2 NSS backends in NSS (I might
> be wrong about the latter, though).

SSSD handles those in libpam-sss/libnss-sss, it doesn't need
libpam-krb5/ldap etc.

> = Automatic configuration of authentication =
> == SSSD ==
> 
> SSSD is easy to deploy. The problem is that you probably also need the
> backends - LDAP and Kerberos and actually those configurations interfere
> with SSSD and you get install-time questions.

nope, shouldn't happen as mentioned above

> = Suggestions =
> 
> I believe it is crucial to pick a preferred authentication solution for
> Ubuntu. Of course local file authentication is good for most cases, but
> when there is some directory service, it should be at least one obvious,
> preferred and supported method.
> 
> Currently this seems to be LDAP and Kerberos using libnss-ldap,
> libpam-ldap and/or libpam-krb5, but this is not perfect, as mentioned
> before.
> 
> I strongly vote for this to be SSSD. RedHat is actively developing it
> and it seems to be running quite decently on Precise already. For this,
> the following obstacles need to be handled:
> - SSSD needs to be included in main (Main Inclusion Request #903752)

The blocker is getting the new-ish samba stuff (samba4, ldb, libtevent)
in main. Looking at the bug again it looks like the ball is on my court,
boo.. I'll file the missing MIRs soon.

Saucy will get SSSD 1.10.x which builds against libnl-3-dev, so that's
the first version to get in main.

> - SSSD lacks some configuration questions. I'm ok with that, I deploy it
> with CFEngine, but I guess it might be considered a requirement

The current status is on purpose, since it makes no sense to drop a
dummy config there.

> - SSSD will likely use libnss-ldap and either libpam-ldap or
> libpam-krb5. Those do not need to be configured and if there is any use
> of it, these variables should be taken from sssd's config dialogs.

It doesn't use or need them.

> I like RedHat's approach of providing a separate piece of software that
> configures authentication. If you don't like it or you want to configure
> it with CFEngine or with text files, you don't run it or you don't even
> install it. If the configuration absolutely needs to be done inside
> package maintainer scripts, I would lower the question's priorities,
> those are too difficult to be answered by average user anyway.

There have been talks about adding support for authentication services
in user-setup, so that it could have a box to tick when you need to join
the machine as a directory client. Configuring this all should be less
of a hassle these days, not sure if realmd could be used during install
phase though or something more manual. In any case, the values could
then be preseeded for automatic installation.

This is also something I've wanted to add for quite some time now, but
never had the time to finish. How about adding a blueprint now? Not
being able to join a directory from the installer tends to be a
recurring topic on every review of Ubuntu at least on certain Finnish
press ;)

Btw, the Edubuntu guys have experimented with something similar, and I
think for client they are using SSSD as well..? So for the client, we
should indeed standardize on something, and SSSD does seem like the best
bet :)


-- 
t

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Reply via email to