Mailing List ArchivesPublic Access |
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesPublic Access |
|
|
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 ---- |