[Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request

Sumit Bose sbose at redhat.com
Tue Jul 21 12:28:44 UTC 2015


On Tue, Jul 21, 2015 at 01:41:14PM +0200, Sumit Bose wrote:
> Hi,
> 
> this patch is my suggestion to solve
> https://fedorahosted.org/freeipa/ticket/4844 .
> 
> The original issue in the ticket has two part. One is a loop in libkrb5
> which is already fixed. The other is to handle canonicalization better.
> 
> The general way to allow canonicalization on a principal is to add the
> attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together
> with the objectclass 'ipaKrbPrincipal' to the user object. Then the IPA
> KDB backend will use 'ipakrbprincipalalias' for case in-sensitive
> matches and  the principal from 'krbcanonicalname' will be the canonical
> principal used further on. The 'krbPrincipalName' is not suitable for
> either because it has caseExact* matching rules and is a multivalue
> attribute [2].
> 
> What I got from the comments in the ticket and the related bugzilla
> ticket is that it should be possible to get a TGT for a user even if the
> realm is given in lower-case if canonicalization is enabled. Please note
> that the client can only send such request because we have
> 'dns_lookup_kdc = true' in krb.conf and DNS is case in-sensitive. If you
> set 'dns_lookup_kdc = false' the client will fail immediately without
> sending a request at all, because it is not able to find a KDC for the
> lower-case realm.
> 
> On the server-side the request is processed because of
> http://k5wiki.kerberos.org/wiki/Projects/Aliases which made parts of
> processing case in-sensitive.
> 
> With the attached patch a second lookup is done if the lookup with the
> original input returned no result, canonicalization is
> enabled and the realm from the original input matches the IPA realm case
> in-sensitive. For the second lookup the realm is replace with the IPA
> realm. This approach adds a bit redundant code but does not add extra
> processing requests which would be successful before.
> 
> Without the patch
> kinit    ipauser at IPA.REALM -> success
> kinit -C ipauser at IPA.REALM -> success
> kinit    ipauser at ipa.realm -> failure
> kinit -C ipauser at ipa.realm -> failure
> 
> With the patch
> kinit    ipauser at IPA.REALM -> success
> kinit -C ipauser at IPA.REALM -> success
> kinit    ipauser at ipa.realm -> success

ah, sorry, copy-and-paste error, this will of course still fail. Even if
we would automatically canonicalize it on the server the client wouldn't
accept the changed principal without the -C option.

bye,
Sumit


> kinit -C ipauser at ipa.realm -> success
> 
> where 'ipa.realm' can be replace by mixed case version like 'iPa.ReAlM'
> as well.
> 
> bye,
> Sumit
> 
> [1] I was not able to add 'krbcanonicalname' as admin user because of an
> ACI denial. I wonder if this is expected or if the ACI rules should be
> extended here?
> 
> [2] We might to skip the requirement that 'krbcanonicalname' must exists
> if 'ipaKrbPrincipal' only has a single value but canonicalization will
> fail immediately if someone adds a second value so I guess it would be
> more safe to keep it as it is.
> 




More information about the Freeipa-devel mailing list