Re: [HTCondor-users] Lost in IDTOKENS

[Todd L Miller <tlmiller@xxxxxxxxxxx>]

> However, at the moment after reading the manual, I don't know how to enroll 
> local users into this scheme.
	Although submitters can be granted IDTOKENS, in many cases, they 
don't actually need them.  If your submitters, like most, only submit jobs 
by logging into your APs, they can do so using FS instead of IDTOKENS.
> continue to ssh into the schedd machines and can 
> condor_submit/condor_q/condor_rm all they want (especially also condor_q 
> -better-analyze which needs direct read access to a remote collector).
	We frequently allow READ-only access to our collectors to anyone 
the firewall lets through.  (It can be convenient to configure that access 
as the ANONYMOUS method.)  If you'd rather not, and you can't automate 
IDTOKENS, consider using REMOTE_FS, instead (assuming you're willing to 
mount the same shared filesystem on the APs and the CM).
> Final side note (for now), how would one prohibit a user from generating a 
> request for another user's identity? So far, I drew blanks from the manual on 
> that.
	As far as automation, condor_token_fetch is the tool for 
automatically generating IDTOKENs, and as such gives the caller a token 
with the (HTCondor) identity they validated themselves as, e.g., by using 
FS.  If your APs have the pool signing key, and FS is turned on for your 
APs (as proposed above), then you might even just be able to run 
condor_token_fetch out of a user's dotfiles.  (Assuming that if the user's 
dotfiles are available, then so will be .condor.)
- ToddM