[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Condor 6.7.18 on Windows XP SP2 questions on c redd and feedback
- Date: Wed, 29 Mar 2006 15:38:24 -0600
- From: Greg Quinn <gquinn@xxxxxxxxxxx>
- Subject: Re: [Condor-users] Condor 6.7.18 on Windows XP SP2 questions on c redd and feedback
Froebe, Scott wrote:
I found that my issue with credd is the following:
# Only honor password fetch requests to the trusted "condor_pool" user
CREDD.ALLOW_DAEMON = condor_pool@($UID_DOMAIN
"condor_pool" does not have to be a Windows user account. It is a
principal from the perspective of Condor's security system.
Version 6.7.18 adds a new authentication method called PASSWORD, which
relies on a shared secret between two parties for authentication and
encryption. Future releases of Condor will see this method become more
full-featured, but for now it is only available on Windows and can only
be used for inter-daemon authentication. When PASSWORD authentication is
used successfully for daemon-to-daemon authentication, the name of the
authenticated principal is "condor_pool@$(UID_DOMAIN)", which explains
the entry in example config file that you mention.
In order to make PASSWORD authentication work, you need to distribute
the shared secret. This is done via the familiar condor_store_cred tool
via the new "-c" option.
C:\> condor_store_cred add -c -p foo
will store the pool password "foo" to the local machine (there must be a
condor_master running for this to work). This must be done for each
machine that you want to be able to run jobs as the submitting user.
It can also be done remotely, via another new option, "-n", to
C:\> condor_store_cred add -c -n crow.cs.wisc.edu -p foo
Although this should be avoided if Condor cannot construct a secure
channel to the remote host. (The tool will tell you and make you confirm
if you are about to send the pool password over an insecure channel.)
One way of getting a secure channel is to use the NTSSPI authentication
method, but it requires either a domain setup or a common
username/password across standalone machines.
Once you have the pool password distributed, you should be able to
submit jobs that will run as the submitting user by adding the following
line to your submit file:
run_as_owner = true
I'd suggest submitting c:\windows\system32\whoami.exe as a job to test
out this functionality.