You are here
Overrides With SSSD
LINUX has long been plagued with a rather lousy identity management scheme. Beyond the limitations of POSIX's getent and related calls [which can be very inefficient] the attempts to stub in network-aware identity services such as LDAP have only piled onto the rough edges. NSCD attempted to work around performance problems via caching - and did not do very well. Then was NSLCD the next evolution of NSCD which was better, but still inflexible. Identity management in more complex networks is a tedious business and what administrators need more than anything else is flexibility.
Finally we have SSSD - The System Security Services Daemon - which is an identity service that seems to have an answer for every basic issue - from caching, to Kerberos integration, to joining together multiple domains.... On top of all that essential goodness is the simple feature of local overrides for identity values.
As an administrator at a multiple platform enterprise this has always been a dilema - what value should get stored in certain user attributws such as loginShell? Not all systems want/need the same thing. Ugly solutions involve symbolic links and/or installing non-standard shells. None of which can be described as "elegant" or even "correct". Our AIX systems want to use /bin/ksh, our LINUX systems want to use /bin/bash [or even /usr/bin/bash]. Ultimately I end up storing the attribute in user object for the most limited inflexible systems - generally that means AIX gets its way.
This means when I attempt to sign into an out-of-the-box LINUX installation it fails.
Jan 14 08:22:21 example sshd[24292]: User adam not allowed because shell /bin/ksh does not exist
Jan 14 08:22:21 example sshd[24293]: input_userauth_request: invalid user adam
Jan 14 08:22:29 example sshd[24292]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.257 user=adam
Bummer. But now that systems are using SSSD to back the NSS service the solution is as simple as:
[nss]
override_shell = /bin/bash
And now my shell, and the shell for every user, on that host is "/bin/bash".
Aside: How often would users on the same host actually use different shells? That sounds like an administrator’s nightmare. At least on modern systems the loginShell seems much more appropriate as a host property than a user property; the most shell the majority of users ever experience is the login script that starts their application or menu.
SSSD provides overrides for shell, home directory [override_homedir] and primary group [override_gid: make the primary group of all users from the network identity service the same].
Author: Adam Tauno Williams