Authentication services in Ubuntu

[Bear Giles]

Grr - "weak", not "week". Why do I never remember that I should never write
email until I've been awake for at least two hours?!

Embarassingly,
Bear


On Tue, May 21, 2013 at 7:47 AM, Bear Giles <bgiles at coyotesong.com> wrote:

> 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/480acef0/attachment.html>