On 10/03/2014 06:32 PM, Nordgren, Bryce L -FS wrote:
>> I guess a fundamental question is: how would a FreeIPA/sssd
>> cluster handle a "batch job/queue submission workflow"? For instance,
>> I submit my job now, with my active ticket. It runs tomorrow, when
>> ticket is expired. Some available GSSAPI integration hooks in "Son of
>> Grid Engine" are here :
>> .html What's missing and how would the queueing system need to
>> interact with FreeIPA/sssd?
> If I read it right the solution sends TGT around. It does not help when TGT
> would expire before the job is run.
> I think GSS proxy is the solution that you want to consider in this case.
> You might want to consider some constrained delegation i.e. s4u2proxy and
> s4u2self for this use case.
I agree that it looks like it's sending TGT around, and this exposes the user to the
possibility that the TGT will expire before the job runs.
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
You do not give it "your" keytab. It has its own.
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
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.
Of the two, I suspect I'd prefer s4u2proxy if: a] s4u2proxy can acquire a forwardable
TGT; and b] the only thing which can impersonate me is the queue master.
can be configured to do s4u2proxy and AFAIR it can change the
user if configured to do so. It has been built for this use case in mind
Simo would know more.
In any case, this is a band-aid, as jobs may run longer than a TGT is valid (say a week
What if gss-proxy were given a proxy certificate (RFC3820) instead of a keytab file?
PKINIT to the KDC to maintain the TGT. Plusses are that long running jobs could always
have a current TGT. Minuses: same issues as a keytab file; anyone with the proxy can be
me. OTOH, dogtag's secure store could be set up only to release the proxy certificate
to authenticated Kerberos principles (e.g., the gss-proxy services). I'm sort of
liking that. We'd just have to make sure that part of the queue submission process is
the issuing of a proxy certificate for the queue manager to act as me. Users could be sent
a warning if their proxy certificate is going to expire and instructions on how to extend
the proxy. Also want to check to make sure this can be done without fiddling with the
queue manager's internals.
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.
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.
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.