Sign in to follow this  
Followers 0
WiSp

RunAsSet with multiple Admin accounts

10 posts in this topic

In my work place we have multiple OS images each with slightly different passwords for the local administrator account. Is there a way to detect whether a password worked or not and if not, try another username and password?

Here's some pseudocode I've been thinking about:

For $TryAccount = 0 to 3 step 1
    Select
        Case $TryAccount = 0        
            RunAsSet("PCLocal",@ComputerName,"P4ssw3rd1")
            $result = <try some action which will test if admin rights are granted>
                If $result = <admin rights granted>
                    ExitLoop
                EndIf
        Case $TryAccount = 1
            RunAsSet("PCLocal",@ComputerName,"P4ss1")
            $result = <try some action which will test if admin rights are granted>
                If $result = <admin rights granted>
                    ExitLoop
                EndIf
        Case $TryAccount = 2
            RunAsSet("Administrator",@ComputerName,"p455")
            $result = <try some action which will test if admin rights are granted>
                If $result = <admin rights granted>
                    ExitLoop
                EndIf
        Case $TryAccount = 3
            RunAsSet("Administrator",@ComputerName,"p4ssw3rd3")
            $result = <try some action which will test if admin rights are granted>
                If $result = <admin rights granted>
                    ExitLoop
                EndIf
        Case Else
            msgbox (16, "No Admin Account Found", "Create a Administrator account PCLocal or Administrator with our" &@LF& "current Local Admin password before executing program again")
    EndSelect
Next

Any ideas? Has this been handled before?

Share this post


Link to post
Share on other sites



Any ideas? Has this been handled before?

If you figure out some command you can Run() or RunWait() that will only work for a local admin, then it's easy. Maybe trying to write a dummy file to a system folder that is shielded from limited users, or something?

This assuming that you're not trying to build a brute force password cracker...


Roses are FF0000, violets are 0000FF... All my base are belong to you.

Share this post


Link to post
Share on other sites

try:

Opt("RunErrorsFatal", 0)
For $TryAccount = 0 To 3 Step 1
    Select
        Case $TryAccount = 0
            RunAsSet("PCLocal", @ComputerName, "P4ssw3rd1")
            $result = RunWait(@ComSpec & " /c Dir x.y", @ScriptDir, @SW_HIDE)
            If @error = 0 Then ExitLoop
        Case $TryAccount = 1
            RunAsSet("PCLocal", @ComputerName, "P4ss1")
            $result = RunWait(@ComSpec & " /c Dir x.y", @ScriptDir, @SW_HIDE)
            If @error = 0 Then ExitLoop
        Case $TryAccount = 2
            RunAsSet("Administrator", @ComputerName, "p455")
            $result = RunWait(@ComSpec & " /c Dir x.y", @ScriptDir, @SW_HIDE)
            If @error = 0 Then ExitLoop
        Case $TryAccount = 3
            RunAsSet("Administrator", @ComputerName, "p4ssw3rd3")
            $result = RunWait(@ComSpec & " /c Dir x.y", @ScriptDir, @SW_HIDE)
            If @error = 0 Then ExitLoop
    EndSelect
Next
If $TryAccount = 4 Then
    MsgBox(16, "No Admin Account Found", "Create a Administrator account PCLocal or Administrator with our" & @LF & "current Local Admin password before executing program again")
EndIf

Visit the SciTE4AutoIt3 Download page for the latest versions        Beta files                                                          Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

net localgroup administrators will help a bit as to pinpoint the actual user that is being used.... not that it will help much. Edited by jinxter

> there are 10 types of people in the world, those who understand binary and those who don't.

Share this post


Link to post
Share on other sites

net localgroup administrators will help a bit as to pinpoint the actual user that is being used.... not that it will help much.

We use either PCLocal or Administrator as the default local PC account.

Share this post


Link to post
Share on other sites

If you figure out some command you can Run() or RunWait() that will only work for a local admin, then it's easy. Maybe trying to write a dummy file to a system folder that is shielded from limited users, or something?

This assuming that you're not trying to build a brute force password cracker...

Yes, I'm trying to figure out a command that can be run as an "Administrator" but NOT as a "Power User" or "User" in order to determine whether the RunAsSet worked. It would be best if this was handled by the RunAsSet and would return a 0 if it didn't work, but understandably it doesn't. I can only assume it's because of the very issue you mentioned of building a brute force password cracker.

In any case, I still have this problem I need to solve and the code example above doesn't seem to do the trick, any other ideas?

WiSp

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

In any case, I still have this problem I need to solve and the code example above doesn't seem to do the trick, any other ideas?

WiSp

You mean the script I posted doesn't work for you ? Edited by JdeB

Visit the SciTE4AutoIt3 Download page for the latest versions        Beta files                                                          Forum Rules
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

We use either PCLocal or Administrator as the default local PC account.

What I meant was that you save at least 2 tries if you know the username. I bet you will save at least 0.01 ms of waiting time (which of course mean about 1 second if you run it on 100 computers!). You also don't fill the log-file with your failed login-attempts.


