Re: [Condor-users] Condor 6.7.18 on Windows XP SP2 questions on c redd and feedback

[Greg Quinn <gquinn@xxxxxxxxxxx>]

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>)

Scott,

"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