Bug 870173 - kerberos support for lower case AD trusted user
kerberos support for lower case AD trusted user
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: krb5 (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Nalin Dahyabhai
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-25 13:35 EDT by Scott Poore
Modified: 2014-07-03 08:43 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-03 08:43:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Poore 2012-10-25 13:35:18 EDT
Description of problem:

I have a cross domain trust set up in IPA environment with an AD Domain.  With ssh client, I can define the user's domain as either upper or lower case on the command line.  However, kinit appears to be case sensitive.

This is what I am seeing:

[root@rhel6-1 ~]# kinit testuser1@ADTESTDOM.COM
Password for testuser1@ADTESTDOM.COM:
[root@rhel6-1 ~]#
[root@rhel6-1 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: testuser1@ADTESTDOM.COM

Valid starting     Expires            Service principal
10/25/12 11:42:21  10/25/12 21:42:00  krbtgt/ADTESTDOM.COM@ADTESTDOM.COM
        renew until 10/26/12 11:42:21

And it does not work (because it's case sensitive?) when I use lower:

[root@rhel6-1 ~]# kinit testuser1@adtestdom.com
Password for testuser1@adtestdom.com:
kinit: KDC reply did not match expectations while getting initial credentials

Can libkrb5 be modified to support lower case domain

Version-Release number of selected component (if applicable):

ipa-server-3.0.0-105.20121019T0244zgita5684b0.el6.x86_64
krb5-workstation-1.10.3-6.el6.x86_64

How reproducible:
always


Steps to Reproduce:
1.  Setup IPA Master
2.  Setup AD Server
3.  Setup AD Cross Domain Trust from IPA to AD Domain.
4.  kinit Adminstrator@<ad.testdomain.com>

Actual results:
kinit: KDC reply did not match expectations while getting initial credentials

Expected results:
fully qualified user with lowercase domain on command line is authenticated.

Additional info:
Comment 3 Sumit Bose 2012-10-26 04:47:46 EDT
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@adtestdom.com returns information about testuser1@ADTESTDOM.COM. I think it is up to upstream to decide if an AD compatibility flag or config option can be added to a later version.
Comment 5 Nalin Dahyabhai 2013-07-16 10:36:59 EDT
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?
Comment 6 Scott Poore 2013-07-30 13:31:45 EDT
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@ad1.example.test
Password for aduser1@ad1.example.test: 

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

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

[root@f19-1 ~]# 

Thanks,
Scott
Comment 7 Nalin Dahyabhai 2013-07-30 14:16:55 EDT
(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@ad1.example.test
> Password for aduser1@ad1.example.test: 
> 
> [root@f19-1 ~]# kinit aduser1@ad1.example.test
> Password for aduser1@ad1.example.test: 
> kinit: KDC reply did not match expectations while getting initial credentials
> 
> [root@f19-1 ~]# kinit aduser1@AD1.EXAMPLE.TEST
> Password for aduser1@AD1.EXAMPLE.TEST: 

Okay, that matches my understanding of how things work.  Sumit, are you looking for this to be changed?  If so, in what way?
Comment 8 Sumit Bose 2013-07-31 10:22:02 EDT
Hi Nalin, no, I'm fine, I just thought that Scott expected plain kinit without the -C option to work too.
Comment 9 Scott Poore 2013-08-01 09:34:23 EDT
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
Comment 10 Martin Kosek 2013-10-07 02:50:28 EDT
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@my.domain
Password for mkosek@my.domain: 
#

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?
Comment 11 Jakub Hrozek 2013-10-07 04:28:19 EDT
The sssd has krb5_canonicalize option that should already be true by default for IPA
Comment 12 Scott Poore 2013-10-07 14:02:18 EDT
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
Comment 13 Jakub Hrozek 2013-10-07 16:17:18 EDT
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!
Comment 14 Jakub Hrozek 2013-10-07 16:55:31 EDT
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..
Comment 15 Martin Kosek 2013-10-08 02:40:50 EDT
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.
Comment 16 Sumit Bose 2013-10-08 03:08:40 EDT
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.
Comment 17 Martin Kosek 2013-10-08 03:15:49 EDT
Jakub, I think that sssd ticket shall be created :)

Nalin, what would you advise?
Comment 18 Jakub Hrozek 2013-10-08 05:20:05 EDT
https://fedorahosted.org/sssd/ticket/2113
Comment 19 Nalin Dahyabhai 2013-10-15 12:12:09 EDT
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.
Comment 20 Scott Poore 2013-10-15 13:32:33 EDT
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
Comment 21 Martin Kosek 2013-10-16 03:40:44 EDT
(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.
Comment 22 Nalin Dahyabhai 2013-11-18 14:03:49 EST
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?
Comment 23 Scott Poore 2013-11-18 20:43:07 EST
Nalin,

Which comment (or link) are you referring to?  

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

Thanks,
Scott
Comment 24 Sumit Bose 2013-11-19 03:37:32 EST
(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.
Comment 25 Nalin Dahyabhai 2013-11-19 09:31:22 EST
(In reply to Scott Poore from comment #23)
> Nalin,
> 
> Which comment (or link) are you referring to?  
> 
> Isn't aduser1@AD1.EXAMPLE.TEST the "principal" for the user (aduser1)?

It is, yes, but I believe that "aduser1@ad1.example.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.
Comment 26 Scott Poore 2013-11-20 11:27:50 EST
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?

Note You need to log in before you can comment on or make changes to this bug.