Re: [HTCondor-users] Windows credd, pool password, run_as_owner

[John M Knoeller <johnkn@xxxxxxxxxxx>]

So this message

<store_cred_handler> (0) for command 479 (STORE_CRED) from CONDOR-SUB-ENT4$@nexus <aaa.bbb.ccc.ddd:54406>

indicates that whatever is running the condor_store_cred command is running as user CONDOR-SUB-ENT4$  

Is that your helper service?  You said the helper service is running as local system, but that does not appear to be the name of the local system account, so I'm a bit confused.  

The  "condor_store_cred add" command will not allow an ordinary user to set the password on an account other than the account running the command.   The local system account would not be considered an ordinary user, but CONDOR-SUB-ENT4$ is not the system account.

Users listed in the CRED_SUPER_USERS knob can store the password for any user. 

So I can see two ways for you to fix this,  

   1)   switch to the user you want to store the password for before calling condor_store_cred add.

   2)  add CONDOR-SUB-ENT4$ to the CRED_SUPER_USERS list.

   3)  run your service as the SYSTEM user

-tj

---

From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Hitchen, Greg (IM&T, Kensington WA) <Greg.Hitchen@xxxxxxxx>
Sent: Wednesday, February 23, 2022 1:01 AM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: [HTCondor-users] Windows credd, pool password, run_as_owner

 

Hi All

I have put in the necessary configuration items on our windows submit nodes and windows execute nodes
to allow users to "run_as_owner".

This has been tested, is about to go into production, and works as expected.

That is, no "net use" statements are needed in the job batch files, and users can still access their fileservers.
We are using "pool password" authentication.

All users first need to run the "condor_store_cred add" command so that their credentials are saved on
the credd server. All good so far.

Most of our users just use cmd line stuff for submitting files and this works fine.

The issue if for a particular group that use a GUI app. This sets up monte-carlo simulations and back-ends
the jobs to their HTCondor submit nodes. This backend communicates with the submit nodes via a simple
"remotequeue" service (RUNNING under the "local system account") that runs on these submit nodes.

This service listens on a particular port and responds to a few simple plain text requests:
status dummy dummy - return number of running and queuing jobs on the submit node
storecred username password - run condor_store_cred to update user credentials on the submit node
passwdcheck username password - check whether username/password combo corresponds to a valid account
queue username password - call 'remotequeue' program on the service to manage various tasks

So users run this GUI software on their own machines and it send jobs to the submit node. They have no
direct interaction with the submit node itself.

What happens on the credd server when they now try to store their credentials is:

"There are a number of successful AUTHENTICATE and PERMISSON GRANTED lines first which I haven't listed"

02/23/22 15:28:27 (fd:4) (pid:1708) (D_COMMAND) Calling HandleReq <store_cred_handler> (0) for command 479 (STORE_CRED) from CONDOR-SUB-ENT4$@nexus <aaa.bbb.ccc.ddd:54406>
02/23/22 15:28:27 (fd:4) (pid:1708) (D_ALWAYS) WARNING: store_cred() for user hit023@nexus attempted by user CONDOR-SUB-ENT4$, rejecting

If that same user logs directly into the submit machine and in a cmd prompt uses the "condor_store_cred add"
command then that runs fine.

I'm a bit stuck on why this is happening, and how to make it work, or work around it.

Thanks for any help/advice/comments.

Cheers

Greg


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