On Wed, Dec 07, 2011 at 06:48:31PM +0100, Jakub Hrozek wrote:
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@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?
either, or, check if there is another way cyrus-sasl might be reading the value?