我一直在使用Get-ADUser和Get-ADComputer来帮助解决系统中的问题。
我已经看到通过registry， PsLoggedon.exe和其他脚本识别哪个用户login到特定机器上的几种方法，但是由于我不是一个真正的networkingpipe理员，我经常被拒绝访问。 这很好，因为我挖掘深度并不是很有趣。
我所需要的只是以某种方式确定哪些用户在计算机上拥有帐户（configuration文件）（或者哪些机器有用户帐户），以便我们可以联系他们并在他们的IP地址发生exception时帮助他们。
这两个对象之间是不是完全没有关系？
这些对象“开箱即用”之间绝对没有关系。 Windows 8 / Windows Server 2012引入了“主计算机” Active Directory架构属性的概念，但是我非常怀疑您会发现正在使用。
在远程计算机上获取login用户是这样的事情之一， 听起来应该很容易，但实际上并不是这样。
我想你将不得不从你的networkingpipe理人员那里得到一些合作来可靠地得到你想要的东西。 通过“普通方式”（ psloggedon ，WMI查询，远程registry访问）远程查询login用户信息将要求您在远程计算机上拥有本地pipe理员权限，或者更改默认设置为授予您的非授权pipe理员上下文的权利。
为了讨论“黑客”：我可以想象一个情况，你的exception处理程序试图将用户的浏览器redirect到需要NTLM身份validation的页面，如果客户端被configuration为自动尝试使用login用户的凭证进行身份validation，你可以通过这种方式“收获”证书。 我也可以看到，networkingpipe理人员如何将其误解为对用户的攻击，所以我强烈build议不要这样做。
据推测，你正在pipe理一个web应用程序，但不是networkingpipe理人员的一部分。 如果您可以让networkingpipe理员购买将您的Web服务器join到域中，那么您可以启用身份validation，此时您将知道远程用户的用户名，而不必使用任何IP地址。 如果您的客户端configuration正确，authentication也可以透明地进行。
Windows计算机上的现有configuration文件在以下registry项中列出：
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
它包含每个用户configuration文件的子密钥，每个子密钥的名称由安全标识符标识相应的用户。
您可以通过枚举子键来“发现”用户configuration文件，并将所有用户SID转换为相应的帐户对象：
$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"} }