User: Password:
Subscribe / Log in / New account



Posted Mar 22, 2012 17:03 UTC (Thu) by drag (subscriber, #31333)
In reply to: !Bizarre by ringerc
Parent article: Shadow hardening

> 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.

(Log in to post comments)


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 (subscriber, #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.

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