[Freeipa-devel] fixing Kerberos principal aliases handling in IPA

[Simo Sorce]

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