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.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.