[Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created

Petr Viktorin pviktori at redhat.com
Fri Sep 20 08:04:00 UTC 2013


On 09/20/2013 09:23 AM, Tomas Babej wrote:
> On 09/11/2013 09:12 PM, Alexander Bokovoy wrote:
>> 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.
>>>> >
>>>> >Look in:
>>>> >cn=REALM.NAME,cn=kerberos,$SUFFIX
>>>> >
>>>> >there we have 2 lists:
>>>> >krbDefaultEncSaltTypes  <- use this
>>>> >krbSupportedEncSaltTypes
>>>> >
>>>> >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
>>>> >FreeIPA.
>>>> >
>>>> >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
>>> though).
>> 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)
>>
>
> ACK
>

Pushed to:
master: a9843d6918f73c2236d0083b1e8adf54ca34eb0d
ipa-3-3: de5ec4fbd916c52e7474f1e4dae3b69c80eb497a


-- 
Petr³




More information about the Freeipa-devel mailing list