6 thoughts on - Help With Default Shell

• The shell is a symptom, not the core issue here. The core issue is that local console logins aren’t configured to use LDAP on your system, so they fall back to the old flat-file-based user info sources. (/etc/passwd, /etc/group, /etc/shadow…)

  The question then is, do you really *want* local logins to require the LDAP server to be up before it’ll accept a login? If an LDAP package upgrade roaches things, do you want to be forced to reboot into single-user mode to fix it? If there’s a network outage between this box and the openLDAP server, are you going to wait to log in locally as well until the network’s fixed?

  Me, I’d just do a “chsh” on the users or a sed pass on /etc/passwd to change all the shells locally so they match the LDAP configuration so I can have it both ways.

  However, if you’re bound and determined to have LDAP be the single source of all user truth, the bit at the end of Step 2 here looks like it should do that:

  https://arthurdejong.org/nss-pam-ldapd/setup

  May you live to *not* regret doing that!

• All local users in /etc/passwd These Linux computers [26] are used in a lab and the student accounts are on the LDAP Server. In this way students can login to any computer in the lab. The console logins that use LDAP work fine except for the shell issue. in the /etc/nsswitch.conf I have the following.

  passwd: files sss ldap shadow: files sss ldap group: files sss ldap

  —–Original Message—

• So my first thing I would try to do would be to see if `getent passwd
  ` showed different configs when a person logged in different ways. Aka
  “`
  $ SSH foobaz
  $ getent passwd ssmoogen ssmoogen:x:14353:14353:Stephen Smoogen:/home/ssmoogen:/bin/csh
  $ exit

  login: ssmoogen passwd:
  $ getent passwd ssmoogen:x:14353:14353:Stephen Smoogen:/home/ssmoogen:/bin/bash
  $ exit
  “`

  In either case, I think from going down the rabbithole of bugs/etc that something in your system is using attribute mapping to force a shell but only for console logins. The general way this is done is sticking

  map passwd loginShell “/bin/bash”
  map passwd shell “/bin/bash”

  Beyond that I do not have any openLDAP systems to confirm how this would be done.

• Thanks Stephen, Where will I find the attribute mapping?
  Today I only have remote access via SSH and RDP.

  —Original Message—

• The various pages on this were rather ‘vague’ on where it might be. I
  would try with

  find /etc -type f -print0 | xargs grep -il ‘map.*passwd.*shell’

  and see if it comes up with anything. After that I really don’t know. I haven’t used openLDAP in 15 years and I have not used csh in 20.

• It isn’t a bad idea to have users in LDAP, if you’ve got a redundant or clustered LDAP service, although I’d only suggest using LDAP for authorization (can the user log in? what groups are they in?) and not authentication (is the user who they claim to be?). I usually use Kerberos for authentication.

  In an enterprise environment, if the network is down, we don’t want users logging in, because logging won’t be collected and the user won’t be able to use network resources anyway (such as network printers, home directory, licensed software, etc.).

  Admins typically have a local account defined but still use network authentication, but honestly, yes, we’d prefer to restrict local login authentication completely — it makes it easier to manage access centrally. (I also took advantage of the fact that local users had a different GID to put them in a different SELinux confined user group, so they had different access rights anyway)

  We do this for servers and workstations.

  —
  Jonathan Billings