What Im trying to do is map a network drive using a VB script at login through my GPO. What seems to be happening is when a user logs in, the script is executed, but it stalls at the actual mapping of the drive. From what I can surmise, it stalls here because no valid username or password has been supplied and thus I get Access is denied. I came to this conclusion because when I take the same address and enter it into a normal explorer window or map drive wizard, it prompts for a username and password and thus allows access, but the script does not give this same prompt.
When I wrote this script, I was hoping that the same credentials that were used to login to the workstation could be somehow used to also login to the mapped drive, but so far, I've had little luck.
I included the script that maps the drive as well, verbatim.
Any Ideas?
Thanks in advance.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
my guess is your problem resides somewhere in the credentials negotiation process (hehehe, I know, DUH, you already knew that....)
however, there are specific reasons why this may happen... If you've successfully connected to the server via "net use" then part of the battle is over... you've proven it CAN be done..
my guess is there's a problem in the process or logic or structure in your authentication request... I didn't notice any reference in your response describing the authentication protocol you're testing (user@domain typically suggests DNS type auth, domain\user typically suggests a netbios form of authentication...) often both approaches will work, but not always... if possible, can you modify your script to attempt both methods?
We use a DNS type of auth domain\user
But, regardless of my attempts, my whole issue centers around the problem of the lack of the username and password prompts.
I guess to clarify, when I put the same address into an explorer window or try to map the drive, the typical username and password prompt appears and I get access. However, when the script runs, it doesn't display those prompts and thus errors out or times-out. Same with the "net use" command, when I enter the command by itself, it prompts for the username and password, but in a batch file, it errors out.
My ultimate goal is to prevent the user from entering their username and password again, but at this point i see no way around it as the server requires this login.
I'm somewhat confused why your users should have to re-authenticate themselves at all to a server in a trusted environment...
are any of your users accessing multiple servers w/ multiple credentials?
e.g. user1 logs onto server1 with account1
user1 logs onto server2 with account2
OR
is user1 employing multiple protocols to access server resources?
e.g. NFS to server1, FTP to server2, etc?
also, I believe you may be mistaken w/ regard to the first statement in your last post.... DNS auth is NOT domain\user, rather, DNS is user@domain
all of that aside, it's well known and frequently discussed the fact M$ doesn't provide an easy/secure means to pass credentials to shared resources via the command line... I am familiar with a few methods to accomplish this task but they all require clear text storage and/or clear text transmission of the credentials... typically this is a BAD approach.
I've recently tested and researched creative methods to leverage scheduled tasks to provide a semi-secure, semi-reliable, semi-fluid means for providing access to certain resources to our end users...
e.g.
say you define a scheduled task on CLIENT1 that's defined to execute with USER1's credentials... now, your credentials are stored and (for argument's sake, protected.)
you could write a script, create a shortcut, whatever, to launch that task from the end user's desktop. When the task runs, it will execute with the predefined credentials... no interaction required...
e.g.
client1 host
scheduled task list
task points to mapjdrive.bat
that task is defined with user1's credentials
user1 can launch that task via a script or shortcut
the task will map the drive with user1's stored credentials
done
it's not perfect or pretty, but it can work... I'm confident superior techs here can suggest a better approach than this, but for now..... ;-}
"I'm somewhat confused why your users should have to re-authenticate themselves at all to a server in a trusted environment... "
Exactly my point, this same question has had me scratching my head for a week now.
The way I want this is to work is when a user logs in to a workstation via the domain, this map drive script executes so I can redirect the my documents folder to the newly mapped drive. The drive i'm trying to map is a fileshare that is given to every user that can be accessed via the web, but my goal is to allow access to these shares through the desktop.
What I can't figure out is why should my users have to re-authenticate to access their shares. Normally, in a domain environment, a user can gain access to whatever resources they are trying to use, provided their in that group. No re-authentication necessary, it just works.
All of your solutions work, but unfortunately are unsecure and would not be allowed by my network admin.
I guess in the end I may have to ask them to re-authenticate again. Not a big deal, I'm just a perfectionist.
Business Accounts
Answer for Membership
by: fhmcPosted on 2008-07-14 at 20:05:36ID: 22003877
upfront, I have ZERO VB script experience; however, I consider myself to be rather handy w/ batch scripting and command line logic...
1. a review of both the client and target's security logs may prove usefull
2. conducting a similar set of instructions, manually, line by line (likely via ANOTHER method may help as well)
e.g. from the command line on the client side, execute a similar set of instructions line by line and verify the logic works
3. protocols matter... m$ windows type example, domain\user is very different than user@domain... possibly the username credentials aren't being passed to the host in an acceptable format?
4. if possible, can you test a similar script locally to the client?
ex... say you're currently attempting to map drive J on CLIENT1 to a shared resource on SERVER1.
can you define a shared resource on CLIENT1 to map drive J to?
essentially, can CLIENT1 map drive J to a shared resource of its own?
again, this isn't my field of expertise so my logic may very well be completely off base...