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.
On Fri, 2 Dec 2011, Stephen Gallagher wrote:
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. So we ended up with a second prcoess that watched it and tried to restart it, clearing the caches and reseeding the cache when it happened. Performance was never as good or as reliable as an internally tweaked nss_ldap setup with nscd.
nss_ldap however can't cope with large nested groups in an efficient way, and nscd isn't the most loved daemon in these parts (although it's much better 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.
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.
I looked at switching to SSSD as I wanted to get away from custom site-specific performance hacks for nss_ldap, and wanted a proper ldap-aware caching setup. SSSD isn't perfect performance wise, but it's moving in the right direction, we've had fewer stability problems than with winbind even thought it's relatively immature and the developers have been highly 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.
If the last patch gets rid of my remaining SEGV with sssd_be, pretty much the *only* thing on my list is performance improvements.
jh
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,
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!
Regards,
Maxim Burgerhout maxim@wzzrd.com ---------------- EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A
On Fri, Dec 2, 2011 at 15:08, Stephen Gallagher sgallagh@redhat.com 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-interest mailing list Freeipa-interest@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-interest
Darn. That was the 'Send' button instead of the 'Save Now' :(
My previous email wasn't the version that I intended to send to the list; I had some proofreading to do and I was just writing down things as they came to mind. Sorry if not everything is crystal clear :P
Maxim Burgerhout maxim@wzzrd.com ---------------- EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A
On Fri, Dec 2, 2011 at 17:39, Maxim Burgerhout maxim@wzzrd.com wrote:
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!
Regards,
Maxim Burgerhout maxim@wzzrd.com
EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A
On Fri, Dec 2, 2011 at 15:08, Stephen Gallagher sgallagh@redhat.comwrote:
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-interest mailing list Freeipa-interest@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-interest
Hi Maxim, 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.
Cheers,
Greg ________________________________________ From: sssd-devel-bounces@lists.fedorahosted.org [sssd-devel-bounces@lists.fedorahosted.org] On Behalf Of Maxim Burgerhout [maxim@wzzrd.com] Sent: Saturday, December 03, 2011 2:39 AM To: sssd-devel@lists.fedorahosted.org Subject: Re: [SSSD] [Freeipa-interest] IMPORTANT: Your input requested: SSSD LDAP Provider vs Winbind
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!
Regards,
Maxim Burgerhout maxim@wzzrd.commailto:maxim@wzzrd.com ---------------- EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A
On Fri, Dec 2, 2011 at 15:08, Stephen Gallagher <sgallagh@redhat.commailto:sgallagh@redhat.com> 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-interest mailing list Freeipa-interest@redhat.commailto:Freeipa-interest@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-interest
Hi,
What about strategic reasons and not tactical ones?
I know this may not be the case in this instance, but, personally I hate doing short term "mangles" to make things work....I'd much rather bite the bullet and go for a "better" long term engineered solution...I find doing things that way doesnt come back to bite me....usually at 2am........
;]
regards
Steven Jones
Technical Specialist - Linux RHCE
Victoria University, Wellington, NZ
0064 4 463 6272
On 12/04/2011 02:08 PM, Steven Jones wrote:
Hi,
What about strategic reasons and not tactical ones?
I know this may not be the case in this instance, but, personally I hate doing short term "mangles" to make things work....I'd much rather bite the bullet and go for a "better" long term engineered solution...I find doing things that way doesnt come back to bite me....usually at 2am........
Is this a vote of confidence to SSSD? It is unclear which you prefer based on your reply.
;]
regards
Steven Jones
Technical Specialist - Linux RHCE
Victoria University, Wellington, NZ
0064 4 463 6272 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Greg Lehmann -
John Hodrien -
Marko Myllynen -
Maxim Burgerhout -
Stephen Gallagher -
Steven Jones