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
and I would like to clarify what needs to be done in order to make
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

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
wrong. If that's the case please point me to the right direction.
please write me some additional stuff which I have fogot and needs
to be

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
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
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"
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:=ad...@example.com). 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.


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.


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:=user1005...@example.com)"

2) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname:caseExactIA5Match:=user1005...@example.com)"'

3) ldapsearch -h localhost -D "cn=Directory Manager" -b cn=users,cn=accounts,dc=example,dc=com -w freeipa8 "(krbprincipalname=user1005...@example.com)"

The first two was slow and only the last one was quick.

Once it's fixed we should be good.


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
entry has no krbCanonicalName attribute (sign that it was created
we started adding krbCanonicalName and never "updated").

Note that we also need to think what will happen during and upgrade
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.


David Kupka

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to