> there are 10 types of people in the world, those who understand binary and those who don't.

Share this post


Link to post
Share on other sites

JdeB script at post #3 should work for you. The problem I can see is you have 4 different passwords and you only trying two of them in each account. You may need to test all 4 passwords in each account.

Note: I don't know how is the network at your work configure, but in my work the third time having type the wrong password the account get lock for 30 minutes.

Try:

Dim $AdminPass[4] = ["P4ssw3rd1", "P4ss1", "p455", "p4ssw3rd3"]
Local $AdminName = _GetAdminName()
Local $result = False

For $TryPass = 0 To (UBound($AdminPass) - 1) Step 1
    $result = _CheckUserPass($AdminName, $AdminPass[$TryPass], @ComputerName)
    If $result Then
        $AdminPass = $AdminPass[$TryPass]
        ExitLoop
    EndIf    
Next

If Not $result Then
    MsgBox(16, "No Admin Account Found", "Create a Administrator account PCLocal or Administrator with our" & @LF & "current Local Admin password before executing program again")
    Exit
EndIf

MsgBox(0, 'Administrator Account', 'Admin Name: ' & $AdminName & @CRLF & 'Admin Pass: ' & $AdminPass)

Func _GetAdminName()
    $wbemFlagReturnImmediately = 0x10
    $wbemFlagForwardOnly = 0x20
    $Output = ""
    $colItems = ""
    $strComputer = "localhost"
    
    $objWMIService = ObjGet("winmgmts:\\" & $strComputer & "\root\CIMV2")
    $colItems = $objWMIService.ExecQuery("SELECT * FROM Win32_UserAccount", "WQL", _
                                          $wbemFlagReturnImmediately + $wbemFlagForwardOnly)

    If IsObj($colItems) then
        For $objItem In $colItems
            If StringRight($objItem.SID, 4) = '-500' Then
                $Output = $objItem.Name
                ExitLoop
            EndIf      
        Next
    EndIf
    Return($Output)
EndFunc

Func _CheckUserPass($sUsername, $sPassword, $sComputerName)
    Local $iCheck = True
    
    Opt("RunErrorsFatal", 0)
    RunAsSet($sUsername, $sComputerName, $sPassword, 0)
    Run(@ComSpec & " /c  echo checking password...", @ScriptDir, @SW_HIDE)
    If @error Then $iCheck = False
    RunAsSet()
    Opt("RunErrorsFatal", 1)
    Return $iCheck
EndFunc

AutoIt Scripts:NetPrinter - Network Printer UtilityRobocopyGUI - GUI interface for M$ robocopy command line

Share this post


Link to post
Share on other sites

Func _CheckUserPass($sUsername, $sPassword, $sComputerName)

Local $iCheck = True

Opt("RunErrorsFatal", 0)

RunAsSet($sUsername, $sComputerName, $sPassword, 0)

Run(@ComSpec & " /c echo checking password...", @ScriptDir, @SW_HIDE)

If @error Then $iCheck = False

RunAsSet()

Opt("RunErrorsFatal", 1)

Return $iCheck

EndFunc

Nice, simple, but intuitive, function, Danny35d. I am new to AutoIT and like the feature of RunAsSet. However, I was dumbfounded when I ran your script as a test from a network drive. The script errors out telling me that "The directory name is invalid." If I run the script from a location local to my PC it works like a charm, with both local and domain credentials.

To test the sanity of this I modified Danny35d's function to simply run cmd.exe without the RunAsSet and with the RunAsSet in sequence with fatal errors on. When the script is run from a network drive the Command Prompt window opens before RunAsSet is run, but then I get an error from the next Run function that is supposed to open the Command Prompt a second time. The error is telling me that "The directory name is invalid."

I have tested this using local credentials as well as domain credentials. The sample script I am suppling is using a local administrator account I set up on my PC because I was tired of locking out my domain super-id.

$check = _CheckUserPass("test", "51lly", @ComputerName)

if $check Then
    MsgBox(0,"GOOD", "GOOD CREDENTIALS")
Else
    MsgBox(0,"BAD", "BAD CREDENTIALS")
EndIf

Func _CheckUserPass($sUsername, $sPassword, $sComputerName)
    Local $iCheck = True
   
   ;Opt("RunErrorsFatal", 0)
    Run(@ComSpec)
    RunAsSet($sUsername, $sComputerName, $sPassword, 0)
    Run(@ComSpec)
    If @error Then $iCheck = False
    RunAsSet()
   ;Opt("RunErrorsFatal", 1)
    Return $iCheck
EndFunc

Does anyone know if this is a known bug in AutoIT? I am using the @ComSpec macro to define cmd.exe. It is pretty hard to loose your directory location with @ComSpec.

If someone could explain to me why the script runs without error on my local PC but then dies when run from a network drive, I would be very grateful. Most of the scripts I write get run from network locations. I can't have them dieing on me just because they are run from the network. Please let me know if you have the same issues running a script with RunAsSet off of a network drive location.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0