On Wed, 11 Sep 2013, Simo Sorce wrote:
On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote:
On Sat, 07 Sep 2013, Simo Sorce wrote:
>On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote:
>> On Sat, 07 Sep 2013, Simo Sorce wrote:
>> >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote:
>> >> On Sat, 07 Sep 2013, Simo Sorce wrote:
>> >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote:
>> >> >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC |
>> >> >> + KERB_ENCTYPE_DES_CBC_MD5 |
>> >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 |
>> >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 |
>> >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96;
>> >> >
>> >> >Why are we hardcoding support for *DES* enctype, we disable DES by
>> >> >default and also Windows never uses it by default.
>> >> This is actually a copy of the same statement from
>> >> fill_pdb_trusted_domain().
>> >> Should I remove it?
>> >Yes please remove DES types, is there any chance we can make this list
>> >configurable ? (not a hard requirement, only if ti is something easy to
>> >do, maybe as a further enhancement down the road).
>> If you can point me to some place in cn=config or $SUFFIX that could be
>> read by cifs/fqdn on ipa-sam module init, I can look in fetching that.
>> But I suspect it is much harder to deduce exact list of supported types.
>there we have 2 lists:
>krbDefaultEncSaltTypes <- use this
>in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples()
>that can covert strings to enctypes.
>> >> RC4 enctype will be the only one available for
>> >> Windows 2003 trusts then...
>> >It's the only one 2003 enables by default anyway and the only one that
>> >we can use as DES is disabled on FreeIPA.
>> Since admin could enable DES on FreeIPA manually, right now ipa-sam
>> would allow using DES to Windows 2003. If we remove DES enctypes
>> unconditionally, it would not be possible.
>If you look at the attributes I pointed you at above, then you have a
>way to support DES by simply changing the defaults and restarting
>DES is dead anyway and not sufficiently secure for cross-realm keys
>anymore, even if we do not support it at all I think we are just fine.
Ok, attached three patches 0114-0116 is a new revision that implements also
fetching encryption types from the Kerberos configuration container.
The patches depend on each other in that order.
I think you should explictly add cn=<REALM.NAME> to the filter when
seraching the kerberos container in the 3rd patch.
But beyond that the patches look sane to me (I haven't tested them
I'm already searching on cn=<REALM.NAME>,cn=kerberos,$SUFFIX with a base
scope so this is pretty tight, no need to expand the filter.
(Simo agreed to this argument on IRC)
/ Alexander Bokovoy
Freeipa-devel mailing list