On 10/03/2014 07:23 PM, Nordgren, Bryce L -FS wrote:
If I understand GSS proxy right, I provide a keytab with my password in it so
that it can get a TGT as me whenever it wants. The keytab may not be human readable, but it is directly usable by kinit. This seems too much like typing my passwd into a plain text file.
You do not give it "your" keytab. It has its own.
Ah. I had to give k5start a keytab with my encrypted password in it. It doesn't have its own Kerberos identity. How does gss-proxy authenticate as me, then?
I also don't understand how s4u2proxy can be considered "constrained"
delegation, or even really delegation: "The client has no control over whether a service can delegate on behalf of the user. The client does not request delegation nor does it pass a forwardable TGT to the service. The client cannot detect that delegation will be, or has been, performed. If local policy allows the service to perform S4U2proxy delegation, this delegation is performed solely at the discretion of the service." It sounds more like identity appropriation to me. Like "su - <username>" by root.
No. This is not how it works. S4U2proxy running on service A takes your ticket that you sent to service A and asks KDC can I get a ticket to service B for this user on user behalf. It is constrained in the terms of KDC having all the policies to define the rules which services set A can impersonate which users talking to services B. It is constrained by these relationships. It is not wild west.
Wouldn't my service ticket expire at the same time my TGT does? How does this help me make sure my ticket stays valid for the life of my long lived process?
The part in quotes was from the Microsoft website explaining how s4u2proxy works. Bullet #1 (not quoted), seems to say the opposite of the above. The verbatim quote is from the fourth bullet point, here:
http://msdn.microsoft.com/en-us/library/cc246079.aspx
I would be very happy to learn that this is a mistake, but their page is clear to the point of being emphatic.
First they talk about S4u2proxy and s4u2self at the same time on the same page and it might be a bit confusing. S4u2proxy works as i described. S4u2self allows a service A to acquire a ticket on user's behalf for itself. This is controlled by central policy. Which services can do that for which users. If them this service can use s4u2proxy then it can impersonate user but only for the purposes of working with service B and not in general. User does not provide any keys for that.
Yes client does not have any control. It is totally abstracted from the client by service A. The whole intent is that the control is between configuration of service A and policies on the KDC and client does not need to know anything. AMO it is big win not a problem.
The certificate or keytab are not different from each other so I really do not see a point here. Everything that you describe can be done just using a keytab.
Ah, so we're back to "what's in the keytab?" If it's gss-proxy's keytab, what does it have to do with me? How does my identity get delegated?
What I was trying to say is that whether you give some one your keytab or your pki pair it really does not matter. Then they have them and they can do kinit or pkinit on your behalf that would result in the TGT.
In case of S4U you do not give the service the end user keys at all. Instead you craft policies on the server side who can impersonate whom and for what purpose. So if you have a controlled environment and there is a job manager that is trusted to run the jobs it can also be trusted to get user tickets. So if you do not have a user ticket or it expired it can do s4u2self and then s4u2proxy and launch the job with a fresh ticket.
IPA can manage s4u2proxy but it is not exposed in the UI [1]. I do not recall what is the state of the policy management related to su2self. may be it is time to file a ticket.
[1] https://fedorahosted.org/freeipa/ticket/3644
In any case, keytabs are long term secrets (for users or services), and proxy certificates are not. If I'm going to give something access to my identity, I don't want to be giving it my long term secret (password), but I do want to give it _something_! It's also my understanding that DogTag is set up to securely store certificates, controlling their release to authorized parties. I am not aware of a similar service for keytabs.
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.