[SSSD] [PATCH] Add ldap_sasl_minssf option

Jakub Hrozek jhrozek at redhat.com
Wed Dec 7 17:48:31 UTC 2011


On Wed, Dec 07, 2011 at 05:52:45PM +0100, Jan Zelený wrote:
> > 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

The patch itself is OK, ack

Can you either open a bug against MIT Kerberos to expose this value?



More information about the sssd-devel mailing list