|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Message-ID: <546622D5.3090704@mit.edu> Date: Fri, 14 Nov 2014 10:42:13 -0500 From: Greg Hudson <ghudson@mit.edu> MIME-Version: 1.0 To: kerberos@mit.edu In-Reply-To: <54661226.5030409@cc.in2p3.fr> Content-Type: text/plain; charset="windows-1252" Errors-To: kerberos-bounces@mit.edu Content-Transfer-Encoding: 8bit On 11/14/2014 09:31 AM, Rémi Ferrand wrote: > * How could I know which service principal was used to authenticate to > the remctl server ? I need this information for > gss_acquire_cred_impersonate_name() 3d argument and for > gss_init_sec_context() 4th argument. gss_acquire_cred_impersonate_name is for S4U2Self. You do not need to use S4U2Self if the client authenticated to the intermediate service using Kerberos. You only need to use S4U2Proxy. The fourth argument to gss_init_sec_context is the name of the target service, not the name of the client. So, while you can find out which service name was used using gss_inquire_context, you should not need it. Once the code is written, the administrator does need to pay some attention to this. The server process needs a TGT in order to make the S4U2Proxy request, and the client principal of this TGT must match the name of the key used to decrypt the client ticket. This is perhaps a bit more restrictive than necessary, and the diagnostics aren't great if the admin gets it wrong; see: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8033 > * Which credentials should I use for > gss_acquire_cred_impersonate_name(), gss_init_sec_context() and > gss_accept_sec_context(). I'm only dealing with two different > credentials for now (client_delegated ones and remctl server ones). Acquire a cred with usage GSS_C_BOTH and the default name. Pass this cred as the verifier_cred_handle to gss_accept_sec_context and get a delegated_cred_handle. Pass that delegated cred as the claimant_cred_handle to gss_init_sec_context. Give gss_init_sec_context the target_name of the service you want to authenticate to as the client. That is all you have to do for S4U2Proxy with a client-supplied evidence ticket. > * How should I expect my KDc to behave if it does not support S4U2Proxy > ? Will it just deny granting a TGS and the GSS libraries will fail with > an explicit message ? Yes. > * In S4U2Proxy and S4U2Self, is there any kind of *authorization* done > at the KDC level ? MIT Kerberos as the *ok_to_auth_as_delegate* flag. > In a MIT KDC for instance, is enabling S4U2Proxy as simple as adding the > *ok_to_auth_as_delegate* flag to the *service/remctl@EXAMPLE.ORG* > principal ? > I suppose that more complex operations are involved if the LDAP backend > is a prerequisite. Is there any support for ACL such as "principal_A" is > authorized to proxy this very ticket ... ? Yes, there is authorization performed at the KDC level. At present, MIT krb5 only supports this authorization with the LDAP KDB module using the AllowedToDelegateTo attribute; the DB2 KDB module will always reject S4U2Proxy requests. > Learning how to properly use the GSS with those extensions isn't as > simple as I expected. The S4U implementation in MIT krb5 went in at a time when our documentation infrastructure was still in flux, so it unfortunately did not receive a proper writeup. The project page at http://k5wiki.kerberos.org/wiki/Projects/Services4User can be useful but is really design notes rather than proper developer-facing documentation. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |