On 09/29/2014 09:54 PM, Nordgren, Bryce L -FS wrote:
> -----Original Message-----
> From: sssd-users-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
> bounces(a)lists.fedorahosted.org] On Behalf Of Nordgren, Bryce L -FS
> Sent: Thursday, September 25, 2014 4:13 PM
> To: dpal(a)redhat.com; End-user discussions about the System Security
> Services Daemon
> Subject: Re: [SSSD-users] rocks cluster user mgmt
>
>> The configs do not talk about SSSD at all. This area definitely
>> requires some face lift.
>> I wounder if they are aware about SSSD and IdM? Any chance someone
> can
>> ask them to consider SSSD and IdM using SSO as you described above?
I guess a fundamental question is: how would a FreeIPA/sssd compute 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 :
http://arc.liv.ac.uk/repos/hg/sge/source/security/gss/doc/gss_customer.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.
Interesting conference proceeding from 2001. A little dated, but you can see how they
guided some GSSAPI/Kerberos development in the 2000's.
http://www.sc2001.org/papers/pap.pap192.pdf
Bryce
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.