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. bye, Sumit > > -- > 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 -- 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