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

["Froebe, Scott" <froebes@xxxxxxx>]

Ah, thanks Greg for that explanation.  I was missing the shared password bit.  Now everything works great.  Since this isn't in the manual yet, is there a timeline for the windows sections of the manual to be updated to 6.7.18?

 

 

 

Thanks,

Scott

-----Original Message-----
From: condor-users-bounces@xxxxxxxxxxx
[mailto:condor-users-bounces@xxxxxxxxxxx]On Behalf Of Greg Quinn
Sent: March 29, 2006 4:38 PM
To: Condor-Users Mail List
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
> <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
_______________________________________________
Condor-users mailing list
Condor-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/condor-users

CONFIDENTIAL AND PRIVILEGED INFORMATION NOTICE

This e-mail, and any attachments, may contain information that
is confidential, subject to copyright, or exempt from disclosure.
Any unauthorized review, disclosure, retransmission, 
dissemination or other use of or reliance on this information 
may be unlawful and is strictly prohibited.  

AVIS D'INFORMATION CONFIDENTIELLE ET PRIVILÉGIÉE

Le présent courriel, et toute pièce jointe, peut contenir de 
l'information qui est confidentielle, régie par les droits 
d'auteur, ou interdite de divulgation. Tout examen, 
divulgation, retransmission, diffusion ou autres utilisations 
non autorisées de l'information ou dépendance non autorisée 
envers celle-ci peut être illégale et est strictement interdite.