C# + LDAP: Getting current logged in user remotely

So, I'm starting to work with AD in C#.  I've discovered how to find all the computer names on a domain; How do I figure out what user(s) are logged into that system?  Assume, for the purposes of this experiment, that I am a domain admin on that domain.

SlackmasterK wrote:

So, I'm starting to work with AD in C#.  I've discovered how to find all the computer names on a domain; How do I figure out what user(s) are logged into that system?  Assume, for the purposes of this experiment, that I am a domain admin on that domain.

You won't be able to get that from the Active Directory since there's no central authority that tracks who's logged on to where.

What you need to do is connect to the machine using WMI (using the System.Management namespace) and retrieve it that way.
Try connecting to the Win32_ComputerSystem WMI class and retrieving the UserName property. Here's a tutorial on WMI in general. 

As Raymond would say, Who says there is only one? The concept of the logged on user is fundamentally flawed.

While I usually agree with Raymond's rants against the evils perpetrated by thoughtless programmers, this time I think he's overgeneralizing.

When you're using Windows XP in a domain, there's only one interactive user connected. He's the one on Session 0, the Console or whatever you want to call it. In many cases, this is the information we want to have.
Yes, Fast User Switching changes matters. Yes, Terminal Services change matters. But these are not to say that you can't get the currently logged-on interactive console user, it just means you have to be aware of the caveats. In most cases, I won't write code to find out who the currently logged-on user is on my Terminal Server box, I'll do it on my XP or W2k workstations.

Yggdrasil wrote:


When you're using Windows XP in a domain, there's only one interactive user connected. He's the one on Session 0, the Console or whatever you want to call it. In many cases, this is the information we want to have.

• Remote Desktop breaks that assumption.
• RunAs breaks that assumption.
• Scheduled tasks breaks that assumption.
• Terminal Servers break that assumption.
• Windows Vista will completely break that assumption (no Session 0, Fast User Switching enabled)

It's a broken way of thinking and it will bite you at some point.

AndyC wrote:



• Remote Desktop breaks that assumption.
• RunAs breaks that assumption.
• Scheduled tasks breaks that assumption.
• Terminal Servers break that assumption.
• Windows Vista will completely break that assumption (no Session 0, Fast User Switching enabled)

It's a broken way of thinking and it will bite you at some point.

1) Now, it doesn't. Under XP logging into Remote Desktop will log off the current user. There is one currently logged-on user.
2-3) Runas runs a process under a different context, as do scheduled tasks. Likewise Windows Services. This still doesn't change the fact that there's a currently logged on user. Press CTRL-ALT-DEL in Windows and see what it says there.
Think in practical terms. THIS is the information that the OP wanted to access.

Terminal Servers and Windows Vista will break that assumption. But I want to write code that works now, today, for independent Windows XP clients.

Just because something can break in 40% of possible scenarios doesn't mean it's not the right solution for me, now.  Especially for the sort of code the OP wanted that seems to be a part of an administration script more than it is a part of full-blown application.

Be aware of what you code can or can't do, but don't throw it all away just because of remote complications.

So if I have 800 workstations to scan, there's really no fast way of doing it, eh?  Well, thanks.

SlackmasterK wrote:

So if I have 800 workstations to scan, there's really no fast way of doing it, eh?  Well, thanks.

There is likely a better way than scanning 800 workstations, how to go about it largely depends on exactly what it is you're trying to achieve.

AndyC wrote:

There is likely a better way than scanning 800 workstations, how to go about it largely depends on exactly what it is you're trying to achieve.

I'm trying to create a custom controlthat would accept a username and return a list of all workstations that user is logged into on that domain.  This way, when somebody calls the IT help desk from another state and their problem causes us to require their computer name (i.e. filesharing or VNC/MSTSC sessions), we wouldn't need to lead them through finding the computer name (Quite an obstacle for some users).

SlackmasterK wrote:


I'm trying to create a custom controlthat would accept a username and return a list of all workstations that user is logged into on that domain.  This way, when somebody calls the IT help desk from another state and their problem causes us to require their computer name (i.e. filesharing or VNC/MSTSC sessions), we wouldn't need to lead them through finding the computer name (Quite an obstacle for some users).

Well I'd be inclined to have a simple app in the Start menu that brings up all the relevant details you might ask for in a simple web page; quicker, easier and more reliable - if a user is currently logged into 5 machines scanning won't help you much wheras running something on the actual machine would.

Alternatively, you should be able to accomplish roughly what you want using cconnect.exe from the Windows Resource Kit.

If you've got WINS running you should be able to see a user object in the WINS management console. Not sure how it works with a user logged on to multiple machines though.