How to check windows administrative privilege?

[alemrantareq]

I've made a tweak software which needs administrator rights before running. Does anyone tell me what will be the script for checking administrative privilege of windows with if function? I've searched it in the sample script websites but there are no such scripts that might help me. pls pls help me ...[/quote]

[SparkOut]

The only way I know how you could do this would be with getting Rev to run some vbscript which you can call by running a file from the shell. I don't believe it would be possible to use the "do... as vbscript" method directly from Rev, as

Any scripts on Windows which contain references to WScript will fail to run as WScript objects do not exist in the Revolution Environment

whereas the Rev shell command will receive the wscript.echo as a return value. In any event I'm unaware of how to get a "do..." statement list to parse "if..then" constructs.

The best way I've found (rather than interrogating the user groups, which may be nested very deeply) is as suggested near the end of this thread http://www.myitforum.com/forums/m_14241 ... htm#142413 which checks to see if the logged on user has access to the administrative share on the local drive.

So you could store this vbscript code file in the appropriate place, or write it out temporarily and delete it after running:

Code: Select all

Set Shell = CreateObject("WScript.Shell") 
Set filesys = CreateObject("Scripting.FileSystemObject") 
computername = Shell.ExpandEnvironmentStrings("%computername%") 
if filesys.FolderExists("\" & computername & "\Admin$\System32") then 
wScript.echo ("Admin") 
else 
wScript.echo ("Not Admin") 
end if
set filesys = nothing
set Shell = nothing

Then in your Rev app, call it via

Code: Select all

local tResult
set the hideConsoleWindows to true
--stops a command prompt window/task bar icon appearing

put shell("cscript.exe //nologo" && quote & <<path/filename.vbs>> & quote) into tResult
--enclose the path/filename in quotes to be on the safe side
--use cscript.exe rather than wscript.exe to return values to the command
--console from where it will be picked up by the Rev shell, rather than
--the Windows interface where it will pop up on screen and not be
--available to Rev.
--if you leave out the nologo option, then the result will be returned with
--a text "logo" of several lines of "Microsoft Windows Scripting Host" blah
--before the returned value. Using the nologo option just gives you the
--returned value on its own. (With the proviso indicated below).

if the last char of tResult is cr then delete the last char of tResult
--windows normally returns a trailing cr via the wscript.echo so this just tidies it up. 

if tResult is "Admin" then
  answer "Admin"
  --do stuff based on admin status
else
  answer "Sorry, you need administrative rights to proceed"
end if

[SparkOut]

As a slight variation, you could also potentially get the computer name from Rev and pass that as an argument, so that the vbscript doesn't have to make another wScript shell for interrogating the machine name, as in

Code: Select all

computername = wScript.Arguments.Named.Item("comp")
Set filesys = CreateObject("Scripting.FileSystemObject") 
if filesys.FolderExists("\\" & computername & "\Admin$\System32") then 
wScript.echo ("Admin") 
else 
wScript.echo ("Not Admin") 
end if
set filesys = nothing

Code: Select all

set the hideConsoleWindows to true
   put shell ("cscript.exe //nologo" && quote & <<path/filename.vbs>> & quote && quote & "/comp:" & $COMPUTERNAME & quote) into tResult
   if the last char of tResult is cr then delete the last char of tResult
  etc etc...

[trevordevore]

Thanks for posting that code SparkOut. I modified it a bit so it would work with 'do as vbscript' and I added some error checking. I did a quick test on XP admin/non-admin accounts and it worked but the code returned a false positive on a Vista standard (non-admin) account. In any case here is the example of how to run it using 'do ... as'.

Here is the VBScript:

Code: Select all

On Error Resume Next

if Err.Number = 0 then
	Set Shell = CreateObject("WScript.Shell") 
	if Err.Number <> 0 then
		result = "error,unable to create shell object"
	end if
end if

if Err.Number = 0 then
	Set filesys = CreateObject("Scripting.FileSystemObject") 
	if Err.Number <> 0 then
		result = "error,unable to create file system object"
	end if
end if

if Err.Number = 0 then
	computername = Shell.ExpandEnvironmentStrings("%computername%") 
	if filesys.FolderExists("\\" & computername & "\Admin$\System32") then 
		result = "admin"
	else 
		result = "not admin"
	end if
	
	if Err.Number <> 0 then
		result = "error,unable to check administrative rights"
	end if
end if

set filesys = nothing 
set Shell = nothing

And here is some code for a button to test. I put the VBScript in a custom property of the button:

Code: Select all

    put the uVBScript of me into theScript
    do theScript as "vbscript"
    answer the result

If all goes well you will get "admin" or "not admin" back. If an error occurred then the string will start with "error,".

[SparkOut]

Do you mean to tell me it's as simple as that to "do" a statement list? I have been trying various ways, but it was always under the premise of parsing one line at a time. (Also I thought there was a 10 line limit for a standalone, but it seems that isn't the case either, is it?) Thank you!

