Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
|
Hi Brian, I tried doing what you describe below, with a domain account,
but when the job is started it fails with an error about not being able to switch
to the domain\condor account. This is what’s puzzling to me, because it seems like I have
things working otherwise – in fact, jobs work on my master (when I turn on
startd) exactly the way I want them to run on the rest of the pool… --Ivan From:
condor-users-bounces@xxxxxxxxxxx [mailto:condor-users-bounces@xxxxxxxxxxx] On
Behalf Of Bryan S. Maher --> Ivan, I’m not
sure I fully understand your problem but hopefully I can help. When you
say “user switching is impossible” I believe you are referring to the mechanism
known as “fast user switching” which allows more than one user to share the
console on a non-domain affiliated machine. The fast user switching
mechanism has nothing to do with ability of a operating system to run processes
with different user credentials. You can see this for yourself by opening
task manager and looking at the owner of the various running processes.
You should see many users running processes such as SYSTEM, NETWORK
SERVICE, LOCAL SERVICE, as well as your own username. You can test to see
if your Condor user can run concurrently by doing the following at a command
prompt: Ø
runas /user:condor cmd.exe You will
be prompted for the Condor user’s password after which a command window should
open running under the Condor user’s context. In my environment, I don’t
use a local Condor user (i.e. machinename\Condor) instead I created a domain
user called Condor (i.e. domain\Condor). By using a domain level account
Condor’s rights and privileges can be centrally controlled just like that of
any other user. When
setting up Condor in this fashion you need to be mindful that all jobs will run
in the domain\Condor user context. You should be careful when granting
permissions to that user otherwise you might inadvertently provide a backdoor
to your end-users for elevating their privilege level. My own users
figured out that Condor had more rights than they did so they just submitted
jobs to condor to access files which they could not. Another
thing to keep in mind; since the jobs will be running as domain\Condor, you
need to do store the Condor user credentials on each execution node. You
can do this by logging is as domain\Condor or by using the same runas technique
we used above. Ø
runas /user:domain\Condor cmd.exe In the
resulting command window: Ø
condor_store_cred add -Bryan From:
condor-users-bounces@xxxxxxxxxxx [mailto:condor-users-bounces@xxxxxxxxxxx] On
Behalf Of Michael McClenahan The run as
user option is the cleanest way of doing this but you say it isnt possible as
you are running an NT domain. Before
they added this functionality we had a similar issue, to work around it we
granted Read&Execute perms for the local "Users" group to cmd.exe
and net.exe in %systemroot%\System32. Very easy to do across all machines with
a quick script. We also added it to our machine build process. This will
then allow the local condor user accounts access to these binaries. The obvious
downside is reduced security as you will have to supply a username and password
along with the net use command. Mike From:
condor-users-bounces@xxxxxxxxxxx [mailto:condor-users-bounces@xxxxxxxxxxx] On
Behalf Of Judson, Ivan Hi, I’m deploying
condor on our campus labs. It’s a windows based deployment. I’ve been fighting
job authentication issues, mostly because I have applications and data
installed on a windows share, I think. Here’s what I’ve done and what’s
happened. I’m currently stuck and wondering what the right way to solve this
problem is. Master/Execute/Submit
running on XP box, all execute hosts running on XP. All machines are part of
the NT domain (this makes user switching impossible, apparently). Applications and
data are housed on a share. When condor jobs
try to run, one of a two things happen: 1) If they run as
the “transient” user (done by default), they have no access to the net.exe
command, and therefore can’t mount the share. 2) After reading all
about users and condor and windows, we’ve created the condor user, and it has
the rights to mount the share, which works great except, because we’re part of
the NT domain, condor daemons can’t run jobs as the condor user because user
switching is disabled. What’s the correct
way to resolve this issue? I’m sure there’s some obvious solution that I’ve
overlooked, I just need someone to tell me what it is … Thanks, --Ivan ---- Gloucester Research
Limited believes the information provided herein is reliable. While every care
has been taken to ensure accuracy, the information is furnished to the
recipients with no warranty as to the completeness and accuracy of its contents
and on condition that any errors or omissions shall not be made the basis for
any claim, demand or cause for action. The
information in this email is intended only for the named recipient. If
you are not the intended recipient please notify us immediately and do not
copy, distribute or take action based on this e-mail. All messages
sent to and from this email address will be logged by Gloucester Research Ltd
and are subject to archival storage, monitoring, review and disclosure. Gloucester
Research Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London WC1E
7EA. Gloucester
Research Limited is a company registered in England and Wales with company
number 04267560. ---- |