Hi, >> This may result in a change in our strategy going forward. I'm looking >> for users to describe to us the reasons why they're choosing SSSD (in >> its current incarnation) over winbind. What I'm trying to sort out is >> whether there are specific *issues* with winbind that SSSD is solving >> for users. In other words, I'm trying to determine whether our decision >> to write and support a winbind provider backend is misplaced. > > Stability and performance. We'd tried winbind as a solution but ended up > having to baby sit it far too much for it to be a great solution. It could > crash in a few different ways and didn't recover. > > than it used to be). SSSD's with the LDAP backend has been more stable than > winbind, generally faster than winbind, and is currently working with our > AD with no additional patches. > > It's also nice to have the option of running without joining the domain, and > both nss_ldap and SSSD offer that as an option. > > responsive to bug reports. I'm not clear how having a winbind back end is > going to improve what I've got now with the LDAP backend.
I'm also a bit unclear what would be the real benefit of the SSSD/Winbind provider, especially considering that one can already configure both SSSD and Winbind for NSS/PAM on the same system (on Fedora/RHEL with few minor tweaks to authconfig generated PAM files, see RHBZ#760109). Also, as others have already mentioned, there have been issues even when using pure Winbind. So if you'll create the SSSD/Winbind provider it might be that you'll end up debugging both the SSSD/Winbind integration code and Winbind itself when trying to resolve issues reported with the SSSD/Winbind provider. And as we all know Winbind requires the system to be a domain member which is not required with SSSD (but currently SSSD requires IdM for UNIX on AD to be in use unlike Winbind+idmap_rid or recent nss-pam-ldapd). By adding the AD specific features to the SSSD/LDAP provider you wouldn't be dependant on Winbind in any way and you'd have crystal clear understanding as always on what's going on with your SSSD/LDAP provider. This would allow to use SSSD with any number of AD domains and remove the need for both joining systems to a domain and also using IdM for UNIX on AD. With IPAv3 this could allow for an interesting scenario, it should be possible to setup an AD/IPA trust and then provide the host keytabs/principals from IPA to clients which would be used to do LDAP bind when communicating with AD. So just by setting up the AD/IPA trust there would be zero additional requirements for AD side to allow AD users to login to IPA clients if so configured in sssd.conf. In an ideal world we would of course have both the options to choose from and we should see them more as completing than competing solutions but in the real world we have some unfortunate restrictions like developer hours to dedicate per a task so I fully appreciate that some prioritization is needed. Since going with the SSSD/Winbind provider involves a whole new backend completely dependant on not-quite-perfect Winbind as opposed to enhancing the already proven SSSD/LDAP provider it seems to me that adding the AD specifics to the SSSD/LDAP would provide a rather elegant solution for certain AD environments probably with less effort. But as always there are certainly some issues waiting to be discovered with both approaches.. Thanks, -- Marko Myllynen _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
