User: Password:
Subscribe / Log in / New account



Posted Mar 22, 2012 5:20 UTC (Thu) by ringerc (subscriber, #3071)
Parent article: Shadow hardening

I struggle to understand the appeal of this when LDAP auth solves so many problems already. About the only big issue is that it's painfully hard to get a Linux distro to use *only* LDAP because there's too much that still assumes /etc/passwd rather than going through NSS.

In particular, distro package config scripts are frequently guilty of trying to create or update users in /etc/passwd and /etc/group, with no mechanism offered to switch them to using LDAP. This tends to leave systems with a split auth setup, where some users and groups are local and some are in the directory. When you want to add a directory user to a local group, this becomes a nightmare.

Please: scrap the file-based auth, and move to LDAP.

(Log in to post comments)


Posted Mar 22, 2012 6:34 UTC (Thu) by eru (subscriber, #2753) [Link]

Please: scrap the file-based auth, and move to LDAP.

But if the network is down or LDAP otherwise hosed, how do you get access for fixing things? Files are also useful for situations where the system is never meant to be part of a wider authentication domain (eg. most home users and embedded systems).

But I agree that in most professional deployments you want to use network-based authentication, except for root and other special cases, so improving shadow password security in the ways described in the article does not seem terribly important.


Posted Mar 22, 2012 6:48 UTC (Thu) by ringerc (subscriber, #3071) [Link]

Loopback is never down. Well, not past *incredibly* early boot, anyway, such that a NSS module that provided a hardcoded uid 0 and a uid for the LDAP daemon (to run it as non-root) would be all that'd be required until LDAP came up.

I'm talking about LDAP on the local host, as the primary and only storage for user credentials. Unlike passwd/shadow/group, it's extensible, supports fine-grained access control, mirroring and sync, etc.

I run an LDAP daemon on each server. When a change is made, the change is pushed to the master and then out to all the slaves via client-cert-protected tls-secured channels. If the master goes down, nobody cares.


Posted Mar 22, 2012 11:29 UTC (Thu) by cortana (subscriber, #24596) [Link]

Do you have a particularly slimmed-down build of OpenLDAP for this purpose? How much memory does it take up in regular use? Does anything break if it needs to do a lookup while the daemon is being restarted (I imagine you build it yourself, but imagine if you were using a distro-provided package that pushed out a security update). How do you handle the split between 'system' users created by distro packages with low UIDs and human users created with high UIDs? Do you use nss_ldap, nss_ldapd + nslcd (with or without nscd or unscd), nss_ldapd + slapd's nss overlay, or nss_cache?

I've been thinking along these lines for a while, but I haven't actually bothered to look at setting such a system up yet. The tuning & maintenance requirements of OpenLDAP's use of libdb put me off. Current versions have a new backend however, mdb, that appears have no such demands on the admin. The main problem I'd forsee is that slapd is not available during boot, and particularly so in early boot when everything's being run out of the initramfs.


Posted Mar 22, 2012 11:49 UTC (Thu) by ringerc (subscriber, #3071) [Link]

I use regular OpenLDAP from the Debian archives. It's probably possible to optimise it for memory use and cut out optional features, but with RSS at 7MB I don't care to. Remember, much of that RSS is overhead - `grep` has 1MB RSS on my system!

That kind of memory use might be a concern on particularly tiny embedded boxes, but few of those will want a full NSS anyway, they're likely to be using busybox and uclibc with their very cut down identity stuff.

slapd restarts haven't been a problem the couple of times I've done them to add new schema. Requests though PAM or NSS are delayed until slapd comes up again, then continue as normal. The delay hasn't been noticeable since slapd restarts in a fraction of a second.

Because LDAP is an afterthought in Linux distros at the moment, the situation with ldap auth in current distros is absolutely rotten. The separation between system and LDAP users that you alluded to is the problem, and the lack of testing of package scripts etc with LDAP adds to the pain. It's particularly bad when you need users the system thinks are "system" users to appear in the directory because they must be consistent across several systems for, say, NFS4 shared storage. Most package scripts will scream when they can't find the user in /etc/passwd even though it exists.

At this point I don't recommend running LDAP auth for Linux environments because it's badly tested and badly integrated into most distros as a half-assed afterthought. To work well, it must *replace* /etc/passwd and friends, not layer on top of them, and all system tools for user creation/removal/etc must manipulate LDAP transparently instead of passwd.

With the current situation I've even had to remove a user from LDAP and allow a package to create the user in the system auth files with a different auto-generated uid, then remove that generated user, add the original user back to ldap, and chown everything to the new uid. I'm not impressed.

As for my setup: I use plain old nscd on top of slapd.

FWIW, I don't particularly adore LDAP, but it's there and it works. Apple demonstrated the folly of rolling their own directory system with the short-lived NetInfo; IMO, LDAP should be adopted because we need *something* better than passwd, LDAP is there, and LDAP is mature and interoperable.


Posted Mar 22, 2012 17:03 UTC (Thu) by drag (guest, #31333) [Link]

> At this point I don't recommend running LDAP auth for Linux environments because it's badly tested and badly integrated into most distros as a half-assed afterthought.

LDAP auth always seemed weak to me. If you are doing network authentication, why not doing it right with Kerberos? It seems like any decent software has support for SASL and/or GSSAPI. This seems like a much better and more robust approach and has been the one I always have taken.

Also most of your issues with PAM and NSS can be taken care of with SSSD. Vastly better then nscd and can support 'road warrior' type configurations, which is fantastic.

Howeve, Seeing how this article is about improving the security of your shadow user database putting it all in a network daemon, even if it's localhost-only, seems like a step backwards.


Posted Mar 23, 2012 13:27 UTC (Fri) by Creideiki (subscriber, #38747) [Link]

Is there a way to do passwordless entry into a Kerberos system? I like using public-key SSH to save me from having to remember passwords for all the systems I have accounts on, but from what I understand Kerberos requires you to enter your password at some point (either at login or later using kinit) to get a TGT.


Posted Mar 23, 2012 13:32 UTC (Fri) by cortana (subscriber, #24596) [Link]


Pkinit provides support for using public-key authentication with Kerberos. Pkinit is useful in the following situations:

  • Using smart cards for Kerberos authentication
  • Authentication based on soft tokens (or certificates stored on a computer) instead of passwords
  • In conjunction with anonymous kerberos and FAST protecting password exchanges to remove the possibility of dictionary attacks


Posted Mar 23, 2012 16:34 UTC (Fri) by drag (guest, #31333) [Link]

With Kerberos it is single sign on. Which means, of course, once you get your ticket then you don't have to re-enter your password for the lifetime of that ticket. (usually about 8 hours)

On your main administrative system I found that it's most useful to not actually have it hooked into your domain. That way when something goes wrong with your domain you can do something to fix it. In that case you run 'kinit username' to request a ticket. Once you get your ticket then you should be good for at least 8 hours without having to re-enter it.

The biggest downside is that Kerberos requires a fairly significant amount of functionality to be present and working on your network before you can use it. Most networks that have grown up fairly willy-nilly tend to have a lot of brokenness in them and that won't fly with kerberos.

Your reverse DNS lookups need to be working perfectly for all the machines in the domain, for example.

The easiest way to implement a domain nowadays is to use FreeIPA. Install a CentOS or Fedora system on your network and follow Redhat's documentation.

For non-Redhat/Fedora type systems all you really need to do is install 'sssd'. There was a couple recent bugs that popped into Debian unstable that I had issues with, but Debian stable works very well.

The biggest problem with FreeIPA and SSSD is if you already have a existing OpenLDAP deployment it's not going to work well with that. You need to use the specific configuration provided with FreeIPA packages with the 389 LDAP server to be compatible.

Once you get that sorted out though then it makes all sorts of previously difficult things to do pretty easy.


Posted Mar 26, 2012 18:48 UTC (Mon) by sorpigal (subscriber, #36106) [Link]

Your analysis sadly mirrors mine. I'd like to use slapd, because it doesn't make any choices for me, but it's so dedicated to not making choices for me that I can't understand how to do anything useful with it without an enormous investment of time to learn and configure it. 389ds is better, and obviously made by people who expect real sysadmins to be able to use it, but it makes so many assumptions about how you want to do things that it leaves a bad taste in my mouth. The real down side to 389ds is that using it on non-Fedora non-RHEL (read: Debian) is so difficult you may as well hand craft a slapd setup.

I came from an eDir/NDS background so I think I know what I want, but creating it is an enormous pain. Where's the distribution the presumes you want to put $everything into LDAP, users and all, right from the start, use kerberos everywhere, etc? I get a very 1996-friendly-linux-desktop kind of vibe where I think "Of course it's possible to configure Linux to do this" but in practice you may as well give up. It would be a shame if the eventual solution to this problem is to adopt samba4 and just have everyone follow Microsoft's lead.

SSSD is refreshing, but it only makes the client side easier. FreeIPA is really nice for being sort of the KDE of my desktop linux analogy, but it's a lot more than I need and is sadly tied to 389ds only and thus to Fedora systems. There seem to be only two types of person trying to get things working in this area: the people who are wizards and use slapd and the people who aren't necessarily wizards and use Fedora specific solutions.


Posted Mar 26, 2012 19:08 UTC (Mon) by cortana (subscriber, #24596) [Link]

I think recent versions of slapd are getting better in this area. They have a new database backend, mdb, which has no configuration knobs at all, and yet outperforms hdb/bdb. So operationally, administering slapd is a lot easier than it used to be (particularly since the hdb/bdb docs say "read the Berkeley DB documentation", which Oracle have now helpfully broken all the links to...)

Of course, you still have to decide on your schema, and come up with tools for creating and maintaining objects, set up replication and so on.


Posted Mar 23, 2012 9:15 UTC (Fri) by phajdan.jr (subscriber, #83686) [Link]

I think the main problem with LDAP is the complexity. I agree that in environments with many machines centralizing account management is very important. However, in smaller setups it may just not be worth it.

By the way, hardened-shadow is not just about splitting /etc/shadow into a directory tree and switching from SUID binaries to SGID ones. Utilities like login, su, passwd, useradd, groupadd are also re-implemented, and are smaller than their shadow-utils counterparts.

The above makes it possible to make those tools work more seamlessly with LDAP (if that makes sense), maybe addressing your point. Feedback and patches are welcome - feel free to post to MLs listed at .

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds