Sign in to follow this  
Followers 0
LostUser

Get currently logged in user through system rights.

8 posts in this topic

#1 ·  Posted (edited)

Hi all.

I run an AutoIt compiled script that gets some general PC information. Username, IP, domain, memory, etc. My issue is this. I have pushed the program from our Kaspersky administration kit and the user name that comes up is SYSTEM (because that is how kaspersky agent runs the software remotely). When I run it this way, is there a way to pull the username of whomever is currently logged on rather than retrieving the SYSTEM administrator login?

Thanks

Edited by LostUser

Be open minded but not gullible.A hammer sees everything as a nail ... so don't be A tool ... be many tools.

Share this post


Link to post
Share on other sites



Hi all.

I run an AutoIt compiled script that gets some general PC information. Username, IP, domain, memory, etc. My issue is this. I have pushed the program from our Kaspersky administration kit and the user name that comes up is SYSTEM (because that is how kaspersky agent runs the software remotely). When I run it this way, is there a way to pull the username of whomever is currently logged on rather than retrieving the SYSTEM administrator login?

Thanks

what method are you using to determine the "logged on user"?

Share this post


Link to post
Share on other sites

Yeah, are you using @UserName ?

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

I thought something more direct had been posted before, but I'm too lazy to search very hard. This method returns the owner of the console session's explorer.exe process:

MsgBox(64, "Test", "Currently logged in user is: " & _GetConsoleUser())

Func _GetConsoleUser($strComputer = ".")
    Local $objWMIService = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\" & $strComputer & "\Root\CIMV2")
    Local $colProcesses, $objProcess
    Local $strUser = "", $strDomain = ""
    Local $strAccount, $lReturn

    $colProcesses = $objWMIService.ExecQuery("Select Name from Win32_Process Where Name = 'Explorer.exe' AND SessionId = 0")
    For $objProcess In $colProcesses
        $lReturn = $objProcess.GetOwner($strUser, $strDomain)
        If $lReturn = 0 Then
            $strAccount = $strDomain & "\" & $strUser
        EndIf
    Next

    If $strAccount <> "" Then
        Return $strAccount
    Else
        Return SetError(1, 0, 0)
    EndIf
EndFunc   ;==>_GetConsoleUser

Extracted from a VBScript example and translated from coolchap_here-ga at: http://answers.google.com/answers/threadview?id=539229

:D

Edit: Maybe this one is more direct, derived from: JSI Tip 8277

MsgBox(64, "Test", "Currently logged in user is: " & _GetConsoleUser())

Func _GetConsoleUser($strComputer = ".")
    Local $objWMIService = ObjGet("winmgmts:{impersonationLevel=impersonate}!//" & $strComputer)
    Local $colUsers, $objUser
    Local $strAccount

    $colUsers = $objWMIService.InstancesOf("Win32_ComputerSystem")
    For $objUser In $colUsers
        $strAccount = $objUser.UserName
    Next

    If $strAccount <> "" Then
        Return $strAccount
    Else
        Return SetError(1, 0, 0)
    EndIf
EndFunc   ;==>_GetConsoleUser
Edited by PsaltyDS

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law

Share this post


Link to post
Share on other sites

On XP Pro the console command "qwinsta" will list logged in users.

You can parse for the line containing "Console".

Share this post


Link to post
Share on other sites

Sorry, been busy for replying.

I use the AutoIt script @username. I think this pulls from a registry key but I don't remember where in the AutoIt help it mentions that.

I have been checking other areas in the registry to see where I could pull this info from but the SIDs don't come right out and point directly to a specific user name ... at least not that I've found looking in the registry. I found this key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" which has the SID numbers then the subkey "ProfileImagePath" which shows the location of the user directory, eg. (%SystemDrive%\Documents and Settings\Administrator). I am sure I can hash it out that way too. I just have to find out a consistent location of which SID is authenticated.

Thanks Turion and Psalty. I'll check both of those options out.

I am finding all kinds of new things that I hadn't dealt with before because most of the workstation users do not have administrative rights. In my last job, the PCs logged on through Novell with an automatic windows login of a specific user and that user was the same for all the PCs. That user also had full admin rights so installs, settings, and other changes were never a problem as far as rights to the workstation were concerned. It's just something new and different to work with.


Be open minded but not gullible.A hammer sees everything as a nail ... so don't be A tool ... be many tools.

Share this post


Link to post
Share on other sites

Func _ConsoleUser()
    $pid=Run(@SystemDir&"\qwinsta","",@sw_hide,$STDERR_CHILD + $STDOUT_CHILD)
    ProcessWaitClose($pid)
    $output = StdoutRead($pid)
;   $offset=StringinStr($output,"console")
;   $username=StringStripWS(StringMid($output,$offset+18,20),3)
    $username=StringStripWS(StringMid($output,StringinStr($output,"console")+18,20),3)
    ConsoleWrite("qwinsta:"&TimerDiff($timer)&@CRLF)
    return $username
EndFunc

In my testing Qwinsta and the WMI approach take about the same amount of time (300ms) if WMI isn't "warmed up".

Share this post


Link to post
Share on other sites

Thanks for the help guys. I ended up using Psalty's WMI w/o the explorer.exe check. It seems to work fine with my initial testing. I did see that it must error out if the computer is not logged in or is locked out and it gives a 0 for the username.

I really want to learn more on how to access WMI. I've used the WMI explorer but I tried to make a laptop battery monitor once and there were some things in WMI that weren't referenced (from what I could find) at Microsoft's WMI references. Someone using vbs or AutoIt had gotten the information on that though.


Be open minded but not gullible.A hammer sees everything as a nail ... so don't be A tool ... be many tools.

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