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}