3

I have been using Get-ADUser and Get-ADComputer a few times to help troubleshoot problems in the system.

I have seen a few ways of identifying which user is logged on a specific machine through either registry, PsLoggedon.exe and other scripts, but since I'm not really a network administrator, I often get access denied. Which is fine because I'm not really interesting in digging that deep.

All I need is to somehow identify which users have an account (profile) on a machine (or which machines have a user account) so I can contact them and help them whenever an exception is coming from their ip address.

Is there absolutely no relationship between these two objects out-of-the-box?

Community
  • 1
Tiago Duarte
  • 142
  • 8
  • When I use psloggedon v1.34 against a remote system where my account does not have admin access to that system, it works fine. Are you using an older version that requires admin access? Do these remote systems belong to the same domain? workgroup? – Clayton Oct 15 '14 at 13:24
  • I get a lot of "error opening" entries. how are you calling/which parameters? – Tiago Duarte Oct 15 '14 at 13:51
  • 1
    psloggedon \\servername – Clayton Oct 15 '14 at 13:57
  • +1 thanks for that. I wasn't using the \\ at the beggining. however, it only displays proper output on machines were I am local admin. others say "Error opening HKEY_USERS for \\xxx" – Tiago Duarte Oct 15 '14 at 14:01
  • My remote target is Windows 7. HKEY_USERS has Everyone/Read. What OS version is your remote target? Has that key been secured? What vesion of PSLOGGEDON are you using? – Clayton Oct 15 '14 at 14:11
  • destination SO is W7 enterprise. psloggedon 1.34. possible hardening in place, wouldn't know – Tiago Duarte Oct 15 '14 at 14:16

2 Answers2

6

There is absolutely no relationship between these objects "out of the box". Windows 8 / Windows Server 2012 introduced a concept of a "primary computer" Active Directory schema attribute but I highly doubt you're going to find that being used.

Getting the logged-on user on a remote machine is one of those things that sounds like it should be really easy but, in practice, isn't.

I think you're going to have to get some cooperation from your network administration staff to reliably get what you're looking for. Remotely querying logged-on user information through "normal means" (psloggedon, WMI queries, remote registry access) is going to require that you either have local Administrator rights on the remote machine, or that changes are made to defaults to grant your non-Administrator context that right.

To get into talking about "hacks": I could imagine a scenario where your exception handler attempts to redirect the user's browser to a page that requires NTLM authentication and, if the clients are configured to automatically attempt authentication with the logged-on user's credential, you could "harvest" the credential that way. I could also see how that could be badly misinterpreted by the network administration staff as being an attack on users, so I'd strongly recommend against doing that.

Presumably you're administering a webapp but not part of the network administration staff. If you could get network administration to buy into joining your web server to the domain you could enable authentication, at which point you'd know the username of the remote user and wouldn't have to muck about with any of this IP address stuff. If your clients are properly configured that authentication can happen transparently, too.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • that's exactly what I was looking for hearing. thanks. I managed to use our inhouse helpdesk application (landesk) which has an option "link to configuration item" which actually displays computer info after filling in the machine name. but for all purposes, I believe your answer is "the" answer – Tiago Duarte Oct 15 '14 at 14:13
5

Existing profiles on a Windows computer are listed in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

It contains a subkey per user profile, and the name of each subkey identifies the corresponding user by a Security Identifier.

You could "discover" user profiles by enumerating the subkeys and translate all user SIDs to their corresponding account objects:

$profileList = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"
# Retrieve subkeys that represent user profiles
$UserProfiles = Get-ChildItem $profileList |? {$_.Name -like "*S-1-5-21-*"}

foreach($Profile in $UserProfiles)
{
    $ntAccType = [System.Security.Principal.NTAccount] -as [Type]
    $userSid = ($Profile.Name-split"\\")[-1]
    try{
        # Attempt to translate the SID to an NTAccount object
        (New-Object System.Security.Principal.SecurityIdentifier $userSid).Translate($ntAccType)
    } catch {"Translating SID $userSid to Account failed"}
}
Mathias R. Jessen
  • 24,907
  • 4
  • 62
  • 95