Bug 870173

I changed the component to krb5 because this is not related to ipa.

Please note, this is expected behavior and in fully agreement with the Kerberos RFCs.

The issue occurs because the Active Directory KDC handles the client principal in the TGT request case-insensitive and returns the canonical version of the principal, which might differ in case from the one in the request. The client program, kinit, correctly complains that a request for testuser1 returns information about testuser1. I think it is up to upstream to decide if an AD compatibility flag or config option can be added to a later version.

Scott, can you check that supplying kinit's -C flag, or setting "canonicalize = true" in the [libdefaults] section of /etc/krb5.conf, tells the client to accept the server's response?

Sumit, are you suggesting that canonicalization should be requested by default, or something else?

Nalin,

Do I need to test on RHEL7?  Or are you just looking for confirmation?

I see that behavior on an F19 VM with trust setup:

[root@f19-1 ~]# kinit -C aduser1.test
Password for aduser1.test: 

[root@f19-1 ~]# kinit aduser1.test
Password for aduser1.test: 
kinit: KDC reply did not match expectations while getting initial credentials

[root@f19-1 ~]# kinit aduser1.TEST
Password for aduser1.TEST: 

[root@f19-1 ~]# 

Thanks,
Scott

(In reply to Scott Poore from comment #6)
> Nalin,
> 
> Do I need to test on RHEL7?  Or are you just looking for confirmation?
> 
> I see that behavior on an F19 VM with trust setup:
> 
> [root@f19-1 ~]# kinit -C aduser1.test
> Password for aduser1.test: 
> 
> [root@f19-1 ~]# kinit aduser1.test
> Password for aduser1.test: 
> kinit: KDC reply did not match expectations while getting initial credentials
> 
> [root@f19-1 ~]# kinit aduser1.TEST
> Password for aduser1.TEST: 

Okay, that matches my understanding of how things work.  Sumit, are you looking for this to be changed?  If so, in what way?

Hi Nalin, no, I'm fine, I just thought that Scott expected plain kinit without the -C option to work too.

Sumit, Nalin, 

It was my expectation that there would be a way to run it without an arg and I also testing with "canonicalize = true" in krb5.conf which worked as well.  Would it be unreasonable to default to set that when ipa-adtrust-install is run?

Thanks,
Scott

I just run few tests and "canonicalize = true" worked fine.

It seems to me as something we should be setting for at least for AD domains. Given it needs to be run on all clients (i.e. setting it up in ipa-adtrust-install won't help)  connected to IPA, SSSD's krb5.conf include file seems to me as the right spot to set it. Adding Jakub to CC.

This configuration worked:

# cat /var/lib/sss/pubconf/krb5.include.d/domain_realm_martinovo_test
[domain_realm]
.my.domain = MY.DOMAIN
my.domain = MY.DOMAIN

[libdefaults]
  canonicalize = yes

# kinit mkosek
Password for mkosek: 
#

I am just thinking if it is OK to set this as a default for all realms. IMO it would be best to set it only for AD realm if we want to keep IPA kerberos case-sensitive. But I did not find a krb5.conf configuration to set it per-realm. Maybe a candidate for improvement in MIT KRB?

The sssd has krb5_canonicalize option that should already be true by default for IPA

Oh yeah, I see this when I put sssd into debug_level = 10 (in sssd.conf):


[root@cloud-qe-13 sssd]# grep -i krb5_canonicalize /var/log/sssd/*
/var/log/sssd/sssd_testrelm.com.log:(Mon Oct  7 13:58:34 2013) [sssd[be[testrelm.com]]] [dp_get_options] (0x0400): Option krb5_canonicalize is TRUE
/var/log/sssd/sssd_testrelm.com.log:(Mon Oct  7 13:58:34 2013) [sssd[be[testrelm.com]]] [dp_get_options] (0x0400): Option krb5_canonicalize is TRUE

So, that should do the same thing as updating krb5.conf or would kinit still need -C?

Thanks,
Scott

I'm quite certain that the options mean the same. What I'm not completely certain is whether this option is set for the trusted AD domain as well. I will run some local tests. Thanks for checking the debug output!

It seems that the trusted AD domain defaults to no canonicalization, both according to the Kerberos logs and the testing.

I admit my Kerberos knowledge is lacking here and Sumit or Nalin are better equipped to answer whether we should allow principal canonicalization by default for trusted AD domains..

IMHO we should. But I'd like to hear opinion from domain experts. If they agree, we should move this bug to sssd component and enable canonicalization as default.

yes, we should use canonicalization and enterprise principals for trusted AD domains as well,

Please note that this is all for sssd only kinit would still need the option in krb5.conf set. Nevertheless I'm not sure if we should set it by default because the AD use case mentioned above is somewhat special.

In general if the -C option is set a special flag will be set in the TGS request which asks the KDC to canonicalize the principal if possible. As a consequence the principal in the response might differ from the one in the request and with the option set the client accepts this change as well.

In the AD case even without the -C option the AD KDC canonicalizes the principal and we only need the option to tell the client to accept the change principal. (As a side note, although AD does an implicit canonicalization here when using enterprise principal where implicit canonicalization is expected, the flag must be set explicitly to get the expected result)

If a change is needed here at all I would prefer to ask upstream if a client side option can be introduced to make the client accept implicit canonicalization on the server.

Jakub, I think that sssd ticket shall be created :)

Nalin, what would you advise?

https://fedorahosted.org/sssd/ticket/2113

It'd be in violation of 4120, but 6806 changes the rules and doesn't appear to directly address referrals for clients in the same realm, so yeah, probably worth checking with upstream.  Based on how that goes for you, I'm prepared to either mark this UPSTREAM, roll it over to an update release, or WONTFIX it.

You mean checking with Kerberos upstream on a client specific option for canonicalization?  Or did I misunderstand Sumit's last comment?

If possible, I'd prefer this be left to roll it over to an update release when it becomes available in bz.  That was we can still track this. 

So, we should not be setting "canonicalize = yes" in /etc/krb5.conf for all clients?   I guess if upstream will not provide a client side option, and this shouldn't be enabled by default, can it be documented?  

I think the scope expanded a little here.  My original request was just concerning kinit.   Should I clone a separate BZ to track the sssd side of this?

Thanks,
Scott

(In reply to Scott Poore from comment #20)
> You mean checking with Kerberos upstream on a client specific option for
> canonicalization?  Or did I misunderstand Sumit's last comment?

Nalin, can you please file an upstream ticket?

> 
> If possible, I'd prefer this be left to roll it over to an update release
> when it becomes available in bz.  That was we can still track this. 

+1

> 
> So, we should not be setting "canonicalize = yes" in /etc/krb5.conf for all
> clients?   I guess if upstream will not provide a client side option, and
> this shouldn't be enabled by default, can it be documented?  

Nalin, please clarify.

> 
> I think the scope expanded a little here.  My original request was just
> concerning kinit.   Should I clone a separate BZ to track the sssd side of
> this?

I do not think we need to clone this one, https://fedorahosted.org/sssd/ticket/2113 can be cloned back to Bugzilla after a triage.

Hang on, what I'm seeing here is that kinit, which expects a principal name, is being handed a user name.  Generally, that's not expected to work unless canonicalization is enabled (which marks the supplied name as an enterprise name) and the KDC can map that name to a principal name.

If canonicalization isn't being requested, why is the KDC handing back a TGT rather than a client-principal-unknown error?  What's happening in the KDC's log and the directory server's access log while the KDC's processing the request?

Nalin,

Which comment (or link) are you referring to?  

Isn't aduser1.TEST the "principal" for the user (aduser1)?

Thanks,
Scott

(In reply to Nalin Dahyabhai from comment #22)
> Hang on, what I'm seeing here is that kinit, which expects a principal name,
> is being handed a user name.  Generally, that's not expected to work unless
> canonicalization is enabled (which marks the supplied name as an enterprise
> name) and the KDC can map that name to a principal name.
> 
> If canonicalization isn't being requested, why is the KDC handing back a TGT
> rather than a client-principal-unknown error?  What's happening in the KDC's
> log and the directory server's access log while the KDC's processing the
> request?

It's not a KDC it's AD :-). AD handles the principals case-insensitive (in violation of the related RFC). kinit can find the AD DC because DNS is case in-sensitive as well so looking up _kerberos._tcp.ad.domain or _kerberos._tcp.AD.DOMAIN will return the same SRV record. The request is then send with the argument from the command line (which should be a principal). Since AD handles the argument case in-sensitive it can find a related object in it's database but instead of using the same argument as in the request it put the canonical name/principal in the response. So AD canonicalize the name although it is not requested. As a result the response is not expected when kinit is run without -C.

(In reply to Scott Poore from comment #23)
> Nalin,
> 
> Which comment (or link) are you referring to?  
> 
> Isn't aduser1.TEST the "principal" for the user (aduser1)?

It is, yes, but I believe that "aduser1.test" (second attempt in comment #0) is not.

Sumit, your analysis makes sense.  But it sounds like the client's doing exactly what it's expected to do.

I do believe everything is working as expected and the krb5.conf "canonicalization" option does answer my original question.  It sounds like this cannot or should not be defined as default for all IPA Clients in an environment with an established AD trust.  

So, can we get this scenario documented?

Q:  How to allow AD users to use lower case realm names with ssh/login on IPA Clients?

A: On all IPA Clients needing this, set "canonicalization = true" in /etc/krb5.conf

And then in the future if other solutions are presented, the documents can be expanded/modified as necessary?