On Wed, 2015-09-02 at 14:36 +0200, Martin Kosek wrote: > 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"?
It would,. but so would a change to krbCanonicalName. If you need to change something we might as well go CN. Otherwise keep it as is, but I guess your worry is that the RDN becomes multivalued which is really a pain. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
