[Freeipa-devel] [DESIGN] IPA client in AD DNS domain

[Petr Spacek]

On 24.5.2016 09:44, Alexander Bokovoy wrote:
> On Tue, 24 May 2016, Petr Spacek wrote:
>> On 24.5.2016 09:26, Alexander Bokovoy wrote:
>>> On Tue, 24 May 2016, Petr Spacek wrote:
>>>>>>>> Speaking of certs, should we introduce a aliases for host entries to
>>>>>>>> avoid
>>>>>>>> the
>>>>>>>> need of fake hosts?
>>>>>>> These 'fake hosts' are as good as aliases, even better, because they
>>>>>>> allow us to have full control over who can manage them.
>>>>>>
>>>>>> I do not see how this is different from any other object which has
>>>>>> managedBy
>>>>>> attribute. It is not a special property of host.
>>>>> We have managedBy handling in hosts and services specifically to allow
>>>>> certificate issuing on behalf of another entity.
>>>>
>>>> I'm still not convinced that 'we historically do it this way' is good enough
>>>> justification for using fake host objects instead of tailored aliases.
>>> I'm not sure it is good to add that. Note that host objects can be used
>>> to provide a lot more than just mere aliases:
>>> - they can have services associated, with both Kerberos keys and
>>>   certificates
>>> - they can be used to target HBAC rules against them which will be
>>>   extremely useful when we'll get Authentication Indicators management
>>>   in place
>>>
>>> Having "fake" host objects is also crucial for clustered services.
>>
>> Let me clarify this:
>> I'm not saying that we should drop host object completely.
>>
>> I'm saying that 1 host should have exactly 1 host object + 0..n alises
>> pointing to the host object.
>>
>> HBAC etc. can be set on the 'canonical' object, of course. Alias simply makes
>> possible to automate things like 'get certificate will all associated names in
>> SAN' etc. without manual procedures.
>>
>> This would make it easy to distinguish what is canonical name and what is mere
>> alias. That will get handy e.g. when a host is deleted - it would allow us to
>> delete all aliases with host etc.
> The latter is the only benefit I see here, sorry. The rest is not giving
> any real feature. If you want to have automated case for retrieving a
> certificate with all dNSName records, we can add this one specifically
> as an option to existing code to just follow managedBy -- CA has right
> to ignore anything in the certificate request already and issue what it
> thinks is right.
> 
>> Alternative technical approach is to add aliases to an host's attribute and
>> use it from there. I suspect that this would be less flexible and less
>> future-proof.
> I don't see a need for alias-as-a-property. Instead, I'm interested in
> having a possibility to have different keys, certificates, etc, on
> objects used as aliases. This improves security position by splitting
> the manager and the user of the resource.

I think that these two are not mutually exclusive.

a) If you need separate keys (and the headache associated with it) use a new
host object.
b) If you need to share keys use alias.
Aliases could have other advantages, e.g. using diffrent DNS checks to the
user does not need to use --force just to create the alias.

Right now we do not have the (b) option so code needs to use hacks like the
one you proposed above:
"we can add this one specifically as an option to existing code to just follow
managedBy"

This is simply a hack and relies on user not forgetting to add option
--follow-managed-by (e.g.) when requesting a certificate. Not speaking about
automated processes requesting certs which would need own heuristics to detect
when the option should be supplied.

I really do not like these ad-hoc hacks and I'm looking for a systematic solution.

-- 
Petr^2 Spacek