1

I'd like to use SSSD ldap as a provider for shadow entries. It seems to be supported, given the default config with sssd installed adds sss to both passwd and shadow in nsswitch.conf, but I can't get the shadow entries.

Testing getent passwd myuser gives me the right result. getent shadow myuser returns nothing immediately (seems to not check with sssd at all).

The shadow entry does exist in LDAP and sssd seems aware of it, since I see this in the logs:

[sdap_attrs_add_ldap_attr] (0x2000): [RID#4] Adding pwdAttribute [....] to attributes of [myuser@domain]. 

Unfortunately it doesn't seem to be ever used.

To prevent trying authentication through LDAP bind, I'm using:

id_provider=ldap auth_provider=none 

Unfortunately only results in:

(2023-08-11 7:04:03): [be[okta]] [dp_pam_handler_send] (0x0100): Got request with the following data (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): domain: domain (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): user: myuser@domain (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): service: sudo-i (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): tty: /dev/pts/3 (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): ruser: myuser (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): rhost: (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): authtok type: 1 (Password) (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): newauthtok type: 0 (No authentication token available) (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): priv: 1 (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): cli_pid: 2368059 (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): logon name: not set (2023-08-11 7:04:03): [be[okta]] [pam_print_data] (0x0100): flags: 0 (2023-08-11 7:04:03): [be[okta]] [dp_attach_req] (0x0400): [RID#5] DP Request [PAM Authenticate #5]: REQ_TRACE: New request. [sssd.pam CID #1] Flags [0000]. (2023-08-11 7:04:03): [be[okta]] [dp_attach_req] (0x0400): [RID#5] Number of active DP request: 1 (2023-08-11 7:04:03): [be[okta]] [dp_find_method] (0x0100): [RID#5] Target [auth] is not initialized (2023-08-11 7:04:03): [be[okta]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #5]: Receiving request data. (2023-08-11 7:04:03): [be[okta]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #5]: Request removed. (2023-08-11 7:04:03): [be[okta]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (2023-08-11 7:04:03): [be[okta]] [sbus_issue_request_done] (0x0200): sssd.dataprovider.pamHandler: Error [1432158215]: DP target is not configured 

What configuration am I missing to expose the user attributes as a standard shadow database?

1
  • Is the problem still exist? Commented May 30, 2024 at 15:29

1 Answer 1

0

What you are observing is normal.

SSSD performs authentication directly (usually called by pam_sss.so).

Providing nss entries via getent is an additional, and separate service. It is done on a best-effort basis. In the case of shadow and authentication from LDAP, sssd is missing some key information. Specifically, the password hash in LDAP is not suitable for shadow entries (and in a properly configured LDAP server, usually is not retrievable at all).

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.