Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My development pc at the office is NOT on the Active Directory. It's a normal install, no domain. Everything works fine.

When i wish to connect to a share drive, I need to map the drive with my company credentials

eg. CompanyDomain\UserName and password eg. Foo\User1 and secretpassword

Works great.

So now I'm trying to run Visual Studio and SSMS under my NETWORK user credentials. So i left-click-hold the shift button, right-click the application icon under the 'start' button, and then left click the Run As A Different User.

I enter my credentials (as above) .. and fail. Say's my credentials are bad.

WTF? Is there any way I can fix this? figure out what is goin gon?

cheers :)

P.S. OS is Win 7 RC

share|improve this question

closed as off-topic by MDMarra, Falcon Momot, mdpc, kce, TheCleaner Feb 3 '14 at 15:33

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must be relevant to professional system administration. Server Fault is dedicated to professional system and network administrators. End user and enthusiast questions are off-topic (contact your system administrator or hire a professional to help you out). Please see the Help Center for more information." – MDMarra, Falcon Momot, mdpc, kce, TheCleaner
If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 4 down vote accepted

You can only run an application under an account that exists locally. But as Windows will fallback to using the {username,password} you entered to authenticate on when other methods fail (or are unavailable) there is a work around.

Create a local account with the same name (domain\pure.\pure) and the same password, then run the program that needs network resources under the new local account. You will need to ensure the new local account has access to the local resources it needs also.

share|improve this answer
Richard, can u please elaborate what you mean by: you can work around by having a local account with the same name and password as the domain account and using that. – Pure.Krome Jul 14 '09 at 11:49
@Pure: Usually, yes. – Richard Jul 14 '09 at 13:29
@Richard: um .. no no .. can u explain what u mean by the original statement (i quoted) -- i don't get it. – Pure.Krome Jul 14 '09 at 14:15
@Pure: Expanded to try and be clearer. – Richard Jul 14 '09 at 20:02

Assuming I understand the question correctly:

When you map a domain resource like a network share you need to authenticate to the domain controller, hence you put in your domain username and password as you describe.

But the Visual Studio installed on your PC is a local resource and if your PC does not belong to the domain no domain accounts will have access to it. To run VS you would need to authenticate locally to the SAM on your PC, and obviously this requires a local account. You won't be able to run VS as a domain account unless you have in some way granted domain accounts access to your PC i.e. joined your PC to the domain.

Why do you need to run VS as a domain account? Is it so that VS has access to domain resources? If so just run VS as normal, but map a network drive (any network drive) first, and VS should be able to use domain resources.


share|improve this answer
Your assumption is correct :) I was trying to see if I could run VS as a domain account so, when i try to remote debug, it's connecting (both directions) as my domain account and not the local (foreign) account. Also, i was going to see if I could run SSMS as a domain user, and then log in with INTERGRATED instead of using a Sql User to authenticate :) – Pure.Krome Jul 14 '09 at 11:46

Your computer is foreign to the domain, and as such foreign to the fileservers etc. When you map a drive, you supply the foreign resource fileserver with your foreign credentials, the fileserver authenticates with the domain, which works fine because the fileserver is a member of the domain. When you RunAs a local application with foreign credentials, it doesnt work because your workstation cant authenticate with the foreign domain.

share|improve this answer
Now that makes a lot of sence! Gotcha now :) ... damn it. i was trying to be too tricky, then? – Pure.Krome Jul 14 '09 at 11:50

Just use runas command with /netonly switch and it should work. Like this:

runas /netonly /user:DOMAIN\username "path to the application.exe"
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.