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?

- "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).

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





--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to