permissions login for network files within LabView

[MarcoDelgado]

Hello SandraB1, could you share your example to do this?
I am on the same situation.

I will be grateful.

Thanks.

[bharathp10]

Hi,

I faced access issue while logging into network shared folder and i tried the following to get it work.

I used 'net use' command to get the access.

In your case  i think it will give the access to  currently logged  user through explorer. you may need to again login with account having read only rights to avoid this.

[MarcoDelgado]

Thanks!

just one question: 

on the command line, "username" should be replaced by the username used, and "password" by the password? or password is a constant on the command?

[bharathp10]

Yes you need to replace username and password with actual user information. And pc name with actual computer name. The last keyword is persistent yes/no. I used it on a win10.

• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/gg... 

[wiebe@CARYA]

Sorry for joining the party so late.

.NET impersonation can do this. It's tricky, as it's thread based, and LabVIEW doesn't give full control over threads.

Also, no scheme you'll come up with will be safe. Your program will need the user name and password, so it will be exposed at some point. Not to the intermediate users, but to hacker for sure.

Here's a crude library: https://github.com/Carya-Automatisering/LogonUser

Note that net use has very big disadvantages. For instance, if you kill your application before the drive is removed, the drive (and credentials) will remain available to the user.

Net use will also fail if the user (or the IT department) makes another net use to the same server... Ask me how I know.

[MarcoDelgado]

Yes, that is what I thought, is not secure at all, and can be easily hacked. 

Good, let me try with that  library, it has the same purpose?

Have you had troubles with IT deparment using "net use"?

[wiebe@CARYA]

---

@MarcoDelgado wrote:

Yes, that is what I thought, is not secure at all, and can be easily hacked. 

Good, let me try with that  library, it has the same purpose?

---

No application that uses credentials to login is safe. The credentials can be read and used by the application, so everybody can read and use them if they know how. That's just how it is. 

Of course if you can install the application on a machine that is totally under your control, things are better. You can actually use Windows security to deny certain things. If 'hackers' are not allowed to, for instance, start the application in a debugger, you can make things harder.

---

@MarcoDelgado wrote:

Have you had troubles with IT deparment using "net use"?

---

I've delivered a solution that used use net. Then it stopped working. Turned out IT added mapped network drivers to the same share I was 'net using' to. So it stopped working...

I've used runas as well, but that stopped working under Windows 10.

Started using runacp (IIRC). Windows 10 deals with credentials differently as Window 8... In Windows 10, if the application has "user A" rights, it will loose "current user" rights. So the user couldn't save files on his desktop, because (s)he didn't have the rights. Also, if the application has those rights, nothing is stopping the user to use any application browse dialog to go to the protected files.

It's not easy, that's for sure.

I've tested the .NET impersonation with network files and AX and .NET database connections to database files (I'm not sure I've tested windows credential bases database access). Besides the credentials being available, and a few caveats, it worked well for me.

[bharathp10]

Hi,

Yes i was worried too about access being compromised.

I used it because it was required for short time and systems were not connected to the internet. 

Is there any setting available in windows/net use to logout specific user using timeouts?

Thanks

[wiebe@CARYA]

I doubt net use has an automatic disconnect feature. It's really not the purpose of the tool.

If I'd wanted net use to automatically disconnect, I'd probably start a batch file to start it, then pause, then disconnect. But this will expose the credentials even longer. And killing the process will still prevent the disconnect.

The .NET impersonation will only work for given thread(s). So if the process (or even the thread) stops, the impersonation is gone. The only gap is the username\password has to be send to the OS (LogonAs, IIRC), and this call can be monitored, or the information can be extracted. As similar to every other method...