Logon type: 10 when accesing thru mstsc/console?

inline

"ThOF" <mpareja RemoveThis @apsic.com> wrote on 28 jun 2006 in
microsoft.public.windowsnt.terminalserver.misc:

>> Now wait a second.... an application was running on the
>> console, that means that someone was logged in at the physical
>> console, correct? Running the application.
>
> YES! THAT IS!!
>
>> And you believe that someone else connected to the console
>> session and killed the application?
>
> YES! EXACTLY!
>
>> But *that* is logged in the EventLog! First you see the normal
>> remote logon type 10 event, and after that you see an event
>> that the current console session is disconnected/closed/logged
>> off and then an event that the console is connected to the new
>> remote session.
>
> Well, I think it has to be not so easy as you explain.

I think it is, see below.

> Here is my point of view:
>
> 1. Someone connects to the console using TS (mstsc.exe /console)
> with the "admin_xx_" user (day 1)
>
> 2.. Someone else (in fact, different people) connect to the same
> server, using the same user "admin_xx" but they don't connect to
> the console, but to normal TS connections (day 2, day 3, day 4,
> ..., day 35)

This is the real cause of the problem: Administrators should have a
unique account, just like normal users.

> 3. On day 36, some user (we don't know who) connects to the
> console, using TS (mstsc.exe /console) and entering the
> credentials of "admin_xx" (in fact, what he does is to
> "reconnect" the console session which was opened on day 1)

But this is recorded in the EventLog, EventID 682: Session
reconnected to winstation

> 4. This person accidentally logs out the console session and
> therefore the critical application that should be running stops
> :-/
>
> 5. How to know who the heck was the one who logged out from the
> console session?

This is how it looks on my server, when I reconnect to the console
session with the same user account:

EventID: 682
Computer: <my_server>
Session reconnected to winstation:
User Name: vera
Domain: <MY_DOMAIN>
Logon ID: (0x0,0x2F6B2)
Session Name: RDP-Tcp#3
Client Name: <MY_CLIENT>
Client Address: 192.168.xxx.xxx


In case the first user (on day 1) started the application while
logged in at the physical console, and the session is later connected
to with mstsc /console, then you see first EventID 683:

Session disconnected from winstation:
User Name: vera
Domain: <MY_DOMAIN>
Logon ID: (0x0,0x2A73E)
Session Name: Console
Client Name: Unknown
Client Address: Unknown

Followed by EventID 682 (as above)

> The only possibility I can think is if we had knew the
> "session_id" of the user who first logged ino the console on day
> 1, then we could have looked for the same session_id being
> logged out (I suppose you know what I mean, this is, the
> session_id that appears at the 'Description' field in Event IDs
> 528 and 551)
>
> The problem is we DO NOT know the "session_id" of the person who
> first logged on the server on day 1.

The session-id is in EventID 682, as shown above.
But since several persons seem to share the same Administrator
account, this only shows you from which client the person connected
to the console session. If you also have shared clients, then you
will still not know "whodunit".

I would do two things:
1. create a unique user account with Administrator rights for every
Administrator
2. get the whole Administrator group together and use this incident
as a life example for some inhouse education.
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

OK, all understand all you say and seems pretty clear

The only thing you say that differs from what it happened to us is that the
first session on day 1 was opened using 'mstsc.exe/console' instad of
connecting to the REAL console (the server is an IBM Blade and we don't have
the possibility to connect a monitor or keyboard to it)

This is, the first day the server was rebooted, someone connected to the
console using 'mstsc.exe/console' and ran the resident program in order for
the app to work

All the rest is the same as you point (the following days, some other users
reconnected to that session, using 'mstsc.exe /console', too)

In that case, EventId 682 reports the same info when you reconnect as if you
were connected the first time to the real console?

Thx.


"Vera Noest [MVP]" <vera.noest RemoveThis @remove-this.hem.utfors.se> escribió en el
mensaje news:Xns97F0E7586168Cveranoesthemutforsse@207.46.248.16...
> inline
>
> "ThOF" <mpareja RemoveThis @apsic.com> wrote on 28 jun 2006 in
> microsoft.public.windowsnt.terminalserver.misc:
>
>>> Now wait a second.... an application was running on the
>>> console, that means that someone was logged in at the physical
>>> console, correct? Running the application.
>>
>> YES! THAT IS!!
>>
>>> And you believe that someone else connected to the console
>>> session and killed the application?
>>
>> YES! EXACTLY!
>>
>>> But *that* is logged in the EventLog! First you see the normal
>>> remote logon type 10 event, and after that you see an event
>>> that the current console session is disconnected/closed/logged
>>> off and then an event that the console is connected to the new
>>> remote session.
>>
>> Well, I think it has to be not so easy as you explain.
>
> I think it is, see below.
>
>> Here is my point of view:
>>
>> 1. Someone connects to the console using TS (mstsc.exe /console)
>> with the "admin_xx_" user (day 1)
>>
>> 2.. Someone else (in fact, different people) connect to the same
>> server, using the same user "admin_xx" but they don't connect to
>> the console, but to normal TS connections (day 2, day 3, day 4,
>> ..., day 35)
>
> This is the real cause of the problem: Administrators should have a
> unique account, just like normal users.
>
>> 3. On day 36, some user (we don't know who) connects to the
>> console, using TS (mstsc.exe /console) and entering the
>> credentials of "admin_xx" (in fact, what he does is to
>> "reconnect" the console session which was opened on day 1)
>
> But this is recorded in the EventLog, EventID 682: Session
> reconnected to winstation
>
>> 4. This person accidentally logs out the console session and
>> therefore the critical application that should be running stops
>> :-/
>>
>> 5. How to know who the heck was the one who logged out from the
>> console session?
>
> This is how it looks on my server, when I reconnect to the console
> session with the same user account:
>
> EventID: 682
> Computer: <my_server>
> Session reconnected to winstation:
> User Name: vera
> Domain: <MY_DOMAIN>
> Logon ID: (0x0,0x2F6B2)
> Session Name: RDP-Tcp#3
> Client Name: <MY_CLIENT>
> Client Address: 192.168.xxx.xxx
>
>
> In case the first user (on day 1) started the application while
> logged in at the physical console, and the session is later connected
> to with mstsc /console, then you see first EventID 683:
>
> Session disconnected from winstation:
> User Name: vera
> Domain: <MY_DOMAIN>
> Logon ID: (0x0,0x2A73E)
> Session Name: Console
> Client Name: Unknown
> Client Address: Unknown
>
> Followed by EventID 682 (as above)
>
>> The only possibility I can think is if we had knew the
>> "session_id" of the user who first logged ino the console on day
>> 1, then we could have looked for the same session_id being
>> logged out (I suppose you know what I mean, this is, the
>> session_id that appears at the 'Description' field in Event IDs
>> 528 and 551)
>>
>> The problem is we DO NOT know the "session_id" of the person who
>> first logged on the server on day 1.
>
> The session-id is in EventID 682, as shown above.
> But since several persons seem to share the same Administrator
> account, this only shows you from which client the person connected
> to the console session. If you also have shared clients, then you
> will still not know "whodunit".
>
> I would do two things:
> 1. create a unique user account with Administrator rights for every
> Administrator
> 2. get the whole Administrator group together and use this incident
> as a life example for some inhouse education.
> _________________________________________________________
> Vera Noest
> MCSE, CCEA, Microsoft MVP - Terminal Server
> TS troubleshooting: http://ts.veranoest.net
> ___ please respond in newsgroup, NOT by private email ___