Re: [HTCondor-users] valid mapped user name

[Rita <rmorgan466@xxxxxxxxx>]

Thanks for your response Todd.

I am using SSL authentication. In my StarerLog on remote scheduler I can see this message when I run condor_q -name otherhost

DC_AUTHENTICATE: authentication of <ip:port> did not result in valid mapped user name, which is required for this command (519 QUERY_JOB_ADS_WITH_AUTH), so aborting.

The SSL key and cert file match on both server and client.Â

On Thu, Feb 25, 2021 at 9:14âAM Todd Tannenbaum <tannenba@xxxxxxxxxxx> wrote:

On 2/22/2021 12:19 PM, rmorgan466@xxxxxxxxx wrote:

Hello.

I am trying to do condor_submit subfile -name hostA

But, I keep seeingÂ

"...did not result in valid mapped user name, which is required for this command..." on hostA'sÂscheduler log file.

How can I fix this?Â

Hi,

So my understanding of the above is you are trying to submit a job to a schedd running on a remote server (hostA). I also assume you are on Linux, and you can run condor_submit successfully if you actually logged in to hostA and ran condor_submit there.

When you try to submit from job to the schedd, the schedd needs to authenticate (determine) the user that is running condor_submit. It does so via an "authentication method". HTCondor has several supported authentication methods (idtokens, fs_remote, ssl certicates, gsi certicates, munge, etc), but unfortunately most of them require additional setup to work when trying to authenticate over the network from one host server to another.Â

An explanation of the authentication choices is in the manual at:Â https://htcondor.readthedocs.io/en/latest/admin-manual/security.html#authentication

Example using FS_REMOTE: If your two hosts have a secure shared file system in common, and the user ids (UIDS) on the two hosts match (e.g. in /etc/passwd user rmorgan has UID on both hosts), then you create a tmp directory with chmod 777 on your shared file system and add the following to the config on both hosts:

  # FS and IDTOKENS are good defaults. Here we add FS_REMOTE so hosts can submit
ÂÂÂ # to a remote schedd so long as they can both mount /some/shared/path/tmp
ÂÂÂ SEC_DEFAULT_AUTHENTICATION_METHODS = FS IDTOKENS FS_REMOTE
ÂÂÂ FS_REMOTE_DIR = /some/shared/path/tmp

Example using IDTOKENS: If you are running v8.9.7 or above of HTCondor, login to the schedd host (hostA) as the user who wants to submit jobs remotely (e.g. user rmorgan) and run:
ÂÂÂ condor_token_fetch -token rmorgan_htcondor_token
This will create the file "rmorgan_htcondor_token", and anyone who can read the contents of this file can authenticate as rmorgan to the schedd on hostA. So treat this file with care! If you move this file to he remote server where you are trying to submit and place it in subdirectory ~rmogan/.condor/token.d/ then things will work.Â

If you are on a private network behind a firewall and trust everyone who can access both hosts, you could setup CLAIMTOBE authentication which simply tells the schded to trust whomever condor_submit claims to be without requiring any proof.Â

Hope the above helps
Todd
Â

--

--- Get your facts first, then you can distort them as you please.--