The PAC must be the first ad-element

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

The PAC must be the first ad-element

Isaac Boukris
Hi,

When I recently confirmed that windows hosts have no problem with
other ad-elements along side the PAC, I was  lazy to test change of
order. Today I tested it and found that Windows servers are not happy
when the PAC is not the first ad-if-relevant element.

The error is somewhat tricky, since the ldap bind succeeds using the
ticket, but subsequent search call fails with (see more details in:
https://pagure.io/freeipa/issue/8185):
"In order to perform this operation a successful bind must be
completed on the connection"

Technically the current KDC code looks alright, although maybe I'll
add a code comment and a test for it. But Alexander pointed out that
previous KDC code in v1.17 is not good as it would place CAMMAC as
first element (fixed in 7196c03f18f14695abeb5ae4923004469b172f0f).

https://github.com/krb5/krb5/blob/master/src/kdc/kdc_authdata.c#L849-L867
https://github.com/krb5/krb5/blob/krb5-1.17/src/kdc/kdc_authdata.c#L869-L885

Isaac
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The PAC must be the first ad-element

Andrew Bartlett
On Fri, 2020-01-31 at 13:46 +0100, Isaac Boukris wrote:
> Hi,
>
> When I recently confirmed that windows hosts have no problem with
> other ad-elements along side the PAC, I was  lazy to test change of
> order. Today I tested it and found that Windows servers are not happy
> when the PAC is not the first ad-if-relevant element.

Also, the original Samba PAC handling code was the same way, it very
much assumed that the PAC was the first AD-IF-RELEVANT element.  

Andrew Bartlett
--
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The PAC must be the first ad-element

Isaac Boukris
On Fri, Jan 31, 2020 at 7:25 PM Andrew Bartlett <[hidden email]> wrote:

>
> On Fri, 2020-01-31 at 13:46 +0100, Isaac Boukris wrote:
> >
> > When I recently confirmed that windows hosts have no problem with
> > other ad-elements along side the PAC, I was  lazy to test change of
> > order. Today I tested it and found that Windows servers are not happy
> > when the PAC is not the first ad-if-relevant element.
>
> Also, the original Samba PAC handling code was the same way, it very
> much assumed that the PAC was the first AD-IF-RELEVANT element.

Looking at the MIT code in handle_authdata(), I wonder if
request-authdata would pose a problem, and if so what can be done
about it, I'll try to test this.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The PAC must be the first ad-element

Isaac Boukris
In reply to this post by Isaac Boukris
On Fri, Jan 31, 2020 at 1:46 PM Isaac Boukris <[hidden email]> wrote:
>
> When I recently confirmed that windows hosts have no problem with
> other ad-elements along side the PAC, I was  lazy to test change of
> order. Today I tested it and found that Windows servers are not happy
> when the PAC is not the first ad-if-relevant element.

Interestingly, in the trust case if the PAC is the first element the
trusted windows KDC would remove the other element and leave only the
PAC (if the other element was first, then it is not removed but it
breaks service access).
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The PAC must be the first ad-element

Isaac Boukris
On Sat, Feb 1, 2020 at 2:05 AM Isaac Boukris <[hidden email]> wrote:
>
> Interestingly, in the trust case if the PAC is the first element the
> trusted windows KDC would remove the other element and leave only the
> PAC (if the other element was first, then it is not removed but it
> breaks service access).

This makes me think we may need a way to suppress some ad-types from
the request, which I think is not possible with the current API.  If
so, maybe we could add an out a param to sign_authdata() with a list
of ad-types to filter out.
In contrast, perhaps we can reduce the number of passed arguments by
mandating the use of krb5_db_get_authdata_info(), and not passing
header_server and header_key.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The PAC must be the first ad-element

Isaac Boukris
On Mon, Feb 3, 2020 at 10:32 AM Isaac Boukris <[hidden email]> wrote:

>
> On Sat, Feb 1, 2020 at 2:05 AM Isaac Boukris <[hidden email]> wrote:
> >
> > Interestingly, in the trust case if the PAC is the first element the
> > trusted windows KDC would remove the other element and leave only the
> > PAC (if the other element was first, then it is not removed but it
> > breaks service access).
>
> This makes me think we may need a way to suppress some ad-types from
> the request, which I think is not possible with the current API.  If

Actually in that trust case it's the tgt authdata that got suppressed
not request, but the idea is the same.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev