OK-AS-DELEGATE FLAG setting.

[Douglas E. Engert]

Simo Sorce wrote:
> On Thu, 2008-05-08 at 18:40 -0400, Jeffrey Altman wrote:
>> Paul Moore wrote:
>>> The GSS layer should enforce the obedience of this flag. In the current
>>> MIT gss code it does not. This is very bad (we have reported this
>>> before). The KDC has set a flag saying 'don't forward this' and yet the
>>> MIT client code forwards it anyway. We offered a fix (we have it in
>>> place already) but were told 'no thanks'. I suspect that the reason the
>>> client side code ignores it is because the MIT KDC never sets it and so
>>> nobody in MIT has paid much attention to it. MS AD KDC uses it all the
>>> time. In fact AD's default mode is to set 'do not forward '
>> You have to understand that the creation of this flag changes the
>> behavior.  Historically there was no flag indicating whether or not the
>> KDC thought it was safe to forward.  So is the absence of the flag an
>> indication that it is not safe or that the KDC does not support the flag?
>>
>> If you add support for this in the client and I use that client to
>> talk to a realm whose KDC does not support the flag, then I lose.
>>
>> If you have a realm whose KDC does not support the flag and you
>> upgrade to a new version that does, does the upgrade set the flag by
>> default to ensure backward compatibility with the previous behavior?
>>
>> If not, does the realm administrator know that they need to set the
>> flag and on which service principals it is required on?
>>
>> These are serious issues and it would be inappropriate for MIT to simply 
>> take a patch that enabled the option in the KDC and enforced it in the
>> client without working through an appropriate upgrade path.
>>
>> In my opinion the flag that should have been added is not OK-AS-DELEGATE
>> but DO-NOT-FORWARD and have AD set that flag by default on all 
>> principals.  Doing so would have provided an easy upgrade path for other 
>> Kerberos KDC and client implementations.
>>
>> The way things are, no matter what is done someone is going to have to
>> pay a significant price.
> 
> If the upgrade path is the issue it is easy to add a [libdefaults]
> options to turn on/off obeying the flag, with default set to off.
> 
> example:
> 
> [libdefaults]
>   honor-ok-as-delegate = true|false

It should be on a per-realm basis, as some realms may or may not
set the flag.

Even Microsoft realized this, and for non-AD KDCs, on a client machine
"ksetup /SetRealmFlag <realm> Delegate" says Everyone in this realm is trusted
for delegation. In effect setting your "honor-ok-as-delegate = false"

Mircosoft also controls who can set the bit on the principal,
by a group policy on the DC. Only selected admins can set the
TRUSTED_FOR_DELEGATION bin the the userAccountControl flag.
Thus workstaion level admins, those that join workstations to the
domain can not set this bit.



And as Jeff pointed out, the flag should have been a DO-NOT-FORWARD bit.
It would have made for a better transition.

> 
> 
> But not having at all the option to honor the flag is worst imo.
> 
> Simo.
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444