Authentication services in Ubuntu

Tue May 21 13:47:13 UTC 2013

I'm pretty sure the default encryption is relative week is because the
packages are distributed internationally. Cryptographic software is
consider a munition and subject to ITAR regulation. Many countries restrict
what can be imported and/or used within the country.

I think the most common solution to this is to distribute a weak
configuration and provide a mechanism for admins to change to a strong
configuration <i>if allowed by local law</i>. (This is enforced by a
click-thru agreement and fear of prison, not technology like GeoIP.) Java
takes this approach, for example, where you can download and install a
stronger "policy" file or just install a different crypto provider like
Bouncy Castle.

Obviously you can write your own scripts to do whatever you want but it is
a strong consideration for distributions. E.g., for years Debian had a
"non-US" category for packages that contained strong cryptography since the
US export restrictions prevented them from being exported. This would have
caused huge headaches for US-based download sites and they solved it by
moving those packages off-shore. (The US has since relaxed (but not
eliminated) export restrictions and the packages are now hosted in the US.)

This is only one small piece of the puzzle, of course, but it's going to
have a definite effect.

BTW "old" is usually "better" in cryptography (as long as you can use
modern keys and the latest implementations). That means there's been time
for knowledgeable people to look for holes. MIT Kerboros has had an
alarming number of implementation bugs but the underlying algorithm has
been extensively studied and fixed.

In contrast "new" usually makes people shudder. There are a lot of subtle
ways to screw it up and all it takes is one oversight for the system to be
(potentially) compromised. Heck, look at the Debian openssl screwup a few
years ago where a fairly knowledgeable person made a small change and left
countless web sites with easily compromised SSL keys.

Bear

On Tue, May 21, 2013 at 3:37 AM, Bolesław Tokarski <
boleslaw.tokarski at tieto.com> wrote:

