5

We have 50 RH-5 machines and 70 RH-6 machines. I am looking to decide what we should use for LDAP:

  1. nscd/nslcd for all RH-5/RH-6 servers
  2. nscd/nslcd for RH-5 servers, sssd for RH-6 servers
  3. sssd for all RH-5/RH-6 servers

SSSD is available on both version (RHEL5 - sssd 1.5 & RHEL6 - sssd 1.9+)

The last option means that RHEL5 machines would run sssd 1.5.

I would prefer an environment with the same software and configuration as much as possible, unless people say that sssd is really better for RH-6 and nscd/nslcd is really better for RH-5.

What is the best option?

ujjain
  • 3,963
  • 15
  • 50
  • 88

3 Answers3

4

sssd is probably the more "forward thinking" option to go with. To that extent, the other answers are correct. That said, sssd does not completely supersede the features of nslcd, contrary to popular opinion.

The primary (situational) advantage of nslcd over sssd is that you can write a custom authz query with parameter substitution:

   pam_authz_search FILTER
          This option allows flexible fine tuning of the authorisation check that should be performed. The search filter specified is executed and if  any  entries
          match, access is granted, otherwise access is denied.

          The  search  filter can contain the following variable references: $username, $service, $ruser, $rhost, $tty, $hostname, $dn, and $uid.  These references
          are substituted in the search filter using the same syntax as described in the section on attribute mapping expressions below.

          For example, to check that the user has a proper  authorizedService  value  if  the  attribute  is  present:  (&(objectClass=posixAccount)(uid=$username)
          (|(authorizedService=$service)(!(authorizedService=*))))

          The default behaviour is not to do this extra search and always grant access.

The last time I checked the sssd docs (within the last six months), there was still no replacement for this capability. So it really depends on whether this feature is important enough to put aside the benefits of sssd's consolidated solution.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
2

I would prefer an environment with the same software and configuration as much as possible, unless people say that sssd is really better for RH-6 and nscd/nslcd is really better for RH-5.

SSSD is the future and you get Kerberos auth & better compatibility with AD if that's your LDAP server for instance.

Otherwise I don't see any reason not to use nslcd, it works fine in my environment assuming you're using a new enough version that it supports nested groups - see the "nss_nested_groups" option (assuming you use them, otherwise you should be fine).

TheFiddlerWins
  • 2,973
  • 1
  • 14
  • 22
1

SSSD is the future and much more powerful than nslcd.

SSSD can provide additional features like SSO in offline machines, so you can as example, use SSSD in Notebook Workstations and the users will be able to login through the Single Sigo-On Daemon even without connection with the authentication server.

There's no reason to implement nslcd and all the dependencies that nslcd requires with sssd in the game.

And finally, SSSD is a Fedora Hosted project. So it should play nicely with RHEL.

Additional information can be found in the website: http://fedoraproject.org/wiki/Features/SSSD

There's a plenty of AD, LDAP, and multiple authentication backends howtos on the web.

Vinícius Ferrão
  • 5,400
  • 10
  • 52
  • 91
  • 4
    I'm going to have to downvote this for saying that there is "no" reason to use nslcd. Unless you've exhaustively researched documentation and confirmed that one presents an entirely superior featureset (which is incorrect in this case) or can identify a significant design flaw for production environment use, that tends to be an irresponsible generalization. – Andrew B Oct 19 '13 at 05:37
  • 1
    NSLCD is not maintained anymore whereas SSSD is. The only feature NSLCD provides that SSSD don't is host caching. – Tcharl Dec 02 '21 at 07:58