Your experience parallels my own. I think the cases where winbind get used are
more political (and then maybe historical if the politics ever get sorted) in that AD
admins may not want to populate those extra fields in AD. It is crazy not to use AD as a
directory server if you can. It just makes sense to have a single source of this
information. Spreading it around leads to problems in the long run.
[sssd-devel-bounces(a)lists.fedorahosted.org] On Behalf Of Maxim Burgerhout
Sent: Saturday, December 03, 2011 2:39 AM
Subject: Re: [SSSD] [Freeipa-interest] IMPORTANT: Your input requested: SSSD LDAP Provider
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:
- in environments with several different flavors of Linux, it's wasn't always
possible to use Winbind the same way on all machines; RHEL3'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.
- 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
- Kerberos and LDAP are native protocols and native authentication mechanisms; AD might be
a bit quirky at times in it'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?
- I find the fact that you need to assign UID's and GID'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's, DBA's in another
range, etc. :)
- I have seen winbind fail in too many, too exotic ways over the years.
- 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
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.
Keep up the good work!
EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A
On Fri, Dec 2, 2011 at 15:08, Stephen Gallagher
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
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
So please, share with us your stories for why you prefer SSSD over
winbind and help us choose our direction for SSSD's future.
Freeipa-interest mailing list