sssd-ldap using id_provider=files and auth_provider=ldap

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

[Sumit Bose]

Am Mon, Apr 29, 2024 at 03:25:49PM +0900 schrieb koson823(a)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 
Hi,

my first guess would be that the `uid=search_id` object does not have
the permissions to read the `objectClass` attribute from other objects.
Please check the ACIs on the LDAP server side for this user.

HTH

bye,
Sumit

>  
>  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
>  --
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Hi,

Thank you for your quick response. Yes, that was the reason. In this regard, let me allow
to add the following question. 

Is there any way to remove objectClass from the filter, such as to be (uid=hogehoge) but
not (&(uid=hogehoge)(objectclass=inetOrgPerson)) as in the failure case?

Even though I tried to remove the objectclass filter in sssd.conf, I couldn’t.
Removing “ldap_user_object_class" statement in [domain/local] automatically gives the
following:
(&(uid=hogehoge)(objectclass=posixAccount))
(as mentioned before, posixAccount is not used in the LDAP database.)
Or, is the declaration of objectclass mandatory in the filter?
I would greatly appreciate any assistance.

>  2024/04/29 19:55、Sumit Bose <sbose(a)redhat.xn--com&gt;-1e4f10b4csi:
>  
>  Hi,
>  
>  my first guess would be that the `uid=search_id` object does not have
>  the permissions to read the `objectClass` attribute from other objects.
>  Please check the ACIs on the LDAP server side for this user.
>  
>  HTH
>  
>  bye,
>  Sumit
>  
> > 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)

[Sumit Bose]

Am Mon, Apr 29, 2024 at 09:12:08PM +0900 schrieb koson823(a)me.com:
>  Hi,
>  
>  Thank you for your quick response. Yes, that was the reason. In this regard, let me allow
> to add the following question. 
>  
>  Is there any way to remove objectClass from the filter, such as to be (uid=hogehoge) but
> not (&(uid=hogehoge)(objectclass=inetOrgPerson)) as in the failure case?
>  
>  Even though I tried to remove the objectclass filter in sssd.conf, I couldn’t.
>  Removing “ldap_user_object_class" statement in [domain/local] automatically gives
> the following:
>  (&(uid=hogehoge)(objectclass=posixAccount))
>  (as mentioned before, posixAccount is not used in the LDAP database.)
>  Or, is the declaration of objectclass mandatory in the filter?
>  I would greatly appreciate any assistance. 
Hi,

SSSD will always use an objectclass in the filter to make sure that
only the expected type of objects are returned.

HTH

bye,
Sumit

>  
>  > 2024/04/29 19:55、Sumit Bose <sbose(a)redhat.xn--com&gt;-1e4f10b4csi:
>  > 
>  > Hi,
>  > 
>  > my first guess would be that the `uid=search_id` object does not have
>  > the permissions to read the `objectClass` attribute from other objects.
>  > Please check the ACIs on the LDAP server side for this user.
>  > 
>  > HTH
>  > 
>  > bye,
>  > Sumit
>  > 
>  >> 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)
>  --
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Thank you for the explanation. I understand.

>  2024/04/29 22:45、Sumit Bose <sbose(a)redhat.xn--com&gt;-1e4f10b4csi:
>  
>  Am Mon, Apr 29, 2024 at 09:12:08PM +0900 schrieb koson823(a)me.com
> <mailto:[e-mail]>:
> > Hi,
> > 
> > Thank you for your quick response. Yes, that was the reason. In this regard, let me
> allow to add the following question. 
> > 
> > Is there any way to remove objectClass from the filter, such as to be (uid=hogehoge)
> but not (&(uid=hogehoge)(objectclass=inetOrgPerson)) as in the failure case?
> > 
> > Even though I tried to remove the objectclass filter in sssd.conf, I couldn’t.
> > Removing “ldap_user_object_class" statement in [domain/local] automatically
> gives the following:
> > (&(uid=hogehoge)(objectclass=posixAccount))
> > (as mentioned before, posixAccount is not used in the LDAP database.)
> > Or, is the declaration of objectclass mandatory in the filter?
> > I would greatly appreciate any assistance.
>  
>  Hi,
>  
>  SSSD will always use an objectclass in the filter to make sure that
>  only the expected type of objects are returned.
>  
>  HTH
>  
>  bye,
>  Sumit
>  
> > 
> >> 2024/04/29 19:55、Sumit Bose <sbose(a)redhat.xn--com&gt;-1e4f10b4csi:
> >> 
> >> Hi,
> >> 
> >> my first guess would be that the `uid=search_id` object does not have
> >> the permissions to read the `objectClass` attribute from other objects.
> >> Please check the ACIs on the LDAP server side for this user.
> >> 
> >> HTH
> >> 
> >> bye,
> >> Sumit
> >> 
> >>> 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)
> > --
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>  --
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> <mailto:[e-mail]>
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> <mailto:[e-mail]>
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue