JML54
Contributor
Contributor

Authority issue for HDD access (Windows 10 Pro)

Jump to solution

I have a situation that revolves around security for a added Hard Disk which is defined as an entire HDD partition (Disk 1, Partition 2).

Thanks to another kind and knowledgeable member, I was helped in how to create a persistent drive using an entire partition. That issue is solved.

Further testing though reveals that:

  1. Access is limited to a very specific set of criteria, specifically the launch of the VMWare Workstation Pro 12.5 host must be done as "Run as administrator".
  2. Launch of the host using any other method results in "You have insufficient permissions..." message.
  3. The partition, though assigned a name, has NOT been assigned a drive letter and therefore, is invisible to Windows Explorer. Although other techniques are possible to access the drive, this is adequate for the use purpose.

I have checked the security on the hidden drive (before any attempts to define, add and implement the drive in VMWare 12.5) and where it appeared to be inadequate, the security was updated to include, all with appropriate authority (other than FULL)::

  • Administrators (Group)
  • Individually defined profiles (both my Admin Profile and the Standard User profile.)
  • Other groups which have access authority:
    • Users
    • Everyone
    • and standard system level groups

All needed authorities appear to be in place.

Is there a way to solve the access issue on a drive as a physical partition?

The end-state is to use the drive from a VMWare Workstation 12.5 host launch when using a Standard User profile and w/o launch using "Run as administrator". This has been easily implemented and executes w/o issue for other defined clients that do not have a partition defined as a Hard Drive.

As support, my rig is as follows:

  • AMD 8-core FX8320
  • 32GB DDR3
  • 20.5TB HDD (across five physical drives.)
  • Windows 10 v1703 (will all current updates applied.)
  • VMWare Workstation Pro v12.5.7 (Build 5813279)
    • Six clients defined, standard configuration includes: Windows 10 v1607 (current updates), 16GB RAM, 4 processors

Any guidance is greatly appreciated!

Jim

0 Kudos
1 Solution

Accepted Solutions
cdc1
Expert
Expert

You can try this: User-Mode Raw Disk Access

... but be aware, the problem you have encountered is a restriction that is by design from Microsoft, as documented here: https://support.microsoft.com/en-us/help/942448/changes-to-the-file-system-and-to-the-storage-stack-...

As a side note, if it were me in this position, I would move on to the next project. The hoops required to get this to work crosses a line with me. It adds a layer of complexity which increases the risk of issues, that could in turn damage your reputation more than if you had just moved on to the next project now.

View solution in original post

0 Kudos
8 Replies
frodo
Community Manager
Community Manager

Can you offer more infomration? The VM relative logs, vmx settings, the Host and Guest OS and disk type.  And you metioned you are helped in how to create a persistent drive using an entire partition, can you give more operation details?

0 Kudos
gimmely
Hot Shot
Hot Shot

Access is limited to a very specific set of criteria, specifically the launch of the VMWare Workstation Pro 12.5 host must be done as "Run as administrator".

This is a very common situation where a local admin account or a (Windows) domain account in local Administrators group doesn't seem to be able to achieve the same result in not specifying "Run as Administrator" as in specifying "Run as Administrator", which is mostly due to GPOs if the host is on a domain and controlled/managed by GPOs.  In another word, it's not an issue specific to VMware, rather general to all executables.  Some may give the same results regardless of this "selection" because of, again, GPOs may not put any restrictions on specific "objects".

0 Kudos
JML54
Contributor
Contributor

For host and client, the original thread provided my current rig/configuration parameters. For convenience, please see:

  • Host: Windows 10 v1703 (build 15063.413)
  • Client: Wincows 10 v1607
  • Disk drive type: HDD

For setup help and guidance, I received a response to my earlier thread, titled "Insufficient permission to access file. (Windows 10)".

Operationally, my system is a isolated test bed (see rig configuration in original post) for my clients as we work out the kinks to configuration and final implementation on proprietary company systems. This is a new approach for the company, not yet attempted, and was brought about by SLT discussions to permit confidential and proprietary work by engineers in a distributed environment.

