I would recommend you use NTSSPI or IDTOKEN. There is no reason to use PASSWORD if you are running HTCondor 24.
"host" based authentication one of those ideas from the Linux version of HTCondor that doesn't really apply
to the Windows version in quite the same way. When we say host based is bad, what we really mean is that its bad on Linux
becasue ordinary users can inpsersonate daemons if you use host based security policy.
but on Windows using NTSSPI a service on one machine can prove to a service on another machine that it is running as a service using the SYSTEM account. They can do that if both
machines are in the same NT domain. So for machines in the same NT domain, NTSSPI is the best choice for authenticating HTCondor daemons to each other. Also for authenticating users to the SCHEDD daemon, and for authenticating specific users to run administrative
tools like condor_reconfig.
The MSI installer will put the user that ran the installer into the ALLOW_ADMINISTRATOR list by default, you need to add any others by hand. It will add identities for IDTOKEN
and PASSWORD to ALLOW_DAEMON by default.
Now, if your machines are not in a common NT domain. the next best choice is IDTOKEN. IDTOKEN can do everything that PASSWORD can, and much more. If two machine have the
same secret value in their c:\condor\tokens.sk\POOL file, then IDTOKEN behaves just like
PASSWORD, allowing daemons that can read that file to authenticate to each other as either condor_pool or condor identity.
Remember that SEC_CLIENT_AUTHENTICATION_METHODS is used by users when they send commands, and by daemons when they act as the client
talking to other daemons. you should never set SEC_CLIENT_AUTHENTICATION_METHODS that that to just PASSWORD, because tools do not have access to the secret necessary to use PASSWORD authentication.
You should generally not need to change SEC_CLIENT_AUTHENTICATION_METHODS or any of the SEC_ knobs away from their default values.
The installer should leave condor_config with something like this in it. (johnkn the user that ran the installer)
...
use SECURITY : recommended_v9_0(SYSTEM, Administrator@*, johnkn@*)
##--------------------------------------------------------------------
## Settings from the the installer questions
##--------------------------------------------------------------------
INSTALL_USER = johnkn
...
You can edit condor_config.local to make changes to the security config to add ALLOW config for machines
and for additional administrators.
On the central manager, you need to add identifiers of the other machines in the pool to ALLOW_DAEMON like this
# use the DENIED messages as a guide to the machine names to add here
ALLOW_DAEMON = $(ALLOW_DAEMON) hostname$@company
# or just use a wildcard to match multiple hostnames
ALLOW_DAEMON = $(ALLOW_DAEMON) *name$@company
# give bob the ability to run admin commands like condor_off and condor_reconfig,
ALLOW_ADMINISTRATOR = $(ALLOW_ADMINISTRATOR) bob@company
-tj
Subject: [HTCondor-users] windows authentication ht-condor 24.1.1
Hi,
I am working on testing ht-condor 24.1.1 on a small network of Windows 11 workstations. These machines are in a secure environment and only authenticated users can access the machines. I need to be able to utilize the run as owner option to launch jobs as
the user who submitted them.
Is there a recommended authentication method I should use? I see Host-Based Security mentioned by HTCondor as less secure but I'm not sure how to setup
I tried to setup the recommended security method and did the following.
I successfully setup and ran ht-condor on 1 machine. I have condor_credd running on that machine and can successfully use the run as owner option on that machine. The machine with the initial setup is running, collector, credd, master, negotiation, procd,
schedd, shared_port,, and startd.
Now, I would like to install ht-condor on each users workstation with submit and execute roles so that users can submit jobs from their workstation and run on anyone's workstation in the pool.
So I installed ht-condor on a 2nd windows 11 workstation. While reading the documentation, I feel like I just need PASSWORD authentication and have created a pool password on both machines, condor_store_cred add -c
On my 1st machine (Central Manager) which works, condor_store_cred add, works fine.
On my 2nd submit execute machine I get, condor_store_cred add -c
Enter password:
Operation failed.
Make sure your ALLOW_WRITE setting includes this host.
I have tried to allow everything using * for most things,
ALLOW_ADMINISTRATOR = *
ALLOW_READ = *
ALLOW_WRITE = *
ALLOW_CLIENT = *
ALLOW_NEGOTIATOR = *
SEC_CONFIG_NEGOTIATION = REQUIRED
SEC_CONFIG_AUTHENTICATION = REQUIRED
SEC_CONFIG_ENCRYPTION = REQUIRED
SEC_CONFIG_INTEGRITY = REQUIRED
If I change to SEC_CLIENT_AUTHENTICATION_METHODS = PASSWORD then my 1st machine doesn't work.
So for now I am using
SEC_CLIENT_AUTHENTICATION_METHODS = NTSSPI, PASSWORD
but this gives me the following in the master log file on my 2nd computer.
11/07/24 14:01:38 SECMAN: FAILED: Received "DENIED" from server for user hostname$@company using method NTSSPI.
11/07/24 14:01:38 ERROR: SECMAN:2010:Received "DENIED" from server for user hostname$@company using method NTSSPI.
11/07/24 14:01:38 Failed to start non-blocking update to <ip addres of master:9618>.
I have through the config process process twice re-reading the documentation and spending 4 hours each time on it but still end up with the same issue.
Thanks for the help!
Andy
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}