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
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.
condor-users-bounces@xxxxxxxxxxx [mailto:condor-users-bounces@xxxxxxxxxxx] On Behalf Of Judson, Ivan
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 …
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.
Research Limited, 5th Floor, Whittington House,
Research Limited is a company registered in