[SSSD] Re: [RFC] sbus2 integration

[Simo Sorce]

On Fri, 2018-05-18 at 16:11 +0200, Sumit Bose wrote:
> On Fri, May 18, 2018 at 02:33:32PM +0200, Pavel Březina wrote:
> > Hi folks,
> > I sent a mail about new sbus implementation (I'll refer to it as sbus2) [1].

Sorry Pavel,
but I need to ask, why a new bus instead of somthing like varlink ?

> > Now, I'm integrating it into SSSD. The work is quite difficult since it
> > touches all parts of SSSD and the changes are usually interconnected but I'm
> > slowly moving towards the goal [2].
> > 
> > At this moment, I'm trying to take "miminum changes" paths so the code can
> > be built and function with sbus2, however to take full advantage of it, it
> > will take further improvements (that will not be very difficult).
> > 
> > There is one big change that I would like to take though, that needs to be
> > discussed. It is about how we currently handle sbus connections.
> > 
> > In current state, monitor and each backend creates a private sbus server.
> > The current implementation of a private sbus server is not a message bus, it
> > only serves as an address to create point to point nameless connection. Thus
> > each client must maintain several connections:
> >  - each responder is connected to monitor and to all backends
> >  - each backend is connected to monitor
> >  - we have monitor + number of backends private servers
> >  - each private server maintains about 10 active connections
> > 
> > This has several disadvantages - there are many connections, we cannot
> > broadcast signals, if a process wants to talk to other process it needs to
> > connect to its server and maintain the connection. Since responders do not
> > currently provider a server, they cannot talk between each other.

This design has a key advantage, a single process going down does not
affect all other processes communication. How do you recover if the
"switch-board" goes down during message processing with sbus ?

> > sbus2 implements proper private message bus. So it can work in the same way
> > as session or system bus. It is a server that maintains the connections,
> > keep tracks of their names and then routes messages from one connection to
> > another.
> > 
> > My idea is to have only one sbus server managed by monitor.

This conflict wth the idea of getting rid of the monitor process, do
not know if this is currently still pursued but it was brought up over
and over many times that we might want to use systemd as the "monitor"
and let socket activation deal with the rest.

> >  Other processes
> > will connect to this server with a named connection (e.g. sssd.nss,
> > sssd.backend.dom1, sssd.backend.dom2). We can then send message to this
> > message bus (only one connection) and set destination to name (e.g. sssd.nss
> > to invalidate memcache). We can also send signals to this bus and it will
> > broadcast it to all connections that listens to this signals. So, it is
> > proper way how to do it. It will simplify things and allow us to send
> > signals and have better IPC in general.
> > 
> > I know we want to eventually get rid of the monitor, the process would stay
> > as an sbus server. It would become a single point of failure, but the
> > process can be restarted automatically by systemd in case of crash.
> > 
> > Also here is a bonus question - do any of you remember why we use private
> > server at all?
> 
> In the very original design there was a "switch-board" process which
> received a request from one component and forwarded it to the right
> target. I guess at this time we didn't know a lot about DBus to
> implement this properly. In the end we thought it was a useless overhead
> and removed it. I think we didn't thought about signals to all components
> or the backend sending requests to the frontends.
> 
> > Why don't we connect to system message bus?
> 
> Mainly because we do not trust it to handle plain text passwords and
> other credentials with the needed care.

That and because at some point there was a potential chicken-egg issue
at startup, and also because we didn't want to handle additional error
recovery if the system message bus was restarted.

Fundamentally the system message bus is useful only for services
offering a "public" service, otherwise it is just an overhead, and has
security implications.

> > I do not see any benefit in having a private server.

There is no way to break into sssd via a bug in the system message bus.
This is one good reason, aside for the other above.

Fundamentally we needed a private structured messaging system we could
easily integrate with tevent. The only usable option back then was
dbus, and given we already had ideas about offering some plugic
interface over the message bus we went that way so we could later reuse
the integration.

Today we'd probably go with something a lot more lightweight like
varlink.

> If I understood you correctly we not only have 'a' private server but 4
> for a typically minimal setup (monitor, pam, nss, backend).
> 
> Given your 

[SSSD] [sssd PR#573][opened] winbind idmap plugin: fix detection

[sumit-bose]

   URL: https://github.com/SSSD/sssd/pull/573
Author: sumit-bose
 Title: #573: winbind idmap plugin: fix detection
Action: opened

PR body:
"""
Currently when compiling the detection code for the idmap interface
version only SMBCLIENT_CFLAGS are used. Since libsmbclient does not use
NTSTATUS the cflags do not contain '-DHAVE_IMMEDIATE_STRUCTURES=1' which
make NTSTATUS to a struct instead of an integer. Since Samba itself
might be complied with this define (it typically is) we have to make
sure we use it as well. Otherwise the test program might crash on
platforms where this change changes the calling convention as well.

Related to https://pagure.io/SSSD/sssd/issue/3741
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/573/head:pr573
git checkout pr573
From 9d4cfbd277f50f992169f19bc2477cb3cd16b1c0 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 18 May 2018 21:34:44 +0200
Subject: [PATCH] winbind idmap plugin: fix detection

Currently when compiling the detection code for the idmap interface
version only SMBCLIENT_CFLAGS are used. Since libsmbclient does not use
NTSTATUS the cflags do not contain '-DHAVE_IMMEDIATE_STRUCTURES=1' which
make NTSTATUS to a struct instead of an integer. Since Samba itself
might be complied with this define (it typically is) we have to make
sure we use it as well. Otherwise the test program might crash on
platforms where this change changes the calling convention as well.

Related to https://pagure.io/SSSD/sssd/issue/3741
---
 src/external/samba.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/external/samba.m4 b/src/external/samba.m4
index 610831bf0..a67e17dcb 100644
--- a/src/external/samba.m4
+++ b/src/external/samba.m4
@@ -59,7 +59,7 @@ them. In this case, you will need to execute configure script with argument
 sambalibdir="`$PKG_CONFIG --variable=libdir smbclient`"/samba
 SAVE_CFLAGS=$CFLAGS
 SAVE_LIBS=$LIBS
-CFLAGS="$CFLAGS $SMBCLIENT_CFLAGS -I/usr/include/samba-4.0"
+CFLAGS="$CFLAGS $SMBCLIENT_CFLAGS $NDR_NBT_CFLAGS $NDR_KRB5PAC_CFLAGS -I/usr/include/samba-4.0"
 LIBS="$LIBS -L${sambalibdir} -lidmap-samba4 -Wl,-rpath ${sambalibdir}"
 AC_RUN_IFELSE(
 [AC_LANG_SOURCE([
@@ -98,7 +98,7 @@ int main(void)
 /* Check the versions we know about */
 for (v = 5; v <= 6; v++) {
 ret = smb_register_idmap(v, NULL, NULL);
-if (ret != NT_STATUS_OBJECT_TYPE_MISMATCH) {
+if (!NT_STATUS_EQUAL(ret,NT_STATUS_OBJECT_TYPE_MISMATCH)) {
 return v;
 }
 }
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/COI72J5ZCHIRM3TEFPWT4UAUFIWQPDB3/

[SSSD] Re: [RFC] sbus2 integration

[Simo Sorce]

On Fri, 2018-05-18 at 21:02 +0200, Jakub Hrozek wrote:
> > On 18 May 2018, at 14:33, Pavel Březina  wrote:
> > 
> > Also here is a bonus question - do any of you remember why we use private 
> > server at all? Why don't we connect to system message bus? I do not see any 
> > benefit in having a private server.
> 
> To expand on what Sumit said, at one point we were betting on kdbus
> to become a thing and then it didn’t. (I don’t know enough about
> bus1, but IIRC was "just" a userspace reimplementation of the D-Bus
> protocol, so the same trust limitations apply)

bus1 was also a kernel implementation, but that one also did not pan
out ...

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/RWGIJVWWJEUPZAWE3BGHG7SNQKWTBA46/

[SSSD] Re: [RFC] sbus2 integration

[Jakub Hrozek]

> On 18 May 2018, at 14:33, Pavel Březina  wrote:
> 
> Also here is a bonus question - do any of you remember why we use private 
> server at all? Why don't we connect to system message bus? I do not see any 
> benefit in having a private server.

To expand on what Sumit said, at one point we were betting on kdbus to become a 
thing and then it didn’t. (I don’t know enough about bus1, but IIRC was "just" 
a userspace reimplementation of the D-Bus protocol, so the same trust 
limitations apply)
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/SOTVIQ7CCHEY3CDU6KH4SYP5ZNHHIVAD/

[SSSD] [sssd PR#572][comment] winbind idmap plugin: support inferface version 6

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/572
Title: #572: winbind idmap plugin: support inferface version 6

fidencio commented:
"""
master:
 c6b99b0
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/572#issuecomment-390243490
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/5MQAURAQ5DVSGLF2COEIZZ3GCZJR64X6/

[SSSD] [sssd PR#572][closed] winbind idmap plugin: support inferface version 6

[fidencio]

   URL: https://github.com/SSSD/sssd/pull/572
Author: sumit-bose
 Title: #572: winbind idmap plugin: support inferface version 6
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/572/head:pr572
git checkout pr572
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/W5LWW2QYLOWNYAULWULONOTS2C5N7CMF/

[SSSD] [sssd PR#572][-Accepted] winbind idmap plugin: support inferface version 6

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/572
Title: #572: winbind idmap plugin: support inferface version 6

Label: -Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/7DVWMVDH33EHFYB63D7RHJ6AUS7CMVBN/

[SSSD] [sssd PR#572][+Pushed] winbind idmap plugin: support inferface version 6

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/572
Title: #572: winbind idmap plugin: support inferface version 6

Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/OUZICPSBQPFVA7M7VOXBSOPMLA4WVIWR/

[SSSD] [sssd PR#571][comment] MAN: Clarify how comments work in sssd.conf

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/571
Title: #571: MAN: Clarify how comments work in sssd.conf

fidencio commented:
"""
master:
 4ab4a26
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/571#issuecomment-390243061
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/LGYM7HBGRUDYEEZH7RBDU2EGUIR2U6A5/

[SSSD] [sssd PR#571][-Accepted] MAN: Clarify how comments work in sssd.conf

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/571
Title: #571: MAN: Clarify how comments work in sssd.conf

Label: -Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/Q3TPRMRF2UX2MI7FIPB66PHFKBWDQC2D/

[SSSD] [sssd PR#571][closed] MAN: Clarify how comments work in sssd.conf

[fidencio]

   URL: https://github.com/SSSD/sssd/pull/571
Author: amitkumar50
 Title: #571: MAN: Clarify how comments work in sssd.conf
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/571/head:pr571
git checkout pr571
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/UOUDOJEDCSSFDBTPOYSE7XP5T5FFHZER/

[SSSD] [sssd PR#572][+Accepted] winbind idmap plugin: support inferface version 6

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/572
Title: #572: winbind idmap plugin: support inferface version 6

Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/SYZZID34UZLXMRTMH5YWA6OA3SRK5M7G/

[SSSD] [sssd PR#572][comment] winbind idmap plugin: support inferface version 6

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/572
Title: #572: winbind idmap plugin: support inferface version 6

fidencio commented:
"""
Ack!
CI:  http://sssd-ci.${idm}/job/ci/8930/
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/572#issuecomment-390211974
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/SXVAPITMXXOTQUVAUSDUPHIR5UWZTEYM/

[SSSD] [sssd PR#571][comment] MAN: Clarify how comments work in sssd.conf

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/571
Title: #571: MAN: Clarify how comments work in sssd.conf

fidencio commented:
"""
Ack!
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/571#issuecomment-390199893
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/B4WVKFRD5OXROOCQE2XQMXDTROWI4NST/

[SSSD] [RFC] sbus2 integration

[Pavel Březina]

Hi folks,
I sent a mail about new sbus implementation (I'll refer to it as sbus2) 
[1]. Now, I'm integrating it into SSSD. The work is quite difficult 
since it touches all parts of SSSD and the changes are usually 
interconnected but I'm slowly moving towards the goal [2].


At this moment, I'm trying to take "miminum changes" paths so the code 
can be built and function with sbus2, however to take full advantage of 
it, it will take further improvements (that will not be very difficult).


There is one big change that I would like to take though, that needs to 
be discussed. It is about how we currently handle sbus connections.


In current state, monitor and each backend creates a private sbus 
server. The current implementation of a private sbus server is not a 
message bus, it only serves as an address to create point to point 
nameless connection. Thus each client must maintain several connections:

 - each responder is connected to monitor and to all backends
 - each backend is connected to monitor
 - we have monitor + number of backends private servers
 - each private server maintains about 10 active connections

This has several disadvantages - there are many connections, we cannot 
broadcast signals, if a process wants to talk to other process it needs 
to connect to its server and maintain the connection. Since responders 
do not currently provider a server, they cannot talk between each other.


sbus2 implements proper private message bus. So it can work in the same 
way as session or system bus. It is a server that maintains the 
connections, keep tracks of their names and then routes messages from 
one connection to another.


My idea is to have only one sbus server managed by monitor. Other 
processes will connect to this server with a named connection (e.g. 
sssd.nss, sssd.backend.dom1, sssd.backend.dom2). We can then send 
message to this message bus (only one connection) and set destination to 
name (e.g. sssd.nss to invalidate memcache). We can also send signals to 
this bus and it will broadcast it to all connections that listens to 
this signals. So, it is proper way how to do it. It will simplify things 
and allow us to send signals and have better IPC in general.


I know we want to eventually get rid of the monitor, the process would 
stay as an sbus server. It would become a single point of failure, but 
the process can be restarted automatically by systemd in case of crash.


Also here is a bonus question - do any of you remember why we use 
private server at all? Why don't we connect to system message bus? I do 
not see any benefit in having a private server.


[1] https://github.com/pbrezina/sbus
[2] https://github.com/pbrezina/sssd/tree/sbus
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/Z7ZSIEX7QAAZAUGCVNLTYDAYEUHOQHY6/

[SSSD] [sssd PR#572][comment] winbind idmap plugin: support inferface version 6

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/572
Title: #572: winbind idmap plugin: support inferface version 6

fidencio commented:
"""
Patches look good. I'm just firing a CI run and I'll add the "Accepted" label 
as soon as I get the results.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/572#issuecomment-390186788
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/sssd-devel@lists.fedorahosted.org/message/JEYDFRIMURNEAR2YZEI6MVERRPMHJBB3/

[SSSD] [sssd PR#572][opened] winbind idmap plugin: support inferface version 6

[sumit-bose]

   URL: https://github.com/SSSD/sssd/pull/572
Author: sumit-bose
 Title: #572: winbind idmap plugin: support inferface version 6
Action: opened

PR body:
"""
With Samba 4.7 the interface version of the idmap plugin was updated to
6. The patch adds support for this new version but can be complied with
the older version as well.

A configure option is added to select the version, if no version is
given configure tries to detect the version with the help of an internal
Samba library libidmap-samba4.so.

To make sure that always the right version is used configure will fail
if Samba is used (--with-samba, default) and no version can be
determined.

Resolves https://pagure.io/SSSD/sssd/issue/3741
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/572/head:pr572
git checkout pr572
From b78fced9263a2aa2d229879a868825aa7ebe19ac Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Tue, 15 May 2018 11:55:35 +0200
Subject: [PATCH] winbind idmap plugin: support inferface version 6

With Samba 4.7 the interface version of the idmap plugin was updated to
6. The patch adds support for this new version but can be complied with
the older version as well.

A configure option is added to select the version, if no version is
given configure tries to detect the version with the help of an internal
Samba library libidmap-samba4.so.

To make sure that always the right version is used configure will fail
if Samba is used (--with-samba, default) and no version can be
determined.

Resolves https://pagure.io/SSSD/sssd/issue/3741
---
 contrib/ci/configure.sh   |  9 +++
 contrib/sssd.spec.in  | 12 
 src/external/samba.m4 | 82 +++
 src/lib/winbind_idmap_sss/winbind_idmap_sss.c |  6 ++
 src/lib/winbind_idmap_sss/winbind_idmap_sss.h |  6 +-
 5 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/contrib/ci/configure.sh b/contrib/ci/configure.sh
index 9d18d0c18..09da5b4e7 100644
--- a/contrib/ci/configure.sh
+++ b/contrib/ci/configure.sh
@@ -35,6 +35,7 @@ declare -a CONFIGURE_ARG_LIST=(
 if [[ "$DISTRO_BRANCH" == -redhat-redhatenterprise*-6.*- ||
   "$DISTRO_BRANCH" == -redhat-centos-6.*- ]]; then
 CONFIGURE_ARG_LIST+=(
+"--with-smb-idmap-interface-version=5"
 "--disable-cifs-idmap-plugin"
 "--with-syslog=syslog"
 "--without-python3-bindings"
@@ -56,6 +57,14 @@ if [[ "$DISTRO_BRANCH" == -redhat-redhatenterprise*-7.*- ||
 )
 fi
 
+# Different versions of Debian might need different versions here but this is
+# sufficient to make the CI work
+if [[ "$DISTRO_BRANCH" == -debian-* ]]; then
+CONFIGURE_ARG_LIST+=(
+"--with-smb-idmap-interface-version=5"
+)
+fi
+
 declare -r -a CONFIGURE_ARG_LIST
 
 fi # _CONFIGURE_SH
diff --git a/contrib/sssd.spec.in b/contrib/sssd.spec.in
index d674f3011..c81dd3f11 100644
--- a/contrib/sssd.spec.in
+++ b/contrib/sssd.spec.in
@@ -127,6 +127,14 @@
 %global with_gdm_pam_extensions 0
 %endif
 
+# Do not try to detect the idmap version on RHEL6 to avoid conflicts between
+# samba and samba4 package
+%if (0%{?fedora} || 0%{?rhel} >= 7)
+%global detect_idmap_version 1
+%else
+%global with_idmap_version --with-smb-idmap-interface-version=5
+%endif
+
 Name: @PACKAGE_NAME@
 Version: @PACKAGE_VERSION@
 Release: 0@PRERELEASE_VERSION@%{?dist}
@@ -235,6 +243,9 @@ BuildRequires: nfs-utils-lib-devel
 
 BuildRequires: samba4-devel
 BuildRequires: libsmbclient-devel
+%if (0%{?detect_idmap_version} == 1)
+BuildRequires: samba-winbind
+%endif
 
 %if (0%{?enable_systemtap} == 1)
 BuildRequires: systemtap-sdt-devel
@@ -757,6 +768,7 @@ autoreconf -ivf
 %{?enable_systemtap_opt} \
 %{?with_secret_responder} \
 %{?with_kcm_option} \
+%{?with_idmap_version} \
 %{?experimental}
 
 make %{?_smp_mflags} all
diff --git a/src/external/samba.m4 b/src/external/samba.m4
index 91a583a0d..6084484e7 100644
--- a/src/external/samba.m4
+++ b/src/external/samba.m4
@@ -39,4 +39,86 @@ them. In this case, you will need to execute configure script with argument
 --without-samba
 ]])
 fi
+
+AC_ARG_WITH([smb-idmap-interface-version],
+[AC_HELP_STRING([--with-smb-idmap-interface-version=[5|6]],
+[Idmap interface version of installed Samba]
+   )
+]
+   )
+
+if test x"$with_smb_idmap_interface_version" != x; then
+if test x"$with_smb_idmap_interface_version" = x5 -o x"$with_smb_idmap_interface_version" = x6; then
+idmap_test_result=$with_smb_idmap_interface_version
+else
+AC_MSG_ERROR([Illegal value -$with_smb_idmap_interface_version- for option --with-smb-idmap-interface-version])
+fi
+else
+
+AC_MSG_CHECKING([Samba's idmap plugin interface version])
+sambalibdir="`$PKG_CONFIG --variable=libdir