Hi all, I have a computer with CentOS 7. The users are authenticated using OpenLDAP. On LDAP the default shell is csh. When ssh to login it works, i.e. $SHELL = /bin/csh Also, when using xrdp it works. However, a login from the keyboard and screen attached computer we get $SHELL = /bin/bash
Any help is welcome. Regards,
Ger.
--
Gerard Hooton. Senior Technical Officer School of Engineering. University College Cork. College Road. Cork. Ireland.
On Jun 23, 2021, at 7:12 AM, Hooton, Gerard g.hooton@ucc.ie wrote:
The users are authenticated using OpenLDAP. On LDAP the default shell is csh. When ssh to login it works, i.e. $SHELL = /bin/csh Also, when using xrdp it works. However, a login from the keyboard and screen attached computer we get $SHELL = /bin/bash
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----- From: Warren Young <warren@etr-usa.commailto:Warren%20Young%20%3cwarren@etr-usa.com%3e> Reply-To: CentOS mailing list <centos@centos.orgmailto:CentOS%20mailing%20list%20%3ccentos@centos.org%3e> To: CentOS mailing list <centos@centos.orgmailto:CentOS%20mailing%20list%20%3ccentos@centos.org%3e> Subject: Re: [CentOS] Help with default shell Date: Wed, 23 Jun 2021 15:13:23 -0600 Mailer: Apple Mail (2.3608.120.23.2.7)/etc/passwd
[EXTERNAL] This email was sent from outside of UCC.
On Jun 23, 2021, at 7:12 AM, Hooton, Gerard <
g.hooton@ucc.ie
wrote:
The users are authenticated using OpenLDAP.
On LDAP the default shell is csh.
When ssh to login it works, i.e. $SHELL = /bin/csh
Also, when using xrdp it works.
However, a login from the keyboard and screen attached computer we get $SHELL = /bin/bash
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
https://arthurdejong.org/nss-pam-ldapd/setup
May you live to *not* regret doing that!
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
https://lists.centos.org/mailman/listinfo/centos
--
Gerard Hooton. Senior Technical Officer School of Engineering. University College Cork. College Road. Cork. Ireland. Loc8: WDR-04-60G Tel: +353 21 4902296 Mobile: +353 852813491
On Wed, Jun 23, 2021 at 03:13:23PM -0600, Warren Young wrote:
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?
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.
On Wed, 23 Jun 2021 at 09:13, Hooton, Gerard g.hooton@ucc.ie wrote:
Hi all, I have a computer with CentOS 7. The users are authenticated using OpenLDAP. On LDAP the default shell is csh. When ssh to login it works, i.e. $SHELL = /bin/csh Also, when using xrdp it works. However, a login from the keyboard and screen attached computer we get $SHELL = /bin/bash
So my first thing I would try to do would be to see if `getent passwd <username>` 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.
Any help is welcome. Regards,
Ger.
--
Gerard Hooton. Senior Technical Officer School of Engineering. University College Cork. College Road. Cork. Ireland.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Thanks Stephen, Where will I find the attribute mapping? Today I only have remote access via ssh and RDP.
---Original Message----- From: Stephen John Smoogen <smooge@gmail.commailto:Stephen%20John%20Smoogen%20%3csmooge@gmail.com%3e> Reply-To: CentOS mailing list <centos@centos.orgmailto:CentOS%20mailing%20list%20%3ccentos@centos.org%3e> To: CentOS mailing list <centos@centos.orgmailto:CentOS%20mailing%20list%20%3ccentos@centos.org%3e> Subject: Re: [CentOS] Help with default shell Date: Thu, 24 Jun 2021 05:53:44 -0400
[EXTERNAL] This email was sent from outside of UCC.
On Wed, 23 Jun 2021 at 09:13, Hooton, Gerard <
g.hooton@ucc.ie
wrote:
Hi all,
I have a computer with CentOS 7.
The users are authenticated using OpenLDAP.
On LDAP the default shell is csh.
When ssh to login it works, i.e. $SHELL = /bin/csh
Also, when using xrdp it works.
However, a login from the keyboard and screen attached computer we get $SHELL = /bin/bash
So my first thing I would try to do would be to see if `getent passwd
<username>` 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.
Any help is welcome.
Regards,
Ger.
--
Gerard Hooton.
Senior Technical Officer
School of Engineering.
University College Cork.
College Road.
Cork.
Ireland.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
https://lists.centos.org/mailman/listinfo/centos
--
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on BBS...
time to reboot.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
https://lists.centos.org/mailman/listinfo/centos
--
Gerard Hooton. Senior Technical Officer School of Engineering. University College Cork. College Road. Cork. Ireland. Loc8: WDR-04-60G Tel: +353 21 4902296 Mobile: +353 852813491
On Thu, 24 Jun 2021 at 06:22, Hooton, Gerard g.hooton@ucc.ie wrote:
Thanks Stephen, Where will I find the attribute mapping? Today I only have remote access via ssh and RDP.
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.
-
Hooton, Gerard -
Jonathan Billings -
Stephen John Smoogen -
Warren Young