The support forum

Network share access under Admin/Service mode?

Alex Pankratov :

Nov 05, 2013

.
So I want to pick everyone's brain on this.

Here's a problem - a program running with full Admin privileges (via "Run as Administrator") on Vista+ does NOT see existing mapped drives. Nor can it access network paths that are accessible in the non-admin mode *if* those require different username and/or password.

In other words, you map a drive, you open a console via Run as Admin, check the drive and it's not there. Apparently, this is by design.

--

The underlying cause is that starting with Vista, there are TWO logged in user sessions sharing the desktop. One is limited-privilege session (pre-UAC) and second is elevated, full-admin session (post-UAC). Each session has its own set of drives and connected network shares.

From the usability perspective this is a major pain in the butt.

--

There's a simple registry fix - http://technet.microsoft.com/en-us/library/ee844140%28v=ws.10%29.aspx - but in a typical Microsoft fashion it doesn't always work.

A "proper" fix according to another Microsoft article is to re-map drives and re-connect shares in elevated session when needed. The problem here, of course, is that you need a username *and the password* to do that in many cases. And this is what I wanted to ask about -

1. How would you feel if an app would ask for a share username and a password and reconnect required drives and shares for you?

2. Alternatively, I can have it launch a console window with standard "net use..." and that's what will prompt for the username and password instead. Not sure if it's better - is it?

3. What about storing username and passwords? It's either a password prompt on every login into Windows -or- it's a password stored somewhere in some form in app's config. What's worse?

Any thoughts in general - let me know. I'm just a bit stuck thinking about this.

jrothlis :

Nov 05, 2013

I thought you fixed this? It works fine for me in Admin mode, backing up to my network share...

Alex Pankratov :

Nov 05, 2013

I put a couple of hacks in that cover two specific cases, one of them must be yours. But in general situation this cannot be done without knowing username/password that was used to map the drive or connect a share.

adrewbus :

Nov 08, 2013

I would be all for being able to apply credentials - usernames and passwords- to each specific job, that get stored securely and must be re entered if the the task gets edited. Also non viewable by the person editing so it stays secure. I'm betaing this at a family small business that has a server requiring user name and passwords. Different locations have different passwords, and some computers back up to multiple locations on that server. (I didn't set it up, i'm just trying to make it work.) Currently I use acronis as it allows credentials per task, but bvckup is so much faster! I'm not a programmer i don't know what it would take to implement, but it would nice to have. That being said, major props all around! This software is excellant in design and implementation!!!!

Alex Pankratov :

Nov 10, 2013

@adrewbus - Thanks, all noted. There's a built-in Windows service that is meant for storing sensitive data and making it unavailable to processes outside of user's context - http://msdn.microsoft.com/en-us/library/aa922939.aspx

I haven't used it before, just saw it mentioned, so I'm not set if it's the right way to go.

That being said, major props all around! This software is excellant in design and implementation!!!!


!! :)

theCrow :

Jul 24, 2014

Is there a fix / workaround for this issue in Wiindows 8.1? The registry hack doesn't seem to help.

Alex Pankratov :

Jul 24, 2014

To get obvious out if the way - have you rebooted?

If yes, then fhe workaround for now is to open the console as Administrator and access the share with "net use". A proper fix is to specify share's username/password and support for this will be in the next release; most of the work has already been done - https://bvckup2.com/wip/20072014 - should be out next week.

theCrow :

Jul 24, 2014

Sorry for being unclear. I actually already had that entry in the registry - can't remember why but there it was. Nevertheless, I tried rebooting but still get the error "Destination device not found".

It was working fine when running Bvckup 2 normally but I decided that running it as a service would be better after I had some problems with the registration (for some reason, it kept telling one of my home computer's two users that there is no license although I've entered the correct license code).

I'm happy to wait for the update for a while. The program seems to be absolutely great for my needs when this thing gets sorted out.

Alex Pankratov :

Jul 24, 2014

Ah, Ok.  That regiatry setting is meant for resolving run-as-admin flavor of the issue. When you switch to the service mode it is all much more straight-forward - the app simply runs under a different account called LocalService and as such it cannot log into the remote computer.

The workaround is to create a separate account, add it to the BackupOperators group, grant it required access right on the remote end and then switch bvckup2 service to run under this account.

