sssd sometimes forgets all but one group memberships of a user

[Thomas Hood]

I have sssd configured to look up names in a Samba 4 LDAP directory running on the same machine.

In the following console log notice that the output of "groups foo" changes. User foo is actually in four groups. After su'ing to foo all but one group are omitted. After restarting sssd they are remembered after a ten second delay.

root@ellen:/# date ; groups foo
Tue Sep 11 16:55:14 CEST 2012
foo : domusers devel publish domadmins
root@ellen:/# su -c pwd foo
/
root@ellen:/# date ; groups foo
Tue Sep 11 16:55:28 CEST 2012
foo : domusers
root@ellen:/# date ; groups foo
Tue Sep 11 16:56:31 CEST 2012
foo : domusers
root@ellen:/# date ; restart sssd
Tue Sep 11 16:56:35 CEST 2012
sssd start/running, process 2906
root@ellen:/# date ; groups foo
Tue Sep 11 16:56:38 CEST 2012
foo : domusers
root@ellen:/# date ; groups foo
Tue Sep 11 16:56:50 CEST 2012
foo : domusers devel publish domadmins

Here's another console log, this time using "getent group domadmins". Notice how the member foo disappears from the group after "su foo" and reappears exactly ten seconds after restarting sssd.

root@ellen:/# date +%T.%N ; getent group domadmins ; su -c pwd foo ; date +%T.%N ; getent group domadmins ; restart sssd ; sleep 1 ; date +%T.%N ; getent group domadmins ; sleep 8 ; while : ; do date +%T.%N ; getent group domadmins ; sleep 0.1 ; done
17:11:42.514625566
domadmins:*:512:bar,foo
/
17:11:42.563576391
domadmins:*:512:bar
sssd start/running, process 3913
17:11:43.950506244
domadmins:*:512:bar
17:11:51.965140171
domadmins:*:512:bar
17:11:52.078101328
domadmins:*:512:bar
17:11:52.190149762
domadmins:*:512:bar
17:11:52.302006153
domadmins:*:512:bar
17:11:52.413620217
domadmins:*:512:bar
17:11:52.525430264
domadmins:*:512:bar
17:11:52.637152288
domadmins:*:512:bar
17:11:52.748823736
domadmins:*:512:bar
17:11:52.860533911
domadmins:*:512:bar
17:11:52.972191264
domadmins:*:512:bar
17:11:53.084747702
domadmins:*:512:bar,foo

# dpkg -l sssd | grep ^ii
ii sssd 1.9.0~beta6-0ubuntu1 System Security Services Daemon

# grep '\(group\|passwd\|shadow\)' /etc/nsswitch.conf
passwd: compat sss
group: compat sss
shadow: compat sss
netgroup: nis sss

root@ellen:/# cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = SAMBA

[nss]
filter_groups = root
filter_users = root

[pam]

[domain/SAMBA]
description = Samba 4 Authentication Environment
enumerate = true
min_id = 500
id_provider = ldap
ldap_uri = ldap://192.168.1.2
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/ssl/certs/cmpny.crt
ldap_schema = rfc2307bis
ldap_search_base = dc=cmpny,dc=nl
ldap_referrals = False
ldap_default_bind_dn = cn=ldap-ellen,cn=users,dc=cmpny,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = ReadOnlyAccount
ldap_user_object_class = person
ldap_user_name = msSFU30Name
ldap_user_fullname = name
ldap_user_gecos = name
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_user_principal = userPrincipalName
ldap_user_pwd = unixUserPassword
ldap_user_modify_timestamp = whenChanged
ldap_group_object_class = group
ldap_group_name = msSFU30Name
ldap_group_gid_number = gidNumber
ldap_group_pwd = unixUserPassword
ldap_group_modify_timestamp = whenChanged
ldap_force_upper_case_realm = True
auth_provider = krb5
chpass_provider = krb5
krb5_server = 192.168.1.2
krb5_kpasswd = 192.168.1.2
krb5_kdcip = 192.168.1.2
krb5_realm = CMPNY.COM
krb5_changepw_principal = kadmin/changepw
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX

[Jakub Hrozek (jakub-hrozek)]

Without the SSSD logs it's hard to tell for certain, but I suspect this is caused by enumerate=True in the sssd.conf config file.