> Hello,
>
> I put some time and effort creating this, please read at the very least
> introduction and suggestions.
>
> = Introduction =
>
> I am a maintaining the Ubuntu deployment in Tieto company. We have over
> 500 Ubuntu desktops. I am also trying to gather the Ubuntu Enterprise
> community (see https://launchpad.net/~**enterprise-ubuntu<https://launchpad.net/~enterprise-ubuntu>and its mailing list). The group is open so feel invited.
>
> I would like to take up the topic of Corporate authentication in Ubuntu
> and base my actions depending on the direction Ubuntu heads for.
>
> = Authentication choice =
>
> First - authentication in general. There is a number of authentication
> services available to an enterprise deployment open source:
> - plain LDAP (optionally including cached credentials with nss-updatedb
> and pam-ccreds)
> - LDAP+Kerberos (optionally including cached credentials with nss-updatedb
> and pam-ccreds)
> - SSSD by RedHat
> - winbind3 by Samba
> - winbind4 by Samba
> and proprietary:
> - Likewise Open/Enterprise
> - Centrify
> - VAS/QAS/DAS I think it's currently Dells
> - PowerBroker Identify Services by Beyondtrust
> - more, I guess
>
> == Open source+supported ==
>
> The packages that are currently supported officially (I mean by Canonical
> by being included in the main archive) are:
> - plain LDAP
> - LDAP+Kerberos
> - winbind3
>
> Hopefully, the SSL bug in LDAP libraries is now gone (Bug #423252), so the
> first 2 can be used productively on desktops and/or servers. Note that
> cached credentials (with nss-updatedb and pam-ccreds) are not officially
> supported as their respective packages are in universe.
>
> Winbind3 might work for some Active Directory deployments, but sorry - not
> mine. Perhaps it's a size issue (20k accounts), perhaps it's something
> else. There's always been problems with Winbind3.
>
> == Open source+unsupported ==
>
> I found that the Linux/Ubuntu community is very helpful, so not having
> official Canonical support for some pieces of software is ok for me, not
> sure about other companies. Anyway I find it less troublesome to use common
> open source solutions than to buy a niche commercial product.
>
> This being said, there is:
> - LDAP/Kerberos with cached credentials
> - SSSD by RedHat
> - winbind4 by Samba4
>
> LDAP and/or Kerberos with cached credentials work pretty well, though this
> solution seems pretty old. Due to the fact that the packages are not
> supported (nss-updatedb and libpam-ccreds), they are not being re-built
> against the latest Ubuntu release. A side effect is that they depend on the
> Berkeley DB that was installed on the build system. A Precise system
> contained libdb5.1, libdb4.8. The nss caching stuff is split into libnss-db
> - the NSS backend that reads the cached NSS data (main archive, depends on
> libdb5.1) and nss-updatedb, which downloads and stores the data into the
> database (universe archive, depends on libdb4.8). I can see that Raring's
> packages only depend on libdb5.1, but I am not sure if that's not a pure
> coincidence.
>
> 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.
>
> I heard Samba4 being advertised as the ultimate solution that will solve
> all the enterprise issues. I hope it really does, though to me it only
> solves the issues for people running Active Directory and/or Samba4 on DCs.
> I know the market share is quite larger than those using plain LDAP or MIT
> Kerberos or some RedHat's Directory Server, but picking Winbind4 as the
> ultimate solution just does not feel right.
>
> == Proprietary ==
>
> I don't care. It's up to the company behind it to support it in a reliable
> manner. Rumours have it that they have issues too, fall behind in their
> releases for new Ubuntu releases, provide a set of their own libraries
> which land in /opt and more.
>
> = Authentication configuration by package =
>
> Assuming that the system is being manually configured, below is the help
> that one gets from the package maintainer scripts.
>
> == LDAP configuration ==
>
> If you install libpam-ldap or libnss-ldap, they depend on
> ldap-auth-config, which configures /etc/ldap.conf. ldap-auth-config depends
> on auth-client-config, which configures /etc/nsswitch.conf, and on
> libpam-ldap and libnss-ldap. You can't have a package without its config
> nor vice-versa.
>
> The current authentication configuration is based on an example ldap.conf.
> This defaults to an LDAP attribute set that matches one provided by
> OpenLDAP, but if you have whatever else (Active Directory, Novell NDS, not
> sure about RedHat's DirServ), you need to configure /etc/ldap.conf yourself
> anyway. So I'd say it's "best effort" configuration.
>
> == Kerberos configuration ==
>
> I believe Kerberos config (krb5-config) is a little better. Although I
> needed to adjust the encryption types after configuration, I think I am an
> exception and the Kerberos configuration actually works in most
> environments out of the box.
>
> == 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).
>
> == winbind3/winbind4 ==
>
> Can't say.
>
> = Automatic configuration of authentication =
>
> Now, because I have people running Ubuntu in my company in multiple
> countries and it would be too trobulesome to configure everything by
> myself, I'm not doing it :) And believe me or not, unless you have a Ubuntu
> client environment of more than 5 machines, you should not be doing it,
> either.
>
> We are using CFEngine here to install the packages required for
> authentication, copy working configuration files to /etc. Other parties
> might be using puppet, chef or hand-crafted shell scripts or they copy the
> configs from a machine where they previously managed to configure the
> system properly.
>
> Below I will try to explain how the easy the automated configuration of
> particular solution is.
>
> == LDAP ==
>
> The fact that ldap-auth-config and auth-client-config are separate from
> the LDAP packages is good. It is theoretically possible to not install
> these packages and deploy the configs automatically with tools mentioned
> above. In practice it's difficult because the LDAP packages depend on them.
> This is unlike in Debian, it seems to be one of the Ubuntu specific changes.
>
> As a side effect, during package installation you will be asked about ldap
> URI etc, which you do not want to fill, as you will be overwriting the
> configs anyway.
>
> On the positive side, it is possible to create a dummy package that
> provides ldap-auth-config and auth-client-config and those questions do not
> pop-up.
>
> == pam-ccreds/nss-updatedb ==
>
> This one is ok. It doesn't pop any questions, just gets the job done.
>
> == Kerberos ==
>
> krb5-config is a similar story to ldap-auth-config, aside the fact that it
> is a dependency on both Debians and Ubuntus. You also get pop-ups with
> questions etc.
>
> On the positive side, it is possible to create a dummy package that
> provides krb5-config and those questions do not pop-up.
>
> == 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.
>
> == winbind3/winbind4 ==
>
> Can't say.
>
> == Proprietary ==
>
> Can't say.
>
> = 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)
> - SSSD lacks some configuration questions. I'm ok with that, I deploy it
> with CFEngine, but I guess it might be considered a requirement
> - 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.
>
> 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.
>
> Samba4's winbind might be a good official alternative, but that assumes
> you have AD. Samba3's winbind can be abandoned.
>
> = Conclusions =
>
> To the very least, I would like to know a decision. I am not able to fix
> all the stuff myself, particularly because I am not managing any of the
> packages, but I can help with some tasks.
>
> Cheers,
> Ballock
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.**ubuntu.com<Ubuntu-devel-discuss at lists.ubuntu.com>
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/ubuntu-devel-**discuss<https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20130521/d5b71bc4/attachment.html>