UAC Prompt Looks Like Administrator Prompt but Administrator Cannot Rename File

Topic

New Reply

I was helping a customer with a software package installation. The installer package is created by the SageKey Access 2003 packager product. The installer installs the MS Access 2003 runtime, the Access 2003 SP3 update and several other files. It then runs an additional patch to install the latest version of MSCOMCTL.ocx. Microsoft initially released a broken update for MSCOMCTL.ocx. Then subsequently rereleased the update but the rerelease doesn’t fix the broken update, if it was already installed. Fixing the broken update is performed by a .Net 2 process. It’s essentailly a script of a manual process outlined by Microsoft to repair a broken MSCOMCTL.ocx patch.

Upon launching the application, if the broken MSCOMCTL.ocx installation is detected, the same .Net utility that was run in the installer package is run again. This is for situations where an update was performed, instead of the full installation.

I remoted into the user’s computers so I didn’t physically see them and time was of the essence so I wasn’t able to check the specs. There were two computers with the problem and the customer said that they were identical computers. They both ran Windows 7. I saw that one of them was an HP but I don’t know the model. As stated earlier, the application that I’m working on is a Microsoft Access 2003 runtime application. It’s possible that a newer version of MS Office was also installed but this shouldn’t be an issue. Many other computers running this application have another version of MS Office installed and have no issues.

Other machines for other customers are working without issue. This particular customer is an administrator. I don’t know what the state the computer was in when she ran the installer but I found that the correct version of the ocx file existed but it was improperly registered. Upon trying to fix the registry, both manually and by using the .Net utility to fix it, the UAC prompt for an administrator popped up (the prompt didn’t ask for a user name/password because it detected that the user was an administrator). Clicking OK to continue made it appear like everything was running correctly but the end result was that the user didn’t have elevated privileges so the issue was not resolved. Manually attempting to do the same thing didn’t work. Logged in as my customer, I was unable to rename MSCOMCTL.ocx.

The way I worked around this was to turn UAC off. Upon doing so, it was just a matter of running the .Net utility that fixes the errant registry keys. After doing that, I enabled UAC again and everything proceeded to work, like it should.

Has anyone ever seen a situation where an administrative user would receive the correct UAC prompt for an administrative user, no Windows errors are generated (I need to add some additional error handling to my utility) but UAC is not allowing the administrative user to perform administrative tasks, such as renaming files and running regsvr32.exe? Do you know if there is a fix for this situation?

Reply | Quote

Replies

The only thing I can think is the install process spawns other processes and one of those requires UAC elevation but cannot request it because it was spawned as a background process.

cheers, Paul

Reply | Quote

I understand what you are saying about the installer having issues but that’s not it. The part that’s failing is a utility that was written in VB .Net 2. The utility does the following:
1) Unregisters MSCOMCTL.ocx. It uses regsvr32 and shells out using “Run As”. Since the utilit is already running as an elevated user, no UAC prompt is displayed.
2) Renames the file.
3) Replaces it with an older version of the oxc.
4) Registers the old version.
5) Unregisters the old version.
6) Deletes the old version.
7) Renames the original file back to the original name.
8) Registers it.

If I run this utility, I receive the correct UAC prompt. In the case of most users that are experiencing problems, they are administrators on their computers and they receive the correct UAC prompt but the utility fails to perform all of the steps. It is unable to rename the original ocx file. If, while logged in as the same user, I go into the SYSWOS64 folder, I can manually rename the file. I am not running Windows Explorer as an administrator so I receive the usual message to authorize the file to be renamed. I can also manually unregister and register the ocx using an elevated command prompt, while logged in as the same user. None of the computers that have experienced this problem are on a Windows domain.

I’m trying to figure out why UAC consider’s the elevated user’s security context different between running my utility and manually performing the steps in Windows Explorer and an elevated command prompt. I have been unable to reproduce the problem on any of my development computers.

Reply | Quote

Do they have AV software that you don’t have on your dev system?

cheers, Paul

Reply | Quote

Good suggestion. I hadn’t thought of that and the machines are not popping up any warnings that an application is attempting to write to the file system. I’ll look for that the next time I run into one of these problem machines.

Reply | Quote

Anti-spyware and anti-malware can also meddle with successive Windows sessions if they flag/quarantine file during previous sessions, thus including current session. I have to “educate” my castle moat alligators weekly on what to leave alone.

"Take care of thy backups and thy restores shall take care of thee." Ben Franklin, revisted

Reply | Quote

