[RESOLVED] Elevate Code in Vista using VB6

[Michel_K17]

I was unable to find any code on how to elevate to run as an administrator portions of my VB6 code under Vista. So, I tried it on my own, and I am getting really close, but not quite there.

Note: I could simply run a separate EXE using ShellExecute with the "Runas" verb, but I would like to avoid the extra warning and therefore, I am trying to use the COM route.

To summarize, this is what I have done so far:

1. Created a new VB6 ActiveX EXE project.
2. Added a couple of methods
3. Compiled.
4. Added the needed keys to the registry, namely:
   
   - Localized String
   - Elevation\Enabled = 1
5. Created a new VB6 Project as a normal EXE
   
   - Declared the object, and
   - Used the CreateObject Function so that I can use the Moniker:

Dim MyObj As My_Vista.My_Vista_Cmds
Set MyObj = CreateObject("Elevation:Administrator!new:My_Vista.My_Vista_Cmds")
MyObj.Test_Elevate "This Elevation"
Set MyObj = Nothing

Running the program, this is what I get:

Running as an Administrator

• I get the request to elevate
• Click "Allow"
• Object is created
• Methods are available and can be called.

Running as a Standard Vista User

• I get the request to elevate
• Enter the password of the Administrator account
• The COM object appears as a process in the Task Manager running under the Admin's account
• The "Initialize" code of the COM runs correctly
• In the calling program, "CreateObject" fails (70 - Permission denied)

Since the changes I need to make are minor (I am changing the name of a printer), I can run what I need under the "Initialize" sub and then simply quit: it works in that the code is indeed running under the Administrator account, but I would rather use the proper methods/properties to return the results to the user (ie it passed or failed).

Any ideas? Thx!

[RobDog888]

Welcome to the Forums.

Well there is very little nw documentation or support for VB 6 on Vista. What I do know about the security process is that a new security token should be creaetd for minor admin tasks. If multiple tasks are to be done uder the admin account or if one elevation may involve another admin task you need to restart the app using an admin account. I read it on the MS site white paper fo r Vista Security somewhere.

I am not good at security tokens but that is what I remember reading on how it should be done. Should be worth looking into.

[Michel_K17]

Thank you for the welcome.

You make an interesting point: I could move all of the program's preferences to a separate application, and make sure that it is called with an elevated token, or use ShellExecute with the "runas" verb. However, only two out of 30 different settings actually require admin priviledges, so I would rather have it elevate only for those two settings if possible.

Thanks!

[RobDog888]

Is there any way to separate those two?

[mojo_jojo]

I have an application that only requires 2 admin functions. I decided to do these operations in a separate ActiveX exe and use the COM Moniker to elevate this exe.

Set srv = CreateObject("Elevation:Administrator!new:testSrv.Admin")

I was getting the same Permission Error when making a method call into this object as a restricted user.

It seems the ActiveX exe object needs to CoInitializeSecurity.

I was able to get it working using the registry AppID technique refered to at this link: http://na.tm.agilent.com/pna/DCOMSecurity.html

[Michel_K17]

Hi Mojo,

Thanks for the link. Unfortunately, I had no luck with CoInitializeSecurity. This function needs to be called by the main application, not the ActiveX (although I tried it both ways), and it made no difference. I still get the "Permission Denied (70)" error.

The registry settings for AppID apply only to getting CoInitializeSecurity to work properly when you run the code from within the VB IDE, and it does not fix the problem.

The only thing that I found today is this article [here] which may contain useful background information. I have not finished studying it. However, as far as I can tell, it will not give a solution to VB6.

But I am keeping the faith...

[mojo_jojo]

This is working just fine for me when running an exe (no IDE involved) and instantiating the ActiveX exe server.

FYI - Here are the registry settings

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}]
@="testSrv.Admin"
"LocalizedString"="@C:\\Users\\Public\\Documents\\TestApp\\testSrv.exe,-101"

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}\Elevation]
"Enabled"=dword:00000001

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}\Implemented Categories]

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}\Implemented Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502}]

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}\LocalServer32]
@="C:\\Users\\Public\\Documents\\TestApp\\testSrv.exe"

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}\ProgID]
@="testSrv.Admin"

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}\Programmable]

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}\TypeLib]
@="{3F7CFB62-967C-4563-B54B-2A37FD851E10}"

[HKEY_CLASSES_ROOT\CLSID\{29FD271B-F212-4A6A-9A23-67F15F33927C}\VERSION]
@="1.0"



[HKEY_CLASSES_ROOT\AppID\{29FD271B-F212-4A6A-9A23-67F15F33927C}]
@="testSrv.exe"
"AuthenticationLevel"=dword:00000001



[HKEY_CLASSES_ROOT\AppID\testSrv.exe]
@="testSrv.exe"
"AppID"="{29FD271B-F212-4A6A-9A23-67F15F33927C}"

[Michel_K17]

Hi Mojo,

Thank you for your last reply: it worked! It also works if I remove the call to "CoInitializeSecurity", so that does not seem to be related to the problem I was experiencing.

By the way, I added the missing "AppID" entries like you showed, but, until I saw your example, I was using [HKEY_LOCAL_MACHINE\Software\Classes] and your example has the entries in [HKEY_CLASSES_ROOT]. Is there a difference?

Also, it seems like a need to refresh the registry (F5) before the new entries I added are recognized: Is a "refresh" also required if I write the entries to the registry via code?

Anyway, I am very pleased that it is finally working properly: thank you for the help.

[Michel_K17]

OK. I got my own answer on where to write to the registry from Microsoft's web site [here]. The short answer is to write to: [HKEY_LOCAL_MACHINE\Software\Classes].

[RobDog888]

Not sure if its still the correct place because the KBA doesnt apply to Vista.

[gearbox]

Hi, can you please post an example project for us coders. I would love to see this. Thanks in advance.