<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">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?!</div> <div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)"><br>Embarassingly,</div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">Bear</div></div><div class="gmail_extra"> <br><br><div class="gmail_quote">On Tue, May 21, 2013 at 7:47 AM, Bear Giles <span dir="ltr"><<a href="mailto:bgiles@coyotesong.com" target="_blank">bgiles@coyotesong.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div> <div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div> <div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.)</div> <div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">This is only one small piece of the puzzle, of course, but it's going to have a definite effect.</div> <div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div> <div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div> <span class="HOEnZb"><font color="#888888"> <div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Bear</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"> <br><br> <div class="gmail_quote">On Tue, May 21, 2013 at 3:37 AM, Bolesław Tokarski <span dir="ltr"><<a href="mailto:boleslaw.tokarski@tieto.com" target="_blank">boleslaw.tokarski@tieto.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hello,<br> <br> I put some time and effort creating this, please read at the very least introduction and suggestions.<br> <br> = Introduction =<br> <br> 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 <a href="https://launchpad.net/~enterprise-ubuntu" target="_blank">https://launchpad.net/~<u></u>enterprise-ubuntu</a> and its mailing list). The group is open so feel invited.<br> <br> I would like to take up the topic of Corporate authentication in Ubuntu and base my actions depending on the direction Ubuntu heads for.<br> <br> = Authentication choice =<br> <br> First - authentication in general. There is a number of authentication services available to an enterprise deployment open source:<br> - plain LDAP (optionally including cached credentials with nss-updatedb and pam-ccreds)<br> - LDAP+Kerberos (optionally including cached credentials with nss-updatedb and pam-ccreds)<br> - SSSD by RedHat<br> - winbind3 by Samba<br> - winbind4 by Samba<br> and proprietary:<br> - Likewise Open/Enterprise<br> - Centrify<br> - VAS/QAS/DAS I think it's currently Dells<br> - PowerBroker Identify Services by Beyondtrust<br> - more, I guess<br> <br> == Open source+supported ==<br> <br> The packages that are currently supported officially (I mean by Canonical by being included in the main archive) are:<br> - plain LDAP<br> - LDAP+Kerberos<br> - winbind3<br> <br> 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.<br> <br> 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.<br> <br> == Open source+unsupported ==<br> <br> 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.<br> <br> This being said, there is:<br> - LDAP/Kerberos with cached credentials<br> - SSSD by RedHat<br> - winbind4 by Samba4<br> <br> 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.<br> <br> 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.<br> <br> 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.<br> <br> == Proprietary ==<br> <br> 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.<br> <br> = Authentication configuration by package =<br> <br> Assuming that the system is being manually configured, below is the help that one gets from the package maintainer scripts.<br> <br> == LDAP configuration ==<br> <br> 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.<br> <br> 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.<br> <br> == Kerberos configuration ==<br> <br> 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.<br> <br> == sssd ==<br> <br> 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).<br> <br> == winbind3/winbind4 ==<br> <br> Can't say.<br> <br> = Automatic configuration of authentication =<br> <br> 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.<br> <br> 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.<br> <br> Below I will try to explain how the easy the automated configuration of particular solution is.<br> <br> == LDAP ==<br> <br> 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.<br> <br> 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.<br> <br> 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.<br> <br> == pam-ccreds/nss-updatedb ==<br> <br> This one is ok. It doesn't pop any questions, just gets the job done.<br> <br> == Kerberos ==<br> <br> 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.<br> <br> On the positive side, it is possible to create a dummy package that provides krb5-config and those questions do not pop-up.<br> <br> == SSSD ==<br> <br> 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.<br> <br> == winbind3/winbind4 ==<br> <br> Can't say.<br> <br> == Proprietary ==<br> <br> Can't say.<br> <br> = Suggestions =<br> <br> 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.<br> <br> 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.<br> <br> 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:<br> - SSSD needs to be included in main (Main Inclusion Request #903752)<br> - SSSD lacks some configuration questions. I'm ok with that, I deploy it with CFEngine, but I guess it might be considered a requirement<br> - 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.<br> <br> 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.<br> <br> Samba4's winbind might be a good official alternative, but that assumes you have AD. Samba3's winbind can be abandoned.<br> <br> = Conclusions =<br> <br> 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.<br> <br> Cheers,<br> Ballock<span><font color="#888888"><br> <br> -- <br> Ubuntu-devel-discuss mailing list<br> <a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com" target="_blank">Ubuntu-devel-discuss@lists.<u></u>ubuntu.com</a><br> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss" target="_blank">https://lists.ubuntu.com/<u></u>mailman/listinfo/ubuntu-devel-<u></u>discuss</a><br> </font></span></blockquote></div><br></div> </div></div></blockquote></div><br></div>