[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] Question about configuring a pool password



By design, users do not have access to the password, so they cannot use it.
 I'm not sure whether client tools will even try using PASSWORD
authentication.
Interesting. In our case, it looks like root can run condor_status (on a non-cm host), but a non-root user gets authentication error even though they have permissions to access the password file. Same thing happens when running condor_q -global on the cm. I guess root can pass for condor_pool, but regular users can't?

What I am actually trying to do is configure our password-protected pool so that commands like condor_status and condor_q work for any user, but only from machines that are part of the pool (i.e. have the pool password file). Is there a way to do this without explicitly listing the machines from which those commands are allowed, or setting up a condor password for every user?



Thanks very much,

Vlad





On 12/13/16 11:38, Fischer, Max (SCC) wrote:
By design, users do not have access to the password, so they cannot use it. I'm not sure whether client tools will even try using PASSWORD authentication.
It's sufficient if you have another authentication besides PASSWORD, e.g. FS.

Cheers,
Max

Am 13.12.2016 um 17:54 schrieb Vladimir Brik <vladimir.brik@xxxxxxxxxxxxxxxx>:

Also, I didn't mention that earlier because we were talking specifically
about PASSWORD, and you shouldn't be using PASSWORD for
user-to-daemon communications.  Thus, you don't want to require
PASSWORD using the SEC_DEFAULT_* mechanisms.
Do you mean it's not possible to use password authentication for user-to-daemon communications?


Vlad



On 11/16/16 12:55, Zach Miller wrote:
-----Original Message-----
From: Kandes, Martin
Sent: Wednesday, November 16, 2016 12:50 PM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] Question about configuring a pool password

Zach,

Okay, cool. Thanks. One last follow-up question then: Would you still have
to specify the SEC_NEGOTIATION_* options if you already have the
SEC_DEFAULT_* options specified? i.e., I assumed explicitly setting
SEC_DEFAULT_* would implicitly also set SEC_NEGOTIATION_*.


SEC_DEFAULT_* is used if SEC_NEGOTIATION_* is not defined.  It's a fall-back, not an override.

Also, I didn't mention that earlier because we were talking specifically about PASSWORD, and you shouldn't be using PASSWORD for user-to-daemon communications.  Thus, you don't want to require PASSWORD using the SEC_DEFAULT_* mechanisms.

Hope that helps.


Cheers,
-zach

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

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

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

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



_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

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