Ivan, Depending on what local group your Condor
user falls under, it may not have sufficient privileges to run jobs as batch
job or service. Using group policy editor, you may need to grant the Condor
user one or both of the following rights: “Log on as a batch
job” “Log on as a
service” - From:
condor-users-bounces@xxxxxxxxxxx [mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of Judson, Ivan 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 - 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, Gloucester
Research Limited is a company registered in ---- |