sssd-ldap using id_provider=files and auth_provider=ldap
by koson823＠me.com
Hi,
I am trying to authenticate a user on a server (Rocky Linux release 8.9) using the combination of id_provider=files and auth_provider=ldap since our organization's LDAP server does not have a posixAccount object class. It almost works but has an authentication problem, as follows:
1) Failure case (initial binding by a search_id followed by user_id(hogehoge))
/etc/sssd/sssd.conf has the following default_bind_dn for searching a user DN to log in.
ldap_default_bind_dn = uid=search_id,ou=System,dc=example,dc=com
ldap_default_authtok = password_for_searchid
This initial search binding works fine and returns the user DN to log in, for example,
uid=hogehoge,ou=staff,ou=Users,dc=example,dc=com
However, as shown below, the user (hogehoge) cannot be authenticated.
/var/log/sssd/sssd_local.log
(2024-04-28 21:57:11): [be[local]] [sdap_call_op_callback] (0x20000): [RID#2] Handling LDAP operation [3][server: [xxx.xx.xx.x:636] filter: [(&(uid=hogehoge)(objectclass=inetOrgPerson))] base: [ou=Users,dc=example,dc=com]] took [2.910] milliseconds.
(2024-04-28 21:57:11): [be[local]] [sdap_parse_entry] (0x1000): [RID#2] OriginalDN: [uid=hogehoge,ou=staff,ou=Users,dc=example,dc=com].
(2024-04-28 21:57:11): [be[local]] [sdap_parse_entry] (0x0020): [RID#2] Unknown entry type, no objectClasses found!
/var/log/secure
Apr 28 21:57:11 server sssctl[1635756]: pam_sss(system-auth:auth): authentication failure; logname=dummy uid=0 euid=0 tty= ruser= rhost= user=hogehoge
Apr 28 21:57:11 server sssctl[1635756]: pam_sss(system-auth:auth): received for user hogehoge: 4 (System error)
/var/log/secure says that the authentication ends with "System error(4)", which implies "Unhandled Exception." Meanwhile, the authentication process succeeds without the error by changing the ldap_default_bind_dn from search-only DN to user DN to be logged in, as follows:
2) Success case (initial binding by a user_id(hogehoge))
/etc/sssd/sssd.conf now has the user DN as a default_bind_dn. This is, of course, only for testing and useless for actual operation.
ldap_default_bind_dn = uid=hogehoge,ou=staff,ou=Users,dc=example,dc=com
ldap_default_authtok = password_for_hogehoge
Now, this setting enables the user (hogehoge) to log in, as follows:
/var/log/sssd/sssd_local.log
(2024-04-28 21:54:54): [be[local]] [sdap_call_op_callback] (0x20000): [RID#2] Handling LDAP operation [3][server: [xxx.xx.xx.x:636] filter: [(&(uid=hogehoge)(objectclass=inetOrgPerson))] base: [ou=Users,dc=example,dc=com]] took [2.006] milliseconds.
(2024-04-28 21:54:54): [be[local]] [sdap_parse_entry] (0x1000): [RID#2] OriginalDN: [uid=hogehoge,ou=staff,ou=Users,dc=example,dc=com].
(2024-04-28 21:54:54): [be[local]] [sdap_parse_range] (0x2000): [RID#2] No sub-attributes for [objectClass]
(2024-04-28 21:54:54): [be[local]] [sdap_parse_range] (0x2000): [RID#2] No sub-attributes for [uid]
/var/log/secure also shows no error.
Apr 28 21:54:54 server sssctl[1635713]: pam_sss(system-auth:auth): authentication success; logname=dummy uid=0 euid=0 tty= ruser= rhost= user=hogehoge
I would appreciate it if someone could let me know how to correctly use the search-only bind first, as in case 1). This might not be related to the mixed-use of id_provider=files and auth_provider=ldap, though. FYI, the combination of id_provider=files and auth_provider=ldap seems fine; UID and GID are referred correctly from /etc/passwd as in the output of sssctl:
[root@server dummy]# sssctl user-checks hogehoge
user: hogehoge
action: acct
service: system-auth
SSSD nss user lookup result:
- user name: hogehoge
- user id: 5000
- group id: 1002
- gecos:
- home directory: /home/hogehoge
- shell: /bin/bash
SSSD InfoPipe user lookup result:
- name: hogehoge
- uidNumber: 5000
- gidNumber: 1002
- gecos: not set
- homeDirectory: /home/hogehoge
- loginShell: /bin/bash
testing pam_acct_mgmt
pam_acct_mgmt: Success
PAM Environment:
- no env -
The whole /etc/sssd/sssd.conf follows (credential info has been modified):
[sssd]
debug_level = 9
config_file_version = 2
services = nss, pam, ssh, sudo
domains = default, local
[domain/default]
...truncated...
[domain/local]
debug_level = 9
id_provider = files
auth_provider = ldap
chpass_provider = none
ldap_search_base = ou=Users,dc=example,dc=com
ldap_user_object_class = inetOrgPerson
ldap_uri = ldaps://xxx.xxx.xxx.xxx.xxx
ldap_default_bind_dn = uid=search_id,ou=System,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = password_for_searchid
ldap_id_use_start_tls = False
ldap_search_timeout = 3
ldap_network_timeout = 3
ldap_opt_timeout = 3
enumerate = False
ldap_connection_expire_timeout = 600
ldap_sudo_smart_refresh_interval = 600
ldap_sudo_full_refresh_interval = 10800
entry_cache_timeout = 1200
cache_credentials = False
[nss]
homedir_substring = /home
entry_negative_timeout = 20
entry_cache_nowait_percentage = 50
filter_groups = root
filter_users = root
[pam]
debug_level = 9
[sudo]
[autofs]
[ssh]
FYI, sssd-related rpms installed are the following:
sssd.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-ad.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-client.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-common.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-common-pac.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-dbus.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-ipa.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-kcm.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-krb5.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-krb5-common.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-ldap.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-nfs-idmap.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-proxy.x86_64 2.9.1-4.el8_9.5 @baseos
sssd-tools.x86_64 2.9.1-4.el8_9.5 @baseos
1 day, 4 hours
transient, intermittent "No user exists" errors
by Gary Miguel
I'm using SSSD and Google LDAP. My users can log (via tailscale SSH, if that matters) in but after being logged in for a while they get errors like:
No user exists for uid 61270005
If they log out and log back in things work. Some users have reported that just waiting without logging out / in also resolves the issue.
Any suggestions as to how to debug or fix?
Here's my sssd.conf:
[sssd]
services = nss, pam
domains = example.org
[domain/example.org]
create_homedir = true
auto_private_groups = true
cache_credentials = true
ldap_tls_cert = /etc/ldap/ldap-client.crt
ldap_tls_key = /etc/ldap/ldap-client.key
ldap_uri = ldaps://ldap.google.com
ldap_search_base = dc=example,dc=org
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_user_uuid = entryUUID
ldap_groups_use_matching_rule_in_chain = true
ldap_initgroups_use_matching_rule_in_chain = true
[pam]
offline_credentials_expiration = 1
Here's nsswitch.conf:
passwd: files systemd sss
group: files systemd sss
shadow: files sss
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: files sss
2 weeks
Cannot unlock screen with different smart card
by Orion Poplawski
It seems like one cannot unlock the screen with a different smart card
then the one that was used to log into the session, or at least one with
a different token id, even though they resolve to the same user (of course).
Is there any immediately obvious reason this might be? Is the token id
cached somehow in the session? I would have thought that each
authentication would have been independent.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
2 weeks, 6 days
Starting SSSD without root
by Tero Saarni
Hi,
I'm trying to run SSSD inside docker container without root user. The
container is executed in OpenShift cluster which does not allow running as root
inside container.
SSSD requires root and checks for this specifically.
Is there any workaround for this?
I believe the limitation is implemented for security reasons, in order to have
most critical parts executed as root and have it drop privileges for other
parts but this now completely blocks using SSSD in the above environment.
--
Tero
3 weeks
