[Freeipa-devel] Please review: V4/AD user short names design draft

[Jan Cholasta]

On 1.3.2017 13:39, Martin Babinsky wrote:
> Alexander,
>
> thank you for your comments. Replies inline:
>
> On 02/28/2017 01:48 PM, Alexander Bokovoy wrote:
>> On ti, 28 helmi 2017, Martin Babinsky wrote:
>>> Hello list,
>>>
>>> I have put together a draft of design page describing server-side
>>> implementation of user short name -> fully-qualified name resolution.[1]
>>>
>>> In the end I have taken the liberty to change a few aspects of the
>>> design we have agreed on before and I will be grad if we can discuss
>>> them further.
>>>
>>> Me and Honza have discussed the object that should hold the domain
>>> resolution order and given the fact that IPA domain can also be a part
>>> of this list, we have decided that this information is no longer bound
>>> to trust configuration and should be a part of the global config
>>> instead.
>>>
>>> Also we have purposefully cut down the API only to a raw manipulation
>>> of the attribute using an option of `ipa config-mod`. The reasons for
>>> this are twofold:
>>>
>>>  * the developer resources are quite scarce and it may be good to
>>> follow YAGNI[2] principle to implement the dumbest API now and not to
>>> invest into more high-level interface unless there is a demand for it
>>>
>>>  * we can imagine that the manipulation of the domain resolution order
>>> is a rare operation (ideally only once all trusts are established), so
>>> I am not convinced that it is worth investing into designing
>>> higher-level API
>>>
>>> I propose we first develop the "dumber" parts first to unblock the
>>> SSSD part. If we have spare cycle afterwards then we can design and
>>> implement more bells-and-whistles afterwards.
>> Looks mostly OK, but there are few comments I have:
>>
>> - I do not see you mention how validation of the
>>  ipaDomainResolutionOrder is done. This is important to avoid hard to
>>  debug issues because SSSD will ignore domains it doesn't know about.
>>
>
> The validation is described in a Design section as follows:
>
> """
> Finally, any modification of the domain resolution order must ensure
> that each of the specified domain names corresponds either to that of
> FreeIPA domain or to one of the trusted AD domains stored in LDAP
> backend. In the case of trusted domains, the domain must not be marked
> as disabled.
> """
>
> Is this sufficient or is a more thorough validation required? Shall I
> split the whole section into sub-sections for easier navigation?
>
>> - Space separator initially caused me to look up DNS RFCs as strictly
>>  speaking domain names can contain any 8-bit octet (while host names
>>  should follow LDH rule). But then [1] does explicitly say space is not
>>  allowed in AD domain names.
>>
>
> I have discussed this with Jan and consulted the same document that you
> cited, that's why I have arrived to the conclusion to use whitespace as
> separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain
> names or should we consider other options to avoid breakage with more
> exotic domain names?

Actually I would prefer something else than whitespace as a separator. A 
':' maybe?

>
>> - "If ipaDomainResolutionOrder is empty then *all* users must use fully
>>  qualified names." This is not correct with regards to the current
>>  behavior. I think we should change this to "if
>>  ipaDomainResolutionOrder is empty, then standard SSSD configuration
>>  logic applies on each client." This would make current behavior
>>  compatible with either empty or ipaDomainResolutionOrder value of
>>  a single IPA domain name.
>>
>
> I have considered a empty attribute value to be a distinct state from
> the missing attribute and assigned a different semantic meaning to it.
>
> The reasoning is as follows: if the attribute is not set, SSSD will not
> retrieve it and this signals that it should continue operate in usual way.
>
> If the attribute is present but is empty, the semantics change slightly
> as now we consider *no* domains during short name resolution (extension
> of the missing domain behavior to the case of all domains are missing
> from list).

It doesn't have to be literally empty (LDAP character string syntaxes 
don't allow it anyway IIRC), there can be a value which denotes an empty 
list of domain (e.g. the separator alone).

>
> That is however open to discussion and I think we can even get away from
> this by letting SSSD guys to decide how to handle this case.
>
>> - There are typos in the page.
>>
>
> I know there was not much proofreading involved in this iteration. I
> have already tried to fix them.
>
>> [1]
>> https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers,-domains,-sites,-and-ous
>>
>>
>>
>>
>
>


-- 
Jan Cholasta