On 09/02/2015 02:32 PM, Simo Sorce wrote: > On Wed, 2015-09-02 at 14:19 +0200, Sumit Bose wrote: >> On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote: >>> On 09/01/2015 04:53 PM, Simo Sorce wrote: >>>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote: >>>>> Hi list, >>>>> >>>>> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 >>>>> and I would like to clarify what needs to be done in order to make IPA >>>>> to fully support multiple aliases per entry. >>>>> >>>>> So far I have identified these task based on the ticket comments and >>>>> discussion with Simo way back in the past: >>>>> >>>>> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is >>>>> not used in the new code. >>>>> >>>>> 2.) fix ACIs that do not permit setting multiple values of >>>>> 'krbPrincipalName' attribute per entry (see >>>>> https://fedorahosted.org/freeipa/ticket/3961) >>>>> >>>>> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and >>>>> 'ipadb_find_principal' functions) to correctly perform lookup of >>>>> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname >>>>> case-insensitively and krbcanonicalname case-sensitively, return >>>>> krbcanonicalname when canonicalization is requested. >>>>> >>>>> 4.) Modify KDB backend and IPA framework to handle creation of both >>>>> krbprincipalname and krbcanonicalname. I am not quite sure what cases >>>>> should be covered here (I remember that we should create >>>>> krbcanonicalname when we add another aliases to krbprincipalname), so it >>>>> would be nice if you could comment on this. >>>>> >>>>> 5.) write tests which cover all this stuff so that we don't shoot >>>>> ourselves in the foot. >>>>> >>>>> I am not very well versed in Kerberos so I might get some of this stuff >>>>> wrong. If that's the case please point me to the right direction. Also >>>>> please write me some additional stuff which I have fogot and needs to be >>>>> done. >>>>> >>>> >>>> I think the summary is correct, the only thing we need to be careful is >>>> to keep handling entries that have only a single valued krbprincipalname >>>> correctly as that will happen in upgrade paths and potentially if >>>> someone uses external tools. >>>> >>>> The tricky part for point 3 is to implement it *without* changing the >>>> schema. KrbPrincipalName is case-sensitive, however I think we can solve >>>> the issue of "searching case-insensitively" by always lower-casing the >>>> principal name components and always upper casing the realm part on >>>> storage. If we always store a krbCanonicalName we get the "correct" case >>>> there anyway so out mucking with the krbPrincipalName case will not be a >>>> problem for any new entry. >>>> >>>> This *may* cause issues with upgrades though, so we may need fallback >>>> code that searches with the case sent by the client if we determine the >>>> entry has no krbCanonicalName attribute (sign that it was created before >>>> we started adding krbCanonicalName and never "updated"). >>>> >>>> Note that we also need to think what will happen during and upgrade when >>>> some servers still use the current code and some servers will use the >>>> new code. So I guess it would be nice if you could write down a table >>>> with all possible forms a principal can be in on rows, and old/new >>>> server states in columns, and mark what will happen for various >>>> operations in each case. >>>> >>>> Simo. >>> >>> The list looks OK. Do we also plan to change the default RDN for new >>> services >>> or other objects that use krbPrincipalName as RDN at the moment? >>> >>> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and >>> then only allow krbPrincipalName to be added for the aliases. Of course, the >>> framework needs to still work with old services having krbPrincipalName. >> >> no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName >> is only optional according to the scheme. > > We might stropping using either and use CN instead for the RDN.
This would make changing krbPrincipalName that happens to be RDN much easier. Wouldn't this break software that depends on this RDN already? Like "ldapsearch -b "<principal>,cn=services,cn=accounts,SUFFIX"? Martin -- 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
