When we originally designed SSSD, we looked at it as a solution for dealing with LDAP and Kerberos identity and authentication for Linux and UNIX clients. With our initial approach, we decided to include only marginal support for Microsoft's Active Directory as a source of user information (only supporting it when it is enabled for use with posixAccount and posixGroup object classes).
Our original assumption was that for complicated deployments relying on Active Directory, users would prefer to continue using Winbind. It has a very long history and is specifically designed around managing the peculiarities of Microsoft's LDAP implementation.
Of late, it has become apparent that many users are opting to "jump ship" from winbind to SSSD for use with Active Directory. This has been shown by a sharp uptick in community bug reports with Active Directory servers.
Up until now, our plans around Active Directory have circulated around including a "Winbind Provider" into SSSD, similar to the LDAP provider but making use of the original winbind features found in the Samba project. However, it's beginning to seem like users are expressing an interest to move AWAY from that solution.
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.
It may be that if SSSD's LDAP provider is offering a significant advantage over winbind, we will consider dropping (or deferring) our efforts to integrate winbind and instead put that effort into adding Active Directory-specific features into the LDAP provider. For example, we might reprioritize bugs https://fedorahosted.org/sssd/ticket/995 and https://fedorahosted.org/sssd/ticket/996
So please, share with us your stories for why you prefer SSSD over winbind and help us choose our direction for SSSD's future.