Or you can wait for the update and specify the logon credentials explicitly.

All this said however - are you sure that you really need to run the app as a service? It's primarily meant for headless servers.

genl :

Jul 25, 2014

I think it should be similar to how Windows does this:

- display a window asking for username/password.
- save the last used username by default, don't save the password.
- add an option to save credentials to never ask those again (display again only when they are not valid anymore).
- maybe add a warning/note about the fact that Bvckup will be saving credentials independently from the OS.

For your questions:
1. User would reconnect his shares anyway so why not do it rightaway?
2. It will only serve good if user doesn't trust Bvckup, I guess. Question is, is there anyone like that? Also, I think there may be certain conditions where network shares would disconnect due to different (Windows related or not) issues, so user may decide to make it automatic afterall - then he will be disappointed if Bvckup is only be able to launch a console for him to enter credentials by hand every time.
3. Many apps do not hesitate to save user credentials independently. Why should you?

I think the part with "must be re entered if the the task gets edited" proposed by adrewbus is unnecessary. If someone got to that menu it means he is already logged in with privileges high enough to cause far more damage.

theCrow :

Jul 25, 2014

This goes badly off-topic for this topic but the reason why I tried running it as a service is that for some reason I can't get it to work for two users as a normal program. For one of the users the program keeps asking for license and stops automatic backups after each backup because of the missing license (for the other it works fine after entering the license key). I also can't get the program to start automatically for either user when logging in to Windows even though I've selected "Launch when you log in to Windows" in Preferences for both users.

theCrow :

Jul 25, 2014

Nevermind the licensing thing. This https://bvckup2.com/support/forum/topic/232 solved that.

Lurch :

Jul 25, 2014

1. How would you feel if an app would ask for a share username and a >password and reconnect required drives and shares for you?


2. Alternatively, I can have it launch a console window with standard "net >use..." and that's what will prompt for the username and password instead. >Not sure if it's better - is it?


I'd probably go for option 2, although I do have trouble with mapping different drives with different user credentials, even when all mapped drives are deleted Windows stores some sort of cached log in somewhere so this may be an issue in some circumstances. If Bvckup could store different log in credentials for separate paths with no issues then I'd say use the first option.

3. What about storing username and passwords? It's either a password >prompt on every login into Windows -or- it's a password stored somewhere >in some form in app's config. What's worse?


I'd give the user the option, I have a few different scenarios on different machines, some spend quite some time popping up login prompts and splash screens for various apps and network logins so it's sometimes preferable to avoid adding more. However some people don't like storing passwords on the local machine for anything so always good to have the option.

Any thoughts in general - let me know. I'm just a bit stuck thinking about >this.


I think using the Windows built in controls make sense as it saves re-inventing the wheel as it were, although if the built in controls don't work then roll your own.

Alex Pankratov :

Jul 28, 2014

(I thought I replied to this a couple of days ago, but apparently the post didn't go through)

The way I have it done in Release 70 is that it obfuscates and stores the password in backup's settings.ini. Obfuscation is relatively strong, but it can obviously be reversed by a determined attacker. It is primarily meant for protecting against lazy snooping and it's generally meant for home users, where such snooping won't be that likely. For professional setups the share access needs to be configured at the system level and, presumably, this part of the backup config won't be used to begin with.

Also, popping up a Login dialog is not a good idea, because it splices user interaction into backup process, which is something that tends to lead to all sorts of "funny" edge cases.

Rogier :

Jan 30, 2015

You could try MapDrive.
Screenshot: http://imgurl.nl/2C
Link: http://zornsoftware.codenature.info/blog/windows-7-disconnected-network-drives.html

It allows you to start network drives with different usernames, passwords and addresses on startup.
Just create a simple batch script and run it on startup, example:

***
@ECHO OFF
SET mapdrive=C:\MapDriveFolder\MapDrive.exe
@%mapdrive% Y: \\192.168.2.10\backup-profile username password 5
@%mapdrive% Z: \\192.168.2.10\backup-public 5
EXIT
***

New topic

Create
Made by Pipemetrics in Switzerland
Support


Follow
Twitter
Dev blog
Miscellanea Press resources
Testimonials
On robocopy
Company
Imprint

Legal Terms
Privacy