[Freeipa-devel] Kerberos over HTTPS (KDC proxy)

Petr Spacek pspacek at redhat.com
Thu May 28 08:16:26 UTC 2015


On 28.5.2015 07:42, Jan Cholasta wrote:
> Dne 27.5.2015 v 15:54 Simo Sorce napsal(a):
>> On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote:
>>> Dne 27.5.2015 v 15:43 Simo Sorce napsal(a):
>>>> On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote:
>>>>>>>
>>>>>>>      ipa config-mod --enable-kdcproxy=TRUE
>>>>>>>      ipa config-mod --enable-kdcproxy=FALSE
>>>>>
>>>>> I don't like this approach, as it is completely inconsistent with
>>>>> every
>>>>> other optional component. There should be *one* way to handle them
>>>>> and
>>>>> there already is one, no need to reinvent the wheel.
>>>>
>>>> Sorry Jan, but this is really the correct approach.
>>>
>>> I don't think so.
>>>
>>>>
>>>> We want a boolean in LDAP to control whether the IPA Domain allows
>>>> proxying or not, the code is embedded in the overall framework and has
>>>> no need for explicit install/uninstall unlike the CA or DNS components.
>>>
>>> There is a boolean for every other component/service as well. If you
>>> want to add new API to manipulate the boolean, fine, but it should be
>>> done in a generic way that works for other components as well.
>>
>> This is the same as:
>> ipa config-mod --enable-migration=TRUE
>>
>> Why is it a problem ?
> 
> This is a switch to enable the migrate-ds plugin. I think it's hardly fair to
> compare it to a whole new component which provides a new service to the
> outside world.
> 
>> This is not a separate service.
> 
> How is it not a separate service? If it's installed, MS-KKDCP is provided to
> the outside world, and if it's not installed MS-KKDCP is not provided to the
> outside world. How is this different from, say, DNS? (Besides implementation
> details, such as what protocols or how many daemons it uses - think about IPA
> as a black box for a moment.)

I very much agree with Honza - we have per-replica boolean for every service
so there is no reason not to have one for kdc proxy, especially when we
consider future containerization of services.

-- 
Petr^2 Spacek




More information about the Freeipa-devel mailing list