Re: [HTCondor-users] Question on using IDTOKEN for draining a worker

[Jaime Frey <jfrey@xxxxxxxxxxx>]

We have a fix ready for an upcoming release. You can see details here:

https://opensciencegrid.atlassian.net/browse/HTCONDOR-3301

 - Jaime

On Oct 10, 2025, at 4:14âAM, Giffels, Manuel (IAP) <manuel.giffels@xxxxxxx> wrote:

Dear Jaime,

thank you very much. I was indeed hitting that bug.

condor_drain -graceful slot1@removed
Attempt to send DRAIN_JOBS to startd <removed> failed
Failed to start DRAIN_JOBS command to slot1@removed

_CONDOR_SEC_CLIENT_AUTHENTICATION=REQUIRED  condor_drain -graceful removed
Sent request to drain the startd <removed> with slot1@removed

Best regards,
Manuel

Am 29.09.2025 um 23:10 schrieb Jaime Frey via HTCondor-users <htcondor-users@xxxxxxxxxxx>:

Your condor_drain must be able to authenticate to the collector at the ADMINISTRATOR authorization level (i.e. authenticate with an identity thatâs in the collectorâs ALLOW_ADMISITRATOR config param). If the command is run as root and your third-party host has a copy of the central managerâs POOL signing key, that is sufficient. Otherwise, you need to create an IDToken for an identity thatâs listed in ALLOW_ADMINISTRATOR and make it available to the condor_drain command.
That allows the condor_drain command to retrieve an administration security capability from the collector that can be used to issue commands to each worker node.

However, your question caused us to discover a bug with retrieving the administration capability when using the default security configuration. You need to force authentication to occur for READ-level commands (e.g. condor_status) when itâs not required by default. You can do this by setting _CONDOR_SEC_CLIENT_AUTHENTICATION=REQUIRED as an environment variable before running the condor_drain command.
We are working on a fix for a future release to fix this bug.

- Jaime

On Sep 23, 2025, at 10:38âAM, Giffels, Manuel (IAP) <manuel.giffels@xxxxxxx> wrote:

Dear all,

I have deployed a key on the central manager and distributed the corresponding IDTOKEN to the worker nodes for token-based authentication.

I now need to drain a worker from a third-party host running a SCHEDD, which also has access to the key.

Iâm unsure about the best approach in this scenario:
 â Do I need to create a second key and distribute it to the workers, using the corresponding IDTOKEN locally on the third-party host to drain?
 â Or is there a simpler/recommended way to perform this operation without creating a new key?

I would appreciate any guidance or best practices for handling IDTOKENs in that scenario.

Thanks a lot and best regards,
Manuel

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe

The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/