Re: [HTCondor-users] host based authentication for condor_submit -remote

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

Hi Kevin,

For daemon-to-daemon communication, you may want to look at the PASSWORD authentication method. Like munge, this is based on a shared secret stored in a file that both daemons have access to.

Unlike SLURM or PBS, thereâs no standalone munge-like daemon that a host can run to authenticate with the remote schedd on behalf of the user.

The most commonly used mechanisms (outside using CLAIMTOBE for debugging) are either KRB5 or GSI.  Both of these are easiest when they piggy-back on pre-existing site authentication methods.

If you have neither KRB5/GSI, then another option would be FS_REMOTE authentication method.  This would require both the client and server side to have access to a shared filesystem (basically, you use the shared filesystem as a mechanism to establish trust).

As you point out, host-based authentication and CLAIMTOBE are approximately equivalent.

Brian

> On Jul 27, 2016, at 10:53 AM, Fox, Kevin M <Kevin.Fox@xxxxxxxx> wrote:
> 
> I've been trying to figure out how to do this too.
> 
> Does the host based auth do any kind of validation that one user isn't claiming to be another user on that host?
> 
> NFS does that by at ensuring the tcp port used is a root only one.
> 
> SLURM uses MUNGE to do something similar. Non root users on the machine can ask a root owned process on the machine to vouch for them.
> 
> Can you do something like run a stub schedd on your local machine that has no actual queue, but submits the job on to the remote schedd with its own creds vouching for the user validated via FS?
> 
> Thanks,
> Kevin
> 
> ________________________________________
> From: HTCondor-users [htcondor-users-bounces@xxxxxxxxxxx] on behalf of Todd L Miller [tlmiller@xxxxxxxxxxx]
> Sent: Wednesday, July 27, 2016 8:28 AM
> To: HTCondor-Users Mail List
> Subject: Re: [HTCondor-users] host based authentication for condor_submit -remote
> 
>> If you just want host-based authentication, you probably want to enable
>> the CLAIMTOBE mode: that allows the client to simply assert an identity,
>> and the server will believe it.
> 
>        You don't normally have to do this, and probably don't want to;
> CLAIMTOBE is mostly intended for debugging.  What you probably want to do
> instead is reconfigure HTCondor to not require authentication at all --
> host-based authorization at least checks DNS entries against the peer
> address of incoming connections, but CLAIMTOBE does nothing at all.
> 
>        The default for SEC_DEFAULT_AUTHENTICATION is OPTIONAL, so you
> don't normally have to do anything to use host-based authorization.  If
> you've changed that in your configuration, you may have to change it back.
> (HTCondor can use both host-based authorization and GSI/kerberos/etc
> authentication simultaneously, but it's trickier to configure.)
> 
> - ToddM
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> 
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> 
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/