Constrained Delegation and PAC : Realm crossover

[Simo Sorce]

On 20/10/15 05:03, Rick van Rein wrote:
> 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 is a potential optimization I have been thinking about before, but 
requires clients that understand how to extract these tickets and put 
them in their ccache. Perfectly doable though.

> 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.

S4U2Proxy is built this way because in the Microsoft implementation it 
is the receiving service that enforces access control. IIRC the KDC does 
not, it just either always allow proxy for any target or for none.

>> (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 at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>


-- 
Simo Sorce * Red Hat, Inc * New York