none
Does Windows Server Active Directory have an API which allows queries to determine whether there is ANY user is currently logged in at a particular workstation ?

    Question

  • Suppose an application has administration rights on a particular workstation. Can that application query the local Windows OS to determine whether there is ANY user actually logged into the workstation currently and also when did they last login ? Can that application query Windows Server Active Directory remotely and query the same specific details for that workstation and user login details ? Also is there anyway to determine if there is someone there physically sitting at the workstation making use of the applications on that workstation ? Can Active Directory or some other Microsoft application or service tell us that in the case even if the user is not making use of any internet enabled applications such a browser or using an a FTP SSH TELNET POP/SMTP and etc... application ? Any computer activity (keyboard/mouse) and the monitor goes to sleep or the same for the computer itself this sort of activity.
    Friday, March 17, 2017 10:01 PM

Answers

  • The scripts can log anything available during logon, such as date, time, user name, computer name, site, IP address, domain, etc. I have used scripts as simple as batch files that echo date, time, user name, and computer name to a shared log file, appending to the end of the text file. I make the fields comma delimited so the file can be read by Excel for analysis.

    The only time I have done anything similar to encryption was logon scripts that enforced one logon at a time for users. In that case the scripts created one file per user and it base64 encoded the file name and contents to obscure what was happening. The file name was a base64 encoding of the user's GUID, the contents were a base64 encoding of the computer name. All of these files were in a shared folder. And of course, if a user recognizes the encoding, and is knowledgeable, they can decode it.

    But a log file where you append logon events would be a challenge to encrypt. The logon script would need to decrypt the file, append the information, then re-encrypt it. Better to have one file per logon event. Maybe name the file after the computer, so a script doesn't need to decrypt all of the files to find the one for a given computer. But encrypt the user name. But this scheme must account for more than on user logged into any computer at any time, plus remove the information/file at logoff. And you must account for the possibility that the computer crashes or is shutdown before the user logs off. And if all users have read/write permissions in the folder, as they must for the logon/logoff scripts to work, a user could delete any file they want. That argues for encrypting (or encoding) the file name.

    I guess I see this as potentially very complicated.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Saturday, March 25, 2017 1:30 AM

All replies

  • To see if someone is logged on you may be able to use qwinsta. For processes running you can try process monitor or pslist

    https://technet.microsoft.com/en-us/sysinternals/bb795533

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Friday, March 17, 2017 10:18 PM
  • Dave thanks. But does Qwinsta query Active Directory directly or does it query the local workstation kernel or services to find this out ? I'm also trying to figure out what Active Directory can and cannot do at the moment in terms of knowing who is active on on the network. Qwinsta is a command line utility yes ? But can itself be queried via an API ?

    Also can a user be logged into the local workstation without signing into Active Server Directory ? Can a network be configured this way ? I believe it can.

    Friday, March 17, 2017 10:37 PM
  • Active Directory does not keep track of which user log into which client.  There is no way to query AD for this. You must query every computer, or have logon and logoff scripts configured in Group Policy that log logon and logoff events to a shared log file. Or if auditing is enabled, a script can scan the security logs on DCs for logon and logoff events. Logic would be required to determine where users have logged but not logged off as yet, but also handle situations where the computer crashes before the user can logoff.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Friday, March 17, 2017 10:54 PM
  • qwinsta queries the local machine. Should be able to read the SessionName for "console" or session ID to know if local or RDP. Like Richard said AD would not have the level of detail you're asking for.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.


    Saturday, March 18, 2017 12:16 AM
  •  Any computer activity (keyboard/mouse) and the monitor goes to sleep or the same for the computer itself this sort of activity.

    I am not sure if that's relevant or not, but I have written a script, which, once you enter samaccountname, it will generate a list of computers where that user had logged on during last X days. You can find the script in my signature right below this post. Something like this, is the result:


    Mahdi Tehrani | | www.mahditehrani.ir
    Make sure to download my free PowerShell scripts:



    Saturday, March 18, 2017 4:45 PM
    Moderator
  • Another approach would be to enable audit logon events which may help you to audit users successful logon/logoff and failed logon attempts.

    You can follow this article for step-wise instructions - https://www.lepide.com/blog/audit-successful-logon-logoff-and-failed-logons-in-activedirectory/

    Monday, March 20, 2017 8:02 AM
  • Active Directory does not keep track of which user log into which client.  There is no way to query AD for this. You must query every computer, or have logon and logoff scripts configured in Group Policy that log logon and logoff events to a shared log file. Or if auditing is enabled, a script can scan the security logs on DCs for logon and logoff events. Logic would be required to determine where users have logged but not logged off as yet, but also handle situations where the computer crashes before the user can logoff.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Richard thanks. If Active Directory does not keep track of which user logs into which client or whether any user is logged into a particular workstation then does Windows Server any version or some other component of Windows Server keep track of these details ? So leaving aside AD can Windows Server any component of keep track of these details.

    i assume that when you say the "You must query every computer, or have logon and logoff scripts configured in Group Policy" you're referring to is the Group Policy at a workstation locally not on Windows Server yes ?

    Thanks to all responses much appreciated the help.

    Tuesday, March 21, 2017 12:14 AM
  • Logon and logoff scripts can be configured in Group Policy in AD. These are not local workstation policies. I have used such scripts to log Active Directory user and computer names, with date and time, to shared log files. These log files can be read into Excel and sorted by user or computer (and time) to determine which computer has been used by each user. They can be used to determine where any user is currently logged on. Outside of Active Directory, Windows Server is not involved in logon and logoff, so has no provision to track which user authenticates to which client computer.

    Auditing of logon and logoff events is also a function of Active Directory, and scripts can query the resulting system log files for similar information.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Tuesday, March 21, 2017 2:31 AM
  • Logon and logoff scripts can be configured in Group Policy in AD. These are not local workstation policies. I have used such scripts to log Active Directory user and computer names, with date and time, to shared log files. These log files can be read into Excel and sorted by user or computer (and time) to determine which computer has been used by each user. They can be used to determine where any user is currently logged on. Outside of Active Directory, Windows Server is not involved in logon and logoff, so has no provision to track which user authenticates to which client computer.

    Auditing of logon and logoff events is also a function of Active Directory, and scripts can query the resulting system log files for similar information.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Richard thank you again. Can the scripts used to generate these log files be pretty much customized in terms of what does and does not go into the generated log file(s) ? Can the log files be encrypted by the script file or locked by a process upon creation ? The purpose of the encryption or locking of the log file is so that only a single process may access it (read/write) and no other.

    • Edited by Victor Mehta Friday, March 24, 2017 10:16 PM further clarification
    Friday, March 24, 2017 10:13 PM
  • The scripts can log anything available during logon, such as date, time, user name, computer name, site, IP address, domain, etc. I have used scripts as simple as batch files that echo date, time, user name, and computer name to a shared log file, appending to the end of the text file. I make the fields comma delimited so the file can be read by Excel for analysis.

    The only time I have done anything similar to encryption was logon scripts that enforced one logon at a time for users. In that case the scripts created one file per user and it base64 encoded the file name and contents to obscure what was happening. The file name was a base64 encoding of the user's GUID, the contents were a base64 encoding of the computer name. All of these files were in a shared folder. And of course, if a user recognizes the encoding, and is knowledgeable, they can decode it.

    But a log file where you append logon events would be a challenge to encrypt. The logon script would need to decrypt the file, append the information, then re-encrypt it. Better to have one file per logon event. Maybe name the file after the computer, so a script doesn't need to decrypt all of the files to find the one for a given computer. But encrypt the user name. But this scheme must account for more than on user logged into any computer at any time, plus remove the information/file at logoff. And you must account for the possibility that the computer crashes or is shutdown before the user logs off. And if all users have read/write permissions in the folder, as they must for the logon/logoff scripts to work, a user could delete any file they want. That argues for encrypting (or encoding) the file name.

    I guess I see this as potentially very complicated.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Saturday, March 25, 2017 1:30 AM
  • Hi,

    Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, April 3, 2017 2:20 AM
    Moderator