Limited users (xp) being asked for admin credentials for memory sticks.

[jonathanhaddock]

Afternoon all!

 

A while ago (3+ months) I revoked staff administrator rights over their laptops - something they should never have had in the first place (they were installing all sorts of unlicensed software). The level of malware / virus infection dropped considerably as a result and we've got a better handle on things so I've no reason to change this back.

 

However, just recently a few laptops (Windows XP Pro SP3) have started to request elevated privileges when connecting a USB memory stick or other mass storage device. Previously this worked fine.

 

Anybody experiencing the same problems? Given these are plug and play devices which should be installed straight out of Windows' driver cache this shouldn't be happening.

 

Thanks in advance folks,

 

Jonathan

[kili]

It sounds like these USB sticks have encryption software on them that requires a driver install, certain USB sticks with particular software have this issue when using without admin privileges.

 

Advise your users to buy sticks with U3 software which has password protection .If a stick has encryption software on it this seems to be when it requires admin privileges to install a driver of some sort.

 

I would look in this direction to resolve the issue. We had the same issue with a user who had bought a stick with encryption software which was to complicated for them to use and required local admin privileges to install so I gave her one that was U3 and password protected only which worked fine under her logon.

 

Not as secure as encryption but better than nothing.

 

Hope this helps

 

Kili

[cookie_monster]

Posted twice for some reason, see below.

[cookie_monster]

Another policy that can help here is "Load and unload device drivers" BUT this is not really recommended.

 

Microsoft Corporation

[jsnetman]

This problem used to come and go when we had XP, never got to the bottom of it. Extreme cases we had to rebuild, not much help I know. We also gave the local admin username and password to staff but not students, but not really recommended. Edited June 16, 2010 by jsnetman

[Stevenw]

We have the same problem with 20 of our pupil machines.

 

im thinking its the mass storage driver not being installed, but i have not tested it yet

[AngryTechnician]

If you supply admin credentials, does Windows then tell you it's installing an unsigned driver?

 

If so, then in my experience this is often due to with the security certificate catalogue being corrupt, which leads Windows to believe the built-in mass storage drivers (along with any other drivers) are unsigned. By default, unsigned drivers always require admin privileges to be used with a new device, even if the drivers are already installed on the system.

 

There are a plethora of methods to fix this, all documented here: You cannot install some updates or programs (different symptoms, same root cause).

 

I'll be honest, the first two methods never worked for me, and after a while I learned to skip straight to method 3, which worked almost every time.

[box_l]

I have just had this occur on a trolley of XPSP3 laptops, I had tried the load/unload driver and unsigned drivers thing in GP. But nothing has so far worked.

 

I will try this method 3 fix next time I am in the school.

 

Cheers

 

BoX

[box_l]

Thanks to the AngryTechnician for the pointer in the right direction.

 

Option 3 did the fix for me on the first machine I tried, however i ran into issues on the other machines where I got access denied when renaming the catroot2 folder. Svchost.exe was locking the folder and a file within.

 

I eventually found a script online which i slightly edited so it did not ask the user for any interaction.

 

This is then called from a login script or GPO.

 

It works a treat!

 

 

@echo off
:: Batch file that tries to remedy error # 800710D9
:: "Unable to read from or write to the database".
:: Author: Torgeir Bakken
:: Date: 2004-08-30
:: Stop the Cryptographic service
%SystemRoot%\System32\net.exe sto
p CryptSvc

:: Rename all log files in the %SystemRoot%\Security folder
FOR %%a in (%SystemRoot%\Security\*.log) DO move /y %%a %%a.old

:: Rename the %SystemRoot%\System32\CatRoot2 folder
move /y %SystemRoot%\System32\CatRoot2 %SystemRoot%\System32\CatRoot2old

IF not exist %SystemRoot%\System32\CatRoot2 GOTO CONT01

:: In case the folder rename failed because of locked files
:: rename all log files in the %SystemRoot%\System32\CatRoot2 folder
FOR %%a in (%SystemRoot%\System32\CatRoot2\*.log) DO move /y %%a %%a.old
SET catroot2locked=True

:CONT01
cls
echo.
echo Please wait, this might take some time...

:: Unregister DLL files that are associated with Cryptographic Services
CD /D %SystemRoot%\System32
start /wait regsvr32.exe /s /u softpub.dll
start /wait regsvr32.exe /s /u wintrust.dll
start /wait regsvr32.exe /s /u initpki.dll
start /wait regsvr32.exe /s /u dssenh.dll
start /wait regsvr32.exe /s /u rsaenh.dll
start /wait regsvr32.exe /s /u gpkcsp.dll
start /wait regsvr32.exe /s /u sccbase.dll
start /wait regsvr32.exe /s /u slbcsp.dll
start /wait regsvr32.exe /s /u cryptdlg.dll

:: Reregister DLL files that are associated with Cryptographic Services
start /wait regsvr32.exe /s softpub.dll
start /wait regsvr32.exe /s wintrust.dll
start /wait regsvr32.exe /s initpki.dll
start /wait regsvr32.exe /s dssenh.dll
start /wait regsvr32.exe /s rsaenh.dll
start /wait regsvr32.exe /s gpkcsp.dll
start /wait regsvr32.exe /s sccbase.dll
start /wait regsvr32.exe /s slbcsp.dll
start /wait regsvr32.exe /s cryptdlg.dll

:: Configure and start the Cryptographic service
%SystemRoot%\system32\sc.exe config CryptSvc start= auto
:: Start the Cryptographic Service
%SystemRoot%\system32\net.exe start CryptSvc
cls

echo.
If "%catroot2locked%"=="True" GOTO CONT02
echo Finished, please reboot the computer.

GOTO END
:CONT02
echo Please run the batch file again with a newly restarted computer...
echo if this has not worked
GOTO END

:END
echo.

 

Regards

 

BoX

[Butuz]

From RM:

 

"The problem is caused by damage to the security databases maintained by Windows® XP. These databases are used by Microsoft® Windows® to guarantee the authenticity and reliability of driver files and other key system files via a mechanism of file signing. A signed file will have a corresponding entry within what is known as a CAT file. A CAT file is basically a list of numbers which have been generated using a technique known as MD5 summing. This technique will create a different number if even a single character within a file has been changed, thus making it obvious that a file has been modified.

 

The CAT file is actually the file which is signed, and it is signed with a certificate from Microsoft®. If the CAT file is altered in any way, then the certificate becomes invalid. The knock-on effect is that any files referenced in the CAT file also become unsigned.

 

A key file called an nt5inf.cat is responsible for signing most of the system files that make up the Windows® XP operating system, and every time a service pack is installed this file is updated to reflect the changes made to the system, thus keeping the new files signed. If this file is overwritten with an older copy, for example, from the Windows® XP initial release, then many of the files that make up Windows® XP become unsigned. These files include drivers for storage devices such as pen drives, digital cameras, and many other types of hardware.

 

Administrative rights are required to install unsigned drivers into the system, therefore on a workstation where an nt5inf.cat has been damaged normal restricted users are unable to add new hardware even if that hardware is supposed to be supported out of the box by Windows® XP."

 

Butuz