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 :-). 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 ? 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 ? 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 ? 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. 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... 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. 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. Cheers Rémi ----- Original Message ----- From: "Russ Allbery" <ea...@eyrie.org> To: "Simo Sorce" <s...@redhat.com> Cc: "Rémi Ferrand" <remi.ferr...@cc.in2p3.fr>, kerberos@mit.edu Sent: Friday, November 7, 2014 8:19:02 PM Subject: Re: [remctl] Proposal for new credential delegation functionality Simo Sorce <s...@redhat.com> writes: > It is a very nice to have, but, it would be really nice if you did not > use unbounded delegation (ie send the whole TGT) but ratherr allow to > either just send a ticket (set of tickets) for whatever action may be > neded, and/or support constrained delegation on the receiving end > (s4u2proxy). s4u2proxy feels like the right tool to me. I don't like the idea of unconstrained delegation, and constrained delegation where the client sends a specific ticket requires the client know what ticket to send. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
