On Wed, 2015-09-02 at 14:44 +0200, Martin Kosek wrote: > On 09/02/2015 02:38 PM, Simo Sorce wrote: > > 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. > > Yes, this is the worry. I think we want to avoid issues with having to rename > the whole object just because we are changing the alias. > > Using krbCanonicalName as default RDN always and then only allowing users to > play with krbPrincipalName seemed as the most easy way long-term, but if CN is > easier, I am fine with that.
If we are all ok with krbCanonicalName I am fine with that too, CN is just shorter to type :) 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
