sssd é provavelmente a opção mais "progressiva" a seguir. Nesta medida, as outras respostas estão corretas. Dito isso, o sssd não substitui completamente as características do nslcd, ao contrário da opinião popular.
A principal vantagem (situacional) do nslcd sobre o sssd é que você pode escrever uma consulta authz customizada com a substituição de parâmetro:
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.
A última vez que verifiquei os documentos do sssd (nos últimos seis meses), ainda não havia substituto para esse recurso. Então, isso realmente depende se esse recurso é importante o suficiente para deixar de lado os benefícios da solução consolidada do sssd.