I have been doing Active Directory authentication projects for years now, and I have always tried *not* to use Winbind. I initially used the nss_ldap / pam_krb5 combination, but have recently adopted sssd.The reason for this have varied over time, but the most important ones are, in not particular order:<br>
<br>- in environments with several different flavors of Linux, it&#39;s wasn&#39;t always possible to use Winbind the same way on all machines; RHEL3&#39;s Samba for example was not quite up to the task. The nss_ldap / pam_krb5 combination is pretty much distro agnostic and will just about always work.<br>
<br>- I am comfortable debugging Kerberos and LDAP issues, or at least I am much more comfortable debugging them than I am debugging Samba / Winbind issues; both protocols are well-known and well documented<br><br>- Kerberos and LDAP are native protocols and native authentication mechanisms; AD might be a bit quirky at times in it&#39;s implementation, I find it good enough to use a DC as it were an LDAP server and KDC, nothing more (which it basically is, of course), so why not use it that way?<br>
<br>- I find the fact that you need to assign UID&#39;s and GID&#39;s to groups a plus. Most of the time, only a minute subset of the users in AD need to be able to log into my Linux boxes. Having to manually edit accounts to grant people access to Linux boxes is a convenient way of separating Linux admins from other admins. Besides, like the control freak I am, I like to put Linux admins in one range of UID&#39;s, DBA&#39;s in another range, etc. :)<br>
<br>- I have seen winbind fail in too many, too exotic ways over the years.<br><br>- in my experience (but this is old experience, I admit that readily), using winbind gave a slow login sequence compared to nss_ldap and pam_krb5<br>
<br>By the way, the reason for me to start using sssd over nss_ldap / pam_krb5 is the fact that sssd can do ticket management for you and simplifies and centralizes configuration.<br><br>Keep up the good work!<br><br>Regards,<br>
<br><br clear="all">Maxim Burgerhout<br><a href="mailto:maxim@wzzrd.com" target="_blank">maxim@wzzrd.com</a><br>----------------<br>EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A<br><br><br>
<br><br><div class="gmail_quote">On Fri, Dec 2, 2011 at 15:08, Stephen Gallagher <span dir="ltr">&lt;<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
When we originally designed SSSD, we looked at it as a solution for<br>
dealing with LDAP and Kerberos identity and authentication for Linux and<br>
UNIX clients. With our initial approach, we decided to include only<br>
marginal support for Microsoft&#39;s Active Directory as a source of user<br>
information (only supporting it when it is enabled for use with<br>
posixAccount and posixGroup object classes).<br>
<br>
Our original assumption was that for complicated deployments relying on<br>
Active Directory, users would prefer to continue using Winbind. It has a<br>
very long history and is specifically designed around managing the<br>
peculiarities of Microsoft&#39;s LDAP implementation.<br>
<br>
Of late, it has become apparent that many users are opting to &quot;jump<br>
ship&quot; from winbind to SSSD for use with Active Directory. This has been<br>
shown by a sharp uptick in community bug reports with Active Directory<br>
servers.<br>
<br>
Up until now, our plans around Active Directory have circulated around<br>
including a &quot;Winbind Provider&quot; into SSSD, similar to the LDAP provider<br>
but making use of the original winbind features found in the Samba<br>
project. However, it&#39;s beginning to seem like users are expressing an<br>
interest to move AWAY from that solution.<br>
<br>
This may result in a change in our strategy going forward. I&#39;m looking<br>
for users to describe to us the reasons why they&#39;re choosing SSSD (in<br>
its current incarnation) over winbind. What I&#39;m trying to sort out is<br>
whether there are specific *issues* with winbind that SSSD is solving<br>
for users. In other words, I&#39;m trying to determine whether our decision<br>
to write and support a winbind provider backend is misplaced.<br>
<br>
It may be that if SSSD&#39;s LDAP provider is offering a significant<br>
advantage over winbind, we will consider dropping (or deferring) our<br>
efforts to integrate winbind and instead put that effort into adding<br>
Active Directory-specific features into the LDAP provider. For example,<br>
we might reprioritize bugs <a href="https://fedorahosted.org/sssd/ticket/995" target="_blank">https://fedorahosted.org/sssd/ticket/995</a> and<br>
<a href="https://fedorahosted.org/sssd/ticket/996" target="_blank">https://fedorahosted.org/sssd/ticket/996</a><br>
<br>
So please, share with us your stories for why you prefer SSSD over<br>
winbind and help us choose our direction for SSSD&#39;s future.<br>
<br>_______________________________________________<br>
Freeipa-interest mailing list<br>
<a href="mailto:Freeipa-interest@redhat.com">Freeipa-interest@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-interest" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-interest</a><br></blockquote></div><br>