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

["Fox, Kevin M" <Kevin.Fox@xxxxxxxx>]

Bummer. Ok.

I ran into some issues trying FS-REMOTE with LDAP. wasn't working correctly. Couldn't resolve the uid for some reason. but worked fine with a getent passwd username

Is there any way with host based to limit it to just a few specific users at least, rather then giving access to all users?

I did try and make a quick ssl ca for users to test some things, but I haven't figured out how to do revocations. Any ideas there?

I'm trying to keep things relatively simple to support remote job submission, and full blown gsi seems like overkill, but may be the only way to actually secure the channel?

Thanks,
Kevin
________________________________________
From: HTCondor-users [htcondor-users-bounces@xxxxxxxxxxx] on behalf of Brian Bockelman [bbockelm@xxxxxxxxxxx]
Sent: Wednesday, July 27, 2016 11:40 AM
To: HTCondor-Users Mail List
Subject: Re: [HTCondor-users] host based authentication for condor_submit -remote

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/


_______________________________________________
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/