[37264] in Kerberos
Re: Constrained Delegation and PAC : Realm crossover
daemon@ATHENA.MIT.EDU (Rick van Rein)
Tue Oct 20 05:04:12 2015
Message-ID: <56260373.7030308@openfortress.nl>
Date: Tue, 20 Oct 2015 11:03:47 +0200
From: Rick van Rein <rick@openfortress.nl>
MIME-Version: 1.0
To: Simo Sorce <simo@redhat.com>
In-Reply-To: <5624FD3F.4030806@redhat.com>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hi,
> There are 2 different approaches for Constrained Delegation, one where
> Access control is applied at the KDC level, and one that relies on the
> receiving service to apply access control.
>
> When using an MS-PAC you have an AD element that tells you whether the
> ticket is the result of delegations, or is a ticket that has been
> release directly to the owner of the TGT.
>
> So services can always check that.
>
> In FreeIPA however we added actual access control, so that service
> HTTP/webmail.example.com can be allowed to only ever get delegated
> tickets for imap/imap.example.net and nothing else.
>
That's what I was hoping to find, indeed.
> It's up to the imap service admins and the EXAMPLE.NET KDC admins to
> decide what to use and what to enforce.
>
What I'm left wondering is, if the client's KDC knows what delegations
are permitted, as is the case with FreeIPA, is it not simpler to pass on
the additional tickets for smtp/ and imap/ in an AD structure in the
webmail ticket? This might even work recursively, that is if imap/
needed further privileges to afs/ or so. I wouldn't want smtp/ to get
to that ticket but imap/ should.
I must still be missing why S4U2Proxy works the way it does. It may be
that it was designed with more flexibility in mind though, that probably
suits the mindset of its inventors.
> (it seem you sent this to me privately, was that intentional ? If not
> feel free to forward my reply to the list on reply, if needed)
>
Not intended. I've resent my message, and am now forwarding your full
comments inline to the list.
Thanks for your explanations, Simo!
-Rick
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
