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=cccc5a5a87a74cd434fbdf5e87c4158e21ebcf19
>         >
>         > [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