Users must not connect to active session

[Guest 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

[Guest 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

[Guest 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

[Guest 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.

>

[Guest 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

[Guest 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