Hi Christoph,

On Tue, Oct 02, 2012 at 07:00:40AM +0000, Christoph Mueller wrote:

> I have been researching the web for some time, but have not yet found
> a definite answer to the question whether SGE can be used with
> Kerberos authentication. My questions are: How can I forward the
> user's ticket from the submit hosts? Does SGE provide any built-in
> means for that?

AFAIK SGE once had built-in support for Kerberos 4 but it has been
broken for a long time now.

> Otherwise, could it be done using startup scripts?

Yes, there are prolog and epilog scripts as well as hooks meant for AFS
called set_token_cmd, pag_cmd and token_extend_time for doing just that.
They're documented on man 5 sge_conf. There is a collection of scripts
for AFS (https://dvinfo.ifh.de/SGEwithAFS). But as far as I know there
is no ready-to-use solution for Kerberos V.

Also, these hooks are not meant to actually forward user credentials to
the exection hosts. Instead they are supposed to somehow obtain them on
the exection host. For AFS this is done by having a daemon that has
access to the AFS cell's cryptographic key that essentially forges
users' credentials.

This could be done for Kerberos as well but would require giving the
daemon access to the keys of *every* kerberised service the users need
access to. If this can not be clearly defined, it'd even need access to
the users' actual keys (i.e. passwords) for forging TGTs. This would IMO
be a security nightmare.

> Is there any support for automatically renewing ticktes for
> long-running jobs?

set_token_cmd looks right for that, but will only be called while
the job is running. This is inconvenient for Kerberos because tickets
need to be renewed while the job is waiting as well.

This problem (and others) can be avoided using Constrained Delegation
or Protocol Transition. I gave a talk on that at this year's DFN CERT
workshop in Hamburg. The slides (German) explaining various options can
be found here: 

http://www.dfn-cert.de/dokumente/workshop/2012/Folien_Weiser.pdf

There was a longer paper published in the conference proceedings as
well. There was no real resonance however which is why I couldn't get
any traction to actually implement some software. So, as of now there is
no software for actually doing what is proposed in the talk.
Implementing a proof-of-concept using shell or python scripts should
however be a matter of man hours, not months.

> If I have the ticket on the host that runs the job script, the problem
> should be solved for MPI as its children are started using SSH, and I
> could just change the login method of SSH from pubkey to KRB5. Is that
> correct?

Yep, and forward the user's TGT to the other execution hosts using the
-K or GSSAPIDelegateCredentials options.

There are patches for OpenSSH to extend Kerberos support
(http://www.sxw.org.uk/computing/patches/openssh.html). I'm not
up-to-date on how much of them ever made it into mainline OpenSSH. IIRC
these patches include support for re-forwarding the TGT when the ticket
cache on the originating host changes, i.e. the set_token_cmd has
obtained a new ticket for the user (options GssapiRenewalForcesRekey and
GssapiStoreCredentialsOnRekey).

Let me know if you come up with anything or find something I've
overlooked,
-- 
Michael Weiser                science + computing ag
Senior Systems Engineer       Geschaeftsstelle Duesseldorf
                              Martinstrasse 47-55, Haus A
phone: +49 211 302 708 32     D-40223 Duesseldorf
fax:   +49 211 302 708 50     www.science-computing.de
-- 
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Michael Heinrichs, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196


_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users

Reply via email to