The reason why the groups seemingly appear after about ten seconds is that after the SSSD provider starts up, the enumerate task is scheduled. In general, it *should* block the NSS operations until the initial enumeration has completed, though.

Is the behaviour reproducable within a single SSSD session? In other words, if you log in after the ten seconds have passed and the getent command reports correct group memberships, does "groups" still show wrong membership?

Also, is there a particular reason to use enumerate=True?

[Thomas Hood (jdthood)]

Hi Jakub,

You wrote:
> Without the SSSD logs it's hard to tell for certain, but I suspect this is caused by enumerate=True in the sssd.conf config file.

If I comment out "enumerate = True" then the behavior is the same except that even after restarting sssd, "getent group domadmins" continues to fail to list the user even after ten seconds.

root@ellen:/# getent group domadmins
domadmins:*:512:bar,foo
root@ellen:/# su -c pwd foo
/
root@ellen:/# getent group domadmins
domadmins:*:512:bar
root@ellen:/# restart sssd
sssd start/running, process 5154
root@ellen:/# date ; getent group domadmins
Wed Sep 12 00:42:14 CEST 2012
domadmins:*:512:bar
root@ellen:/# date ; getent group domadmins
Wed Sep 12 00:43:16 CEST 2012
domadmins:*:512:bar

(Please note that "su -c pwd foo" doesn't open a new interactive shell; it just executes the pwd command in a short-lived shell process owned by foo.)

> Also, is there a particular reason to use enumerate=True?

Well, the bug is worse without it than with it. :) Without it, sssd fails to remember that foo is a member of domadmins even after it's restarted.

> The reason why the groups seemingly appear after about
> ten seconds is that after the SSSD provider starts up,
> the enumerate task is scheduled. In general, it *should*
> block the NSS operations until the initial enumeration
> has completed, though.

It doesn't block. If you think that this is a bug then please file a report. :)

> Is the behaviour reproducable within a single SSSD session?
> In other words, if you log in after the ten seconds have passed
> and the getent command reports correct group memberships,
> does "groups" still show wrong membership?

With "enumerate = true", after sssd has been restarted and ten seconds have passed, "getent group domadmins" reports foo as a member and "groups foo" shows domadmins as one of foo's groups. Before ten seconds have passed "getent group domadmins" does not show foo as a member and "groups foo" does not show domadmins as one of foo's groups. The getent and groups commands have always been consistent with each other so far as I have seen during my testing.

[Jakub Hrozek (jakub-hrozek)]

Sure, getent group and groups should yield the same results, the are just a different ways of reaching the same information -- getent group <groupname> retrieves members of a group, groups <username> performs an initgroups operation that retrieves the groups the user is a member of.

I think we should debug the information some more...

Can you raise the "debug_level" in the "domain" section of the sssd.conf to 8 perhaps, clear the SSSD caches and run both tests? Then please attach /var/log/sssd/sssd_SAMBA.log.

Did exactly the same config file work with a previous SSSD version?

[Thomas Hood (jdthood)]

I said that "groups" and "getent" are consistent with each other but here is proof that that is not always the case.

After foo logs in and out, "groups foo" and "getent group domadmins" omit foo from domadmins whereas "getent group" still includes foo in domadmins.

root@ellen:/# getent group |grep domadmins
domadmins:*:512:bar,foo
root@ellen:/# getent group domadmins
domadmins:*:512:bar,foo
root@ellen:/# groups foo
foo : domusers devel publish domadmins
root@ellen:/# su -c pwd foo
/
root@ellen:/# getent group |grep domadmins
domadmins:*:512:bar,foo
root@ellen:/# getent group domadmins
domadmins:*:512:bar
root@ellen:/# groups foo
foo : domusers

After restarting sssd, all methods initially agree (incorrectly) that foo is not a member of domadmins.

root@ellen:/# restart sssd
sssd start/running, process 6690
root@ellen:/# getent group | grep domadmins
domadmins:*:512:bar
root@ellen:/# getent group domadmins
domadmins:*:512:bar
root@ellen:/# groups foo
foo : domusers

But ten seconds later, "groups foo" and "getent group domadmins" include foo in domadmins whereas "getent group" still omits foo from domadmins.

