In a large environment, it's often useful to know which computer a user is logged on to, but historically that’s not that very easy to find – until FU that is.
The following command will tell you which workstation a user is logged in to, based on the assumption that your normal user account in Active Directory have a home drive set and automatically mapped when they logon. This assumes the file server hosting the user home drives is Windows 2000 or later.
To run, you'll need the dsquery/dsget utilities, and wmic, and a command prompt with a doskey macro to make it easier to run.
Set user=UserA
for /f "tokens=2 delims=\" %i in ('"dsquery user -name %user% dsget user -hmdir find /i "%user%""') do @for /f "skip=1 tokens=1-3" %m in ('"wmic /node:"%i" path win32_serversession WHERE "UserName Like '%user%'" Get ComputerName,ActiveTime,IdleTime"') do @for /f "tokens=2" %q in ('"ping -a %n -n 1 find /i "pinging""') do @echo %q %user% %n %i %m %o
I realise that’s not easy to type in, so you can use a doskey macro, by:
• Putting the command below in a text file
• Running doskey /macrofile=%path%\fu.txt (or modifying your command shell to run it automatically).
FU=for %g in ($1 $2 $3 $4 $5 $6 $7 $8 $9) do @for /f "tokens=2 delims=\" %i in ('"dsquery user -name %g dsget user -hmdir find /i "%g""') do @for /f "skip=1 tokens=1-3" %m in ('"wmic /node:"%i" path win32_serversession WHERE "UserName Like '%g'" Get ComputerName,ActiveTime,IdleTime"') do @for /f "tokens=2" %q in ('"ping -a %n -n 1 find /i "pinging""') do @echo %q %g %n %i %m %o
You can then run:
fu UserA
workstation1.domain.com UserA 192.168.1.2 fileserver 123 11
Or specify up to 9 usernames, eg:
fu UserA UserB UserC UserD
Note that the major limitation of using WMI (this command) or the ADSI provider is that there is apparently no way of controlling the NetSessionEnum() call to specify the information level you require. Therefore, you'll need administrative privileges on the file server for this to work. See my post for a powershell equivalent that uses information level 10 instead of 502.
Granting WMI access to standard users is not enough, it seems access to Win32_ServerSession results in a call to NetSessionEnum, and regardless of the resultset you specify, access is denied unless you're an administrator. I went some way down the track of modifying the DACLs on securable objects to see whether the permission to enumerate sessions could be granted, but I couldn't find a method (using winobj mainly).
If you do want to grant WMI access for other reasons, on a Windows Server 2003 box, you can:
- Use wmimgmt.msc to provide 'enable account' and 'remote enable' to the root\CIMv2 namespace (assuming you are trying to access the root)
Add a security group to the local 'Distributed COM Users' on the server. This provides remote access for DCOM calls. - After doing this, a standard call to a normal class such as win32_operatingsystem works, but still not to win32_serversession. This does not grant the right to execute methods or write data.
References
The article below indicates that local administrative rights or server operator rights are required to enumerate sessions: NetSessionEnum Function
The Win32_ServerSession Windows Management Instrumentation class returns incorrect server session instances on a Windows Server 2003-based computer
http://support.microsoft.com/kb/903931
Access to WMI Namespaces
http://msdn2.microsoft.com/en-us/library/aa822575(VS.85).aspx
Securing a Remote WMI Connection
http://msdn2.microsoft.com/en-us/library/aa393266(VS.85).aspx
DCOM Security Enhancements
http://technet2.microsoft.com/windowsserver/en/library/4c9a2873-2010-4dbb-b9dd-6a7d1e275f0f1033.mspx
Example: Getting WMI Data from a Remote Computer
http://msdn2.microsoft.com/en-us/library/aa390422(VS.85).aspx
Authorize WMI users and set permissions
http://technet2.microsoft.com/windowsserver/en/library/e1c26788-a6e4-41ea-84ed-2f7800c40d611033.mspx?mfr=true
How To Set WMI Namespace Security in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;en-us;295292
Low-level Security Descriptor Functions
http://msdn2.microsoft.com/en-us/library/aa379204(VS.85).aspx
Securable Objects
http://msdn2.microsoft.com/en-us/library/aa379557(VS.85).aspx
Access to WMI Securable Objects
http://msdn2.microsoft.com/en-us/library/aa822576(VS.85).aspx
Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.
No comments:
Post a Comment