On Tue, Jul 30, 2013 at 4:24 PM, Dmitri Pal dpal@redhat.com wrote:
MSFT is just paranoid about it.
While you may be right, I think that an "ad" provider in SSSD implies that AD is supported no matter what configuration is being used on the server, especially if that configuration is "suggested" as indicated by the verbose log message.
I imagine that this functionality would only need a few more configuration parameters to work. Namely, ldap_tls_*, ldap_service_port, maybe a few others? I believe SSSD supports GSSAPI over SSL/TLS when the provider is LDAP, so, to me, it's a matter of giving more fine-grain control in the configuration file when the provider is AD.
-Chris
On Tue, 2013-07-30 at 16:42 -0400, Chris Hartman wrote:
On Tue, Jul 30, 2013 at 4:24 PM, Dmitri Pal dpal@redhat.com wrote: MSFT is just paranoid about it.
While you may be right, I think that an "ad" provider in SSSD implies that AD is supported no matter what configuration is being used on the server, especially if that configuration is "suggested" as indicated by the verbose log message.
I imagine that this functionality would only need a few more configuration parameters to work. Namely, ldap_tls_*, ldap_service_port, maybe a few others? I believe SSSD supports GSSAPI over SSL/TLS when the provider is LDAP, so, to me, it's a matter of giving more fine-grain control in the configuration file when the provider is AD.
The issue is indeed that the AD LDAP server is a bit literal in checking SASL options and does not 'keep in mind' that if confidentiality is negotiate integrity is also always performed.
This patch [1] in cyrus-sal gies us an option to make AD happy, however we do not enable it by default.
So this is both AD being a little bit stif as well as SSSD not taking advantage of an (admittedly obscure and undocumented) option SASL seem to make available.
So opened a RFE [2] so that we can turn this option on in the sssd_ad provider.
Simo.
[1] http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=cccc5a5a87a74...
[2] https://fedorahosted.org/sssd/ticket/2040
Simo.
On Tue, Jul 30, 2013 at 06:46:22PM -0400, Simo Sorce wrote:
On Tue, 2013-07-30 at 16:42 -0400, Chris Hartman wrote:
On Tue, Jul 30, 2013 at 4:24 PM, Dmitri Pal dpal@redhat.com wrote: MSFT is just paranoid about it.
While you may be right, I think that an "ad" provider in SSSD implies that AD is supported no matter what configuration is being used on the server, especially if that configuration is "suggested" as indicated by the verbose log message.
I imagine that this functionality would only need a few more configuration parameters to work. Namely, ldap_tls_*, ldap_service_port, maybe a few others? I believe SSSD supports GSSAPI over SSL/TLS when the provider is LDAP, so, to me, it's a matter of giving more fine-grain control in the configuration file when the provider is AD.
The issue is indeed that the AD LDAP server is a bit literal in checking SASL options and does not 'keep in mind' that if confidentiality is negotiate integrity is also always performed.
This patch [1] in cyrus-sal gies us an option to make AD happy, however we do not enable it by default.
So this is both AD being a little bit stif as well as SSSD not taking advantage of an (admittedly obscure and undocumented) option SASL seem to make available.
So opened a RFE [2] so that we can turn this option on in the sssd_ad provider.
Simo.
[1] http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=cccc5a5a87a74...
[2] https://fedorahosted.org/sssd/ticket/2040
Simo.
Hi Chris,
Simo kindly provided a patch that sets the cyrus-sasl option that might be helpful in your environment. Would you mind testing it out?
I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch for you to try out.
If you can build the test packages on Ubuntu yourself, that would be much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need.
[1] hopefully. I haven't tried backporting the patch but it looks easy enough.
Jakub,
I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch
for you to try out.
That'd be great, thanks! 64-bit would be best, please, but if that's an issue, I can spin up a 32-bit CentOS test machine easily enough.
If you can build the test packages on Ubuntu yourself, that would be
much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need.
I don't often patch source very often, but I THINK I know what to do. Just to make sure I understand, you want me to pull the source deb for libsasl2-2, recompile with Simo's patch, and then give authentication a go? Would I have to recompile SSSD as well?
-Chris
On Fri, Aug 2, 2013 at 11:38 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Tue, Jul 30, 2013 at 06:46:22PM -0400, Simo Sorce wrote:
On Tue, 2013-07-30 at 16:42 -0400, Chris Hartman wrote:
On Tue, Jul 30, 2013 at 4:24 PM, Dmitri Pal dpal@redhat.com wrote: MSFT is just paranoid about it.
While you may be right, I think that an "ad" provider in SSSD implies that AD is supported no matter what configuration is being used on the server, especially if that configuration is "suggested" as indicated by the verbose log message.
I imagine that this functionality would only need a few more configuration parameters to work. Namely, ldap_tls_*, ldap_service_port, maybe a few others? I believe SSSD supports GSSAPI over SSL/TLS when the provider is LDAP, so, to me, it's a matter of giving more fine-grain control in the configuration file when the provider is AD.
The issue is indeed that the AD LDAP server is a bit literal in checking SASL options and does not 'keep in mind' that if confidentiality is negotiate integrity is also always performed.
This patch [1] in cyrus-sal gies us an option to make AD happy, however we do not enable it by default.
So this is both AD being a little bit stif as well as SSSD not taking advantage of an (admittedly obscure and undocumented) option SASL seem to make available.
So opened a RFE [2] so that we can turn this option on in the sssd_ad provider.
Simo.
[1]
http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=cccc5a5a87a74...
[2] https://fedorahosted.org/sssd/ticket/2040
Simo.
Hi Chris,
Simo kindly provided a patch that sets the cyrus-sasl option that might be helpful in your environment. Would you mind testing it out?
I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch for you to try out.
If you can build the test packages on Ubuntu yourself, that would be much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need.
[1] hopefully. I haven't tried backporting the patch but it looks easy enough.
On Fri, 2013-08-02 at 12:20 -0400, Chris Hartman wrote:
Jakub,
I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch for you to try out.That'd be great, thanks! 64-bit would be best, please, but if that's an issue, I can spin up a 32-bit CentOS test machine easily enough.
If you can build the test packages on Ubuntu yourself, that would be much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need.I don't often patch source very often, but I THINK I know what to do. Just to make sure I understand, you want me to pull the source deb for libsasl2-2, recompile with Simo's patch, and then give authentication a go? Would I have to recompile SSSD as well?
Actually there are 2 patches here.
One is the SASL patch that has been upstream for a few years (I have not written it), but is not available in CentOS, so you'd have to revuild libsasl with that patch (assuming it applies cleanly).
The other is the SSSD patch I wrote and available here[*] that needs to be applied to the version of SSSD in CentOS (assuming it applies cleanly again) and rebuild sssd too.
I guess, just for trying it would be easier if you could use a Fedora 19 system. Then jakub could easily provide you precompiled sssd packages so you would not need to compile anything.
Simo.
[*] http://marc.info/?l=sssd-devel&m=137546010502921&w=2
On Fri, Aug 2, 2013 at 11:38 AM, Jakub Hrozek jhrozek@redhat.com wrote: On Tue, Jul 30, 2013 at 06:46:22PM -0400, Simo Sorce wrote: > On Tue, 2013-07-30 at 16:42 -0400, Chris Hartman wrote: > > On Tue, Jul 30, 2013 at 4:24 PM, Dmitri Pal dpal@redhat.com wrote: > > MSFT is just paranoid about it. > > > > > > While you may be right, I think that an "ad" provider in SSSD implies > > that AD is supported no matter what configuration is being used on the > > server, especially if that configuration is "suggested" as indicated > > by the verbose log message. > > > > > > I imagine that this functionality would only need a few more > > configuration parameters to work. Namely, ldap_tls_*, > > ldap_service_port, maybe a few others? I believe SSSD supports GSSAPI > > over SSL/TLS when the provider is LDAP, so, to me, it's a matter of > > giving more fine-grain control in the configuration file when the > > provider is AD. > > The issue is indeed that the AD LDAP server is a bit literal in checking > SASL options and does not 'keep in mind' that if confidentiality is > negotiate integrity is also always performed. > > This patch [1] in cyrus-sal gies us an option to make AD happy, however > we do not enable it by default. > > So this is both AD being a little bit stif as well as SSSD not taking > advantage of an (admittedly obscure and undocumented) option SASL seem > to make available. > > So opened a RFE [2] so that we can turn this option on in the sssd_ad > provider. > > Simo. > > [1] > http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=cccc5a5a87a74... > > [2] https://fedorahosted.org/sssd/ticket/2040 > > Simo. >
Hi Chris, Simo kindly provided a patch that sets the cyrus-sasl option that might be helpful in your environment. Would you mind testing it out? I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch for you to try out. If you can build the test packages on Ubuntu yourself, that would be much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need. [1] hopefully. I haven't tried backporting the patch but it looks easy enough.
I guess, just for trying it would be easier if you could use a Fedora 19 system. Then jakub could easily provide you precompiled sssd packages so you would not need to compile anything.
I don't mind compiling, but this *is* easier for me. When I get a chance, I'll do a quick 64-bit Fedora 19 install, then I can easily test whatever packages you might require.
Will post back when I've got something up and running.
-Chris
On Fri, Aug 2, 2013 at 3:57 PM, Simo Sorce simo@redhat.com wrote:
On Fri, 2013-08-02 at 12:20 -0400, Chris Hartman wrote:
Jakub,
I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch for you to try out.That'd be great, thanks! 64-bit would be best, please, but if that's an issue, I can spin up a 32-bit CentOS test machine easily enough.
If you can build the test packages on Ubuntu yourself, that would be much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need.I don't often patch source very often, but I THINK I know what to do. Just to make sure I understand, you want me to pull the source deb for libsasl2-2, recompile with Simo's patch, and then give authentication a go? Would I have to recompile SSSD as well?
Actually there are 2 patches here.
One is the SASL patch that has been upstream for a few years (I have not written it), but is not available in CentOS, so you'd have to revuild libsasl with that patch (assuming it applies cleanly).
The other is the SSSD patch I wrote and available here[*] that needs to be applied to the version of SSSD in CentOS (assuming it applies cleanly again) and rebuild sssd too.
I guess, just for trying it would be easier if you could use a Fedora 19 system. Then jakub could easily provide you precompiled sssd packages so you would not need to compile anything.
Simo.
[*] http://marc.info/?l=sssd-devel&m=137546010502921&w=2
On Fri, Aug 2, 2013 at 11:38 AM, Jakub Hrozek jhrozek@redhat.com wrote: On Tue, Jul 30, 2013 at 06:46:22PM -0400, Simo Sorce wrote: > On Tue, 2013-07-30 at 16:42 -0400, Chris Hartman wrote: > > On Tue, Jul 30, 2013 at 4:24 PM, Dmitri Pal dpal@redhat.com wrote: > > MSFT is just paranoid about it. > > > > > > While you may be right, I think that an "ad" provider in SSSD implies > > that AD is supported no matter what configuration is being used on the > > server, especially if that configuration is "suggested" as indicated > > by the verbose log message. > > > > > > I imagine that this functionality would only need a few more > > configuration parameters to work. Namely, ldap_tls_*, > > ldap_service_port, maybe a few others? I believe SSSD supports GSSAPI > > over SSL/TLS when the provider is LDAP, so, to me, it's a matter of > > giving more fine-grain control in the configuration file when the > > provider is AD. > > The issue is indeed that the AD LDAP server is a bit literal in checking > SASL options and does not 'keep in mind' that if confidentiality is > negotiate integrity is also always performed. > > This patch [1] in cyrus-sal gies us an option to make AD happy, however > we do not enable it by default. > > So this is both AD being a little bit stif as well as SSSD not taking > advantage of an (admittedly obscure and undocumented) option SASL seem > to make available. > > So opened a RFE [2] so that we can turn this option on in the sssd_ad > provider. > > Simo. > > [1] >
http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=cccc5a5a87a74...
> > [2] https://fedorahosted.org/sssd/ticket/2040 > > Simo. > Hi Chris, Simo kindly provided a patch that sets the cyrus-sasl option that might be helpful in your environment. Would you mind testing it out? I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch for you to try out. If you can build the test packages on Ubuntu yourself, that would be much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need. [1] hopefully. I haven't tried backporting the patch but it looks easy enough.-- Simo Sorce * Red Hat, Inc * New York
I've got a fully updated Fedora 19 system up and running. I've got authentication working identically to the rest of the domain.
[root@sssd ~]# uname -a
Linux sssd.domain.local 3.10.4-300.fc19.x86_64 #1 SMP Tue Jul 30 11:29:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
If someone can provide packages, I can provide test results :)
Thanks.
-Chris
On Fri, Aug 2, 2013 at 5:09 PM, Chris Hartman qrstuv@gmail.com wrote:
I guess, just for trying it would be easier if you could use a Fedora 19
system. Then jakub could easily provide you precompiled sssd packages so you would not need to compile anything.
I don't mind compiling, but this *is* easier for me. When I get a chance, I'll do a quick 64-bit Fedora 19 install, then I can easily test whatever packages you might require.
Will post back when I've got something up and running.
-Chris
On Fri, Aug 2, 2013 at 3:57 PM, Simo Sorce simo@redhat.com wrote:
On Fri, 2013-08-02 at 12:20 -0400, Chris Hartman wrote:
Jakub,
I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch for you to try out.That'd be great, thanks! 64-bit would be best, please, but if that's an issue, I can spin up a 32-bit CentOS test machine easily enough.
If you can build the test packages on Ubuntu yourself, that would be much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need.I don't often patch source very often, but I THINK I know what to do. Just to make sure I understand, you want me to pull the source deb for libsasl2-2, recompile with Simo's patch, and then give authentication a go? Would I have to recompile SSSD as well?
Actually there are 2 patches here.
One is the SASL patch that has been upstream for a few years (I have not written it), but is not available in CentOS, so you'd have to revuild libsasl with that patch (assuming it applies cleanly).
The other is the SSSD patch I wrote and available here[*] that needs to be applied to the version of SSSD in CentOS (assuming it applies cleanly again) and rebuild sssd too.
I guess, just for trying it would be easier if you could use a Fedora 19 system. Then jakub could easily provide you precompiled sssd packages so you would not need to compile anything.
Simo.
[*] http://marc.info/?l=sssd-devel&m=137546010502921&w=2
On Fri, Aug 2, 2013 at 11:38 AM, Jakub Hrozek jhrozek@redhat.com wrote: On Tue, Jul 30, 2013 at 06:46:22PM -0400, Simo Sorce wrote: > On Tue, 2013-07-30 at 16:42 -0400, Chris Hartman wrote: > > On Tue, Jul 30, 2013 at 4:24 PM, Dmitri Pal dpal@redhat.com wrote: > > MSFT is just paranoid about it. > > > > > > While you may be right, I think that an "ad" provider in SSSD implies > > that AD is supported no matter what configuration is being used on the > > server, especially if that configuration is "suggested" as indicated > > by the verbose log message. > > > > > > I imagine that this functionality would only need a few more > > configuration parameters to work. Namely, ldap_tls_*, > > ldap_service_port, maybe a few others? I believe SSSD supports GSSAPI > > over SSL/TLS when the provider is LDAP, so, to me, it's a matter of > > giving more fine-grain control in the configuration file when the > > provider is AD. > > The issue is indeed that the AD LDAP server is a bit literal in checking > SASL options and does not 'keep in mind' that if confidentiality is > negotiate integrity is also always performed. > > This patch [1] in cyrus-sal gies us an option to make AD happy, however > we do not enable it by default. > > So this is both AD being a little bit stif as well as SSSD not taking > advantage of an (admittedly obscure and undocumented) option SASL seem > to make available. > > So opened a RFE [2] so that we can turn this option on in the sssd_ad > provider. > > Simo. > > [1] >
http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=cccc5a5a87a74...
> > [2] https://fedorahosted.org/sssd/ticket/2040 > > Simo. > Hi Chris, Simo kindly provided a patch that sets the cyrus-sasl option that might be helpful in your environment. Would you mind testing it out? I can build you a test RPM of both SSSD and cyrus-sasl[1] with the patch for you to try out. If you can build the test packages on Ubuntu yourself, that would be much easier as 12.04 already contains cyrus-sasl-2.1.25 which supports the option we need. [1] hopefully. I haven't tried backporting the patch but it looks easy enough.-- Simo Sorce * Red Hat, Inc * New York
On Mon, Aug 05, 2013 at 12:11:44PM -0400, Chris Hartman wrote:
I've got a fully updated Fedora 19 system up and running. I've got authentication working identically to the rest of the domain.
[root@sssd ~]# uname -a
Linux sssd.domain.local 3.10.4-300.fc19.x86_64 #1 SMP Tue Jul 30 11:29:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
If someone can provide packages, I can provide test results :)
Thanks.
-Chris
Hi Chris, thank you for spending the time spinning up the test machine. Here are the F-19 test packages: http://koji.fedoraproject.org/koji/taskinfo?taskID=5783694
On Tue, Aug 6, 2013 at 8:07 AM, Jakub Hrozek jhrozek@redhat.com wrote:
Here are the F-19 test packages: http://koji.fedoraproject.org/koji/taskinfo?taskID=5783694
Success. The 64-bit packages work with my AD installation when server signing is required by the domain controller. SSSD debug output here: http://pastebin.com/B7D1WDm2. No error or notice messages were logged on the domain controller.
Do you need anything else tested? I'd be more than happy to maintain this test machine (and a 32-bit architecture) for future testing if the community finds it useful. Let me know.
Thanks.
-Chris
On Tue, Aug 06, 2013 at 11:28:47AM -0400, Chris Hartman wrote:
On Tue, Aug 6, 2013 at 8:07 AM, Jakub Hrozek jhrozek@redhat.com wrote:
Here are the F-19 test packages: http://koji.fedoraproject.org/koji/taskinfo?taskID=5783694
Success. The 64-bit packages work with my AD installation when server signing is required by the domain controller. SSSD debug output here: http://pastebin.com/B7D1WDm2. No error or notice messages were logged on the domain controller.
Ah, great! Thank you very much for testing Chris.
I will push Simo's patch upstream and open a openldap bug to track the real solution. We probably want to backport the sasl enhancement to RHEL6, too.
Do you need anything else tested? I'd be more than happy to maintain this test machine (and a 32-bit architecture) for future testing if the community finds it useful. Let me know.
I can't say no to more testing :-) Altough I don't have a specific use-case in mind right now. In general, reporting whenever something doesn't work for you would be really useful.
On Tue, Aug 06, 2013 at 06:39:12PM +0200, Jakub Hrozek wrote:
On Tue, Aug 06, 2013 at 11:28:47AM -0400, Chris Hartman wrote:
On Tue, Aug 6, 2013 at 8:07 AM, Jakub Hrozek jhrozek@redhat.com wrote:
Here are the F-19 test packages: http://koji.fedoraproject.org/koji/taskinfo?taskID=5783694
Success. The 64-bit packages work with my AD installation when server signing is required by the domain controller. SSSD debug output here: http://pastebin.com/B7D1WDm2. No error or notice messages were logged on the domain controller.
Ah, great! Thank you very much for testing Chris.
I will push Simo's patch upstream and open a openldap bug to track the real solution. We probably want to backport the sasl enhancement to RHEL6, too.
RHEL6 bug: https://bugzilla.redhat.com/show_bug.cgi?id=994242
sssd-users@lists.fedorahosted.org
-
Chris Hartman -
Jakub Hrozek -
Simo Sorce