Users must not connect to active session

[Count Blackula]

Hi everybody!

I have following scenario/problem:

W2003 TS running in a school. To avoid too many dead sessions, the session
count per user is restricted to 1 session only. Also the "reconnect only
from same client" hook is set.
In the logon script there is a logoff session that compares username and
clientname to a ini-file so that the students can only logon with e.g User01
on Terminal01 User02 on Terminal02 and so on.
The problem now is, that some "funny" students discovered, that they can
take over a active session from their neighbour by logging on at their trm
with the neighbours credentials. Since it is a school there are no passwords
set so if user01 is logged on on trm01 and afterwards user02 loggs on at his
trm02 with user01, the user01 session on trm01 is disconnected and user02
gets the session!
a) This behaviour shouldnt occur with the "reconnect from same client"
option or is this option only valid for disconnected sessions?
b) Is there a way to force the logon-script before the session is taken
over? I tried the GPO Feature "Logonscript before Windowsexplorer-Shell"
(Sorry dont know the exact name since it is in german but im sure you know
what i mean) but no success
c) Isnt there a general parameter not to take over active sessions?

Any help appreciated,

Milenko

 

[Vera Noest [MVP]]

Re: Users must not connect to active session

No, I don't think you can avoid this behaviour.
One solution would be to allow multiple sessions per user account,
and then put a very short time limit on disconnected or broken
sessions and automatically reset them.

But that is still not foolproof (and I'm sure that your students
will find out the new trick soon):
assume user01 is connected from terminal01, and now a second
student logs on also as user01 from terminal02. The second student
gets a separate session on the server, doesn't automatically takes
over the first session, which is good. BUT: since both students are
logged on with the same user account, they will still be able to
take over the other session, with the tscon command.

TS doesn't handle generic user accounts very well (or rather: not
at all). You could also face problems like profile corruption, and
irratic printer bahaviour.
AFAIK, the only technical method to avoid the whole issue is to
create individual, unique user accounts.
An alternative approach is user education. Taking over a session
which belongs to another student is a form of harassment, which
could be dealt with like other forms of abuse.

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

"Count Blackula" <count.blackula@web.de> wrote on 23 okt 2008 in
microsoft.public.windows.terminal_services:

> Hi everybody!
>
> I have following scenario/problem:
>
> W2003 TS running in a school. To avoid too many dead sessions,
> the session count per user is restricted to 1 session only. Also
> the "reconnect only from same client" hook is set.
> In the logon script there is a logoff session that compares
> username and clientname to a ini-file so that the students can
> only logon with e.g User01 on Terminal01 User02 on Terminal02
> and so on. The problem now is, that some "funny" students
> discovered, that they can take over a active session from their
> neighbour by logging on at their trm with the neighbours
> credentials. Since it is a school there are no passwords set so
> if user01 is logged on on trm01 and afterwards user02 loggs on
> at his trm02 with user01, the user01 session on trm01 is
> disconnected and user02 gets the session!
> a) This behaviour shouldnt occur with the "reconnect from same
> client" option or is this option only valid for disconnected
> sessions? b) Is there a way to force the logon-script before the
> session is taken over? I tried the GPO Feature "Logonscript
> before Windowsexplorer-Shell" (Sorry dont know the exact name
> since it is in german but im sure you know what i mean) but no
> success c) Isnt there a general parameter not to take over
> active sessions?
>
> Any help appreciated,
>
> Milenko

 

[Jeff Pitsch]

Re: Users must not connect to active session

See inline:

Count Blackula wrote:
> Hi everybody!
>
> I have following scenario/problem:
>
> W2003 TS running in a school. To avoid too many dead sessions, the session
> count per user is restricted to 1 session only. Also the "reconnect only
> from same client" hook is set.
> In the logon script there is a logoff session that compares username and
> clientname to a ini-file so that the students can only logon with e.g User01
> on Terminal01 User02 on Terminal02 and so on.
> The problem now is, that some "funny" students discovered, that they can
> take over a active session from their neighbour by logging on at their trm
> with the neighbours credentials. Since it is a school there are no passwords
> set so if user01 is logged on on trm01 and afterwards user02 loggs on at his
> trm02 with user01, the user01 session on trm01 is disconnected and user02
> gets the session!
> a) This behaviour shouldnt occur with the "reconnect from same client"
> option or is this option only valid for disconnected sessions?

You nailed it. It is not a disconnected session therefore you are not
reconnecting.

> b) Is there a way to force the logon-script before the session is taken
> over? I tried the GPO Feature "Logonscript before Windowsexplorer-Shell"
> (Sorry dont know the exact name since it is in german but im sure you know
> what i mean) but no success

