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

["Giffels, Manuel (IAP)" <manuel.giffels@xxxxxxx>]

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/

Attachment: smime.p7s
Description: S/MIME cryptographic signature