Kerberos Constrained Delegation and Credential Caching

[Nebergall, Christopher]

Does anyone have any tips on copying the credentials created from Kerberos constrained delegation to a credentials cache file and back in again? In the example krb5-1.10.3/src/tests/gssapi/t_s4u.c at near the end of contrainedDelegate function after the gss_init_sec_context tried to copy the delegated_cred_handle to a credentials cache. I've NEVER seen the a service ticket for the end service make to the cache file so I'm not sure which cred cache I should be using.

I've tried 1) just using the default cache

2) with gss_store_cred with

memset(&elements_stored, 0, sizeof(elements_stored));
memset(&cred_usage_stored, 0, sizeof(cred_usage_stored));
major = gss_store_cred(&minor, delegated_cred_handle, GSS_C_BOTH, GSS_C_NULL_OID, 1, 1, &elements_stored, &cred_usage_stored);

3) or with gss_krb5_copy_ccache

Nothing shows a cached the service ticket. I'm not even certain which prinicipal I should initialize the ccache with - the impersonator prinicipal, or the user principal name?

I've also tried various methods of reading the new cache back in and then re-running constrainedDelegate but I often get a "gss_init_sec_context: Matching credential not found"

My goal is to put this code into mod_auth_kerb with mod_proxy but I'm unclear how to make it not hit the KDC with every request if I can't get a credential's cache saved, and reloaded between requests.

-Christopher

[Greg Hudson]

On 03/11/2013 08:23 PM, Nebergall, Christopher wrote:
> Does anyone have any tips on copying the credentials created from Kerberos constrained delegation to a credentials cache file and back in again?

This is only possible with 1.11 or later. We use the subject principal
as the default ccache principal, and set a ccache config variable to
remember the impersonating service principal. More details at:

http://krbdev.mit.edu/rt/Ticket/Display.html?id=7046

[Nebergall, Christopher]

Thank you I believe that will be very helpful but I'm unable to test because while I could get constrained delegation working with the t_s4u test program in 1.10.3 I can't get the test program to work with the same accounts in 1.11.1. The test AD Server is windows 2008 R2 SP 1 in both cases.

./t_s4u p:test...@TOPHERVILLE.COM p:host/testkcd2.top...@TOPHERVILLE.COM /tmp/kcd_keytab_tv
Protocol transition tests follow
-----------------------------------

gss_acquire_cred_impersonate_name: Unspecified GSS failure. Minor code may provide more information
gss_acquire_cred_impersonate_name: KDC has no support for padata type

-Christopher

[Simo Sorce]

Christopher,
Red Hat has already sent upstream patches to support s4u2proxy
authentication in mod_auth_kerb, you may want to check this thread:
http://sourceforge.net/mailarchive/message.php?msg_id=28531618

(they are not in the upstream code yet apparently nobody picked them
up).

HTH,
Simo.


--
Simo Sorce * Red Hat, Inc * New York

[Nebergall, Christopher]

I've seen the code for mod_auth_kerb-5.4-9.el6.src.rpm which I think is what you are referring to. Is this correct?

Here is the description from the patch

+Constrained Delegation
+----------------------
+S4U2Proxy, or constrained delegation, enables a service to use a client's
+ticket to itself to request another ticket for delegation. The KDC
+checks krbAllowedToDelegateTo to decide if it will issue a new ticket.
+If KrbConstrainedDelegation is enabled the server will use its own credentials
+to retrieve a delegated ticket for the user. For this to work the user must
+have a forwardable ticket (though the delegation flag need not be set).
+The server needs a valid credentials cache for this to work.
+
+The module itself will obtain and manage the necessary credentials.

I looked through the patches and I'm unclear how it is meant to work. I see no new gssapi or krb5 related functions related to http://k5wiki.kerberos.org/wiki/Projects/Services4User. What are the outputs of the code when a user makes an HTTP request? Will a CGI have access to a credentials cache for the user, so it can just call gss-init-sec-context like normal, or will the CGI just have access to a cred cache for the impersonation account - and the CGI must do the heavy lifting to impersonate the user using the Services4User functions mentioned above?

In other words if you have two processes 1) the server which interacts with the user, and 2) a client process on the server which does something on the user's behalf using Kerberos - which process would normally call gss_acquire_cred_impersonate_name? 1 or 2?

Sorry, I'm new to this topic, so I may be missing something fundamental about how it is meant to work.

-Christopher

-----Original Message-----
From: Simo Sorce [mailto:si...@redhat.com]
Sent: Tuesday, March 12, 2013 4:03 PM
To: Nebergall, Christopher
Cc: kerb...@mit.edu
Subject: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

[Simo Sorce]

On Tue, 2013-03-12 at 22:46 +0000, Nebergall, Christopher wrote:
> I looked through the patches and I'm unclear how it is meant to work.
> I see no new gssapi or krb5 related functions related to
> http://k5wiki.kerberos.org/wiki/Projects/Services4User. What are the
> outputs of the code when a user makes an HTTP request?