[trevordevore]

Yes, it is

The 10 line limit is for executing Revolution code. It doesn't apply when using "as" (i.e. AppleScript or VBScript).

[SparkOut]

No more writing out temporary files to kick off vbscript calls then! Yay! Thank you so much!

[trevix]

I noted the repeated

Code: Select all

if err.number=0 then
  ....  
end if

Is there a reason why the VBscript on RunRev does not support a "on error Goto ErrorLabel" at the beginning of the script ?
Is it something the eventually will get implemented ?

[trevordevore]

While Visual Basic does support "on error Goto ErrorLabel", VBScript does not so Revolution cannot implement it. There are no limitations in Revolution that are not inherent to other environments that interpret VBScript.

[trevix]

Thanks for the prompt answer.
I suspected that it could have been something on the MS part...
To implement error cheking, using Vbscript and SQL, I have to put a "if err <>0 then" practically everywhere: after opening the jet connection, checking the password, after the sql statement, after the answer and so on, making the code rather confusing.
Thanks anyway

[Mark]

Hello,

Does the solution described above actually work for anyone? I tried it with an admin account and a standard (guest) account and I always get true returned. It seems to me that you need to check whether you can actually write to the system32 directory, rather than whether it exists. Also, it seems to me that you can do the trick above simply with

Code: Select all

if there is a folder specialFolderPath("system") then
  return "admin" -- bogus result!
else return "non amin" -- never happens

which yields exactly the same result as the VBScript solution presented above.

Any better solutions?

Best,

Mark

[SparkOut]

This original code

Code: Select all

Set Shell = CreateObject("WScript.Shell") 
Set filesys = CreateObject("Scripting.FileSystemObject") 
computername = Shell.ExpandEnvironmentStrings("%computername%") 
if filesys.FolderExists("\\" & computername & "\Admin$\System32") then 
wScript.echo ("Admin") 
else 
wScript.echo ("Not Admin") 
end if 
set filesys = nothing 
set Shell = nothing 

has always worked for me. I just tested with a Vista profile on my daughter's computer and got "Not Admin" returned (correctly). My profile returns "Admin" as expected. By the way, it's not testing for the existence of the System32 directory, but the Admin share of that directory. The admin share is hidden from a limited user by default.

[Mark]

Thanks, SparkOut, I'll give it another try.

Best,

Mark

[SparkOut]

If it still doesn't work, then that same thread offers some alternative methods to try. This one, http://www.myitforum.com/forums/fb.asp?m=142596 testing for the right to delete a specific registry key (Current Control Set, so unlikely to have had the ACL adjusted) I've tested, and have had no issues. Of course, if the machine has had the registry ACLs opened up to allow something as stupid as a default user having rights to delete the Current Control Set key, then you will get false positives, but you'd probably have more pressing issues to worry about on behalf of your client, if so.

Code: Select all

' Create constants for access rights and registry hive 
const KEY_QUERY_VALUE = &H0001 
const KEY_SET_VALUE = &H0002 
const KEY_CREATE = &H0032 
const KEY_CREATE_SUB_KEY = &H0004 
const KEY_DELETE = &H00010000 
const HKEY_LOCAL_MACHINE = &H80000002 

strComputer = "." 

Set objReg=GetObject("winmgmts:"_ 
   & "{impersonationLevel=impersonate}!\\" &_ 
   strComputer & "\root\default:StdRegProv") 
strKeyPath = "SYSTEM\CurrentControlSet" 

bHasAccessRight = False 

' Does the account under which the script runs have the 
'    right to query the SYSTEM\CurrentControlSet key 
objReg.CheckAccess HKEY_LOCAL_MACHINE, strKeyPath, _ 
   DELETE, bHasAccessRight 
If bHasAccessRight = True Then 
   Wscript.Echo "User is an Admin" 
Else 
   Wscript.Echo "User is not an Admin" 
End If 

[alemrantareq]

Hi everybody,
After creating this topic, I could not work with the first 7 replies. May be those can work with someone's pcs but I use Windows XP and those scripts failed to give me the accurate results. Then i did a simple trick to check administrative privilege of windows xp and that is, as far i know admin privilege can be simply checked by setting a registry value in HKEY_LOCAL_MACHINE and then giving a query on it; because without admin account, none can create registry value in HKEY_LOCAL_MACHINE using other accounts. So, i made a script which will set a value, then query it. If the account is not admin, then it shows a failure dialog message and quit; else if admin, it deletes that value after opening the application.