Douglas E. Engert
deengert at anl.gov
Wed Mar 8 16:43:47 EST 2006
Wachdorf, Daniel R wrote:
> Sandia currently has a working implementation of the OK_AS_DELEGATE flag
> running on the MIT code base. I would like to get this running on the
> most current code base and submit a patch back to MIT.
> I doing this, I think the OK_AS_DELEGATE brings up a few questions worth
> 1- Should the clients have influence over this?
> Our implementation requires clients attempt delegation and the
> OK_AS_DELEGATE flag be set on the service ticket in order for delegation
> to occur. This sits in the Kerberos code, so it applies to GSSAPI as
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.
> 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?
> 3- Should there be a configuration option to control the functionality?
The way Windows does this, if the client registry has:
= 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.
> Daniel Wachdorf
> drwachd at sandia.gov
> Sandia National Laboratories
> Cyber Security Technologies
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
More information about the krbdev