Thank you Simo for your detailed answer,Things are becoming more intuitive, but still, I can't really understand the whole picture.
I've created a GIST (https://gist.github.com/riton/bdf6df5b589a20d46c6e)that only shows the main functions that should be called in remctl and all the questions that I'm still unable to solve by myself.
The main questions are:* 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.
* 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).
* 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 ? For now I'm still working with a test version of heimdal-server-1.6.0-0.9.20140621gita5adc06.el6.x86_64. As expected, this version seem to support S4U2Self operations (I've seen message like "2014-11-14T10:47:32 krb5_verify_checksum failed for S4U2Self: Checksum type hmac-md5 is keyed, but the key type aes256-cts-hmac-sha1-96 passed didnt have that checksum type as the keyed type" in the KDC logs, so it's S4U2Self aware). However, I still don't have any clue about additional principal flags introduced in Heimdal.
* 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/rem...@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 ... ?
Thanks in advance for any help and thanks for your time.Learning how to properly use the GSS with those extensions isn't as simple as I expected.
Cheers R. On 12/11/2014 00:57, Simo Sorce wrote:
On Tue, 11 Nov 2014 23:19:41 +0100 (CET) Remi FERRAND <remi.ferr...@cc.in2p3.fr> wrote:Ok, I don't have any experience nor knowledge about s4u2proxy for now. I've read everything I could find about it, there's not a lot of documentation about this (except general concepts)... I'm still not very comfortable with those new concepts so please, apologize for any mistake below. For now, remctl does the following: * gss_init_sec_context() in client/open.c * gss_accept_sec_context() in server/generic.c For my test bed, all I've done is : * add the GSS_C_DELEG_FLAG flag in client's gss_init_sec_context. * provide a gss_cred_id_t structure to server's gss_accept_sec_context in order to retrieve delegated creds. * write delegated creds in a new krb5 ccache file and set KRB5CCNAME variable in process env just like SSH does. For now, I've done uncontrained delegation. The only real documentation I could found about "GSSAPI developpment" and "s4u2" features is http://k5wiki.kerberos.org/wiki/Projects/Services4User#gss_accept_sec_context. There's also Simo's post at https://ssimo.org/blog/id_011.html. I've searched FreeIPA's code for gss/s4u2 specific parts, but I couldn't find any. If you can point some source files or lines, I'll greatly appreciate :-).This may help a little: https://git.fedorahosted.org/cgit/gss-proxy.git/tree/proxy/src/gp_creds.c#n476 This one does s4u2self+s4u2proxy, you may want to do just the latter. IIRC in that case all you need to do (with MIT libraries) is to store delegated_creds you get out of gss_accept_sec_context() (yes even if no creds were delegated, in that case only the user's evidence ticket is saved), and then just use gss_init_sec_context() with those creds.Even after Simo's post, in the example of Service-for-User-to-Proxy (https://ssimo.org/blog/id_011.html), What is quite unclear for me at the moment is the workflow that I should adopt for remctl. For instance, in a very simple scenario like this one: [remctl client / principal "b...@example.org] owns a forwardable TGT, requests command "the_proxy_command" on host "server1" | | V [remctl server on host "server1" / service principal "service/remctl/serv...@example.org"] executes command "the_proxy_command". The script "the_proxy_command" does stuff and among other things, executes the remctl command "the_final_command" on an other host. | | V [remctl server on host "otherhost" / service principal "service/remctl/otherh...@example.org"] executes command "the_final_command" Questions: 1) Simo's blog says "With S4U the user only needs a Forward-able TGT, but does not need to actually forward it at all". How could I specify that in remctl client's code ? I'm currently only using the GSS_C_DELEG_FLAG and I can't find any other way to do so ... . Is this done "behind the scenes" and transparent at the GSS level ?You do not delegate anything from the client, all the server needs is the regular ticket the client send to the server as proof of authentication.2) On the remctl server running on host "server1", gss_accept_sec_context() will deliver me client's TGT in the delegated credentials structure. What extra "gss_*" function should I call to use S4U2Proxy ? The server currently obtain a "gss_cred_id_t" structure fed by gss_accept_sec_context(). What extra manipulation should I do on those creds ?See above, just store the cred (which is really just a ticket in this case) and reuse as is in init_context.3) Does the remctl server on host "server1" needs to know "in advance" the service name "service/remctl/otherhost" in order to obtain a TGS for it ?No.Is the remctl server even responsible for retrieving those TGS and providing them to the remctl command "the_proxy_command" ? In my current "test bed", as the TGT is stored in a ccache file, all of this is not handled by the remctl server.The middle server will need a ticket to talk to the next server, that is what you store in the ccache, the init_sec_context in the remctl client called by "the_proxy_command" is what will perform the TGS request.4) At CC-IN2P3 we're currently running Heimdal KDCs. I was unable to find any attribute to use on a particular principal to allow/disallow delegation (same as MIT kerberos *ok_to_auth_as_delegate* attribute). Am I missing something ? I've seen a message of Love Hörnquist Åstrand in Heimdal's saying that constrained delegation is supported, but I couldn't find any documentation about this...Although Heimdal libraries have some support for S4U2Proxy I have experience and testing only using MIT KDCs and Client libraries. Note though that you need a special database driver that can allow the KDC to perform S4U2Proxy. Ad does that, as well as FreeIPA, we are working on getting the necessary support to express S4U2Proxy ACLs ins the MIT LDAP driver: http://k5wiki.kerberos.org/wiki/Projects/KerberosDelegationACL This is based on the work done in FreeIPA, but is not yet included in the MIT code.Even after reading MIT's test file (https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_s4u2proxy_krb5.c) dedicated to s4u2proxy, I've not seen any "unusual" gss scenario or calls. It basically does gss_init_sec_context() -> gss_accept_sec_context() loop, retrieves delegated credetials through gss_accept_sec_context() argument and then work in a "standard way" with them. If anyone could answer my questions, I'll be very grateful.I hope I addressed your main points, if not ask for more :)Thanks guys for your time, It's a new Kerberos side that I'm discovering here, and It seems quite hard to find documentation about it.S4U2Proxy does not have a ton of docs indeed .. Simo.
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
