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

[Alexander Bokovoy]

On Tue, 24 May 2016, Petr Spacek wrote:
>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.
Well, nothing prevents you from adding 'ipa host-make-alias' command that
would essentially create a host and set managedBy to a proper existing
host, and would use internally a different DNS check. This would be
trivial. Given that enrollment code expects there is already a
pre-created host object (or it will be created with enough privileges),
we can then use it in ipa-client-install to clearly express CNAME case.

>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.
It is not an ad-hoc -- we already getting into situation that we have
three  different layers of permission checks on top of certificate
issuance -- managedBy to permit issuing a cert, CA ACLs to allow using a
specific certificate profile, and interpretation of cert request by CA.
Adding pure aliases into the mix is going to be 'interesting', while
making use of existing managedBy semantics is not complicating anything
here.

Don't also forget that people usually want to have aliases to allow use
of them by name at the edge -- i.e. in HBAC or SUDO rules. Adding an
alias concept means you'd need to make all of these (and HBAC/SUDO
aren't the only ones, actually) places to be modified, including client
software which is something you cannot change. To me aliases on objects
look like a huge pain.

If we want to have better management of co-related objects, then we
should improve the management, e.g. IPA framework. However, the objects
are there and their behavior expected to not change dramatically by the
client side.

>I really do not like these ad-hoc hacks and I'm looking for a systematic solution.
The solution you proposed is actually asking for a systematic
reshuffling of all client pieces. This is not going to happen, sorry.

I'd like to come back to the original topic, though. Aside from security
consideration section which I'm going to add today, I need to add 'how
to use' section with clear sequenced instructions.

Dmitri also asked for a different type of deployment when the host is
enrolled into both IPA and AD with and without different names.
While it is a possible case, I don't think we want to promote it as to
do it correctly we need to have a perfect AD deployment. This is not the
case for majority of customer networks I've saw, and what's more
important, there is no real gain from such deployment.

>
>-- 
>Petr^2 Spacek

-- 
/ Alexander Bokovoy