[SSSD] [PATCH] Add ldap_sasl_minssf option

Jan Zelený jzeleny at redhat.com
Wed Dec 7 16:52:45 UTC 2011


> On Wed, 2011-11-30 at 17:28 +0100, Jan Zelený wrote:
> > > On Wed, Nov 30, 2011 at 09:31:05AM -0500, Rob Crittenden wrote:
> > > > Jakub Hrozek wrote:
> > > > >On Tue, Nov 22, 2011 at 12:45:14PM +0100, Jan Zelený wrote:
> > > > >>https://fedorahosted.org/sssd/ticket/1075
> > > > >>
> > > > >>The only thing is that I'm not sure if 72 is the right default
> > > > >>minssf value for IPA provider, as default IPA installation works
> > > > >>with 56 as the highest possible value for me. In default SSSD
> > > > >>installation, this means that communication with IPA server will
> > > > >>be rejected with no information about the reason being min SSF. I
> > > > >>think this will be very confusing to SSSD users.
> > > > >>
> > > > >>Can anyone give me a hint how to proceed? Lower the default value
> > > > >>in SSSD or do the change in IPA?
> > > > >>
> > > > >>Thanks
> > > > >>Jan
> > > > >
> > > > >The patch itself looks good to me.
> > > > >
> > > > >I don't know what's causing the problem, though. I think that the
> > > > >SSF requirement is set in nsslapd-minssf attribute in cn=config on
> > > > >the server side. My (quite recent) IPA server install has the
> > > > >option set to 0, which means "no restrictions".
> > > > >
> > > > >Rob, is there any other place on the server that sets the SSF
> > > > >values?
> > > > 
> > > > Yes that is the right direction and the 389-ds and IPA default is 0.
> > > > There is a nsslapd-localssf option as well which I believe only
> > > > applies to ldapi.
> > > > 
> > > > rob
> > > 
> > > Ok, I'm confused now.
> > > 
> > > When I perform an GSSAPI search, ldapsearch reports "SASL SSF: 56".
> > > Where does it come from? Is there any override in cyrus-sasl perhaps?
> > > (The openldap source says the value comes from sasl_getprop(), I
> > > haven't looked deeper yet)
> > > 
> > > $ ldapsearch -Y GSSAPI -O "minssf=56" -b cn=example,dc=com uid=admin
> > > SASL/GSSAPI authentication started
> > > SASL username: host/ipa.example.com at EXAMPLE.COM
> > > SASL SSF: 56
> > > SASL data security layer installed.
> > > <LDIF follows>
> > > 
> > > Setting -O "minssf=$value" to anything above 56 then gives:
> > > SASL(-4): no mechanism available: No worthy mechs found
> > 
> > My suspicion was that IPA server doesn't offer encryption method stronger
> > than whatever SSF=56 means. In this context, perhaps no key strong
> > enough in the keytab?
> 
> GSSAPI offers stronger encryption. It looks like SASL and GSSAPI do not
> talk at some level and SASL always sets 56.
> 
> Simo.

Ok, I did some digging and it seems that cyrus-sasl doesn't detect MIT 
Kerberos bacause it is looking for a constant which is in private header file. 
Thanks to this, it sets the maximal possible value of SSF to 56, which is 
apparently supported by every Kerberos implementation, thus making it the 
largest possible value.

I talked with Nalin about this and his suggestion is to lower the default 
value in SSSD to 56 since the detection of 3DES (that's what is done in cyrus-
sasl) is only a guess and the value has only little relevance.

I'm sending a patch with the default value for IPA provider being 56.

Thanks
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jzeleny-072-1-minssf.patch
Type: text/x-patch
Size: 6869 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20111207/42792dde/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20111207/42792dde/attachment.sig>


More information about the sssd-devel mailing list