Yes, the TGT is passed directly by the host.
Please read the section Messages in the Forwarding Process here :
http://technet.microsoft.com/en-us/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f28
It explains the steps clearly with the diagram.
On Sat, Apr 26, 2014 at 3:34 AM, Ben H
Sorry to trudge up a thread a couple of months old - but I believe that the
behavior I'm seeing is directly related to this and instead of coming in
grasping at straws, I decided it would be best to use this as context.
I have a heterogeneous environment with a windows KDC which both my user
and
Your understanding is correct but credential delegation requirements are
API dependent instead of platform.
For Unix :
Putty uses MIT Kerberos - GSS API. When you enable delegation in putty it
requests GSS_C_DELEG_FLAG instead of GSS_C_DELEG_POLICY_FLAG which doesn't
check ok_as_delegate_flag,
On 04/25/2014 06:04 PM, Ben H wrote:
04/25/14 16:34:02 04/26/14 02:31:06 host/centos64-01.mydomain.local@
Flags: FA
04/25/14 16:34:02 04/26/14 02:31:06
host/centos64-01.mydomain.local@MYDOMAIN.LOCAL
Flags: FA
These are the same ticket cached under two different
Great - thanks Greg - beginning to be much clearer.
So the TGT from B is actually a full request for the forwardable ticket
(not just a notification) and it gets sent right to the remote machine and
not cached locally.
I can confirm this with the issued time stamp not changing on the host, but
On 04/25/2014 07:16 PM, Ben H wrote:
Is there some way to show a mapping that these two tickets are really
identical?
In theory it would be possible to checksum the tickets and tell that
they are the same, but list doesn't know how to do this.
Is the empty realm display really necessary once
Ben H bhen...@gmail.com writes:
Based on your prior explanation I can't help but infer this means that
although the new forwardable TGT session key may be different than my
original TGT, it is still shared between all hosts that I delegate to,
leading to a possible attack against all systems
@Christopher : I know about that option. I don't want to disable delegation
but i want to know the correct behaviour of MIT Kerberos with KDC Option i
specified.
@Greg, now it's clear to me.
Checked the code also. So, if initiator has requested GSS_C_DELEG_FLAG,
then delegation will always be
Hi,
Scenario : User A forwards his credentials to User B. User B uses the
forwarded credentials to interact with User C on behalf of user A.
[Delegation]
In windows KDC there is delegation option associated with user properties.
I've set it to Do not trust this user for delegation for User B
Try checking the Account is sensitive and cannot be delegated option
in the user properties and see if that does what you want. (I'm not
sure if it will or not, but I believe this is the option actually
intended to prevent Kerberos delegation.)
CDC
Vipul Mehta wrote, On 2/10/2014 12:50 AM:
On 02/10/2014 01:50 AM, Vipul Mehta wrote:
In windows KDC there is delegation option associated with user properties.
I've set it to Do not trust this user for delegation for User B i.e. User
B will not be able to use delegated credentials.
I believe this option affects the ok-as-delegate
11 matches
Mail list logo
