OSFMount and Admin rights

[eobiont]

When using previous versions of OSFMount, admin rights have not been required. I am not sure if this is because we set the OSFMount to start automatically or not. We would like to enable secure boot and so need to use a newer version to avoid driver signing problems.

Now, with version 2.0 of OSFMount it seems like Administrative rights is a hard requirement - even if the OSFMount service is already running, the user is still prompted for credentials or UAC elevation any time the osfmount.com file is accessed.

Is there any way around this? We would like users to be able to use a ram disk as part of their workflow, but I can't give them admin rights. Can the COM file be elevated or run in a way that doesn't ask for credentials?

I am nearly certain the 1.5 version didn't have this requirement if the OSFService was already running on the client.

[David (PassMark)]

When using previous versions of OSFMount, admin rights have not been required.

This is not correct. Admin rights have always been required.

This page has the detail on driver code signing.
https://www.osforensics.com/faqs-and...nt_driver.html
(it is a complex mess due to Microsoft)

I think there is still an option in Windows to disable the UAC prompt. Maybe you can do that?

[eobiont]

I have needed admin rights to install OSFMount, but not to make calls to osfmount.com -- not if the service is already running.

While running elevated, I mount a drive, which starts the OSFMount service. I then edit the registry to set the service to start up as "automatic" . Now I can reboot and the service starts up automtically - it doesnt have to wait for the user to invoke a command to start up. Once the OSFMount service has been configured as automatic, I've been able to let normal users run programs that call commands via osfmount.com and it was not prompting for credentials.

I am using compiled autoit scripts to make the calls like

ShellExecuteWait(@ProgramFilesDir & "\OSFMount\osfmount.com", "-a -t vm -m n: -o cd -o ro -s 270M",'','open',@SW_HIDE)

and

ShellExecuteWait(@ProgramFilesDir & "\OSFMount\osfmount.com", "-D -m N:",'','open',@SW_HIDE)

and

ShellExecuteWait(@ProgramFilesDir & "\OSFMount\osfmount.com", "-a -t vm -m n: -o rem -o rw -s 280M",'','open',@SW_HIDE)

etc,,,

With the 1.5 version the osfmount.com was not requiring admin credentials - however that version doesn't work with secure boot enabled.

When I install version 2.0, and run the same commands, I am prompted for administrative credentials.

[eobiont]

I was able to resolve this problem with help from your tip.



I overcame the problem by adding an environment setting to my program (a compiled autoit script) that calls osfmount.com -- EnvSet("__COMPAT_LAYER", "RunAsInvoker")

When I set that environment variable in my program, it overrides the manifest I think is present in osfmount.com and allows the program to function without needing or requesting admin rights. I have found that as long as I set the osfmount service to start automatically (start type = 2) then I am able to make ramdisk type calls to OSFMount.com without admin rights.

Thanks for giving me the hint about suppressing UAC. I was going to go down the road of building a shim for osfmount.com, but in doing more research I found I could just set an environment variable for Compat_Layer set to RunAsInvoker in my process that calls osfmount.com. I really appreciate the tip and even more I appreciate you making this software available.

Also, we have secure boot enabled in Windows 10 - 1709 and OSFMount version 2.0 works great! I read through your notes about driver signing... I don't know why Microsoft has to make things so difficult and I'm sure very frustrating. Thank you for working through that mess to allow OSFMount to work with secure boot enabled. I think it is really a big improvement for security to be able to leave that on whenever at all possible.

[David (PassMark)]

Thanks for posting the solution, it will surely help someone else at some point.