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

[Jaime Frey <jfrey@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