The MSI installer does not automatically request a token from the CM.
The admin token in tokens.d after MSI install will have the same identity as the user that installed condor. - Windows MSI installer runtime passes this to the condor installer which uses it as the token identity. That admin token can be used to authenticate to the local condor_master to run commands such as condor_reconfig. It's not really intended to authenticate from one machine to another.
This token is signed by the POOL signing key in c:\condor\tokens.sk, so unless you copy that POOL signing key and the admin token to another machine, that token won't be useful for authenticating to another machine. And even if you did do that, the identity in that token is not one that you should use for daemon to daemon authentication.
If you want your windows nodes to be able to advertise to your Centos7 collector, you should create a token for that purpose on the Centos7 CM and install it in tokens.d on the Windows machine. We currently have no way for the Windows installer to do that automatically. We have some plans for adding that in the future.
You may also want to copy the POOL signing key from the Centos7 CM and overwrite the tokens.sk\POOL on the windows machine, and at that point you can just delete the tokens.d\admin token since it will no longer be usable. on the Centos7 CM run
to locate the POOL signing key file on that machine. Then run the same comand on the Windows nodes and copy the signing key from the CM over the file there. By default this will be c:\condor\tokens.sk\POOL
If the POOL signing key is the same on two machines, then tokens issued on one machine can be validated on the other machine, so could use the Centos7 CM to issue tokens, and they will be considered valid by any machine that has the same POOL signing key. Two machines that have the same POOL signing key can also authenticate to each other even if there are no tokens signed by those keys. it behaves a bit like having a common pool password.
I would suggest that you update your unattended installer to write a token for advertiseing to the CM in tokens.d in addition to overwriting condor_config.
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Beaumont, Martin <Martin.Beaumont@xxxxxxxxxxxxxxx>
Sent: Thursday, November 4, 2021 10:32 AM
To: 'htcondor-users@xxxxxxxxxxx' <htcondor-users@xxxxxxxxxxx>
Subject: [HTCondor-users] IDTOKENS vs Windows compute node in a Linux cluster
I've been using HTCondor for a few years now, but this is my first time asking for advice on this mailing list.
My setup is a cluster made out of a CentOS headnode with compute nodes being either stateless CentOS or stateful Windows provisionned by xCAT.
Since 9.0.0, I've been trying to implement the new IDTOKENS security to my configuration.
It works for Linux compute nodes, but I'm still hitting a wall for Windows nodes.
On Windows, the HTCondor client is installed unattended by SYSTEM prior to first login.
Other than feeding the unattended msi installation and copy/pasting a pre-made config file in C:\condor\config\, no other post-configuration or condor commands are used.
Attached are all the condor_config_val -summary for all 3 node types.
I've also attached the Window's MasterLog when trying to ask for an IDTOKEN.
This is probably the important part:
11/04/21 10:17:54 PW.
11/04/21 10:17:54 PW: getting name.
11/04/21 10:17:54 IDTOKENS: Examining C:\Condor\tokens.d\admin for valid tokens from issuer sms1.
11/04/21 10:17:54 TOKEN: No token found.
11/04/21 10:17:54 PW: Failed to fetch a login name
11/04/21 10:17:54 PW: Generating ra.
11/04/21 10:17:54 PW: Client sending.
11/04/21 10:17:54 Client error: NULL in send?
11/04/21 10:17:54 Client sending: -1, 0(), 0
11/04/21 10:17:54 PW: Client receiving.
11/04/21 10:17:54 Server sent status indicating not OK.
11/04/21 10:17:54 PW: Client received ERROR from server, propagating
11/04/21 10:17:54 PW: CLient sending two.
11/04/21 10:17:54 In client_send_two.
11/04/21 10:17:54 Client error: don't know my own name?
11/04/21 10:17:54 Can't send null for random string.
11/04/21 10:17:54 Client error: I have no name?
11/04/21 10:17:54 Client sending: 0() 0 0
11/04/21 10:17:54 Sent ok.
11/04/21 10:17:54 AUTHENTICATE: method 2048 (IDTOKENS) failed.
So, the client doesn't know his own name apparently. Must have been a severe concussion.
The problem might also be related to not finding a valid token in C:\Condor\tokens.d\admin.
Maybe because he is trying to search for a "" name in there.
Also, no token request is listed on the headnode for that compute node.
Either it's the "" name or the admin file being the problem, I do not know which or how to fix this.
Any ideas would be appreciated.