Skip Menu |
 

History Show all quoted text — Show full headers
# Fri May 24 16:15:36 2013 Sumit Bose <sbose@redhat.com> - Ticket created
Date: Fri, 24 May 2013 21:50:53 +0200
From: Sumit Bose <sbose@redhat.com>
To: krb5-bugs@mit.edu
Subject: PAC checksum verification failed with enterprise principals
Download (untitled) / with headers
text/plain 812B
Hi,

when using enterprise principals with Active Directory PAC verification
fails with the trace message "PAC checksum verification failed: -1765328250/Principal
user@EXAMPLE.COM has realm present".

I think the reason is that in k5_pac_validate_client() it is assume that
the KRB5_PAC_CLIENT_INFO buffer contains only a user name and no realm
component (KRB5_PRINCIPAL_PARSE_NO_REALM flag for
krb5_parse_name_flags()). Section 3.3.5.4.2.2 of the MS-KILE document
says that the cname should be used in the KRB5_PAC_CLIENT_INFO buffer.
But when using enterprise principals the cname includes a realm part.

It would be nice if k5_pac_validate_client() can be enhanced to handle
enterprise principals as well, because they are important in AD
envirionments with trusts and addtional domain suffixes.

bye,
Sumit
# Sat May 25 10:56:27 2013 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 300B
I think this is as simple as parsing with KRB5_PRINCIPAL_PARSE_ENTERPRISE
instead of KRB5_PRINCIPAL_PARSE_NO_REALM.

I'm a bit puzzled why there is an enterprise principal in a PAC client-
info buffer, though. I thought enterprise principals were for lookup,
while a PAC contains a canonical name.
# Mon May 27 05:18:37 2013 Sumit Bose <sbose@redhat.com> - Correspondence added
Date: Mon, 27 May 2013 11:18:34 +0200
From: Sumit Bose <sbose@redhat.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #7646] PAC checksum verification failed with enterprise principals
RT-Send-Cc:
Download (untitled) / with headers
text/plain 869B
On Sat, May 25, 2013 at 10:56:28AM -0400, Greg Hudson via RT wrote:
Show quoted text
> I think this is as simple as parsing with KRB5_PRINCIPAL_PARSE_ENTERPRISE
> instead of KRB5_PRINCIPAL_PARSE_NO_REALM.

yes, I think this would work, but only on clients where default_realm is
set in /etc/krb5.conf.

Show quoted text
>
> I'm a bit puzzled why there is an enterprise principal in a PAC client-
> info buffer, though. I thought enterprise principals were for lookup,
> while a PAC contains a canonical name.

Yes I thought so too. But since the client principal from the Kerberos ticket is
an enterprise principal as well (principal argument to
k5_pac_validate_client is of type KRB5_NT_ENTERPRISE_PRINCIPAL) and the
PAC-CLIENT-INFO buffer should be used to verify that PAC and client of
the ticket matches, I think it makes sense that cname form the
enterprise principal is used here.

bye,
Sumit
# Mon May 27 12:56:50 2013 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 307B
I guess we'd want to parse with KRB5_PRINCIPAL_PARSE_ENTERPRISE |
KRB5_PRINCIPAL_PARSE_IGNORE_REALM.

The presence of an enterprise principal in the ticket is just as
confusing to me as its presence in the PAC. But if these are being
issued by a real AD server, I won't argue with experimental evidence.
# Tue May 28 11:59:07 2013 Sumit Bose <sbose@redhat.com> - Comments added
Date: Tue, 28 May 2013 17:59:04 +0200
From: Sumit Bose <sbose@redhat.com>
To: Greg Hudson via RT <rt-comment@krbdev.mit.edu>
Subject: Re: [krbdev.mit.edu #7646] PAC checksum verification failed with enterprise principals
RT-Send-Cc:
Download (untitled) / with headers
text/plain 696B
On Mon, May 27, 2013 at 12:56:50PM -0400, Greg Hudson via RT wrote:
Show quoted text
> I guess we'd want to parse with KRB5_PRINCIPAL_PARSE_ENTERPRISE |
> KRB5_PRINCIPAL_PARSE_IGNORE_REALM.
>
> The presence of an enterprise principal in the ticket is just as
> confusing to me as its presence in the PAC. But if these are being
> issued by a real AD server, I won't argue with experimental evidence.

Sorry, but I think I used enterprise principals wrong and there is no
issue at all. I was under the assumption that the canonicalize flag is
automatically set when enterprise principals are use but this is
obviously not the case. If set everything is working as expected.

I think the ticket can be closed.
# Tue May 28 12:15:04 2013 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 371B
Huh. Our KDC always canonicalizes AS requests with request->client->type
== KRB5_NT_ENTERPRISE_PRINCIPAL (well, if the KDB module supports it),
and has a comment saying "according to the referrals draft we should
always canonicalize enterprise principal names." But perhaps AD doesn't
behave that way.

Anyway, closing the ticket. Thanks for investigating further.
# Tue May 28 12:15:18 2013 ghudson@mit.edu (Greg Hudson) - Status changed from 'new' to 'resolved'
# Tue May 28 12:15:18 2013 ghudson@mit.edu (Greg Hudson) - Tags nochange added