SSH by LDAP groups – not work
There are "31" servers configured from the same RedOS image (CentOS 7-based). They are entered into the LDAP samba domain, and are configured for authorization via ssh based on ldap user groups. For this purpose the following have been changed:
created as root
echo "Domain admins" > /etc/ssh/access_groups.conf && chmod 600 /etc/ssh/access_groups.conf
____missed default____ account required pam_nologin.so account sufficient pam_localuser.so account required pam_listfile.so onerr=fail item=group sense=allow file=/etc/ssh/access_groups.conf account include password-auth _______ missed default____
#sudo admin users LDAP auth "%mydomain.localDomain admins" ALL=(ALL) NOPASSWD:ALL
systemctl restart sshd
This configuration has been successfully applied to about 30 servers and is working. On server 31 the configuration does not work.
When trying to log in, the client side displays connection closed by server.
debug3: failed to open file:C:/dev/tty error:3 debug1: read_passphrase: can't open /dev/tty: No such file or directory t1_rushao@ruyansvap38's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply Connection closed by 10.65.201.61 port 22
On server side
sshd: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.65.90.176 user=t1_rushao sshd: pam_listfile(sshd:account): Refused user t1_rushao for service sshd sshd: Failed password for t1_rushao from 10.65.90.176 port 59786 ssh2 sshd: fatal: Access denied for user t1_rushao by PAM account configuration [preauth]
If I comment out "account required pam_listfile.so…" I can connect via ssh as a domain user, but sudo doesn’t work either. At the same time,
id t1_rushao uid=1006007868(t1_rushao) gid=1006000513(domain users) groups=1006000513(domain users),1006000512(domain admins)
The sssd service is working, authorization by the domain users on server also seems to be working, I tried kinit, net ads join several times. /etc/security/access.conf is completely commented out by default.
I have run out of ideas why this configuration does not work personally on this server. I understand that the problem is somewhere in the domain groups, the system cannot match the user’s groups with the settings, but why?
Possible character case issue: the
id command reports the group as
domain admins in all-lowercase, but your
/etc/sudoers.d/01-domain-users both have the group specified as
Domain admins with initial upper-case.
Unix/Linux systems are generally case-sensitive, and I find no reason to believe that
pam_listfile.so would be an exception to this rule. I know that
sudo definitely is case-sensitive.
Try changing the group name in both
access_groups.conf and in the sudoers configuration to all-lowercase, to match the exact case reported by
The configuration of
/etc/sssd/sssd.conf and any
/etc/sssd/conf.d/*.conf files) might have some differences in the configuration of e.g. the domain’s
Your working servers obviously must have
case_sensitive = false, which seems not to be the default of sssd – perhaps the non-working server is missing some of these settings?
telcoM, exactly! It really worked.
On the last server,
sssd.conf differs from the others with just one additional line.
re_expression = (?P<name>[a-z0-9._-]+)
On other servers there is no such line.
And on all servers have the sssd.conf setting
case_sensitive = False
I did the analysis, and this file is automatically configured by the
join-to-domain script package from the RedOS development team that adds servers to the LDAP domain. Just a few days ago a new version of the script was released, and on this server (which was created a couple of days ago) the sssd configuration is different from the others.
As a result, 2 conditions coincided at once:
Domain admins separated by a space, and the sssd configuration became case-sensitive. I have tested on simple-named groups, and checked on lowercase-configured group names and it works with it.
re_expression and everything worked with
Domain admins group and any case insensitive configs. It will be necessary to ask the developers why this was done.