On Wed, 30 Dec 2015, Matt . wrote:
Hi John,

With which OS, package version and config ? On Ubuntu 15.10 I'm not
able it seems.
That is purely issue of Ubuntu packaging:
- Samba in Ubuntu 15.10 is built provide and use libwbclient.so.0.11
- SSSD in Ubuntu 15.10 is built to provide libwbclient.so.0.12
  -8<-8<-8<-
root@u1510:~# ls -la /usr/lib/x86_64-linux-gnu/libwbclient.so.0.11 -rw-r--r-- 1 root root 43216 Nov 12 18:08 /usr/lib/x86_64-linux-gnu/libwbclient.so.0.11 root@u1510:~# ls -la /usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.12.0 -rw-r--r-- 1 root root 35032 Sep 7 13:50 /usr/lib/x86_64-linux-gnu/sssd/modules/libwbclient.so.0.12.0
  ->8->8->8-
- There are no alternatives configured to switch libwbclient to use
  SSSD's version (Ubuntu packaging of Samba doesn't really know that
  there could be an alternative implementation of libwbclient)

So you Samba wouldn't be able to use the libwbclient provided by SSSD
directly without special tricks or rebuilding.

Furthermore, - Samba in Ubuntu 15.10 is built with Heimdal Kerberos, SSSD is built
  with MIT Kerberos. When you enroll Ubuntu 15.10 client into FreeIPA,
  it configures /etc/krb5.conf according to use of MIT Kerberos,
  including default ccache location to be in the kernel keyring:
  -8<-8<-8<-
root@u1510:~# cat /etc/krb5.conf|grep default_ccache_name
 default_ccache_name = KEYRING:persistent:%{uid}
  ->8->8->8-

This means that Samba will not be able to see default credentials cache
as set up by SSSD for the user. Also, if you change default_ccache_name
to be somewhere on file system, like FILE:/tmp/krb5cc_%{uid}, MIT
Kerberos has some differences in the internal format of the credentials
cache and applications compiled against Heimdal kerberos library will
not be able to see some of the extended details in that ccache. While
Heimdal and MIT Kerberos are mostly compatible on the wire, there are no
promises of compatibility here for the credentials caches beyond the
basics.

Also, libldap is built against Heimdal in Ubuntu 15.10. This means that
whenever SSSD starts using some advanced features provided by MIT
Kerberos, LDAP libraries might fail to pick them up for SASL GSSAPI
authentication. In most cases this would probably work fine but for
cases like using kernel keyring it would fail miserably as well.

So, really, there are issues with packaging that you might overcome by
doing manual work of symlinking proper libraries like we did in Fedora
in coordination between Samba and SSSD packages, but things still might
not work unless you downgrade a common base to features supported by
both Heimdal and MIT Kerberos. There are also practical issues of SSSD's
ldap helper loading both MIT and Heimdal Kerberos code in the same
process instance -- which is a disaster to happen when a function with
the same name from one library is called on a structure allocated by
another library.

A proper solution would be to get Canonical more involved into the work
we do with move of Samba to use MIT Kerberos for Samba AD as lack of MIT
Kerberos support in Samba AD is what forces Debian and Ubuntu to stick
to Heimdal (and Fedora to abstain from packaging Samba AD flavor for
several years to avoid using Heimdal instead of MIT Kerberos). Until
that happens, using Fedora/CentOS/RHEL is a better choice.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to