OK-AS-DELEGATE Flag

[Douglas E. Engert]

Wachdorf, Daniel R wrote:

> 
> 
> A windows client will look at the registry. A user could always change
> the client code to ignore this so it should be treated as advisory.
> 
> DAN:  I'm not necessarily trying to emulate the windows functionality.
> I think our implementation allows for the most flexibility in terms of
> allowing centralized delegation control and giving the users the ability
> to not delegate if they don't want to.  I don't think you could
> necessarily "stop" an application or user from delegating who really
> want's to.  The goal would be to have a centralized management used to
> tell clients it is ok to delegate.  This is especially helpful when you
> talk about delegating credentials when authenticating to web servers.  
> When you say the windows client will look at the registry - is that
> internal to the SSPI - or are clients required to do that before they
> indicate when then want to delegate or not? 

I believe it is the SSPI, but the application can also see the flags.
I think SecureCRT 5.0 will look at this. We had a situation where
the client would not delegate. I still have to do more testing
since we had the host registered in two realms, and for some reason
the SecureCRT got two ticket one from each realm. I think it looked
at the OK_AS_DELEGATE in one of the tickets, but used the other
for authentication!


> 
> 
>>2- How should cross-realm delegation be handled?  
>>
>>Do you want to trust the delegation flag from a cross realm service?
>>Also - not all Kerberos realms will support OK_AS_DELEGATE, so should
>>you be able to override this.  Should the flag only be relevant for
> 
> the
> 
>>local realm?
> 
> 
> Should the cross realm TGTs also have this bit set?
> 
> DAN:  So, if the cross realm TGT has OK_AS_DELEGATE set, then trust the
> OK_AS_DELEGATE flag on the cross realm service tickets.  This would give
> administrators control of the ability - but it would be an all or
> nothing decision.  Our implementation allows you to specify a value
> (regex) in the krb5.conf file which overrides the OK_AS_DELEGATE flag.  

You brought up an interesting point about cross realm. I did not mean an
all or nothing. I was thinking some or nothing. The service tickets from
the second realm would also need the ok_AS_DELEGATE. If the TGT did not
have it, then the client would never delegate to any servers in the second
realm even if the bit was set in the service ticket.

There are a number of ways to use this.

> 
> 
>>3- Should there be a configuration option to control the
> 
> functionality?
> 
> The way Windows does this, if the client registry has:
> 
> HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains\<Realm-name>\
> RealmFlags
> = 4, then every one in the realm is trusted. i.e. ignore the advise of
> the KDC. It implies this is for non Windows realms only, but I think it
> applies to domains too.
> 
> ksetup can set these for you.
> 
> So this appears to be advisory only. A client could ignore the
> advice of the KDC.
> 
> (Also note that to be able to set the bit on the account in AD requires
> special privilages on the AD machine with the KDC.)
> 
> 
>>
>>Thanks in advance.
>>
>>-dan
>>
>>-------------------------------------- 
>>Daniel Wachdorf 
>>drwachd at sandia.gov 
>>Sandia National Laboratories 
>>Cyber Security Technologies 
>>505-284-8060 
>>
>>
> 
> 

-- 

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