On Mon, 2015-09-07 at 09:20 +0200, David Kupka wrote: > On 04/09/15 12:49, thierry bordaz wrote: > > On 09/03/2015 04:03 PM, David Kupka wrote: > >> On 02/09/15 14:27, Simo Sorce wrote: > >>> On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote: > >>>> On 01/09/15 16:53, 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. > >>>> > >>>> Or as Honza pointed out we can use case-insensitive search like this: > >>>> (krbPrincipalName:caseIgnoreMatch:[email protected]). This will return > >>>> all variants of casing and reduce the need for fallback code. > >>> > >>> The principal name is not case insensitive, a search like that would > >>> probably cause DS to do a full search through the krbPrincipalName > >>> index, it might quickly become a performance issue. Before choosing a > >>> method please create an install with a 10000 principals, and then > >>> compare the speed of a few thousand search with exact matching case and > >>> a few with specifying caseIgnoreMatch and see the difference. > >>> > >>> Simo. > >> > >> We will add index for caseIgnoreCaseIA5Match matching rule on > >> krbPrincipalName and then the case insensitive match should be as > >> quick as the case sensitive. > >> > >> Without the index it is indeed far slower. I've generated 10k users > >> and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and > >> the nonindexed one ~2 minutes. That's by two orders of magnitude worse. > >> > >> When we tried to add the index into DS we uncovered a bug in the way > >> DS handles nsMatchingRule attributes. Thierry investigated it and is > >> filling the ticket for DS right now. Thierry can you please send link? > > > > The ticket is https://fedorahosted.org/389/ticket/48270. > > I think understand where the problem is but I have no fix yet. > > David, when you said the unindexed search was slow, did you index > > 'krbPrincipalName' but added a matching rule to your filter ? > > I would like to also verify the fix against that perf hit. > > > > thanks > > thierry > > I've tried these 3 searches: > > 1) ldapsearch -h localhost -D "cn=Directory Manager" -b > cn=users,cn=accounts,dc=example,dc=com -w freeipa8 > "(krbprincipalname:caseIgnoreIA5Match:[email protected])" > > 2) ldapsearch -h localhost -D "cn=Directory Manager" -b > cn=users,cn=accounts,dc=example,dc=com -w freeipa8 > "(krbprincipalname:caseExactIA5Match:[email protected])"' > > 3) ldapsearch -h localhost -D "cn=Directory Manager" -b > cn=users,cn=accounts,dc=example,dc=com -w freeipa8 > "([email protected])" > > The first two was slow and only the last one was quick.
Sounds like DS do a full search instead of indexed searches when you specify a matching rule ? We should either make sure DS can use indexed searches in this case or go with the plan I proposed earlier. 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