root@ellen:/# # Wait ten seconds
root@ellen:/# getent group | grep domadmins
domadmins:*:512:bar
root@ellen:/# getent group domadmins
domadmins:*:512:bar,foo
root@ellen:/# groups foo
foo : domusers devel publish domadmins

This is, again, with enumerate = true in [domain/SAMBA].

Sometimes, though, nothing changes even after ten seconds.

Sometimes restarting sssd causes "getent group" to include foo in domadmins again. The behavior varies.

[Thomas Hood (jdthood)]

I wrote comment #4 before I saw your new comment #3.

You wrote:
> Did exactly the same config file work with a previous SSSD version?

Yes, I had no trouble with sssd 1.8.2-0ubuntu1.

I'll gather the debugging info you asked for and mail it to you directly.

[Thomas Hood (jdthood)]

Another interesting phenomenon.

I log in as foo.

foo@ellen:~$ groups
domusers
foo@ellen:~$ groups foo
foo : domusers devel publish domadmins
foo@ellen:~$ id
uid=10005(foo) gid=513(domusers) groups=513(domusers)
foo@ellen:~$ id foo
uid=10005(foo) gid=513(domusers) groups=513(domusers),601(devel),602(publish),512(domadmins)

[Stephen Gallagher (stephen-gallagherhome)]

Just for the record, 'getent group username' and 'groups' should NOT be identical.

Just plain "groups" will list the set of groups that were assigned to you *at login time*, whereas 'getent group username' or 'groups username' gives you the list of groups that would be assigned to you if you logged in right now.

So it's expected that they would be different if you changed memberships since logging in. This is standard UNIX behavior, though certainly not what most people would expect.

[Thomas Hood (jdthood)]

You can't compare 'getent group xxx' with 'groups'. The first lists user names, the second group names.

Perhaps you meant to say that 'groups' and 'groups $USER' are not necessarily the same. The first returns a list that was created at login time, the second an up-to-date list. Good to point that out, especially in connection with my comment #6.