No

> c) Isnt there a general parameter not to take over active sessions?

No

I'm curious, as I've dealt with schools before, why you can't have
passwords? I've never known a school to not use passwords even if they
are basic. But I cannot think of a way to prevent the behaviour you are
seeing. You could try ReconnAct
(http://www.loginconsultants.com/index.php?option=com_docman&task=cat_view&gid=20&Itemid=149)
from Login Consultants but I'm not sure that would really help but it's
worth a try.

Jeff Pitsch
Microsoft MVP - Terminal Services

 

[Jeff Pitsch]

Re: Users must not connect to active session

It' not TS that doesn't handle generic user accounts, it's Windows in
general and for all the reasons you listed below Vera.

Vera Noest [MVP] wrote:

> TS doesn't handle generic user accounts very well (or rather: not
> at all). You could also face problems like profile corruption, and
> irratic printer bahaviour.
> AFAIK, the only technical method to avoid the whole issue is to
> create individual, unique user accounts.
> An alternative approach is user education. Taking over a session
> which belongs to another student is a form of harassment, which
> could be dealt with like other forms of abuse.
>

 

[Count Blackula]

Re: Users must not connect to active session

"The second student
> gets a separate session on the server, doesn't automatically takes
> over the first session, which is good. BUT: since both students are
> logged on with the same user account, they will still be able to
> take over the other session, with the tscon command."

BUT when the second user loggs on to a new session, my loginscript with
autom. logoff on wrong client should kick in, shouldnt it (assuming
loginscript will run on new session)? thats at least the solution that came
to my mind, but im currently not able to try it. Using commands when logged
on is not possible for students.
Btw, all schools i encountered here, have unpersonalized users 01...xx.
Schools are always short of money and staff to change Usernames etc.
everytime the class changes...
If they had money they would use Citrix (which is really cheap for schools!)
and the problem would be solved easier.

Thnx for your opinions so far,

Milenko


"Vera Noest [MVP]" <vera.noest@remove-this.hem.utfors.se> schrieb im
Newsbeitrag news:Xns9B40A40145B8Dveranoesthemutforsse@207.46.248.16...
> No, I don't think you can avoid this behaviour.
> One solution would be to allow multiple sessions per user account,
> and then put a very short time limit on disconnected or broken
> sessions and automatically reset them.
>
> But that is still not foolproof (and I'm sure that your students
> will find out the new trick soon):
> assume user01 is connected from terminal01, and now a second
> student logs on also as user01 from terminal02. The second student
> gets a separate session on the server, doesn't automatically takes
> over the first session, which is good. BUT: since both students are
> logged on with the same user account, they will still be able to
> take over the other session, with the tscon command.
>
> TS doesn't handle generic user accounts very well (or rather: not
> at all). You could also face problems like profile corruption, and
> irratic printer bahaviour.
> AFAIK, the only technical method to avoid the whole issue is to
> create individual, unique user accounts.
> An alternative approach is user education. Taking over a session
> which belongs to another student is a form of harassment, which
> could be dealt with like other forms of abuse.
>
> _________________________________________________________
> Vera Noest
> MCSE, CCEA, Microsoft MVP - Terminal Server
> TS troubleshooting: http://ts.veranoest.net
> ___ please respond in newsgroup, NOT by private email ___
>
> "Count Blackula" <count.blackula@web.de> wrote on 23 okt 2008 in
> microsoft.public.windows.terminal_services:
>
> > Hi everybody!
> >
> > I have following scenario/problem:
> >
> > W2003 TS running in a school. To avoid too many dead sessions,
> > the session count per user is restricted to 1 session only. Also
> > the "reconnect only from same client" hook is set.
> > In the logon script there is a logoff session that compares
> > username and clientname to a ini-file so that the students can
> > only logon with e.g User01 on Terminal01 User02 on Terminal02
> > and so on. The problem now is, that some "funny" students
> > discovered, that they can take over a active session from their
> > neighbour by logging on at their trm with the neighbours
> > credentials. Since it is a school there are no passwords set so
> > if user01 is logged on on trm01 and afterwards user02 loggs on
> > at his trm02 with user01, the user01 session on trm01 is
> > disconnected and user02 gets the session!
> > a) This behaviour shouldnt occur with the "reconnect from same
> > client" option or is this option only valid for disconnected
> > sessions? b) Is there a way to force the logon-script before the
> > session is taken over? I tried the GPO Feature "Logonscript
> > before Windowsexplorer-Shell" (Sorry dont know the exact name
> > since it is in german but im sure you know what i mean) but no
> > success c) Isnt there a general parameter not to take over
> > active sessions?
> >
> > Any help appreciated,
> >
> > Milenko

 