You get a ccache created by mod_auth_kerb and KRB5CCNAME variable set in
your CGI.

> Will a CGI have access to a credentials cache for the user, so it
> can just call gss-init-sec-context like normal, or will the CGI just
> have access to a cred cache for the impersonation account - and the
> CGI must do the heavy lifting to impersonate the user using the
> Services4User functions mentioned above?

CGI just needs to use gss_init_sec_context using the ccache provided by
mod_auth_kerb

> In other words if you have two processes 1) the server which interacts
> with the user, and 2) a client process on the server which does
> something on the user's behalf using Kerberos - which process would
> normally call gss_acquire_cred_impersonate_name? 1 or 2?

IIRC It is done for you by mod_auth_kerb.
All you need to do in the client part is use the ccache to obtain the
ticket for the target service and the impersonation part is taken care
off for you transparently by GSSAPI.

> Sorry, I'm new to this topic, so I may be missing something
> fundamental about how it is meant to work.

The fact is that there are a few ways in which this work, when
mod_auth_kerb is used, the action of exporting a ccache file with the
received credentials is basically equivalent to calling
gss_acquire_cred_impersonate_name

[Nebergall, Christopher]

Thank you for your response it helped a great deal.

>The fact is that there are a few ways in which this work, when mod_auth_kerb is used, the action of exporting a ccache file with the received >credentials is basically equivalent to calling gss_acquire_cred_impersonate_name

Ok, so the gss_accept_sec context in mod_auth_kerb can do restricted delegation/S4U2Proxy almost transparently if its creds are acquired using usage = GSS_C_BOTH, and it has TGT for its own creds available. Correct?

My use case also requires the use of S4U2Self in mod_auth_kerb - so a Kerberos cred cache is available even if mod_auth_kerb didn't do the authentication - it instead was done by a different apache module such as mod_auth_radius or shibboleth. So I would need to modify mod_auth_kerb so it supports doing S4U2Self and manage the cache, when it itself didn't authenticate the user - it just gets the identity from the apache request rec. Does that make sense?

-Topher

-----Original Message-----
From: Simo Sorce [mailto:si...@redhat.com]
Sent: Tuesday, March 12, 2013 9:21 PM
To: Nebergall, Christopher
Cc: kerb...@mit.edu

[Nebergall, Christopher]

Do you have an idea why I can't get t_s4u test program in 1.11.1 running against Windows 2008 R2 SP 1?

Set up comments from t_s4u.c

/*
* Test program for protocol transition (S4U2Self) and constrained delegation
* (S4U2Proxy)
*
* Note: because of name canonicalization, the following tips may help
* when configuring with Active Directory:
*
* - Create a computer account FOO$
* - Set the UPN to host/foo.domain (no suffix); this is necessary to
* be able to send an AS-REQ as this principal, otherwise you would
* need to use the canonical name (FOO$), which will cause principal
* comparison errors in gss_accept_sec_context().
* - Add a SPN of host/foo.domain
* - Configure the computer account to support constrained delegation with
* protocol transition (Trust this computer for delegation to specified
* services only / Use any authentication protocol)
* - Add host/foo.domain to the keytab (possibly easiest to do this
* with ktadd)
*
* For S4U2Proxy to work the TGT must be forwardable too.
*
* Usage eg:
*
* kinit -k -t test.keytab -f 'host/test.win...@WIN.MIT.EDU'
* ./t_s4u p:dele...@WIN.MIT.EDU p:HOST/WIN-EQ7E4AA2W...@WIN.MIT.EDU test.keytab
*/

>>Set the UPN to host/foo.domain (no suffix);

I can't do this step, if I don't put @TOPHERVILLE.COM at the end of the UPN, then I can't do a kinit with the impersonator account.

-Christopher

-----Original Message-----
From: kerberos...@mit.edu [mailto:kerberos...@mit.edu] On Behalf Of Nebergall, Christopher
Sent: Tuesday, March 12, 2013 3:04 PM
To: Greg Hudson
Cc: kerb...@mit.edu
Subject: RE: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

Thank you I believe that will be very helpful but I'm unable to test because while I could get constrained delegation working with the t_s4u test program in 1.10.3 I can't get the test program to work with the same accounts in 1.11.1. The test AD Server is windows 2008 R2 SP 1 in both cases.

./t_s4u p:test...@TOPHERVILLE.COM p:host/testkcd2.top...@TOPHERVILLE.COM /tmp/kcd_keytab_tv Protocol transition tests follow
-----------------------------------

gss_acquire_cred_impersonate_name: Unspecified GSS failure. Minor code may provide more information
gss_acquire_cred_impersonate_name: KDC has no support for padata type

