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
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:
Behalf Of Michael McClenahan
Sent: Tuesday, July 03, 2007 12:39
Subject: Re: [Condor-users]
Questions on Windows Deployment
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.
Behalf Of Judson, Ivan
Sent: 03 July 2007 17:06
Subject: [Condor-users] Questions
on Windows Deployment
deploying condor on our campus labs. It’s a windows based deployment.
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.
running on XP box, all execute hosts running on XP. All machines are part of
the NT domain (this makes user switching impossible, apparently).
and data are housed on a share.
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.
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.
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 …
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.
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.
messages sent to and from this email address will be logged by Gloucester
Research Ltd and are subject to archival storage, monitoring, review and
Research Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London
Research Limited is a company registered in England
with company number 04267560.