I created a version of the utility that reported back where it was using message boxes. What I found out is that it is unable to rename the original ocx file that is in SYSWOW64. It did confirm for me that the user is running with elevated privileges. I tried turning off the anti-virus software, which was kind of strange because the virus software then asked me if I wanted to allow the utility to run, which I did. At this time, I don’t believe the issue is caused by anti-virus software.

As stated before, this utility runs on many/most computers with no issues. Any other suggestions?

Reply | Quote

You could try the operation in Safe Mode with Networking to see if there’s anything else on the computer that is conflicting.

That will isolate the AV whereas a clean boot won’t.

Reply | Quote

I believe the difference here is administrator (a member of the Administrators group) vs Administrator (the default Windows Administrator account, usually disabled). There are some tasks (such as messing around with some system files, etc.) that need the express privilege level of the default Windows Administrator.

Being logged in as a member of the Administrators group does not invoke the privilege level of the default Windows Administrator, counter-intuitive as that might be.

For example, I routinely run as a standard user. I have an account in the Administrators group named Admin. In my standard user account, when I want to run some activity that requires Administrator group privilege, the UAC popup has the Admin account login; I put in the password and off I go.

If I want to run a Command Prompt, I click on the shortcut and a Command Prompt window opens with the prompt reading “C:Usersbbearren>_” and the title bar says “Command Prompt”.

If I want to run an elevated Command Prompt, I right-click the Command Prompt shortcut, select Run as administrator, put in the Admin password at the UAC popup, and I get a Command Prompt window with the prompt reading “C:WindowsSystem32>_”, and the title bar says “Administrator: Command Prompt”.

If I am logged into the Admin account (member of the Administrators group) and click on the Command Prompt, I do not get an elevated Command Prompt. I get a Command Prompt window with the prompt reading “C:UsersAdmin>_”, and the title bar says “C:WindowsSystem32cmd.exe”. This command window has limitations, even though I am logged on as a member of the Administrators group; it is not an elevated Command Prompt.

While logged into the Admin account, if I right-click the Command Prompt shortcut and select Run as administrator, I get a Command Prompt window with the prompt reading “C:WindowsSystem32>_”, and the title bar says “Administrator: Command Prompt”. This is an elevated Command Prompt, and doesn’t have the limitations that “C:UsersAdmin>_” has.

Regardless of the type of account, standard or member of the Administrators group, Run as administrator invokes the privilege level of the default Windows Administrator account. That account doesn’t have to be enabled to invoke the privileges, but the password of an account that is a member of the Administrators group is necessary to get past UAC and invoke the privilege level of the default Windows Administrator account.

There are only a couple of instances that I know of where the default Administrator account must be enabled and logged on, but those involve delving deep into the bowels of the registry, and I don’t think many people go there. On my systems, I enable the default Administrator account, give it a password, and then disable it. The default Windows Administrator level of privilege can still be invoked by a member of the Administrators group.

Bottom line is that a member of the Administrators group is not elevated to the privilege level of the default Windows Administrator—even when the UAC pops up and one clicks “Yes”. It doesn’t matter that you might be logged on as a member of the Administrators group. To get that privilege level, right-click (Command Prompt or some executable) select Run as administrator, then click “Yes”.

Yes, it is counter-intuitive, but that’s the way it works.

Always create a fresh drive image before making system changes/Windows updates; you may need to start over!

We all have our own reasons for doing the things that we do with our systems; we don't need anyone's approval, and we don't all have to do the same things.

We were all once "Average Users".

Computer Specs

Reply | Quote

That is as good an explanation as I have, thanks. I am feeling clearer on this topic now. I was not aware that runas admin runs under that Administrator (usually ‘hidden’) account. If you enable the Administrator account and give it a password do you then need that password to runas admin?

Just because you don't know where you are going doesn't mean any road will get you there.

Reply | Quote

That is as good an explanation as I have, thanks. I am feeling clearer on this topic now. I was not aware that runas admin runs under that Administrator (usually ‘hidden’) account. If you enable the Administrator account and give it a password do you then need that password to runas admin?

No, any account that is a member of the Administrators group can be used to invoke the default Administrator privilege level. There is no real need to leave the default Administrator account enabled, though. I only enable it to provide a password for the account (it starts life without a password), then log off, login to my created account in the Administrators group, disable the default Administrator account and leave it disabled.

Always create a fresh drive image before making system changes/Windows updates; you may need to start over!

We all have our own reasons for doing the things that we do with our systems; we don't need anyone's approval, and we don't all have to do the same things.

We were all once "Average Users".

Computer Specs

Reply | Quote