0 Kudos
JML54
Contributor
Contributor

Thank you for the update.

The environment where this is being tested is on an isolated rig, configured as close as possible to the final deployed device. This is for configuration, security and other reasons as required by the SLT (Sr. Leadership Team). - After all, mine is not to reason why... Smiley Happy

I'm a trusted independent contractor, and therefore, use my own device for this work so the companies I work with may request a whole lot of variety in what they ask of me. With maximum configuration of my rig, it can be configured - using VMWare of course - to any required environment as dictated by my clients. And, w/o worry of corrupting my own system... So, after my work is done, the remaining effort is a lot of typing and detail to hand over to my client's internal engineers. Once the POC (proof of concept) is done, they've saved money, I've made money, and all are happy.

This time, I may have put my foot in my mouth, and bitten off more than I can chew... Smiley Sad

Based on your response, the issue is such that it may result in a negative report to the client's management, and conversely the cost of this effort shall increase if they choose to either drop this approach being attempted or to continue. Either one would be an impact to the cost. Me, I won't make as much as I could have; though I'll just move on to another project (with lessons learned.)

The bottom line is that, the final environment where this shall be configured and used, cannot provide the Administrator Password to those where it is deployed.

Jim

0 Kudos
gimmely
Hot Shot
Hot Shot

As I implied in my previous comment, this (topic/discussion) is not specific to VMware - rather, beyond VMware.

However, a couple of (additional) comments:

The bottom line is that, the final environment where this shall be configured and used, cannot provide the Administrator Password to those where it is deployed.

If this means that the logged-in user account to run Workstation will not be put into local Administrators group, either individually/directly or "indirectly" via its domain group (membership), then I'm afraid that Workstation may not work properly.

However, I'm not an expert in this, so I hope someone or VMware documentation would confirm if running Workstation requires local admin rights.  I'd not be surprised if the answer is yes because Workstation does and needs "a lot".

Then, your client may be looking for a virtualization production/application with a "client-server" architecture, in which logged-in users don't have to be local Admins and will be running VMs on the client-side of the application while VMs are "hosted" on the server-side.  Workstation is only a stand-alone application, to my impression.

0 Kudos
wila
Leadership
Leadership

Hi,

AFAIK this is a windows limitation.

The direct access that you want to have to the physical disk requires administrator access.

While you might -somehow- be able to get past that by disabling some of the Windows security layers, that isn't exactly recommended and sounds like it is counteractive against what you are trying to do, have a more secure environment.

The only route I am personally unsure about that might work is to use the VM as a shared VM, but I have no idea if a shared VM can be setup to have direct disk access.

A shared VM does not run under the normal local user account like a normal VM does, so with some luck that would work.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
0 Kudos
cdc1
Expert
Expert

You can try this: User-Mode Raw Disk Access

... but be aware, the problem you have encountered is a restriction that is by design from Microsoft, as documented here: https://support.microsoft.com/en-us/help/942448/changes-to-the-file-system-and-to-the-storage-stack-...

As a side note, if it were me in this position, I would move on to the next project. The hoops required to get this to work crosses a line with me. It adds a layer of complexity which increases the risk of issues, that could in turn damage your reputation more than if you had just moved on to the next project now.

View solution in original post

0 Kudos
JML54
Contributor
Contributor

Okay, I'm convinced.

The design paper was right on point, and shall be included in my report summary to the SLT.

The use of the User-Mode Raw Disk Access approach is not a viable solution, nor would I recommend it. The scope of the need does not include bypassing the design to ensure integrity of the system/drives. This piece of information shall not be provided to the engineers (though many may be aware already) and certainly not to the SLT.

Based on the results, my paper to the SLT shall reflect the constraints and the potential options, none of which shall operate below the design of the base OS and certainly none that shall include potential work-around to that design (virtual drives are not an option either, as the approach may introduce other factors that would interfere with the work of the engineers.)

Your response, though not the expected answer, is in fact the answer to my inquiry.

I thank you for your insight, knowledge sharing and guidance.

Your response is appreciated!

Jim

0 Kudos