#1164 [RFE] prefer krbcanonicalname to krbprincipalname
Closed: wontfix 4 years ago by pbrezina. Opened 12 years ago by nalin.

In a directory-backed KDC using the MIT schema, krbprincipalname can be multi-valued.

If a client's entry does not contain a krbcanonicalname value, then an AS request specifying any of the principal names as the client should work as well as any other -- whether the AS request contains the "canonicalize" option or not doesn't matter. TGTs obtained in this scenario are issued using the requested client name.

However, if the client's entry also contains a krbcanonicalname value (the copy of the schema that I have says that this is single-valued), an AS request specifying a client name other than the krbcanonicalname value will only succeed if the AS request includes the "canonicalize" option. Requests which specify the krbcanonicalname value as the client will succeed whether the "canonicalize" option is set or not. TGTs obtained in this scenario are issued using the name which is stored in the krbcanonicalname attribute.

So I think the simplest thing to do is to also check for the presence of a krbcanonicalname attribute, and if one is found, use that in preference to any krbprincipalname attribute values when deriving the client user's principal name.


I'm not sure that this is the best solution. In particular I'm thinking about using something like proxy provider for ID or using LDAP server not in sync with the one used by KDC (yes, it's not a reasonable configuration, but it could happen). Is there any specific status code returned from KDC when this happens? I think we could just detect that and attempt a second request with "canonicalize" option set.

Shouldn't we simply always canonicalize ?

As I understand it, some older versions of the KDC (such as that shipped with RHEL 5) do not support the canonicalization protocol option.

We can provide an option to disable canonicalization in that case, and the user can remap the user_principal ldap attribute to krb5canonicalname in that case.

In either case I would just add a FAQ about changing the attribute in the conf to point from krbPrincipalName -> KrbCanonicalName if you can't turn on canonicalization and still are using aliases at the same time (very unlikely you do both).

Replying to [comment:1 jzeleny]:

Is there any specific status code returned from KDC when this happens?

When the KDC's LDAP layer locates an entry with a matching krbPrincipalName attribute, but with a krbCanonicalName attribute that differs from the client's name, when the canonicalize option is not set, the entry is discarded and the client receives an client-principal-unknown error.

Replying to [comment:3 sgallagh]:

As I understand it, some older versions of the KDC (such as that shipped with RHEL 5) do not support the canonicalization protocol option.

Versions which did this were 1.2 and earlier, so KDCs on RHEL 2.1 and RHEL 3 were affected. 4 and 5 should be fine.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.10 beta

Fields changed

milestone: SSSD 1.10 beta => SSSD Kerberos Improvements Feature
proposed_priority: => Core

Replying to [comment:6 nalin]:

Replying to [comment:3 sgallagh]:

As I understand it, some older versions of the KDC (such as that shipped with RHEL 5) do not support the canonicalization protocol option.

Versions which did this were 1.2 and earlier, so KDCs on RHEL 2.1 and RHEL 3 were affected. 4 and 5 should be fine.

Based on this it should be safe to always canonicalize.

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: SSSD Kerberos Improvements Feature => SSSD 1.10 beta

Fields changed

priority: major => critical

Fields changed

design: =>
design_review: => 0
fedora_test_page: =>
summary: prefer krbcanonicalname to krbprincipalname => [RFE] prefer krbcanonicalname to krbprincipalname

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Nice to have for 1.12

changelog: =>
milestone: SSSD 1.12 beta => Interim Bucket
priority: critical => minor
review: => 0

Fields changed

milestone: Interim Bucket => SSSD 1.12 beta

Fields changed

milestone: SSSD 1.12 beta => SSSD 1.13 beta

Fields changed

mark: => 0

Fields changed

milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: minor => trivial

Mass-moving tickets not planned for any immediate release and re-setting priority.

milestone: SSSD 1.13 backlog => SSSD Deferred
priority: trivial => major

Metadata Update from @nalin:
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2206

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata