Viewing Currently logged users

[Guest]

Hello,

I wanted to know if i can view all currently logged user to a specific
domain (if i'm an admin of course).

Thank you,

Moty.

 

[Carey Frisch [MVP]]

If you have a Windows XP or a Windows Server 2003 computer, you should
be able to connect to the server with Computer Management and then expand
System Tools -> Shared Folders -> Sessions and see the users connected,
from which computer, the connected time, and the idle time.

--
Carey Frisch
Microsoft MVP
Windows XP - Shell/User

Be Smart! Protect Your PC!
http://www.microsoft.com/athome/security/protect/default.aspx

----------------------------------------------------------------------------------

:

| Hello,
|
| I wanted to know if i can view all currently logged user to a specific
| domain (if i'm an admin of course).
|
| Thank you,
|
| Moty.

 

[Guest]

Thanks but what if the user did not open a shared folder?
So i cant see all users that logged in ?

 

[Torgeir Bakken \(MVP\)]

Hello,

I wanted to know if i can view all currently logged user to a
specific domain (if i'm an admin of course).

Hi

Nothing builtin for this I'm afraid...

You could build your own logon/logoff tracking using logon/logoff
scripts, more here:

http://groups.google.com/groups?selm=#[email protected]


There are tools out there that can help you (with an agent installed
on every computer), I think the two products below should be able to
give you the information you want:

UserLock
http://www.softwareshelf.com/products/display.asp?p=42

Microsoft's solution:
You could install the CCONNECT Microsoft Resource Kit utility onto
every computer, it is in the Win2k Server Resource Kit, Supplement 1
(pay ware, and you will need a SQL server database as well).

More about CCONNECT here:
http://groups.google.com/[email protected]

 

[GTS]

In a cmd prompt running net view /DOMAIN:domainname will list currently
connected users.

 

[Guest]

Actually, net view /domain:domainname will list computers registered with the
master browser.

 

[Mike Brannigan [MSFT]]

Moty,

Technically you can't.
This is because you are not logging into the Server and holding a session
live like various legacy systems that have the concept of a terminal session
on that machine.
You are actually being authenticated by the directory service, and actually
your logon authentication is can be done by any DC in the Domain.
We do log on the DC the lastLoginTimestamp for a user account and on a
native mode Server 2003 domain this attribute is replicated to all DCs in
the domain. So you can see the last time any user account was authenticated
to the domain. However does not tell you who is currently an active user
logged onto a PC in the Domain and authenticated by a DC, since they may
have just logged on and logged off.

So to see who is currently authenticated and has not logged off you would
need to check the lastLogonTimestamp on a single DC and then check the
lastLogoff attribute for that user on every DC in the Domain (since in a
native Server 2003 domain lastLogonTimestamp is replicated but lastLogoff is
not).





--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

 

[Torgeir Bakken \(MVP\)]

Moty,

Technically you can't.
This is because you are not logging into the Server and holding a session
live like various legacy systems that have the concept of a terminal session
on that machine.
You are actually being authenticated by the directory service, and actually
your logon authentication is can be done by any DC in the Domain.
We do log on the DC the lastLoginTimestamp for a user account and on a
native mode Server 2003 domain this attribute is replicated to all DCs in
the domain.

As far as I know, this attribute is only replicated once a week, so it
is not very useful in this type of cases I think (unless you are able
to reduce the replication time interval a lot).

 

[Mike Brannigan [MSFT]]

As far as I know, this attribute is only replicated once a week, so it
is not very useful in this type of cases I think (unless you are able
to reduce the replication time interval a lot).

In which case the poster is back to parsing all DCs for both lastLogon and
lastLogoff (both non replicated) and then doing the appropriate
calculations.

--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

 

[Guest]

Another way might be parsing the security logs on each dc for event id 540
assuming proper auditing is activated. Or do I jump to conclusions?

Isn´t there a problem basing your active users analysis on the
lastlogon/lastlogoff attributes? I mean if you´re logged on to more than one
workstation and you logoff one workstation the lastlogoff attribute gets
updatet but still you´re a logged on user from the other workstation, huh?

 

[Mike Brannigan [MSFT]]

Another way might be parsing the security logs on each dc for event id 540
assuming proper auditing is activated. Or do I jump to conclusions?

Isn´t there a problem basing your active users analysis on the
lastlogon/lastlogoff attributes? I mean if you´re logged on to more than
one
workstation and you logoff one workstation the lastlogoff attribute gets
updatet but still you´re a logged on user from the other workstation, huh?

Correct - this again comes back to the miss understanding that you are
logging onto the servers at all. This is not a time sharing multi terminal
legacy system - you are actually logging onto your PC and the server is
mealy providing the authentication service to that PC and then the
subsequent authorisation services to the servers holding resources being
securely accessed by that authenticated account.

--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

Another way might be parsing the security logs on each dc for event id 540
assuming proper auditing is activated. Or do I jump to conclusions?

Isn´t there a problem basing your active users analysis on the
lastlogon/lastlogoff attributes? I mean if you´re logged on to more than
one
workstation and you logoff one workstation the lastlogoff attribute gets
updatet but still you´re a logged on user from the other workstation, huh?

Mike Brannigan [MSFT] wrote:

Moty,

Technically you can't.
This is because you are not logging into the Server and holding a
session
live like various legacy systems that have the concept of a terminal
session on that machine.
You are actually being authenticated by the directory service, and
actually your logon authentication is can be done by any DC in the
Domain.
We do log on the DC the lastLoginTimestamp for a user account and on a
native mode Server 2003 domain this attribute is replicated to all DCs
in
the domain.

As far as I know, this attribute is only replicated once a week, so it
is not very useful in this type of cases I think (unless you are able
to reduce the replication time interval a lot).

In which case the poster is back to parsing all DCs for both lastLogon
and
lastLogoff (both non replicated) and then doing the appropriate
calculations.

--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups

Mike Brannigan [MSFT] wrote:

Moty,

Technically you can't.
This is because you are not logging into the Server and holding a
session
live like various legacy systems that have the concept of a terminal
session on that machine.
You are actually being authenticated by the directory service, and
actually your logon authentication is can be done by any DC in the
Domain.
We do log on the DC the lastLoginTimestamp for a user account and on a
native mode Server 2003 domain this attribute is replicated to all DCs
in
the domain.

As far as I know, this attribute is only replicated once a week, so it
is not very useful in this type of cases I think (unless you are able
to reduce the replication time interval a lot).


--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.mspx