Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Windows KDC - Delegation Option
505 views
Skip to first unread message
Vipul Mehta
Feb 10, 2014, 1:50:12 AM2/10/14
to kerb...@mit.edu
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 i.e. User
B will not be able to use delegated credentials.
In Windows SSPI API, it works fine and User B is not able to use delegated
credentials.
But the option doesn't seem to be having any impact in MIT Kerberos API in
C++. User B is able to use A's forwarded credentials to establish security
context with User C.
Is this a problem from KDC side ? Any solution for this ?
--
Regards,
Vipul
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 i.e. User
B will not be able to use delegated credentials.
In Windows SSPI API, it works fine and User B is not able to use delegated
credentials.
But the option doesn't seem to be having any impact in MIT Kerberos API in
C++. User B is able to use A's forwarded credentials to establish security
context with User C.
Is this a problem from KDC side ? Any solution for this ?
--
Regards,
Vipul
Christopher D. Clausen
Feb 10, 2014, 2:46:13 PM2/10/14
to kerb...@mit.edu
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
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
Greg Hudson
Feb 10, 2014, 3:51:51 PM2/10/14
to Vipul Mehta, kerb...@mit.edu
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 ticket flag, which was
> 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.
added in RFC 4120. Microsoft's Kerberos implementation honors this
flag, but Unix implementations do not, as doing so would effectively
disable all ticket forwarding in most Unix environments.
MIT krb5 and Heimdal did add the GSS_C_DELEG_POLICY_FLAG flag so that
applications can choose to delegate tickets only if the ok-as-delegate
flag is set on the service ticket. But it's not clear when a Unix
application would want to use that instead of GSS_C_DELEG_FLAG.
Vipul Mehta
Feb 11, 2014, 8:30:42 AM2/11/14
to Greg Hudson, kerb...@mit.edu
@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 done and value of "ok-as-delegate" flag in
service ticket does not matter in that case. Value of "ok-as-delegate" flag
is important when initiator has not requested GSS_C_DELEG_FLAG but has
requested GSS_C_DELEG_POLICY_FLAG.
On Tue, Feb 11, 2014 at 2:21 AM, Greg Hudson <ghu...@mit.edu> wrote:
> I believe this option affects the ok-as-delegate ticket flag, which was
> added in RFC 4120. Microsoft's Kerberos implementation honors this
> flag, but Unix implementations do not, as doing so would effectively
> disable all ticket forwarding in most Unix environments.
>
> MIT krb5 and Heimdal did add the GSS_C_DELEG_POLICY_FLAG flag so that
> applications can choose to delegate tickets only if the ok-as-delegate
> flag is set on the service ticket. But it's not clear when a Unix
> application would want to use that instead of GSS_C_DELEG_FLAG.
>
--
Regards,
Vipul
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 done and value of "ok-as-delegate" flag in
service ticket does not matter in that case. Value of "ok-as-delegate" flag
is important when initiator has not requested GSS_C_DELEG_FLAG but has
requested GSS_C_DELEG_POLICY_FLAG.
On Tue, Feb 11, 2014 at 2:21 AM, Greg Hudson <ghu...@mit.edu> wrote:
> I believe this option affects the ok-as-delegate ticket flag, which was
> added in RFC 4120. Microsoft's Kerberos implementation honors this
> flag, but Unix implementations do not, as doing so would effectively
> disable all ticket forwarding in most Unix environments.
>
> MIT krb5 and Heimdal did add the GSS_C_DELEG_POLICY_FLAG flag so that
> applications can choose to delegate tickets only if the ok-as-delegate
> flag is set on the service ticket. But it's not clear when a Unix
> application would want to use that instead of GSS_C_DELEG_FLAG.
>
Regards,
Vipul
Ben H
Apr 25, 2014, 2:10:35 PM4/25/14
to Vipul Mehta, kerb...@mit.edu
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 computer accounts exist.
When I authenticate to Unix_01 with my credentials, I receive my TGT and
host TGS. From this host I 'ssh [-K] Unix_02' and am presented with a TGT
with flags: FfRA. Unix_02 is then able to request additional tickets to
NFS_01 (where user home directory is stored via NFS4/Krb).
If I authenticate to Windows_01, I receive similar tickets, however my ssh
(putty) connection does not forward tickets to Unix_02. This is true even
if I explicitly enable the GSSAPI delegation in Putty. The only way to get
this to function is to set the "Trust this computer for delegation to any
service" on the Unix_02 computer object in AD and then to request a new
ticket on Windows_01 for host/Unix_02 which will now contain that
ok_as_delegate_flag.
I was baffled by this until I found this thread in my archive and hashed
over the applicable section in 4120. From what I am reading here it would
appear that this behavior is expected as the Unix systems (MIT) will
forward a ticket regardless of the ok_as_delegate flag. IOW, Windows
systems require the host to show ok_as_delegate in order to forward a
ticket, whereas Unix systems do not.
Can I have a confirmation that I understand this correctly?
If so, I would like to ask a couple of follow up questions, but I don't
want to waste time if I am still unclear on the root issue.
TIA
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
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 computer accounts exist.
When I authenticate to Unix_01 with my credentials, I receive my TGT and
host TGS. From this host I 'ssh [-K] Unix_02' and am presented with a TGT
with flags: FfRA. Unix_02 is then able to request additional tickets to
NFS_01 (where user home directory is stored via NFS4/Krb).
If I authenticate to Windows_01, I receive similar tickets, however my ssh
(putty) connection does not forward tickets to Unix_02. This is true even
if I explicitly enable the GSSAPI delegation in Putty. The only way to get
this to function is to set the "Trust this computer for delegation to any
service" on the Unix_02 computer object in AD and then to request a new
ticket on Windows_01 for host/Unix_02 which will now contain that
ok_as_delegate_flag.
I was baffled by this until I found this thread in my archive and hashed
over the applicable section in 4120. From what I am reading here it would
appear that this behavior is expected as the Unix systems (MIT) will
forward a ticket regardless of the ok_as_delegate flag. IOW, Windows
systems require the host to show ok_as_delegate in order to forward a
ticket, whereas Unix systems do not.
Can I have a confirmation that I understand this correctly?
If so, I would like to ask a couple of follow up questions, but I don't
want to waste time if I am still unclear on the root issue.
TIA
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Vipul Mehta
Apr 25, 2014, 2:48:05 PM4/25/14
to Ben H, kerb...@mit.edu
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, hence there is no need to set delegation option
in Active Directory for credential delegation.
For Windows:
Putty uses SSPI in my opinion which requires delegation option in Active
Directory to be set for credential delegation as it checks
ok_as_delegate_flag.
This is all based on my understanding of Kerberos. Someone having more
experience can please correct if i am wrong here.
On Fri, Apr 25, 2014 at 11:40 PM, Ben H <bhe...@gmail.com> wrote:
> From what I am reading here it would appear that this behavior is expected
> as the Unix systems (MIT) will forward a ticket regardless of the
> ok_as_delegate flag. IOW, Windows systems require the host to show
> ok_as_delegate in order to forward a ticket, whereas Unix systems do not.
>
>
>
--
Regards,
Vipul
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, hence there is no need to set delegation option
in Active Directory for credential delegation.
For Windows:
Putty uses SSPI in my opinion which requires delegation option in Active
Directory to be set for credential delegation as it checks
ok_as_delegate_flag.
This is all based on my understanding of Kerberos. Someone having more
experience can please correct if i am wrong here.
On Fri, Apr 25, 2014 at 11:40 PM, Ben H <bhe...@gmail.com> wrote:
> From what I am reading here it would appear that this behavior is expected
> as the Unix systems (MIT) will forward a ticket regardless of the
> ok_as_delegate flag. IOW, Windows systems require the host to show
> ok_as_delegate in order to forward a ticket, whereas Unix systems do not.
>
>
>
Regards,
Vipul
Ben H
Apr 25, 2014, 6:04:21 PM4/25/14
to Vipul Mehta, kerb...@mit.edu
That's interesting - thank you. I was able to actually validate what you
stated by installing MIT Kerberos on my Window system and then configuring
Putty's GSSAPI option to use the MIT GSSAPI libraries as preference.
My first attempt with kfw-4.0.1 was unsuccessful and I suspect it has to do
with how 4.01 integrates into the Windows LSA cache - I didn't seem able to
separate my Windows tickets from the MIT ones (init/destroy in one location
reflected in the other). I suspect I may have been able to find a way to
configure it, but 4.01 seems very turnkey and I couldn't quickly find some
way to customize this behavior.
When I backed down to kfw-3.2.2 I was able to see a separation in the
credentials and then when setting the MIT GSSAPI higher in the preference
order, it indeed forwarded the creds despite the computer object not being
trusted. When i placed Windows SSPI higher in the preference, it once
again failed to delegate.
That test confirms and solidifies this concept for me much better, but I
still have some questions regarding the actual passing of the tickets
between these machines. I apologize that I may exacerbating what is
standard traffic, but in the context of forwarded tickets I have some
confusion.
FIRST, I kinit (-f) to get a TGT for my user on my host station. When I
examine with klist I see a single ticket of the following format:
Default principal: jsm...@MYDOMAIN.LOCAL
Valid starting Expires Service principal
04/25/14 16:31:06 04/26/14 02:31:06 krbtgt/MYDOMAI...@MYDOMAIN.LOCAL
Flags: FIA
The traffic on the wire consists of a single AS-REQ/AS-REP (exclusive of
preauth and too_big) as to be expected.
THEN, I initiate my SSH connection using this forwardable ticket and the
result is the following:
On my host station:
Default principal: jsm...@MYDOMAIN.LOCAL
Valid starting Expires Service principal
04/25/14 16:31:06 04/26/14 02:31:06
krbtgt/MYDOMAI...@MYDOMAIN.LOCAL
<-----------------original ticket (#1)
Flags: FIA
04/25/14 16:34:02 04/26/14 02:31:06 host/centos64-01.mydomain.local@
<--------------new ticket (#2)
Flags: FA
04/25/14 16:34:02 04/26/14 02:31:06
host/centos64-01.m...@MYDOMAIN.LOCAL
<----------------------new ticket (#3)
Flags: FA
On my destination station:
Default principal: jsm...@MYDOMAIN.LOCAL
Valid starting Expires Service principal
04/25/14 16:34:02 04/26/14 02:31:06 krbtgt/MYDOMAI...@MYDOMAIN.LOCAL
Flags: FfA
NOW, this shows that 2 new tickets have been received on my host station,
and one ticket has been received (forwarded) to my destination.
What I am confused about is that the wire shows only the transmission of
two TGS-REQ/TGS-REP pairs from my host station to the KDC. There is no
Kerberos exchange at all from the destination to the KDC.
Can I assume this means that the FfA krbtgt on the destination station was
passed directly from the host over the application (ssh) and no additional
tickets are necessary (at least until destination needs to request one on
my behalf)?
Additionally, the two TGS-REQ/TGS-REP pairs transmitted between host and
KDC are of the following nature:
A - KDC_REQ_BODY is for host/centos64-01.mydomain.local FORWADABLE,
CANONICALIZE
B - KDC_REQ_BODY is for krbtgt/MYDOMAIN.LOCAL FORWARDABLE, FORWARDED
I don't understand how A and B map to ticket's #2 and #3 above.
A seems to be the TGS-REQ that created #2, but what is this secondary
ticket #3 that exists with the additional appended Realm and why is that
not shown in any exchange on the wire?
Does it have anything to do with the CANONICALIZE request?
Additionally, what purpose is request B performing? Is it simply a request
to tell the KDC that my ticket *has* been forwarded to a remote system? If
so what is the necessity for this notification and response
Feel free to point me to any specific RFC sections which describe the
specific traffic and ticket issuance I am confused on - though a bit of a
layman's explanation won't hurt either!
TIA
stated by installing MIT Kerberos on my Window system and then configuring
Putty's GSSAPI option to use the MIT GSSAPI libraries as preference.
My first attempt with kfw-4.0.1 was unsuccessful and I suspect it has to do
with how 4.01 integrates into the Windows LSA cache - I didn't seem able to
separate my Windows tickets from the MIT ones (init/destroy in one location
reflected in the other). I suspect I may have been able to find a way to
configure it, but 4.01 seems very turnkey and I couldn't quickly find some
way to customize this behavior.
When I backed down to kfw-3.2.2 I was able to see a separation in the
credentials and then when setting the MIT GSSAPI higher in the preference
order, it indeed forwarded the creds despite the computer object not being
trusted. When i placed Windows SSPI higher in the preference, it once
again failed to delegate.
That test confirms and solidifies this concept for me much better, but I
still have some questions regarding the actual passing of the tickets
between these machines. I apologize that I may exacerbating what is
standard traffic, but in the context of forwarded tickets I have some
confusion.
FIRST, I kinit (-f) to get a TGT for my user on my host station. When I
examine with klist I see a single ticket of the following format:
Default principal: jsm...@MYDOMAIN.LOCAL
Valid starting Expires Service principal
04/25/14 16:31:06 04/26/14 02:31:06 krbtgt/MYDOMAI...@MYDOMAIN.LOCAL
Flags: FIA
The traffic on the wire consists of a single AS-REQ/AS-REP (exclusive of
preauth and too_big) as to be expected.
THEN, I initiate my SSH connection using this forwardable ticket and the
result is the following:
On my host station:
Default principal: jsm...@MYDOMAIN.LOCAL
Valid starting Expires Service principal
04/25/14 16:31:06 04/26/14 02:31:06
krbtgt/MYDOMAI...@MYDOMAIN.LOCAL
<-----------------original ticket (#1)
Flags: FIA
04/25/14 16:34:02 04/26/14 02:31:06 host/centos64-01.mydomain.local@
<--------------new ticket (#2)
Flags: FA
04/25/14 16:34:02 04/26/14 02:31:06
host/centos64-01.m...@MYDOMAIN.LOCAL
<----------------------new ticket (#3)
Flags: FA
On my destination station:
Default principal: jsm...@MYDOMAIN.LOCAL
Valid starting Expires Service principal
04/25/14 16:34:02 04/26/14 02:31:06 krbtgt/MYDOMAI...@MYDOMAIN.LOCAL
Flags: FfA
NOW, this shows that 2 new tickets have been received on my host station,
and one ticket has been received (forwarded) to my destination.
What I am confused about is that the wire shows only the transmission of
two TGS-REQ/TGS-REP pairs from my host station to the KDC. There is no
Kerberos exchange at all from the destination to the KDC.
Can I assume this means that the FfA krbtgt on the destination station was
passed directly from the host over the application (ssh) and no additional
tickets are necessary (at least until destination needs to request one on
my behalf)?
Additionally, the two TGS-REQ/TGS-REP pairs transmitted between host and
KDC are of the following nature:
A - KDC_REQ_BODY is for host/centos64-01.mydomain.local FORWADABLE,
CANONICALIZE
B - KDC_REQ_BODY is for krbtgt/MYDOMAIN.LOCAL FORWARDABLE, FORWARDED
I don't understand how A and B map to ticket's #2 and #3 above.
A seems to be the TGS-REQ that created #2, but what is this secondary
ticket #3 that exists with the additional appended Realm and why is that
not shown in any exchange on the wire?
Does it have anything to do with the CANONICALIZE request?
Additionally, what purpose is request B performing? Is it simply a request
to tell the KDC that my ticket *has* been forwarded to a remote system? If
so what is the necessity for this notification and response
Feel free to point me to any specific RFC sections which describe the
specific traffic and ticket issuance I am confused on - though a bit of a
layman's explanation won't hurt either!
TIA
Greg Hudson
Apr 25, 2014, 6:45:39 PM4/25/14
to Ben H, kerb...@mit.edu
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@
> 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.m...@MYDOMAIN.LOCAL
> Flags: FA
> 04/25/14 16:34:02 04/26/14 02:31:06 host/centos64-01.m...@MYDOMAIN.LOCAL
These are the same ticket cached under two different names.
When a client cannot determine the realm of a remote host
authoritatively (via krb5.conf [domain_realm] in a typical setup), it
tries to use referrals using the client principal realm. Internally, a
service principal is represented with an empty realm to mean "we don't
know the realm yet." Once the ticket is obtained, it is cached under
the canonical service name with realm, and also under the internal "we
don't know the realm yet" name so that the referral request does not
have to be repeated.
> Can I assume this means that the FfA krbtgt on the destination station
> was passed directly from the host over the application (ssh) and no
> additional tickets are necessary (at least until destination needs to
> request one on my behalf)?
cached on the client.
> Additionally, the two TGS-REQ/TGS-REP pairs transmitted between host and
> KDC are of the following nature:
> A - KDC_REQ_BODY is for host/centos64-01.mydomain.local FORWADABLE,
> CANONICALIZE
> B - KDC_REQ_BODY is for krbtgt/MYDOMAIN.LOCAL FORWARDABLE, FORWARDED
>
> I don't understand how A and B map to ticket's #2 and #3 above.
cache.
> Additionally, what purpose is request B performing? Is it simply a
> request to tell the KDC that my ticket *has* been forwarded to a remote
> system? If so what is the necessity for this notification and response
1. Tickets can have IP address restrictions, in which case you need to
get a new TGT with the address of the remote host. IP address
restrictions have fallen out of favor because of NATs, but they used to
be common.
2. The new TGT has a different session key from your original TGT, which
means the remote host cannot use that credential to decrypt
communications made using your original TGT.
Ben H
Apr 25, 2014, 7:16:08 PM4/25/14
to Greg Hudson, kerb...@mit.edu
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
showing the current time on the remote.
Regarding the first question about the same ticket being cached with
different names... I'm sure this output has led to confusion with me
before, as I can't often justify what some of the tickets in the cache are
for:
Is there some way to show a mapping that these two tickets are really
identical?
Is the empty realm display really necessary once we have achieved the realm
name? Why do we continue to show it if we have already received the realm?
Is it possible to avoid this situation by a more thorough configuration of
krb5.conf?
Why would the client be unable to determine the remote realm if I am
specifying a FQDN (i.e. shouldn't it assume the realm?)
Can you point me to what might be the best resource to learn more about
this feature - as I'm having a hard time understanding the full concept. I
wasn't previously aware that the cache could show two tickets that were
actually the same.
TIA
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
showing the current time on the remote.
Regarding the first question about the same ticket being cached with
different names... I'm sure this output has led to confusion with me
before, as I can't often justify what some of the tickets in the cache are
for:
Is there some way to show a mapping that these two tickets are really
identical?
Is the empty realm display really necessary once we have achieved the realm
name? Why do we continue to show it if we have already received the realm?
Is it possible to avoid this situation by a more thorough configuration of
krb5.conf?
Why would the client be unable to determine the remote realm if I am
specifying a FQDN (i.e. shouldn't it assume the realm?)
Can you point me to what might be the best resource to learn more about
this feature - as I'm having a hard time understanding the full concept. I
wasn't previously aware that the cache could show two tickets that were
actually the same.
TIA
Greg Hudson
Apr 25, 2014, 8:01:17 PM4/25/14
to Ben H, kerb...@mit.edu
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
> Is there some way to show a mapping that these two tickets are really
> identical?
they are the same, but list doesn't know how to do this.
> Is the empty realm display really necessary once we have achieved the
> realm name? Why do we continue to show it if we have already received
> the realm?
realm is necessary to avoid repeating the TGS request the next time we
try to contact the remote host. klist is just displaying the entries in
the cache.
> Is it possible to avoid this situation by a more thorough configuration
> of krb5.conf?
http://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#domain-realm
> Why would the client be unable to determine the remote realm if I am
> specifying a FQDN (i.e. shouldn't it assume the realm?)
do not consider it authoritative, so we try referrals first. In many
situations that heuristic would be inaccurate; for instance, hosts in
the mit.edu domain are typically in the realm ATHENA.MIT.EDU, not MIT.EDU.
> Can you point me to what might be the best resource to learn more about
> this feature - as I'm having a hard time understanding the full concept.
> I wasn't previously aware that the cache could show two tickets that
> were actually the same.
behavior of referrals. Right now I believe all we have is at:
http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#mapping-hostnames-onto-kerberos-realms
and the documentation for the associated kdc.conf variables.
Ben H
Apr 25, 2014, 11:49:42 PM4/25/14
to Greg Hudson, kerb...@mit.edu
Thanks again. I confirmed that the [domain_realm] entry worked both on a
unix host and on my kfw-3.2.2 install.
Once added, no referral was needed and only one entry shows in the cache.
Interestingly, in respect to your information on the forwarded ticket TGS
request, I found that Windows implements this differently.
When using Putty with SPPI, the forwardable TGT is requested by the host
and sent over to the remote system. In this, there is no difference to
GSSAPI.
However, the ticket *is* cached on the windows host:
#0> Client: jsmith @ MYDOMAIN.LOCAL
Server: krbtgt/MYDOMAIN.LOCAL @ MYDOMAIN.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a10000 -> forwardable forwarded renewable
pre_authent name_canonicalize
Start Time: 4/25/2014 22:07:21 (local)
End Time: 4/26/2014 8:07:21 (local)
Renew Time: 5/2/2014 22:07:21 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Because it is cached on the windows host, the same ticket it sent on each
request and not TGS request goes to the KDC.
Not only that, but it would appear that the same forwardable ticket is sent
to any host that is accepts forwarded tickets (trusted for delegation).
I confirmed this by both a wirecap (no TGS sent on subsequent connections
to original remote host and to a second host), and by the fact the
time-stamp on my first cached ticket was the same on both remote hosts.
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 should one be compromised?
Is this the reason that MIT chooses to request a new TGT for each
connection?
unix host and on my kfw-3.2.2 install.
Once added, no referral was needed and only one entry shows in the cache.
Interestingly, in respect to your information on the forwarded ticket TGS
request, I found that Windows implements this differently.
When using Putty with SPPI, the forwardable TGT is requested by the host
and sent over to the remote system. In this, there is no difference to
GSSAPI.
However, the ticket *is* cached on the windows host:
#0> Client: jsmith @ MYDOMAIN.LOCAL
Server: krbtgt/MYDOMAIN.LOCAL @ MYDOMAIN.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a10000 -> forwardable forwarded renewable
pre_authent name_canonicalize
Start Time: 4/25/2014 22:07:21 (local)
End Time: 4/26/2014 8:07:21 (local)
Renew Time: 5/2/2014 22:07:21 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Because it is cached on the windows host, the same ticket it sent on each
request and not TGS request goes to the KDC.
Not only that, but it would appear that the same forwardable ticket is sent
to any host that is accepts forwarded tickets (trusted for delegation).
I confirmed this by both a wirecap (no TGS sent on subsequent connections
to original remote host and to a second host), and by the fact the
time-stamp on my first cached ticket was the same on both remote hosts.
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 should one be compromised?
Is this the reason that MIT chooses to request a new TGT for each
connection?
Russ Allbery
Apr 25, 2014, 11:56:35 PM4/25/14
to kerb...@mit.edu
Ben H <bhe...@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 should one be
> compromised? Is this the reason that MIT chooses to request a new TGT
> for each connection?
A new delegated TGT is retrieved for each delegation normally because the
> 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 should one be
> compromised? Is this the reason that MIT chooses to request a new TGT
> for each connection?
receiving host's IP address is (well, can be -- see below) encoded in the
ticket. Kerberos tickets encode the host that is supposed to have the
ticket... except that this has become essentially useless on the modern
Internet with NAT, and it never provided much in the way of security
anyway. So there are some vestiges of support for that behavior around,
but basically everyone disables addresses in tickets.
Windows probably realizes that the tickets are addressless and therefore
doesn't bother to get another delegated ticket. (You still have to do it
once to get a ticket with the correct flags.)
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
Greg Hudson
Apr 26, 2014, 12:23:39 AM4/26/14
to Ben H, kerb...@mit.edu
On 04/25/2014 11:49 PM, Ben H wrote:
> 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 should one be
> compromised?
It's debatable whether this qualifies as an "attack." If one of the
> 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 should one be
> compromised?
target hosts goes rogue with the forwarded TGT, it can impersonate the
client principal and take arbitrary actions on that principal's behalf.
Being able to also decrypt the traffic of other target hosts is a
relatively small escalation in comparison, but it is an escalation of sorts.
> Is this the reason that MIT chooses to request a new TGT
> for each connection?
MIT krb5 behavior to use one forwarded TGT for all forwarding
operations. It's possible that we might change it anyway, as it can
have a major impact on performance for HTTP negotiation.
Benjamin Kaduk
Apr 26, 2014, 3:37:35 PM4/26/14
to Ben H, kerb...@mit.edu
Hi Ben,
On Fri, 25 Apr 2014, Ben H wrote:
> That's interesting - thank you. I was able to actually validate what you
> stated by installing MIT Kerberos on my Window system and then configuring
> Putty's GSSAPI option to use the MIT GSSAPI libraries as preference.
> My first attempt with kfw-4.0.1 was unsuccessful and I suspect it has to do
> with how 4.01 integrates into the Windows LSA cache - I didn't seem able to
> separate my Windows tickets from the MIT ones (init/destroy in one location
> reflected in the other). I suspect I may have been able to find a way to
> configure it, but 4.01 seems very turnkey and I couldn't quickly find some
> way to customize this behavior.
The intention behind the KfW 4.0 GUI is that people using it would only be
using the API: credentials cache type, and would probably not be
interacting with the native Windows LSA cache (the MSLSA: cache type as
exposed by KfW). As such, the GUI does not offer a way to change what
cache will be used for new tickets obtained using the GUI; they will be
placed into the default cache. Since the API cache is collection-enabled,
it is possibl to have credentials for multiple principals present, and
they will be displayed in the ticket list. Since the LSA cache only
supports having one identity at a time, if the default cache is MSLSA:,
the new ticket will overwrite any preexisting ones.
I'm not sure how your system ended up in a state where the MSLSA: cache
was the default (there is a registry key to control this), but using the
KfW-provided kinit.exe and klist.exe can help understand what's going
on: klist AA will show what cache type is in use, and "kinit -c API:
<principal>" will create an API: cache, viewable from the GUI, which can
be made default therein.
We have had a couple of reports that the lack of visibility into the
default cache type can be confusing, and the upcoming 4.1 release should
include some functionality to help in this situation. I haven't decided
what exactly that will look like, though -- do you have a preference among
(1) another checkbox/display column for the cache name, (2) an option for
cache type in the "get ticket" window, (3) a warning when new tickets will
us the LSA cache, or (4) something else?
We really do appreciate getting feedback about the KfW 4.0 series.
Thanks,
Ben
On Fri, 25 Apr 2014, Ben H wrote:
> That's interesting - thank you. I was able to actually validate what you
> stated by installing MIT Kerberos on my Window system and then configuring
> Putty's GSSAPI option to use the MIT GSSAPI libraries as preference.
> My first attempt with kfw-4.0.1 was unsuccessful and I suspect it has to do
> with how 4.01 integrates into the Windows LSA cache - I didn't seem able to
> separate my Windows tickets from the MIT ones (init/destroy in one location
> reflected in the other). I suspect I may have been able to find a way to
> configure it, but 4.01 seems very turnkey and I couldn't quickly find some
> way to customize this behavior.
using the API: credentials cache type, and would probably not be
interacting with the native Windows LSA cache (the MSLSA: cache type as
exposed by KfW). As such, the GUI does not offer a way to change what
cache will be used for new tickets obtained using the GUI; they will be
placed into the default cache. Since the API cache is collection-enabled,
it is possibl to have credentials for multiple principals present, and
they will be displayed in the ticket list. Since the LSA cache only
supports having one identity at a time, if the default cache is MSLSA:,
the new ticket will overwrite any preexisting ones.
I'm not sure how your system ended up in a state where the MSLSA: cache
was the default (there is a registry key to control this), but using the
KfW-provided kinit.exe and klist.exe can help understand what's going
on: klist AA will show what cache type is in use, and "kinit -c API:
<principal>" will create an API: cache, viewable from the GUI, which can
be made default therein.
We have had a couple of reports that the lack of visibility into the
default cache type can be confusing, and the upcoming 4.1 release should
include some functionality to help in this situation. I haven't decided
what exactly that will look like, though -- do you have a preference among
(1) another checkbox/display column for the cache name, (2) an option for
cache type in the "get ticket" window, (3) a warning when new tickets will
us the LSA cache, or (4) something else?
We really do appreciate getting feedback about the KfW 4.0 series.
Thanks,
Ben
Vipul Mehta
Apr 28, 2014, 8:10:02 AM4/28/14
to Ben H, kerb...@mit.edu
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 <bhe...@gmail.com> wrote:
> That's interesting - thank you. I was able to actually validate what you
> stated by installing MIT Kerberos on my Window system and then configuring
> Putty's GSSAPI option to use the MIT GSSAPI libraries as preference.
> My first attempt with kfw-4.0.1 was unsuccessful and I suspect it has to
> do with how 4.01 integrates into the Windows LSA cache - I didn't seem able
> to separate my Windows tickets from the MIT ones (init/destroy in one
> location reflected in the other). I suspect I may have been able to find a
> way to configure it, but 4.01 seems very turnkey and I couldn't quickly
> find some way to customize this behavior.
>
--
Regards,
Vipul
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 <bhe...@gmail.com> wrote:
> That's interesting - thank you. I was able to actually validate what you
> stated by installing MIT Kerberos on my Window system and then configuring
> Putty's GSSAPI option to use the MIT GSSAPI libraries as preference.
> My first attempt with kfw-4.0.1 was unsuccessful and I suspect it has to
> do with how 4.01 integrates into the Windows LSA cache - I didn't seem able
> to separate my Windows tickets from the MIT ones (init/destroy in one
> location reflected in the other). I suspect I may have been able to find a
> way to configure it, but 4.01 seems very turnkey and I couldn't quickly
> find some way to customize this behavior.
>
> 04/25/14 16:34:02 04/26/14 02:31:06 host/centos64-01.mydomain.local@
> <--------------new ticket (#2)
> Flags: FA
> 04/25/14 16:34:02 04/26/14 02:31:06
> host/centos64-01.m...@MYDOMAIN.LOCAL
> 04/25/14 16:34:02 04/26/14 02:31:06
> host/centos64-01.m...@MYDOMAIN.LOCAL
> <----------------------new ticket (#3)
> Flags: FA
>
> On my destination station:
>
> Default principal: jsm...@MYDOMAIN.LOCAL
>
> Valid starting Expires Service principal
> 04/25/14 16:34:02 04/26/14 02:31:06 krbtgt/MYDOMAI...@MYDOMAIN.LOCAL
> Flags: FfA
>
>
> NOW, this shows that 2 new tickets have been received on my host station,
> and one ticket has been received (forwarded) to my destination.
>
> What I am confused about is that the wire shows only the transmission of
> two TGS-REQ/TGS-REP pairs from my host station to the KDC. There is no
> Kerberos exchange at all from the destination to the KDC.
> Flags: FA
>
> On my destination station:
>
> Default principal: jsm...@MYDOMAIN.LOCAL
>
> Valid starting Expires Service principal
> 04/25/14 16:34:02 04/26/14 02:31:06 krbtgt/MYDOMAI...@MYDOMAIN.LOCAL
> Flags: FfA
>
>
> NOW, this shows that 2 new tickets have been received on my host station,
> and one ticket has been received (forwarded) to my destination.
>
> What I am confused about is that the wire shows only the transmission of
> two TGS-REQ/TGS-REP pairs from my host station to the KDC. There is no
> Kerberos exchange at all from the destination to the KDC.
> Can I assume this means that the FfA krbtgt on the destination station was
> passed directly from the host over the application (ssh) and no additional
> tickets are necessary (at least until destination needs to request one on
> my behalf)?
>
> passed directly from the host over the application (ssh) and no additional
> tickets are necessary (at least until destination needs to request one on
> my behalf)?
>
> Additionally, the two TGS-REQ/TGS-REP pairs transmitted between host and
> KDC are of the following nature:
> A - KDC_REQ_BODY is for host/centos64-01.mydomain.local FORWADABLE,
> CANONICALIZE
> B - KDC_REQ_BODY is for krbtgt/MYDOMAIN.LOCAL FORWARDABLE, FORWARDED
>
> I don't understand how A and B map to ticket's #2 and #3 above.
>
> KDC are of the following nature:
> A - KDC_REQ_BODY is for host/centos64-01.mydomain.local FORWADABLE,
> CANONICALIZE
> B - KDC_REQ_BODY is for krbtgt/MYDOMAIN.LOCAL FORWARDABLE, FORWARDED
>
> I don't understand how A and B map to ticket's #2 and #3 above.
>
> A seems to be the TGS-REQ that created #2, but what is this secondary
> ticket #3 that exists with the additional appended Realm and why is that
> not shown in any exchange on the wire?
> Does it have anything to do with the CANONICALIZE request?
>
> ticket #3 that exists with the additional appended Realm and why is that
> not shown in any exchange on the wire?
> Does it have anything to do with the CANONICALIZE request?
>
> Additionally, what purpose is request B performing? Is it simply a
> request to tell the KDC that my ticket *has* been forwarded to a remote
> system? If so what is the necessity for this notification and response
>
> request to tell the KDC that my ticket *has* been forwarded to a remote
> system? If so what is the necessity for this notification and response
>
Regards,
Vipul
0 new messages