[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

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 <mailto: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.

For example,

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 condor_store_cred:

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.

Good luck!

Greg Quinn