Discussion:
IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind
(too old to reply)
Stephen Gallagher
2011-12-02 14:15:32 UTC
Permalink
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.
Ondrej Valousek
2011-12-02 14:36:26 UTC
Permalink
My story is here:

https://bugzilla.redhat.com/show_bug.cgi?id=652609

And it seems to go nowhere. So, in quick - I still believe winbind is a piece of crap really (Simo forgives) for the reasons outlined above
in the link.
For the same reasons I believe you, SSSD engineers, are wasting your time with the winbind plugin.
If configured properly, sssd can do a much better job.

Now I do not know how much AD differs from the IPA domain from the SSSD prospective - so I do not know how much extra work is needed to be
able to properly cope with AD, but I still believe some of the code can be later re-used for pure IPA domains (see the AD sites in DNS for
example).

So in short again, I think SSSD should continue to concentrate its main effort in the IPA integration because we (Linux community) currently
do not have anything else to match Active Directory - and if we get an SSSD-AD integration as a side-effect, well, a nice bonus! :-)

Ondrej




On 12/02/2011 03:15 PM, Stephen Gallagher wrote:
> 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.
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: ***@s3group.com.
Thank You.
Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
Ondrej Valousek
2011-12-02 14:59:19 UTC
Permalink
Small update so I am not only throwing dirt on winbind:

Winbind has still its use if you can not use / do not have RFC2307 attributes in AD.
So simply, if you want to use RFC2307 attributes, sssd is here for you. If not, go for winbind. But yet I would not bother about winbind
plugin for sssd as it does not make too much sense - that's why we have Glibc and its /etc/nsswitch.conf!

My 5 cents.
Ondrej

On 12/02/2011 03:36 PM, Ondrej Valousek wrote:
> My story is here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=652609
>
> And it seems to go nowhere. So, in quick - I still believe winbind is a piece of crap really (Simo forgives) for the reasons outlined
> above in the link.
> For the same reasons I believe you, SSSD engineers, are wasting your time with the winbind plugin.
> If configured properly, sssd can do a much better job.
>
> Now I do not know how much AD differs from the IPA domain from the SSSD prospective - so I do not know how much extra work is needed to be
> able to properly cope with AD, but I still believe some of the code can be later re-used for pure IPA domains (see the AD sites in DNS for
> example).
>
> So in short again, I think SSSD should continue to concentrate its main effort in the IPA integration because we (Linux community)
> currently do not have anything else to match Active Directory - and if we get an SSSD-AD integration as a side-effect, well, a nice bonus!
> :-)
>
> Ondrej
>
>
>
>
> On 12/02/2011 03:15 PM, Stephen Gallagher wrote:
>> 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 bugshttps://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.
>>
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-***@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
> --------------------------------------------------------------------------------------------------------------------------------------------
> The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended
> recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part
> thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from
> your computer system(s). Please direct any additional queries to: ***@s3group.com. Thank You. Silicon and Software Systems
> Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18
> --------------------------------------------------------------------------------------------------------------------------------------------
>
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-***@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: ***@s3group.com.
Thank You.
Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
Stephen Gallagher
2011-12-02 15:06:43 UTC
Permalink
On Fri, 2011-12-02 at 15:59 +0100, Ondrej Valousek wrote:
> Small update so I am not only throwing dirt on winbind:
>
> Winbind has still its use if you can not use / do not have RFC2307
> attributes in AD.
> So simply, if you want to use RFC2307 attributes, sssd is here for
> you. If not, go for winbind. But yet I would not bother about winbind
> plugin for sssd as it does not make too much sense - that's why we
> have Glibc and its /etc/nsswitch.conf!

Well, just to make one point, there are a few advantages to the winbind
backend over pure winbind:

1) SSSD caching instead of nscd
2) Support for multiple AD domains without trust
3) One-to-one mapping of identity domain to authentication domain (so
you're not exposing your password to multiple authentication domains
until you find the right one, as with traditional PAM).
Ondrej Valousek
2011-12-02 15:26:41 UTC
Permalink
On 12/02/2011 04:06 PM, Stephen Gallagher wrote:
> 1) SSSD caching instead of nscd
Winbind has its own cache. We do not want to implement the yet another one causing confusion, do we?
> 2) Support for multiple AD domains without trust
If needed, winbind itself should provide this functionality.
> 3) One-to-one mapping of identity domain to authentication domain (so
> you're not exposing your password to multiple authentication domains
> until you find the right one, as with traditional PAM).
Yes, That's true, but honestly, who is using it, is it worth the effort?

I am not saying no, of course, everything has its own special use. What I think that we need is the *simplicity*. We need to have a clear
and simple rules where to go if windows/ipa/... backend is needed. Most system admins see sssd as a cleverer libnss_ldap.so provider - and
that is how it should stay, I believe....

Ondrej


The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: ***@s3group.com.
Thank You.
Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
Simo Sorce
2011-12-02 15:50:49 UTC
Permalink
On Fri, 2011-12-02 at 10:06 -0500, Stephen Gallagher wrote:
> On Fri, 2011-12-02 at 15:59 +0100, Ondrej Valousek wrote:
> > Small update so I am not only throwing dirt on winbind:
> >
> > Winbind has still its use if you can not use / do not have RFC2307
> > attributes in AD.
> > So simply, if you want to use RFC2307 attributes, sssd is here for
> > you. If not, go for winbind. But yet I would not bother about winbind
> > plugin for sssd as it does not make too much sense - that's why we
> > have Glibc and its /etc/nsswitch.conf!
>
> Well, just to make one point, there are a few advantages to the winbind
> backend over pure winbind:
>
> 1) SSSD caching instead of nscd

Winbindd has its own caching and nscd use is not recommend with Winbindd
either.

> 2) Support for multiple AD domains without trust

But complete lack of support of multiple trusted domains which is
extremely common on Windows networks.

> 3) One-to-one mapping of identity domain to authentication domain (so
> you're not exposing your password to multiple authentication domains
> until you find the right one, as with traditional PAM).

Well this is interesting only if you have multiple unrelated identity
domains to care about, I wouldn't count this as something better/worse
than what Winbindd provides, Winbindd is clearly built for a single Ad
domain which is the norm and the point is already captured in 2.

4) Winbindd can use MS-RPC to handle legacy NT/Samba3 domains and NTLM
authentication. SSSD has no support for any of that nor Site discovery
ala Windows way etc ...


I do not want to say one is better than the other, they are different.

When I architected SSSD I was full aware of both Winbind limitations and
good features. The point is that AD domain support was not a goal for
SSSD and so it was not built to support multiple trusted domain through
one provider or Windows like domains.

This is changing to some degree so SSSD may grow that ability.

I am neutral to whether we should integrate winbindd through a plugin or
re-implement its functionality, I can see positive and negative aspects
in both approaches and I really do not have a strong preference at this
stage.

Simo.

--
Simo Sorce * Red Hat, Inc * New York
Steven Jones
2011-12-04 19:50:42 UTC
Permalink
Hi,

Oh I dont know about that......

We have at least 4 AD domains controlled by "me" (central IT) and at least 3 ADs on the edge, as schools want to "do their own thing".......then there is at least one Mac LDAP and one OpenLDAP...and that's the ones I know of.....

So my job is to glue this all together and make it work with all the disparate hardware..........securely and seemlessly...........oh joy

I must have been a VERY bad person in my last life....

;]

8><------

Winbindd is clearly built for a single Ad
domain which is the norm and the point is already captured in 2.

8><---------


regards

Steven Jones

Technical Specialist - Linux RHCE

Victoria University, Wellington, NZ

0064 4 463 6272
Continue reading on narkive:
Loading...