6

I'm currently looking for a way to autorize my non administrators users to perform an installation of drivers.

Here is the speech:

All my users are standard users, they got a VirtualBox Hypervisor if they need the administrator rights.

But if they put an USB device on the local machine and try to redirect the device to the Virtual Machine, Windows ask for some Administrator rights.

I've try to set up those GPO:

  • Allow standard users to install drivers.
  • Install WHQL Drivers: Allow Silently.

I don't know how to do this.

Jordan W.
  • 1,423
  • 1
  • 13
  • 20
Dr I
  • 955
  • 17
  • 33
  • 6
    In fact, if you allow any nonprivileged user to install drivers, you subvert the whole security model of Windows, as a driver can do anything... But if you feel safer than giving them Admin rights... – mihi Nov 29 '10 at 23:27
  • 2
    What kind of drivers? The platform is w2k3 and xp? Do you just want the ability to install the driver or do they also need to be able to create a device that uses the driver? – Matt Jan 24 '11 at 02:26
  • 1
    I want to echo Mihi, comment, if you are removing admins rights you are probably concerned with security, it really subverts the model to allow driver installation, especially on windows XP (vista/windows 7 has some special policies on removable devices that make this issue not apply on that platform) – Jim B Jan 27 '11 at 16:02
  • I wonder if there isn't some way to just forward usb control to the virtual environment, like some sort of virtual usb hub... – Jeshizaemon Jan 27 '11 at 17:58

3 Answers3

3

Are you talking about Win7/Vista environment?

I would try this

1) Open up a GPO/policy editor 2)Computer Configuration\Administrative Templates\System\Driver Installation\Allow non-administrators to install drivers for these device setup classes - Enabled

Allowed device setup class GUIDs:

You might find the GUID you need here:

http://msdn.microsoft.com/en-us/library/ff553426%28v=VS.85%29.aspx

Chadddada
  • 1,680
  • 1
  • 19
  • 26
  • Oups I missed that, no in fact we are working under Windows 2003 Domain and forest. Our clients are under Windows XP. And I've found two GPO on W2K3 but there are not working because it's only for non-plug-and-play devices. – Dr I Jun 15 '10 at 11:58
2

The answer realistically is to upgrade. This is functionality was requested about 8 years ago and provided for in windows vista on up. There are specfic security enhancements pertaining to drivers and controlled by security policies now (Computer Configuration\Administrative Templates\System\Driver Installation). While there are partial workarounds that kinda get you there, all of them cause more headaches and other issues then they are worth. You'll spend more time fiddling around with this issue than you would dealing with any potential compatability issues with windows 7.

If you are really stuck with windows XP for some reason your best option is to preinstall the USB drivers required for the devices.

Jim B
  • 24,081
  • 4
  • 36
  • 60
1

I think for the average user, where the devices they may add are unknown ahead of time (and constantly changing), this is not possible or easily managed. However, for your specific scenario, is adding a USB device the only device they need to be able to add? If so, can you control what kind\brand\make\model of USB device? IF so, you can pre-install signed drivers and allow local users to load them. Note the difference here between load and install. Using the GPO setting in User Rights Assignment>Load and unload device drivers this below might work for you.

Copying with my own edits in brackets from an experts-exchange article:

Only Administrators can add device drivers.

The only way to accomplish this without giving users this permission is to due the following:

  1. Create a [network share with appropriate permissions]
  2. Create a folder structure [in this share for all devices but try to keep the full UNC paths as short as possible]

Each subfolder [should] contain just the drivers for each device you want to install.

Once you have your drivers copied there, you must change the following registry key on each machine by script in a GPO>Startup script.

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion :: DevicePath

Add the UNC path to this key to where the drivers are located. You MUST point to each subfolder in your Drivers folder - example \servername\share$\A\0; etc...

A great tool for this is SetDevicePath - which can be run on a reference machine each time you add drivers so it will modify this key for you. All you have to do then is export the key then modify the reg file you're pushing out.

SetDevicePath: http://www.flachestirn.de/msfn/SetDevicePath.exe

Simply drop into a CMD prompt where this tool is located and run SetDevicePath \servername\Share$. It will parse all folders in there for you and set your key accordingly.

By using this key and the share, Windows will install drivers that you have available automatically without needing the user to be an Admin.

Additionally:

be careful of the length of your Path in this key. Keep the foldernames to 1 or 2 digits to conserve characters...

You are limited to 4096 characters in Windows 2000. In XP, the key can only be 64Kb.

Start with one driver to see how it behaves. Add others as you see the need to.

Some additional clarification, the policy setting mentioned above assumes the drivers are already installed.

Also from the same article

If you set this up correctly then all a user needs to do is call in when they need something new and you can add it to the share. The user then just needs to reboot and log into the domain.

Jordan W.
  • 1,423
  • 1
  • 13
  • 20
  • 1
    In regard to that article you copied, anyone who advocates giving all authenticated users full control over something they only need read access for has lost all credibility. It also seems to be an extremely high maintenance way to do the job. – John Gardeniers Jan 28 '11 at 20:25
  • John - I partly agree agree. Except that the way I read it, I think they are saying in the Share Permissions give full control and specify more restrictive permissions at the NTFS level which I believe is the generally agreed upon best-practice way of doing things. I fully agree that this is a high maintenance way of doing it but don't see any other way. – Jordan W. Jan 28 '11 at 20:31
  • if you are adding the drivers to the system ahead of time why wouldn't you simply add the drivers to the driverstore. I believe (but would have to verify as I'm working mostly with win 7) that drivers that exist in the driverstore do not require admin rights to use - since they are already installed. – Jim B Jan 28 '11 at 22:22
  • Jim, I haven't tested this either but I think this is in effect redirecting the drivestore to a share and then you can manage this shared drivestore in one place instead of on all your workstations. As another device driver is needed, you just add it to the share. – Jordan W. Jan 29 '11 at 21:01
  • @jordan, yeah I get that it would just be far simpler to add something like this via scritp to each workstation. Redirecting the driverstore to a share makes me wonder about the stability of the client machine (what happens if the share in unavailable on startup or when a driver is requested?) – Jim B Jan 30 '11 at 15:17
  • @Jordan, I think you'll find that the idea of giving anything greater than the permissions that are actually required at either file or share level isn't "best practice" at all and hasn't been a common practice amongst experienced admins for at least a decade. – John Gardeniers Jan 30 '11 at 20:44
  • @John, obviously this can be a long discussion, only replying b/c I'm very surprised to see this. Everywhere I've worked, both full time and as a consultant, for just over a decade, that has been exactly the way things were done. Authenticated Users got Full Control at the Share level and NTFS permissions we set more restrictive\least privilege required. Not saying right or wrong, just what I've seen in my career. A quick googling shows cases for both methods. – Jordan W. Jan 30 '11 at 21:15
  • @John, as far as CIFS shares go I'm pretty sure that the recommended practice is to set share perms at everyone/fullcontrol and NTFS perms as appropriate, unless you have a specific use case for using the share perms to change permissions (eg users locally logged in required full access but the same users accessing via share need restricted perms) – Jim B Jan 31 '11 at 00:29