[Vera Noest [MVP]]

Re: Users must not connect to active session

Yes, you're right, your logon script should prevent the seocnd
student to logon as user01 from term02.
What about this scenario then: the second student logs on as user02
from term02, just as it should be done, and then takes over the
session from user01, with tscon.
You wrote that they can't execute commands, but are you really sure
that they can't? It's easy from within nearly every application,
simply hiding the "Run.." command on the Start Menu and hiding the
local disks is not enough. Those are just cosmetic features.
The fact that they can run a logon script makes me believe that
they can run any command they want to.

I understand the overhead involved in creating individual user
accounts (have worked on a university myself, responsible for the
student labs), but it's the only technical solution.
Second best is using multiple sessions combined with short time
limits on stale sessions.
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___

"Count Blackula" <count.blackula@web.de> wrote on 23 okt 2008 in
microsoft.public.windows.terminal_services:

> "The second student
>> gets a separate session on the server, doesn't automatically
>> takes over the first session, which is good. BUT: since both
>> students are logged on with the same user account, they will
>> still be able to take over the other session, with the tscon
>> command."
>
> BUT when the second user loggs on to a new session, my
> loginscript with autom. logoff on wrong client should kick in,
> shouldnt it (assuming loginscript will run on new session)?
> thats at least the solution that came to my mind, but im
> currently not able to try it. Using commands when logged on is
> not possible for students. Btw, all schools i encountered here,
> have unpersonalized users 01...xx. Schools are always short of
> money and staff to change Usernames etc. everytime the class
> changes... If they had money they would use Citrix (which is
> really cheap for schools!) and the problem would be solved
> easier.
>
> Thnx for your opinions so far,
>
> Milenko
>
>
> "Vera Noest [MVP]" <vera.noest@remove-this.hem.utfors.se>
> schrieb im Newsbeitrag
> news:Xns9B40A40145B8Dveranoesthemutforsse@207.46.248.16...
>> No, I don't think you can avoid this behaviour.
>> One solution would be to allow multiple sessions per user
>> account, and then put a very short time limit on disconnected
>> or broken sessions and automatically reset them.
>>
>> But that is still not foolproof (and I'm sure that your
>> students will find out the new trick soon):
>> assume user01 is connected from terminal01, and now a second
>> student logs on also as user01 from terminal02. The second
>> student gets a separate session on the server, doesn't
>> automatically takes over the first session, which is good. BUT:
>> since both students are logged on with the same user account,
>> they will still be able to take over the other session, with
>> the tscon command.
>>
>> TS doesn't handle generic user accounts very well (or rather:
>> not at all). You could also face problems like profile
>> corruption, and irratic printer bahaviour.
>> AFAIK, the only technical method to avoid the whole issue is to
>> create individual, unique user accounts.
>> An alternative approach is user education. Taking over a
>> session which belongs to another student is a form of
>> harassment, which could be dealt with like other forms of
>> abuse.
>>
>> _________________________________________________________
>> Vera Noest
>> MCSE, CCEA, Microsoft MVP - Terminal Server
>> TS troubleshooting: http://ts.veranoest.net
>> ___ please respond in newsgroup, NOT by private email ___
>>
>> "Count Blackula" <count.blackula@web.de> wrote on 23 okt 2008
>> in microsoft.public.windows.terminal_services:
>>
>> > Hi everybody!
>> >
>> > I have following scenario/problem:
>> >
>> > W2003 TS running in a school. To avoid too many dead
>> > sessions, the session count per user is restricted to 1
>> > session only. Also the "reconnect only from same client" hook
>> > is set. In the logon script there is a logoff session that
>> > compares username and clientname to a ini-file so that the
>> > students can only logon with e.g User01 on Terminal01 User02
>> > on Terminal02 and so on. The problem now is, that some
>> > "funny" students discovered, that they can take over a active
>> > session from their neighbour by logging on at their trm with
>> > the neighbours credentials. Since it is a school there are no
>> > passwords set so if user01 is logged on on trm01 and
>> > afterwards user02 loggs on at his trm02 with user01, the
>> > user01 session on trm01 is disconnected and user02 gets the
>> > session! a) This behaviour shouldnt occur with the "reconnect
>> > from same client" option or is this option only valid for
>> > disconnected sessions? b) Is there a way to force the
>> > logon-script before the session is taken over? I tried the
>> > GPO Feature "Logonscript before Windowsexplorer-Shell" (Sorry
>> > dont know the exact name since it is in german but im sure
>> > you know what i mean) but no success c) Isnt there a general
>> > parameter not to take over active sessions?
>> >
>> > Any help appreciated,
>> >
>> > Milenko