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 <bgi...@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.tokar...@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@lists.**ubuntu.com<Ubuntu-devel-discuss@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> >> > >
-- 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
