Bug 1175511

Oh, this system has sssd-libwbclient installed, and it was using that. Removing it makes it use the real libwbclient which works.

If you're going to install a higher-priority 'alternative' for Samba's libraries, please make sure they *work*.

It looks like the problem here is that you're using 'alternatives'. That only bases its decisions on what packages are *installed* (unless you expect the user to manually fix things up, which you shouldn't).

I think what you actually want is a shim library in /lib64/libwbclient.so.0 which checks which of SSSD or winbind is actually *running*, and passes calls through to the appropriate implementation.

(In reply to David Woodhouse from comment #3)
> It looks like the problem here is that you're using 'alternatives'. That
> only bases its decisions on what packages are *installed* (unless you expect
> the user to manually fix things up, which you shouldn't).
> 
> I think what you actually want is a shim library in /lib64/libwbclient.so.0
> which checks which of SSSD or winbind is actually *running*, and passes
> calls through to the appropriate implementation.

This is actually a pretty good idea.

Sumit can we open a ticket about this in sssd ?

Actually a potentially simpler solution is to make the init script switch the alternatives when the related daemon starts. This way there is no additional runtime overhead.

Yeah, that works well.

In *addition*, your wbcLogonUser() which only returns 'not implemented' should also set *error=NULL. And any meet any other ABI requirements/assumptions.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2537

How soon can we expect a fix for this? I have users all reporting that Samba/winbind is broken on new installs.

Should I investigate a workaround with Conflicts: sssd-libwbclient on our internal package of setup scripts, or will we have a fix by the time I'm able to do that and test new installs with it?

sssd-1.12.2-6.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/sssd-1.12.2-6.fc21

David, Simo, thank you for your suggestions in comments 3-5. My original idea was that sssd-libwbclient will only be installed manually on purpose for the use cases it was build for which went well in my testing.

It looks like yum/dnf pull in sssd-libwbclient to resolve a libwbclient.so* dependency. I have removed all libwbclient.so* Provides from the new package so that it will not be picked by yum/dnf anymore.

Package sssd-1.12.2-6.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.12.2-6.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-17425/sssd-1.12.2-6.fc21
then log in and leave karma (feedback).

sssd-1.12.2-6.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

This isn't fixed. It looks like there's an updated package in F21 which doesn't provide libwbclient.so, which means that *if* someone's doing a new install with the updates online at the time they install, they should get Samba's libwbclient package installed. That much is fine.

However, I'm still getting failure reports from users. I think what's happening is that they install from media *without* the online updates, and thus they get SSSD's libwbclient package installed anyway. And they later update once they're online, but the system is already hosed by then. Samba's libwbclient package does get installed, but the underlying problem is still present — the SSSD package is hijacking Samba's own internal library.

I think we do need the initscript fix to set the alternatives correctly according to whether sssd or winbind is actually being run.

I installed sssd and sssd-libwbclient was not installed.

[root@host /]# update-alternatives --list | grep wbclient
libwbclient.so.0.11-64  auto    /usr/lib64/samba/wbclient/libwbclient.so.0.11

sssd version of libwbclient.so is used just in case of installed package sssd-libwbclient (which is not installed by default)

[root@host /]# rpm -q sssd-libwbclient
sssd-libwbclient-1.12.3-2.fc22.x86_64
[root@host /]# update-alternatives --list | grep wbclient
libwbclient.so.0.11-64  auto    /usr/lib64/sssd/modules/libwbclient.so.0.11.0

The alternative is correctly update if the package sssd-libwbclient is removed from system.

[root@host /]# yum remove sssd-libwbclient
    #snip
[root@host /]# rpm -q sssd-libwbclient
package sssd-libwbclient is not installed
[root@host /]# update-alternatives --list | grep wbclient
libwbclient.so.0.11-64  auto    /usr/lib64/samba/wbclient/libwbclient.so.0.11

The solution is to remove package sssd-libwbclient from your system.
If you do not want to remove that package from system you can manually configure alternative.

[root@host /]# update-alternatives --config libwbclient.so.0.11-64

There are 2 programs which provide 'libwbclient.so.0.11-64'.

  Selection    Command
-----------------------------------------------
   1           /usr/lib64/samba/wbclient/libwbclient.so.0.11
*+ 2           /usr/lib64/sssd/modules/libwbclient.so.0.11.0

Enter to keep the current selection[+], or type selection number: 1

[root@host /]# update-alternatives --display libwbclient.so.0.11-64
libwbclient.so.0.11-64 - status is manual.
 link currently points to /usr/lib64/samba/wbclient/libwbclient.so.0.11
/usr/lib64/samba/wbclient/libwbclient.so.0.11 - priority 10
/usr/lib64/sssd/modules/libwbclient.so.0.11.0 - priority 20
Current `best' version is /usr/lib64/sssd/modules/libwbclient.so.0.11.0.

(In reply to Lukas Slebodnik from comment #15)

> The solution is to remove package sssd-libwbclient from your system.
> If you do not want to remove that package from system you can manually
> configure alternative.

No, that's completely missing the point. We need a proper fix so that the broken package will stop causing problems for new installs.

In my opinion, this bug is fixed.

Reason:
* crash in sssd-libwbclient is fixed.
* sssd-libwbclient is not installed by default
* installation and removing of package sssd-libwbclient updates alternatives.
* manual updating of alternatives works as well

If you don't like how alternatives works you can open another ticket. This ticket was mainly about crash and it isn't good idea to mix two issues in one BZ.

(In reply to Lukas Slebodnik from comment #17)
> * sssd-libwbclient is not installed by default

This is false.

If users install from the F21 media without the updates, sssd-libwbclient *is* getting installed by default as it provides libwbclient.so.

If they do a network install *with* the updates, the new sssd-libwbclient gets considered instead of the original one in the F21 release, and the problem goes away.

But for F21 Workstation, there appears to be *only* DVD media, not the normal boot.iso which would have encouraged people to configure the proxy as required and do a network install. So I am finding a lot of users who are suffering this bug.

Please do not pretend that there isn't a problem here.

libwbclient was always a *Samba* library. You've made things such that in a stock F21 install, it's overridden by something that is entirely non-functional in a winbind setup. There are no circumstances under which that is justifiable. Even if you make it "just" broken, instead of letting it actually crash.

I'm not going to play games with re-opening the bug again, but I *will* be going to FESCo and asking them to enforce some sanity if this doesn't get fixed properly.

David, I understand your concern here. It's a really unfortunate situation.

There are a number of problems here, and no good solutions. Let me try to outline the full picture.

1) Fedora Workstation has only the Live install media. It performs "installations" by copying the Live deployment directly to the new system. Because of the SSSD situation at the moment when we froze Fedora 21 for release, this means that sssd-libwblient is installed to all Fedora 21 Workstation systems. Unless they are installing via the netinst iso provided by Server, which includes updates, which is uncommon.

2) Because it's already installed, normal updates to the system cannot remove it without providing an Obsoletes: from Winbind. The problem with doing it this way is that anyone who *legitimately* wants the SSSD version will not be able to keep it, since any update will force them to have it replaced by Winbind's version.

Unfortunately, there are only a few ways out of this mess with Fedora 21 and upgrades (We will have it fixed properly for Fedora 22 fresh installs):

a) We need to communicate to users that you have to run 'yum swap sssd-libwbclient libwbclient' in order to get the winbind version working.

b) Choose to force everyone onto the Winbind version by adding an Obsoletes: to libwbclient for sssd-libwbclient for the current version and lower. We then provide a version-bumped copy of sssd-libwbclient that exceeds that version. The result here is that everyone is moved back to the samba libwbclient and people who need the SSSD version then have to run 'yum swap libwbclient sssd-libwbclient' to restore their functionality.

On IRC earlier we settled on a simpler solution which does work for existing systems. An updated SSSD package will install the sssd-libwbclient at a *lower* priority than winbind's, which means that Samba's will take precedence when they are both installed.

https://admin.fedoraproject.org/updates/sssd-1.12.3-4.fc21

OK, that should work. It looks like both are installed by default on Workstation, but if an update can reduce the priority, I think that's probably a good solution.

*** Bug 1186771 has been marked as a duplicate of this bug. ***

I just want to emphasise how truly annoying this bug is.

Right now, on a patched-up F21 machine, you can (and I just did) waste literal hours trying to figure out why *any* wbinfo comment returns WBC_ERR_NOT_IMPLEMENTED, even though the Samba config looks ok:

# wbinfo -D IC
failed to call wbcDomainInfo: WBC_ERR_NOT_IMPLEMENTED
Could not get domain info

Please please please fix this ASAP and please, please don't trick out package-internal libraries like this again. It's hugely annoying.

I note the bug appears to have languished in "closed" since January.

Right. The problem is that a lot of people seem to have the alternative for libwbclient.so stuck in 'manual' mode instead of 'auto', so the "fix" which was shipped doesn't actually fix it.

I saw that problem, but I blamed it on my own attempts at debugging and remediation. But now I'm seeing reports of it from other users who I'm fairly sure *hadn't* screwed with it manually. So there's something else going on here and the "fix" we shipped isn't good enough.

I think we need to reopen this and work it out. How are these getting set into manual mode unless a user *explicitly* does so? Is there some package with a script which sets it? Or *has* there been?

I definitely didn't manually select the alternative, so agree it must have been selected as the alternative elsewhere.

It's a very recently built F21 machine - 19th Jan, based on the /root/anaconda-ks.cfg timestamp - which I installed from the F21 live DVD, patched once right after install and a couple more times since then. "yum.log" lists, for the most likely culprits (I guess):

Jan 19 16:54:41 Updated: 2:libwbclient-4.1.15-1.fc21.x86_64
Jan 19 16:56:17 Updated: sssd-libwbclient-1.12.3-2.fc21.x86_64
Feb 04 13:40:10 Updated: sssd-libwbclient-1.12.3-4.fc21.x86_64
Mar 11 17:00:44 Updated: 2:libwbclient-4.1.17-1.fc21.x86_64
Mar 11 17:01:20 Updated: sssd-libwbclient-1.12.4-1.fc21.x86_64

I'll have a quick mess with a VM install, see what it looks like immediately post-install, if that would be useful?

(In reply to Phil Mayers from comment #25)
> I definitely didn't manually select the alternative, so agree it must have
> been selected as the alternative elsewhere.
> 
> It's a very recently built F21 machine - 19th Jan, based on the
> /root/anaconda-ks.cfg timestamp - which I installed from the F21 live DVD,
> patched once right after install and a couple more times since then.
> "yum.log" lists, for the most likely culprits (I guess):
> 
> Jan 19 16:54:41 Updated: 2:libwbclient-4.1.15-1.fc21.x86_64
> Jan 19 16:56:17 Updated: sssd-libwbclient-1.12.3-2.fc21.x86_64
> Feb 04 13:40:10 Updated: sssd-libwbclient-1.12.3-4.fc21.x86_64
> Mar 11 17:00:44 Updated: 2:libwbclient-4.1.17-1.fc21.x86_64
> Mar 11 17:01:20 Updated: sssd-libwbclient-1.12.4-1.fc21.x86_64

sssd-libwbclient should not be installed by default on fedora 21.
Could you try to figure it out why there is an installed package sssd-libwbclient.

I've literally wasted hours of my life today trying to get a samba shared home directory using security=ads on a Fedora 21 install.


I could not work out how the following was occurring:

../source3/auth/auth_winbind.c:105(check_winbind_security)
  check_winbind_security: wbcAuthenticateUserEx failed: WBC_ERR_NOT_IMPLEMENTED

Because having dug into the source, the call to wbcAuthenticateUserEx from check_winbind_security could not possibly return WBC_ERR_NOT_IMPLEMENTED.


Before digging, I searched for the error messages and found nothing but repos and commit logs. *Hopefully*, this comment will hopefully serve as signpost to others.

In all my years, I'd never have expected that the library internal to a package would be swapped out by an external package with one that returns NOT_IMPLEMENTED for something essential to its function; whoever did this has made me very very angry. I hope that they think a *lot* more carefully about their design decisions in the future.

It's on the Live CD! Less than 5 minutes ago, I installed a copy of the Live DVD in a VM, and with no other config, no patching, no nothing, I get this:

[root@localhost ~]# ls -l anaconda-ks.cfg 
-rw-------. 1 root root 1119 Mar 12 14:17 anaconda-ks.cfg

[root@localhost ~]# date
Thu 12 Mar 14:21:02 GMT 2015

[root@localhost ~]# rpm -q sssd-libwbclient
sssd-libwbclient-1.12.2-2.fc21.x86_64

So, it most certainly is being installed by default, I'm afraid ;o)

Gah. I don't know how to remove the "needinfo" now after hitting a conflicting update.

@Lukas, the GA version of the package on the iso had a Provides which caused it to be pulled in. If was filtered out in later version but unfortunately it will be installed if you install from the iso without online updates enabled. 

@Phil, can you send the output of 'alternatives --list'?

"alternatives --list" for the just-installed Live DVD VM:

[root@localhost ~]# alternatives --list
print	auto	/usr/bin/lpr.cups
libnssckbi.so.x86_64	auto	/usr/lib64/pkcs11/p11-kit-trust.so
jre_1.8.0_openjdk	auto	/usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.25-4.b18.fc21.x86_64
jre_openjdk	auto	/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-4.b18.fc21.x86_64/jre
jre_1.8.0	auto	/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-4.b18.fc21.x86_64/jre
qtchooser-qt4	auto	/etc/xdg/qtchooser/qt4-64.conf
whois	auto	/usr/bin/jwhois
cifs-idmap-plugin	auto	/usr/lib64/cifs-utils/cifs_idmap_sss.so
qtchooser-qt5	auto	/etc/xdg/qtchooser/qt5-64.conf
java	auto	/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-4.b18.fc21.x86_64/jre/bin/java
xinputrc	auto	/etc/X11/xinit/xinput.d/ibus.conf
qtchooser-default	auto	/etc/xdg/qtchooser/qt4.conf

Seems the sssd-libwbclient isn't in there? But I'm not overly familiar with alternatives...

I thought there was another respin of fedora DVD. But the latest version is from 03-Dec-2014.

We can decrease priority of alternative to workaround upgrade from buggy version on DVD.

Phil, of course sssd is not a usable alternative to winbind right now and the working libwbclient was never meant to be replaced by default with something non-working.

We will make sure to resolve this bug as soon as we can.

@Guenther - understood, and I appreciate both the accidental nature of the problem and the efforts to resolve it.

My main aim was to get the ball rolling again, as it seemed as if the discussion stopped in January, as far as this ticket was concerned :o)

Phil, I tried to reproduce with an installation from the iso and then doing an online update to the latest versions. It ended with libwbclient from the samba package properly used via alternatives. I'll collect the old package versions and try your update path now.

Hang on, you're right - I missed something. sssd-libwbclient is definitely installed, but now that I look further, it's not being used.

[root@localhost ~]# ls -l /usr/lib64/libwbclient.so.0.11
-rwxr-xr-x. 1 root root 44104 Oct  7 16:14 /usr/lib64/libwbclient.so.0.11

[root@localhost ~]# rpm -qf /usr/lib64/libwbclient.so.0.11
libwbclient-4.1.12-5.fc21.x86_64

This is still the fresh live DVD install; no updates.

I'll snapshot the qcow2 and update, see if my results match yours when updated as well.

I read bugzilla one more time and David confirmed in Comment 20
that priority of sssd-libwbclient is lower then libwbclient.
According to fedora 21 spec file it should be 5.

man alternatives says:
Each alternative has a priority associated with it. When a link group is in automatic mode, the alternatives pointed to by members of the group will be those which have the highest priority. 

Could you provide output of commands?
rpm -qa "*libwbclient*"
alternatives --display libwbclient.so-64
p.mayers.uk

(In reply to Lukas Slebodnik from comment #37)
> I read bugzilla one more time and David confirmed in Comment 20
> that priority of sssd-libwbclient is lower then libwbclient.
> According to fedora 21 spec file it should be 5.
> 
> man alternatives says:
> Each alternative has a priority associated with it. When a link group is in
> automatic mode, the alternatives pointed to by members of the group will be
> those which have the highest priority. 
> 
> Could you provide output of commands?
One more time without you mail :-)

 rpm -qa "*libwbclient*"
 alternatives --display libwbclient.so-64
 alternatives --display libwbclient.so.0.11-64

Confirmed, an update direct from fresh install to todays updates does not display the problem.

However, another machine, installed Jan 6th, with the following update path:

Jan 06 16:54:34 Updated: 2:libwbclient-4.1.14-1.fc21.x86_64
Jan 06 16:58:11 Updated: sssd-libwbclient-1.12.2-6.fc21.x86_64
Jan 14 12:04:55 Updated: 2:libwbclient-4.1.14-2.fc21.x86_64
Mar 12 12:02:26 Updated: 2:libwbclient-4.1.17-1.fc21.x86_64

...did display the problem. AFAICT there aren't any common updates there to my original machine (listed above, repeated here):

Jan 19 16:54:41 Updated: 2:libwbclient-4.1.15-1.fc21.x86_64
Jan 19 16:56:17 Updated: sssd-libwbclient-1.12.3-2.fc21.x86_64
Feb 04 13:40:10 Updated: sssd-libwbclient-1.12.3-4.fc21.x86_64
Mar 11 17:00:44 Updated: 2:libwbclient-4.1.17-1.fc21.x86_64
Mar 11 17:01:20 Updated: sssd-libwbclient-1.12.4-1.fc21.x86_64

...so maybe something in a range of one of the two package versions "flipped" it to broken, and it never gets flipped back, but the current updates don't. Or an ordering problem?

@Lukas - sorry, updates crossing in flight there. Do you want those on the fresh, un-updated VM, or fully-updated one?

We need to see an output of commands on problematic machine.

Unfortunately we've fixed both problem-case machines here. I can only supply a fresh install and a fully patched, neither of which seems problematic:

Fresh VM:

[root@localhost ~]#  rpm -qa "*libwbclient*"
sssd-libwbclient-1.12.2-2.fc21.x86_64
libwbclient-4.1.12-5.fc21.x86_64
[root@localhost ~]#  alternatives --display libwbclient.so-64
[root@localhost ~]#  alternatives --display libwbclient.so.0.11-64

Following patch to current updates:

[root@localhost ~]#  rpm -qa "*libwbclient*"
sssd-libwbclient-1.12.4-1.fc21.x86_64
libwbclient-4.1.17-1.fc21.x86_64
[root@localhost ~]#  alternatives --display libwbclient.so-64
[root@localhost ~]#  alternatives --display libwbclient.so.0.11-64
libwbclient.so.0.11-64 - status is auto.
 link currently points to /usr/lib64/samba/wbclient/libwbclient.so.0.11
/usr/lib64/sssd/modules/libwbclient.so.0.11.0 - priority 5
/usr/lib64/samba/wbclient/libwbclient.so.0.11 - priority 10
Current `best' version is /usr/lib64/samba/wbclient/libwbclient.so.0.11.

As per above comments, looks like one of the intermediate updates might have triggered it, or maybe even other package installs e.g. Samba?

I'll try and reproduce, but it'll take some time to work through the RPM combos, since they're likely not in the Fedora public repos any more.

Ok, looks like at least the combo:

samba-4.1.15-1.fc21
sssd-1.12.3-2.fc21

...is problematic. From the "fresh" install, fetched and installed:

libsmbclient-4.1.15-1.fc21.x86_64.rpm
libwbclient-4.1.15-1.fc21.x86_64.rpm
samba-client-4.1.15-1.fc21.x86_64.rpm
samba-common-4.1.15-1.fc21.x86_64.rpm
samba-libs-4.1.15-1.fc21.x86_64.rpm
sssd-libwbclient-1.12.3-2.fc21.x86_64.rpm

Install order in case it matters:

Updating / installing...
   1:samba-libs-2:4.1.15-1.fc21    
   2:libwbclient-2:4.1.15-1.fc21   
   3:samba-common-2:4.1.15-1.fc21  
   4:libsmbclient-2:4.1.15-1.fc21  
   5:samba-client-2:4.1.15-1.fc21  
   6:sssd-libwbclient-1.12.3-2.fc21
Cleaning up / removing...
   7:samba-client-2:4.1.12-5.fc21  
   8:libsmbclient-2:4.1.12-5.fc21  
   9:samba-common-2:4.1.12-5.fc21  
  10:libwbclient-2:4.1.12-5.fc21   
  11:samba-libs-2:4.1.12-5.fc21    
  12:sssd-libwbclient-1.12.2-2.fc21


...and we get:

[root@localhost ~]# rpm -qa "*libwbclient*"
libwbclient-4.1.15-1.fc21.x86_64
sssd-libwbclient-1.12.3-2.fc21.x86_64

[root@localhost ~]#  alternatives --display libwbclient.so-64

[root@localhost ~]#  alternatives --display libwbclient.so.0.11-64
libwbclient.so.0.11-64 - status is auto.
 link currently points to /usr/lib64/sssd/modules/libwbclient.so.0.11.0
/usr/lib64/sssd/modules/libwbclient.so.0.11.0 - priority 20
/usr/lib64/samba/wbclient/libwbclient.so.0.11 - priority 10
Current `best' version is /usr/lib64/sssd/modules/libwbclient.so.0.11.0.

The problematic machines have the 'libwbclient.so.0.11' alternative somehow in *manual* state, not auto. So tweaking the priority isn't sufficient to fix them.

I've seen this enough times now that I no longer assume it really *is* due to manual intervention, as I did when I first saw it on my own workstation. There's something — perhaps a %post script on one of the packages or something — which is causing it to get into 'manual' state pointing at SSSD.

David is right - something is causing the alternative to be set to manual and presumably, either an interim package or ordering issue causes it to then get stuck on manual, sssd-libwbclient.

If I go:

1. fresh install
2. update to samba-4.1.15-1.fc21
sssd-1.12.3-2.fc21
3. update to current

I get:

1. working, samba libwbclient, no alternatives config
2. broken, sssd libwbclient, alternatives "auto"
3. working, samba libwbclient, alternatives "manual"

Output for @Lukas' requested commands in the final config (two interim steps listed in comment #42 and #43) is:

[root@localhost ~]#  rpm -qa "*libwbclient*"
libwbclient-4.1.17-1.fc21.x86_64
sssd-libwbclient-1.12.4-1.fc21.x86_64

[root@localhost ~]#  alternatives --display libwbclient.so-64

[root@localhost ~]#  alternatives --display libwbclient.so.0.11-64
libwbclient.so.0.11-64 - status is manual.
 link currently points to /usr/lib64/sssd/modules/libwbclient.so.0.11.0
/usr/lib64/sssd/modules/libwbclient.so.0.11.0 - priority 5
/usr/lib64/samba/wbclient/libwbclient.so.0.11 - priority 10
Current `best' version is /usr/lib64/samba/wbclient/libwbclient.so.0.11.

So although it's pointing at libwbclient, the alternative has transitioned from auto to manual, with no intervention on my part.

Odd...

Looks like it is a feature of the alternatives tool to switch to manual if the priority is changed.

Lukas, do you think we can add something like 

@@ -860,6 +864,7 @@ fi
 %{_sbindir}/update-alternatives --install %{_libdir}/libwbclient.so.0.11 \
                                 libwbclient.so.0.11%{libwbc_alternatives_suffix} \
                                 %{_libdir}/%{name}/modules/libwbclient.so.0.11.0 5
+%{_sbindir}/update-alternatives --auto libwbclient.so.0.11%{libwbc_alternatives_suffix}
 /sbin/ldconfig
 
 %preun libwbclient
@@ -874,6 +879,7 @@ fi
 %{_sbindir}/update-alternatives --install %{_libdir}/libwbclient.so \
                                 libwbclient.so%{libwbc_alternatives_suffix} \
                                 %{_libdir}/%{name}/modules/libwbclient.so 5
+%{_sbindir}/update-alternatives --auto libwbclient.so%{libwbc_alternatives_suffix}
 
 %preun libwbclient-devel
 if [ $1 -eq 0 ]; then


to the sssd spec file to sort this out?

I tried following steps.

[root@host~]# alternatives --display libwbclient.so.0.11-64 
libwbclient.so.0.11-64 - status is auto.
 link currently points to /usr/lib64/samba/wbclient/libwbclient.so.0.11
/usr/lib64/sssd/modules/libwbclient.so.0.11.0 - priority 5
/usr/lib64/samba/wbclient/libwbclient.so.0.11 - priority 10
Current `best' version is /usr/lib64/samba/wbclient/libwbclient.so.0.11.


[root@host ~]# update-alternatives --install /usr/lib64/libwbclient.so.0.11 libwbclient.so.0.11-64 /usr/lib64/sssd/modules/libwbclient.so.0.11.0 6

[root@host ~]# alternatives --display libwbclient.so.0.11-64 
libwbclient.so.0.11-64 - status is auto.
 link currently points to /usr/lib64/samba/wbclient/libwbclient.so.0.11
/usr/lib64/sssd/modules/libwbclient.so.0.11.0 - priority 6
/usr/lib64/samba/wbclient/libwbclient.so.0.11 - priority 10
Current `best' version is /usr/lib64/samba/wbclient/libwbclient.so.0.11.

As you can see the state did not change to manual.

Phil,
Did you use yum or dnf to upgrade packages?

I used yum.

Phil, 
Could you test upgrade with scratch build?
http://koji.fedoraproject.org/koji/taskinfo?taskID=9223405

Sorry, not sure what exactly I'm testing here. From which state - freshly installed, intermediate (which RPMs?), fully updated?

I mean steps mentioned in Comment 45.
You can test also other steps with problematic update.

Sorry, I'm still not clear. #45 had:

1. fresh install
2. install intermediate samba/sssd packages
3. update to current

Do you want me to use your new sssd build in step 2 or 3? Or install it after step 3?

(In reply to Phil Mayers from comment #53)
> Sorry, I'm still not clear. #45 had:
> 
> 1. fresh install
> 2. install intermediate samba/sssd packages
> 3. update to current
> 
> Do you want me to use your new sssd build in step 2 or 3? Or install it
> after step 3?

If you update to current sssd in fedora 21(step 3) then alternative will switch into manual mode. So you should test upgrade to packages from scratch build.

Another user experienced a similar problem:

connect to samba over pptp

reporter:       libreport-2.3.0
backtrace_rating: 4
cmdline:        /usr/sbin/smbd
crash_function: dump_core
executable:     /usr/sbin/smbd
kernel:         3.18.9-200.fc21.x86_64
package:        samba-4.1.17-1.fc21
reason:         smbd killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            0

Created attachment 1004643 [details]
File: backtrace

sssd-1.12.4-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/sssd-1.12.4-2.fc21

Package sssd-1.12.4-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.12.4-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4602/sssd-1.12.4-2.fc21
then log in and leave karma (feedback).

sssd-1.12.4-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.