389-ds + sssd user authentication not working on suse 15.3


OS version=“SUSE Linux Enterprise Desktop 15 SP3”

I’ve been trying to setup 389-ds + sssd by following

Setup steps went fine, except that I have these issues:
**1) user and groups I added in 389-ds are not showing up in the result of “getent passwd” and “getent group”.
2) if I try to ssh login to my server, I get the Invalid credentials(49) error in /var/log/sssd/sssd_ldap.log:
(2021-12-27 0:52:48): [be[ldap]] [fo_set_port_status] (0x0100): Marking port 636 of server ‘localhost’ as ‘working’
(2021-12-27 0:52:48): [be[ldap]] [set_server_common_status] (0x0100): Marking server ‘localhost’ as ‘working’
(2021-12-27 0:52:48): [be[ldap]] [fo_set_port_status] (0x0400): Marking port 636 of duplicate server ‘localhost’ as ‘working’
(2021-12-27 0:52:48): [be[ldap]] [simple_bind_send] (0x0100): Executing simple bind as: uid=miouser,ou=people,dc=auth
(2021-12-27 0:52:48): [be[ldap]] [simple_bind_done] (0x1000): Server returned no controls.
(2021-12-27 0:52:48): [be[ldap]] [simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no errmsg set
(2021-12-27 0:52:48): [be[ldap]] [dp_req_done] (0x0400): DP Request [PAM Authenticate #9]: Request handler finished [0]: Success
(2021-12-27 0:52:48): [be[ldap]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #9]: Receiving request data.
(2021-12-27 0:52:48): [be[ldap]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #9]: Request removed.
(2021-12-27 0:52:48): [be[ldap]] [dp_req_destructor] (0x0400): Number of active DP request: 0
(2021-12-27 0:52:48): [be[ldap]] [dp_method_enabled] (0x0400): Target selinux is not configured
(2021-12-27 0:52:48): [be[ldap]] [dp_pam_reply] (0x1000): DP Request [PAM Authenticate #9]: Sending result [7][ldap]

**I’m 100% sure this is NOT due to wrongly entered password as the password is very simple and I tried many times.
In additiion, this works:
**localhost:/ # ldapwhoami -D uid=miouser,ou=people,dc=auth -W
Enter LDAP Password:

dn: uid=miouser,ou=people,dc=auth
I had some previous experience with openldap but am new to 389-ds. Been stuck on this for days now. Tried manythings as I could imagine, and searched a lot on the net.
I saw this post I saw this port from Robin: https://forums.opensuse.org/showthread.php/560217-389ds-SSSD-Unable-to-login-6-(Permission-denied)****My problem is worse than Robin’s (he was able to see the user with “getent passwd”)

Would really appreciate any help for solving this.

My 389-ds instance name is “auth”, and the suffix is “dc=auth”.



config_version = 2

root_password = system389
self_sign_cert = True
instance_name = auth

sample_entries = yes
suffix = dc=auth

**sssd.conf file:
(I tried to set ignore_group_members = True, didn’t help) **


localhost:/etc/sssd # ls -l sssd.conf
-rw------- 1 root root 2339 Dec 27 01:09 sssd.conf
localhost:/etc/sssd # cat sssd.conf


Generated by 389 Directory Server - dsidm

For more details see man sssd.conf and man sssd-ldap

Be sure to review the content of this file to ensure it is secure and correct

in your environment.

services = nss, pam, ssh, sudo
config_file_version = 2
domains = ldap

homedir_substring = /home


Uncomment this for more verbose logging.


Cache hashes of user authentication for offline auth.

cache_credentials = True
id_provider = ldap
auth_provider = ldap
access_provider = ldap
chpass_provider = ldap
ldap_schema = rfc2307bis
ldap_search_base = dc=auth
#ldap_uri = ldapi://%2fvar%2frun%2fslapd-auth.socket
#ldap_uri = ldaps://%2fvar%2frun%2fslapd-auth.socket
ldap_uri = ldaps://localhost
#ldap_uri = ldaps://auth

If you have DNS SRV records, you can use the following instead. This derives

from your ldap_search_base.

ldap_uri = srv

ldap_tls_reqcert = demand

To use cacert dir, place *.crt files in this path then run:

/usr/bin/openssl rehash /etc/openldap/certs

or (for older versions of openssl)

/usr/bin/c_rehash /etc/openldap/certs

ldap_tls_cacertdir = /etc/openldap/certs

Path to the cacert

ldap_tls_cacert = /etc/openldap/certs/ca.crt

Only users who match this filter can login and authorise to this machine. Note

that users who do NOT match, will still have their uid/gid resolve, but they

can’t login.

ldap_access_filter = (memberOf=cn=miogroup,ou=Groups,dc=auth)
#ldap_access_filter = (objectClass=posixAccount)

enumerate = false
access_provider = ldap
#access_provider = permit
ldap_user_member_of = memberof
ldap_user_gecos = cn
ldap_user_uuid = nsUniqueId
ldap_group_uuid = nsUniqueId

This is really important as it allows SSSD to respect nsAccountLock

ldap_account_expire_policy = rhds
ldap_access_order = filter, expire
#ldap_access_order = expire

Setup for ssh keys

Inside /etc/ssh/sshd_config add the lines:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys

AuthorizedKeysCommandUser nobody

You can test with the command: sss_ssh_authorizedkeys <username>

ldap_user_ssh_public_key = nsSshPublicKey

This prevents an issue where the Directory is recursively walked on group

and user look ups. It makes the client faster and more responsive in almost

every scenario.

ignore_group_members = False

**memberOf plugin is enabled:
localhost:/etc/sssd # dsconf auth plugin memberof show
dn: cn=MemberOf Plugin,cn=plugins,cn=config
cn: MemberOf Plugin
memberofattr: memberOf
memberofgroupattr: member
nsslapd-plugin-depends-on-type: database
nsslapd-pluginDescription: memberof plugin
nsslapd-pluginEnabled: on
nsslapd-pluginId: memberof
nsslapd-pluginInitfunc: memberof_postop_init
nsslapd-pluginPath: libmemberof-plugin
nsslapd-pluginType: betxnpostoperation
nsslapd-pluginVendor: 389 Project
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject

**User and group entries in LDAP:
(so I have the user “miouser” who belongs to “miogorup”, and I do have the memberOf attribute assigned
to the user after adding the user to the group
localhost:/etc/sssd # ldapsearch -D “cn=Directory Manager” -w xxxxxxx -b ou=people,dc=auth

extended LDIF


base <ou=people,dc=auth> with scope subtree

filter: (objectclass=*)

requesting: ALL

people, auth

dn: ou=people,dc=auth
objectClass: top
objectClass: organizationalunit
ou: people

demo_user, people, auth

dn: uid=demo_user,ou=people,dc=auth
objectClass: top
objectClass: nsPerson
objectClass: nsAccount
objectClass: nsOrgPerson
objectClass: posixAccount
uid: demo_user
cn: Demo User
displayName: Demo User
legalName: Demo User Name
uidNumber: 99998
gidNumber: 99998
homeDirectory: /var/empty
loginShell: /bin/false

miouser, people, auth

dn: uid=miouser,ou=people,dc=auth
objectClass: top
objectClass: nsPerson
objectClass: nsAccount
objectClass: nsOrgPerson
objectClass: posixAccount
objectClass: nsMemberOf
uid: miouser
cn: miouser
displayName: miouser
uidNumber: 2010
gidNumber: 2010
homeDirectory: /home/miouser
memberOf: cn=miogroup,ou=groups,dc=auth

search result

search: 2
result: 0 Success

numResponses: 4

numEntries: 3

localhost:/etc/sssd # ldapsearch -D “cn=Directory Manager” -w system389 -b ou=groups,dc=auth

extended LDIF


base <ou=groups,dc=auth> with scope subtree

filter: (objectclass=*)

requesting: ALL

groups, auth

dn: ou=groups,dc=auth
objectClass: top
objectClass: organizationalunit
ou: groups

demo_group, groups, auth

dn: cn=demo_group,ou=groups,dc=auth
objectClass: top
objectClass: groupOfNames
objectClass: posixGroup
objectClass: nsMemberOf
cn: demo_group
gidNumber: 99999

miogroup, groups, auth

dn: cn=miogroup,ou=groups,dc=auth
objectClass: top
objectClass: groupOfNames
objectClass: nsMemberOf
cn: miogroup
member: uid=miouser,ou=people,dc=auth

search result

search: 2
result: 0 Success

numResponses: 4

numEntries: 3

I followed the steps in https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-security-ldap.html#sec-security-ldap-server-sssd
to change /etc/nsswitch.conf and common-account-pc, common-auth-pc, common-password-pc, and common-session-pc
**Before making teh changes, I backed up the original files into <file_name>.ORIG.
After doing the changes, here are the diff:

localhost:/etc # ls -l nsswitch.conf*
-rw-r–r-- 1 root root 2202 Dec 25 22:20 nsswitch.conf
-rw-r–r-- 1 root root 2190 May 6 2021 nsswitch.conf.ORIG
localhost:/etc #
localhost:/etc # diff nsswitch.conf nsswitch.conf.ORIG
< passwd: compat sss
< group: compat sss
< shadow: compat sss

> passwd: compat
> group: compat
> shadow: compat

localhost:/etc/pam.d # pam-config -a --sss
localhost:/etc/pam.d # pam-config -q --sss
localhost:/etc/pam.d #
localhost:/etc/pam.d # diff common-account-pc.ORIG common-account-pc
< account required pam_unix.so try_first_pass

> account requisite pam_unix.so try_first_pass
> account sufficient pam_localuser.so
> account required pam_sss.so use_first_pass
localhost:/etc/pam.d # diff common-auth-pc.ORIG common-auth-pc
< auth required pam_unix.so try_first_pass

> auth sufficient pam_unix.so try_first_pass
> auth required pam_sss.so use_first_pass
localhost:/etc/pam.d # diff common-password-pc.ORIG common-password-pc
< password required pam_unix.so use_authtok nullok shadow try_first_pass

> password sufficient pam_unix.so use_authtok nullok shadow try_first_pass
> password required pam_sss.so use_authtok
localhost:/etc/pam.d # diff common-session-pc.ORIG common-session-pc
> session optional pam_sss.so
localhost:/etc/pam.d #

I do see below error when doing “systemctl restart sssd”
(2021-12-27 1:41:39): [be[ldap]] [dp_req_reply_gen_error] (0x0080): DP Request [Subdomains #0]: Finished. Target is not supported with this configuration.
Full log below


These here are NOT the SLED/SLES forums, these are the openSUSE forums.