1:25 a.m.
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