However, the main issue here (bug #1049186) concerns incorrect output from "getent group", "getent group grpnm" and "groups foo", all of which (I believe) are supposed to report current information, not information collected at login time.

[Thomas Hood (jdthood)]

Jakub wrote in comment #1
> Is the behaviour reproducable within a single SSSD session?
> In other words, if you log in after the ten seconds have
> passed and the getent command reports correct group
> memberships, does "groups" still show wrong membership?

Sorry, Jakub, I didn't answer this question in my first reply to your comment.

As Stephen has just pointed out, the output of "groups" doesn't ever change. It reports information collected at login time. The output of "groups foo" does change ten seconds after restarting sssd.

root@ellen:/# su foo
foo@ellen:/$ groups
domusers
foo@ellen:/$ groups foo
foo : domusers
foo@ellen:/$ # Restart sssd here
foo@ellen:/$ groups
domusers
foo@ellen:/$ groups foo
foo : domusers
foo@ellen:/$ # Wait ten seconds
foo@ellen:/$ groups
domusers
foo@ellen:/$ groups foo
foo : domusers devel publish domadmins
foo@ellen:/$

Logging in again causes foo to disappear again from all but one group.

foo@ellen:/$ exit
exit
root@ellen:/# su foo
foo@ellen:/$ groups
domusers
foo@ellen:/$ groups foo
foo : domusers

[Thomas Hood (jdthood)]

Here's another possible clue.

I have a machine running sssd 1.8.2-0ubuntu1. On startup with debug_level = 0x470 it logs the following.

(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [dc=cmpny,dc=com]
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=group)(msSFU30Name=*)(&(gidNumber=*)(!(gidNumber=0))))][dc=cmpny,dc=com].
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 4 results.
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group devel
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group publish
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group domadmins
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group domusers
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_grpmem] (0x0400): Storing members for group devel
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_grpmem] (0x0400): Storing members for group publish
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_grpmem] (0x0400): Storing members for group domadmins
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_grpmem] (0x0400): Storing members for group domusers
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_process_group_send] (0x0040): No Members. Done!
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group devel
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group publish
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group domadmins
(Sat Sep 15 21:16:05 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group domusers

Sssd 1.9.0~rc1-0ubuntu1 logs the following.

(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [dc=cmpny,dc=com]
(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=group)(msSFU30Name=*)(&(gidNumber=*)(!(gidNumber=0))))][dc=cmpny,dc=com].
(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 4 results.
(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group devel
(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group publish
(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group domadmins
(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_save_group] (0x0400): Storing info for group domusers
(Sat Sep 15 21:10:21 2012) [sssd[be[SAMBA]]] [sdap_save_grpmem] (0x0400): ...

[Thomas Hood (jdthood)]

Here's a partial workaround. In [domain/SAMBA] I set

    ldap_purge_cache_timeout = 3
    ldap_enumeration_refresh_timeout = 3

Then, although user foo still disappears from groups on login, it's back within a few seconds without my having to restart sssd.

This may be an additional clue as to where the bug is.

root@ellen:/# su -c pwd foo ; while : ; do groups foo ; sleep 1 ; done
/
foo : domusers
foo : domusers devel publish domadmins
^C
root@ellen:/# su -c pwd foo ; while : ; do groups foo ; sleep 1 ; done
/
foo : domusers devel publish domadmins
^C
root@ellen:/# su -c pwd foo ; while : ; do groups foo ; sleep 1 ; done
/
foo : domusers
foo : domusers
foo : domusers
foo : domusers
foo : domusers
foo : domusers
foo : domusers devel publish domadmins
^C
root@ellen:/# su -c pwd foo ; while : ; do groups foo ; sleep 1 ; done
/
foo : domusers
foo : domusers
foo : domusers
foo : domusers
foo : domusers devel publish domadmins
^C

[Thomas Hood (jdthood)]

With the partial workaround

    ldap_purge_cache_timeout = 3
    ldap_enumeration_refresh_timeout = 3

when "foo" logs in to the affected system, half the time "groups" shows foo to be a member of four groups; half the time "groups" shows only one group. Whether it's one or the other seems random.

[Thomas Hood (jdthood)]

Following up on the previous comment (#12), the following log output illustrates the "random" nature of the problem.

# while : ; do su -c groups foo ; sleep 1 ; done
domusers
domusers
domusers
domusers
domusers domadmins devel publish
domusers
domusers
domusers
domusers
domusers domadmins devel publish
domusers
domusers
domusers
domusers
domusers
domusers
domusers
domusers
domusers
domusers
domusers
domusers domadmins devel publish
domusers domadmins devel publish
domusers domadmins devel publish
domusers domadmins devel publish
domusers
domusers
domusers domadmins devel publish
domusers domadmins devel publish
domusers domadmins devel publish
domusers
domusers
domusers
domusers domadmins devel publish
domusers domadmins devel publish
domusers
domusers
domusers
domusers domadmins devel publish
domusers domadmins devel publish
domusers
domusers
domusers
domusers
domusers domadmins devel publish
domusers
domusers
domusers

Commenting out either one of the two lines quoted in comment #12 and restarting sssd and repeating the experiment gives something like:

# while : ; do su -c groups foo ; sleep 1 ; done
domusers
domusers
domusers
domusers
domusers
domusers
domusers domadmins devel publish
domusers domadmins devel publish
domusers domadmins devel publish
domusers
domusers
domusers
[... ad infinitum, or at least for several minutes]

[Thomas Hood (jdthood)]

Looking in samba's log I see something interesting. When doing

    # while : ; do su -c groups foo ; sleep 1 ; done

and when we get a

    domusers

just after a (correct)

    domusers domadmins devel publish

samba always prints the following in the log.

[2012/09/26 16:14:06, 1] ../lib/ldb-samba/ldb_wrap.c:68(ldb_wrap_debug)
  ldb: ldb: unknown extended rule_id 1.2.840.113556.1.4.1941
[2012/09/26 16:14:06, 1] ../lib/ldb-samba/ldb_wrap.c:68(ldb_wrap_debug)
  ldb: ldb: unknown extended rule_id 1.2.840.113556.1.4.1941

Is this perhaps a Samba 4 bug or a bad interaction between sssd and Samba 4?

# dpkg -l samba4 sssd
[...]
hi samba4 4.0.0~beta2+dfsg1-2.dbg SMB/CIFS file, NT domain and active directory server (version 4)
ii sssd 1.9.0~rc1-0ubuntu1 System Security Services Daemon

How can I investigate further?

[Thomas Hood (jdthood)]

No improvement with sssd 1.9.0-0ubuntu1.

[Thomas Hood (jdthood)]

I found a solution. Add the following line to [domain/SAMBA]:

    ldap_initgroups_use_matching_rule_in_chain = False

AIUI this prevents sssd from using the LDAP operation 1.2.840.113556.1.4.1941 which hasn't been implemented in Samba 4.

Result:

# while : ; do su -c groups foo ; sleep 1 ; done
domusers domadmins devel publish
domusers domadmins devel publish
domusers domadmins devel publish
[...]

[Thomas Hood (jdthood)]

Returning to the configuration without "ldap_initgroups_use_matching_rule_in_chain = False" but with "ldap_purge_cache_timeout = 3" and "ldap_enumeration_refresh_timeout = 3" I captured sssd logs at debug_level 0x0ff0 and compared a sequence immediately after which "groups" reported only one group --- the "bad" sequence --- with a sequence immediately after which "groups" reported all groups --- the "good" one. Here is the diff between these two sequences of log entries.

In the "bad" case sssd calls ldap_search_ext and receives no error code. In the "good" case it doesn't call ldap_search_ext but, I am wildly guessing, returns values from a cache which has been filled with the correct information by means of a periodic enumeration.

I am wildly guessing further that the error condition reported by Samba 4 is getting lost on its way back to sssd, so sssd just thinks that foo is a member of no groups beyond foo's primary group.

--- bad1 2012-10-03 09:49:22.755381392 +0200
+++ good2 2012-10-03 09:56:59.587392279 +0200
@@ -6,15 +6,6 @@
 [sysdb_search_user_by_uid] (0x0400): No such entry
 [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
 [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success
-[be_get_account_info] (0x0100): Got request for [3][1][name=foo]
-[sdap_get_initgr_next_base] (0x0400): Searching for users with base [dc=cmpny,dc=nl]
-[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(msSFU30Name=foo)(objectclass=person))][dc=cmpny,dc=nl].
-[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
-[sdap_save_user] (0x0400): Storing info for user foo
-[sdap_get_ad_match_rule_initgroups_next_base] (0x0400): Searching for groups with base [dc=cmpny,dc=nl]
-[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(member:1.2.840.113556.1.4.1941:=CN=Foo Doo,OU=Organization,DC=cmpny,DC=nl)(objectClass=group))][dc=cmpny,dc=nl].
-[sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set
-[acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success
 [be_pam_handler] (0x0100): Got request with the following data
 [pam_print_data] (0x0100): command: PAM_ACCT_MGMT
 [pam_print_data] (0x0100): domain: SAMBA
@@ -28,7 +19,7 @@
 [pam_print_data] (0x0100): newauthtok type: 0
 [pam_print_data] (0x0100): newauthtok size: 0
 [pam_print_data] (0x0100): priv: 1
-[pam_print_data] (0x0100): cli_pid: 6632
+[pam_print_data] (0x0100): cli_pid: 6681
 [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success]
 [be_pam_handler_callback] (0x0400): SELinux provider doesn't exist, not sending the request to it.
 [be_pam_handler_callback] (0x0100): Sending result [0][SAMBA]
@@ -46,7 +37,7 @@
 [pam_print_data] (0x0100): newauthtok type: 0
 [pam_print_data] (0x0100): newauthtok size: 0
 [pam_print_data] (0x0100): priv: 1
-[pam_print_data] (0x0100): cli_pid: 6632
+[pam_print_data] (0x0100): cli_pid: 6681
 [be_pam_handler] (0x0100): Sending result [0][SAMBA]
 [be_pam_handler] (0x0100): Got request with the following data
 [pam_print_data] (0x0100): command: PAM_CLOSE_SESSION
@@ -61,6 +52,6 @@
 [pam_print_data] (0x0100): newauthtok type: 0...

[Thomas Hood (jdthood)]

I have filed a report about this problem in the Samba 4 BTS.

    https://bugzilla.samba.org/show_bug.cgi?id=9237

[Thomas Hood (jdthood)]

Not reproducible any more with version 1.9.1.

[Stephen Gallagher (stephen-gallagherhome)]

Thomas, 1.9.1 changed the default behavior so that we do not enable the matching rule by default, but I suspect that the same issue is likely present if it is re-enabled manually.

The SSSD is *supposed* to be properly detecting whether the server it's talking to is capable of understanding that routine, so we definitely need to figure out why the autodetection is not working right with samba4.