Authentication failure on CentOS Stream 8
by Alan Orth
Dear list,
I am using SSSD 2.6.2 on CentOS Stream 8 to authenticate against a 389
directory server over LDAP. Both `getent` and `id` are working, as is
key-based SSH. Anything requiring a password doesn't work: like ssh and
sudo. The 389 directory server is running on CentOS 7 and other CentOS 7
clients can authenticate and sudo just fine (they were set up with
authconfig).
Here is an excerpt from /var/log/secure while trying to SSH with a password
and sudo after logging in with an SSH key:
May 19 14:49:16 server05 sshd[79520]: Connection from x.x.x.x port 58272 on
x.x.x.x port 22
May 19 14:49:19 server05 sshd[79520]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=myuser
May 19 14:49:21 server05 sshd[79520]: Failed password for myuser from
x.x.x.x port 58272 ssh2
May 19 14:53:00 server05 sudo[122435]: pam_unix(sudo:auth): authentication
failure; logname=myuser uid=751 euid=0 tty=/dev/pts/4 ruser=myuser rhost=
user=myuser
May 19 14:53:05 server05 sudo[122435]: pam_unix(sudo:auth): conversation
failed
May 19 14:53:05 server05 sudo[122435]: pam_unix(sudo:auth): auth could not
identify password for [myuser]
May 19 14:53:07 server05 sudo[122435]: myuser : 1 incorrect password
attempt ; TTY=pts/4 ; PWD=/home/myuser ; USER=root ; COMMAND=/bin/su -
I have followed the SSSD troubleshooting guide¹ and it seems there is
something wrong with pam_sss, but I can't figure it out. I used `authselect
select sssd` to configure PAM and have not modified any settings. The
configuration seems to be valid:
# authselect check
Current configuration is valid.
And here is the auth part of the PAM system-auth stack:
# grep '^auth' /etc/pam.d/system-auth
auth required pam_env.so
auth required pam_faildelay.so
delay=2000000
auth [default=1 ignore=ignore success=ok] pam_usertype.so
isregular
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok
auth [default=1 ignore=ignore success=ok] pam_usertype.so
isregular
auth sufficient pam_sss.so
forward_pass
auth required pam_deny.so
Enabling `debug_level = 6` for sssd, domain/default, nss, and pam has not
helped me find anything out of place.
Does anyone have an idea of what to look for in the logs, or what else I
can try?
Thank you,
¹ https://sssd.io/troubleshooting/basics.html
--
Alan Orth
alan.orth(a)gmail.com
https://picturingjordan.com
https://englishbulgaria.net
https://mjanja.ch
1 year
Do any commercial NAS vendors use the SSD ID mapping algorithm?
by mythmail@runbox.com
Hello,
I work in an enterprise environment which has both Linux and Windows systems and an Active Directory for identity.
For good reasons we need to move from Linux based file servers to a NAS. The problem is that all our Linux systems use the SSD ID mapping algorithm to calculate UID and GIDs (and it works great!). We've not found a commercial NAS vendor who supports this algorithm so we can't just drop their products in place.
Do you know of any who do please?
Surely there must be some as many NASs run on Linux and BSD and use open source software heavily.
My colleague asked this in a GitHub issue [1] but I thought that it might be best to ask here.
Thanks in advance!
Ed.
[1]: https://github.com/SSSD/sssd/issues/6126
1 year
Check credentials cache expiration
by David Wittwer
Hi everyone
Short: Is there a way to check how long the cached credentials of a
specific user are still valid?
Somewhat longer:
When I'm offline and I log in with cached credentials, it says something
like "Authenticated with cached credentials, your cached password will
expire at: XYZ".
Unfortunately,
# sssctl user-show <wid>
doesn't show this information...
I've checked with the cache file in /var/lib/sss/db/cache_<domain>.ldb.
The relevant field is probably the "lastOnlineAuth" field, or the
"lastLogin" field. Is there a way to instruct SSSD to reveal those
fields to a user process without doing a full authentication?
Thanks & Regards
--David Wittwer
1 year
ldap_access_filter not active
by Bo Riis Toelberg Kristensen
Hi
I'm trying to authenticate users based on group membership in our Google
LDAP directory.
I can authenticate just fine without the 'ldap_access_filter' but when I
enable it they still authenticate even when the user is not a group member.
Additionally I don't see any check of the group membership in the logs, so
I must be doing something wrong. Please help me.
My sssd.conf
*[sssd]services = nss, pamdomains = domain.dk
<http://domain.dk>[domain/domain.dk <http://domain.dk>]# Base
settingsdebug_level = 8id_provider = ldapauth_provider =
ldapaccess_provider = ldapldap_access_order = filterldap_id_use_start_tls =
trueldap_uri = ldaps://ldap.google.com
<http://ldap.google.com>ldap_search_base =
dc=domain,dc=comldap_user_search_base =
ou=Users,dc=domain,dc=comldap_group_search_base =
ou=Groups,dc=domain,dc=comldap_tls_cert =
/etc/sssd/google-ldap-client.crtldap_tls_key =
/etc/sssd/google-ldap-client.key# Disable TLS 1.3 of google LDAP don't
workldap_tls_cipher_suite = NORMAL:!VERS-TLS1.3# Access
controlldap_access_filter = (memberOf=CN=vpn,ou=Groups,dc=domain,dc=com)#
Google recommended settingsldap_schema = rfc2307bisldap_user_uuid =
entryUUID*
I have been looking for any lines in the logs referencing my vpn group but
there is none. I have even tried switching to 'auth_provider = simple' but
there is no reference of the group check
Regards
Supergoof
--
----CEGO A/S will as part of your communication and interaction with us
collect and process personal data about you. You can read more about our
collection and processing of your personal data and your rights as a data
subject at https://cego.dk/gdpr <https://cego.dk/gdpr>/
1 year