-Christopher
-----Original Message-----
From: Greg Hudson [mailto:ghu...@MIT.EDU]

Sent: Monday, March 11, 2013 10:44 PM
To: Nebergall, Christopher
Cc: kerb...@mit.edu

Subject: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

On 03/11/2013 08:23 PM, Nebergall, Christopher wrote:
> Does anyone have any tips on copying the credentials created from Kerberos constrained delegation to a credentials cache file and back in again?

This is only possible with 1.11 or later. We use the subject principal as the default ccache principal, and set a ccache config variable to remember the impersonating service principal. More details at:

http://krbdev.mit.edu/rt/Ticket/Display.html?id=7046

________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

[Simo Sorce]

On Wed, 2013-03-13 at 15:10 +0000, Nebergall, Christopher wrote:
> Thank you for your response it helped a great deal.
>
> >The fact is that there are a few ways in which this work, when
> mod_auth_kerb is used, the action of exporting a ccache file with the
> received >credentials is basically equivalent to calling
> gss_acquire_cred_impersonate_name
>
> Ok, so the gss_accept_sec context in mod_auth_kerb can do restricted
> delegation/S4U2Proxy almost transparently if its creds are acquired
> using usage = GSS_C_BOTH, and it has TGT for its own creds available.
> Correct?
>
> My use case also requires the use of S4U2Self in mod_auth_kerb - so a
> Kerberos cred cache is available even if mod_auth_kerb didn't do the
> authentication - it instead was done by a different apache module such
> as mod_auth_radius or shibboleth. So I would need to modify
> mod_auth_kerb so it supports doing S4U2Self and manage the cache, when
> it itself didn't authenticate the user - it just gets the identity
> from the apache request rec. Does that make sense?

I don't see a technical problem in this, however it is not clear to me
why you would do all of this in mod_auth_kerb given you are doing no
authentication there at this point.

Is the connecting client doing any kerb auth at all?
If not you may be better off (as in it being more flexible for you)
doing the whole s4u2self+s4u2proxy dance within your application.

[Nebergall, Christopher]

>>Is the connecting client doing any kerb auth at all?

No.

>>I don't see a technical problem in his, however it is not clear to me why you would do all of this in mod_auth_kerb given you are doing no authentication there at this point.

No technical reason beyond reducing code duplication with mod_auth_kerb - my app would also be an apache module with has similar Kerberos config params and cred cache handling abilities exposed to the backend CGI's. It would also add the ability to create Negotiate tokens for downstream webservers contacted through mod_proxy.

Thanks for your help!

-Christopher

-----Original Message-----
From: Simo Sorce [mailto:si...@redhat.com]

Sent: Wednesday, March 13, 2013 10:08 AM
To: Nebergall, Christopher
Cc: kerb...@mit.edu
Subject: RE: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

[Nebergall, Christopher]

I used git-bisect to track down the first commit where t_s4u test program fails running against Windows 2008 R2 SP 1. How do I disable fast support for testing? Or I can help reduce the test case further if someone can tell me where to start.

Thanks,
Christopher

09484d0e835928a48655c0650f7de97825607b2e is the first bad commit
commit 09484d0e835928a48655c0650f7de97825607b2e
Author: Sam Hartman <hart...@mit.edu>
Date: Wed Nov 23 01:04:38 2011 +0000

FAST TGS

Implement RFC 6113 FAST TGS support.

Includes library support for a varient of explicit TGS armor that has not yet been proposed within the IETF.

ticket: 7026

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@25488 dc483132-0cff-0310-8789-dd5450dbe970

:040000 040000 b66f21d675fdcbe7427ba0140d73185e7134a4e0 a59cdbe0e1c273bd63a68f8dfb1c8e21ceb31364 M src

-----Original Message-----
From: Nebergall, Christopher
Sent: Wednesday, March 13, 2013 9:34 AM
To: Nebergall, Christopher; Greg Hudson
Cc: kerb...@mit.edu
Subject: RE: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

Cc: kerb...@mit.edu
Subject: RE: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

Thank you I believe that will be very helpful but I'm unable to test because while I could get constrained delegation working with the t_s4u test program in 1.10.3 I can't get the test program to work with the same accounts in 1.11.1. The test AD Server is windows 2008 R2 SP 1 in both cases.

./t_s4u p:test...@TOPHERVILLE.COM p:host/testkcd2.top...@TOPHERVILLE.COM /tmp/kcd_keytab_tv Protocol transition tests follow
-----------------------------------

gss_acquire_cred_impersonate_name: Unspecified GSS failure. Minor code may provide more information
gss_acquire_cred_impersonate_name: KDC has no support for padata type

-Christopher
-----Original Message-----
From: Greg Hudson [mailto:ghu...@MIT.EDU]
Sent: Monday, March 11, 2013 10:44 PM

To: Nebergall, Christopher
Cc: kerb...@mit.edu