Disconnected RDP sessions re-connect to different users?

ENVIRONMENT:  Windows Server 2003 SP2 (all patches current) running MS Terminal Services (Remote Desktop).  Server is located in a colocation facility, and multiple concurrent users connect from an office premises located some distance away.

We have a client with a poor internet connection at their office, which results in frequent disconnections.  RDP clients automatically re-connect to the server after a few seconds.

PROBLEM:  This client claims that when sessions are disconnected, users at that location are getting re-connected to the sessions of other users at the same location.  All users have different userIDs.  (nobody shares a userID)

For example, user "Receptionist" is getting re-connected to the remote desktop of user "Accountant".  This has serious security issues, with privileged data being exposed to non-privileged employees.

On the surface this "seems" impossible, but the client insists it's happening.

Any ideas?

EcomproAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

cheers4beersCommented:
I would definitely have to agree with the "seems" impossible statement.  Can they provide any proof that it's happening, such as a screen shot?
0
B HCommented:
wow this is odd - i'd ask for proof or go there and see it for myself

but - look in active directory, 'accountant' user, properties, session tab - make sure it's checkmarked to allow reconnect from the original client only

repeat for all users of that source office
0
EcomproAuthor Commented:
This server does not run AD.  When I view a user account's properties under the Sessions tab, there is an option to allow reconnection "From originating client only".  

However, the hover-tip indicates "This option is supported only for Citrix ICA-based clients that provide a serial number when connecting."  So it doesn't immediately appear that would work anyway, since we are not running Citrix.
0
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

B HCommented:
that citrix message is left over from back in the day when microsoft took the code from them and called it terminal server

if this isnt active directory, where are the usernames kept at?  local users and groups?  do you have that option there?

in the terminal server configuration, right-click RDP and properties, see if you have that setting there (from originating client only)
0
EcomproAuthor Commented:
Local user accounts, correct.

I just tested that feature with my administrator account by establishing a remote desktop session. Then I disconnected, walked over to a different PC (which also happens to be homed on a different ISP) and reconnected to the server.  I got the same desktop-- the one I disconnected from.  It did not restrict me from connecting even though I was on a different client PC.

So in that regard, this does seem to be a Citrix-only feature.  (or are admin accounts exempt from the restriction?)
0
EcomproAuthor Commented:
To clerify, I set that restriction on the user account in Local Users and Groups.  

In the Terminal Services Configuration applet, under the Sessions tab, the option to allow reconnection only from previous client is grayed out.  (see attahced)
tsconfig.gif
0
B HCommented:
when these users get disconnected, do they have to re-enter their password?

in the rdp-tcp properties, can you put the checkmark to disable cached logins?  i would assume the secretary doesn't know the accountants password
0
Grasty86Commented:
Im pretty sure that isnt possible, my guess is that Receptionist is getting disconnected, and then reconnecting and re-logging in and getting confused when their previous session comes up instead of a new session, leading them to believe they are getting someone elses session.

I know from working with terminal servers here that if two people are using the same username and password they will continually steal each others sessions even if they are on different computers. So basically if Receptionist logs in on her computer, and then i login as Receptionist on my computer, she gets booted and I resume her session from wherever she left off.
0
B HCommented:
if they have their passwords saved, and get disconnected for 5 minutes.... and during that 5 minutes they play musical desks and now the receptionist is sitting at the accountants desk... of course she'll jump into his session because she won't be presented with a password prompt....  this is true if it reconnects during the "attempting to reconnect, attempt X of 20..." window.

to prevent this, tell them to stay at their own workstation - or force their password every time as my comment above.
0
EcomproAuthor Commented:
These are the things I've already ruled out.  Shared usernames are the first thing I suspected.  But here's a specific example.  Accountant has privileged access to their accounting and payroll system, and has her own office.  Receptionist only has access to front-desk (messaging) type apps.

After a recent disconnect due to poor internet, and subsequent re-connection, the Accountant's session was reconnected to the Receptionist's workstation.  The accountant had the payroll application running (which the Receptionist userID does not even have privileges to access-- no NTFS permissions on that directory containing the payroll app).  

When the reconnection occurred, the Accountant's RDP desktop came up on the Receptionist's computer, and the Receptionist got a good look at the payroll for the company executives.  Obviously a VERY BAD thing.  

I've been telling my client this is absolutely impossible, but they absolutely insist this is exactly what is happening.... and they absolutely insist that neither Accountant nor Receptionist use each other's PC or RDP login.
0
Grasty86Commented:
I have seen something similar with the Citrix Provisioning software where every once in a while two computers would boot up on opposite ends of the school and they would both have their own sessions running i.e. Student A had the Student A session, and Student B had the Student B Session. but if they both had word open and somehow they both managed to attach to the same instance of word, you would see what Student A was typing on Student B's computer and it would appear that the computer is just typing by itself. Could this happen with RDP and spotty connections? maybe.

If nothing else you could create a seperate terminal server for the people with the confidential stuff so that Accountant and Payroll or whatever are only on one terminal server and Receptionist and such are on a different one. That way they cant get each others sessions and you are completely seperating the Receptionist and such from the confidential information.

But of course that isnt really a fix for the problem
0
B HCommented:
requiring that they type their passwords, via the checkmark above, should eliminate this...  

is there anything different about their setup of their network?  is it straight internet with nat, or vpn?  

what version of the remote desktop client are they running, can you get them on the latest version?
0
EcomproAuthor Commented:
Nothing unusual about the server or their internet setup.  Running terminal servers is our primary line of business (I've been a terminal server sys admin since the days of Citrix on NT4) and we deploy all new servers from an pre-configured image.  This is the first time in my career I've heard of such a problem and I'm 100% puzzled.

At their end, the internet is straightforward-- business class broadband running through a Cisco ASA firewall with NAT.

I still think there must be some other explanation-- was hoping someone here mght have heard rumors of such a problem and knew the cause.  (even if it's the client's fault)  Requiring them to type in a password every time it auto-reconnects will be a show stopper.  They're already fighting with their ISP over the unstable connection and are talking of cancelling their service because the frequent disconnects are making everyone miserable.

I really do have to find the root cause.
0
B HCommented:
well, the root cause being the internet connection is easy enough to fix with a new one...

have you ruled out any issues with the ASA?  perhaps it's causing the drop-offs, and mixing up the tcp sessions or ARP tables?
0
EcomproAuthor Commented:
"have you ruled out any issues with the ASA?  perhaps it's causing the drop-offs, and mixing up the tcp sessions or ARP tables?"

I wondered if that might be a problem-- but then I thought that was (probably) unlikely since:
  a) the RDP client would try to connect back to the session belonging to the specific username, and
  b) the dropped connection would result in the RDP client trying to establish a NEW connection back to the server.  (because the current connection was dropped / lost)

I'm open to correction if my logic is flawed.  And I'm still have not ruled out a PEBKAC error at the client's office which they're not telling me about-- but I don't want to wrongly accuse an innocent client, so I'm still very open to suggestions, facts, and even good educated guesses.
0
B HCommented:
The only thing I can think of is the ASA actually routing the tcp session to the wrong internal ip... like, some internal problem in the ASA causes it to hang all tcp, then it sends all hung sessions back to the wrong mac addresses...  that or the users are mistaken
0
EcomproAuthor Commented:
That brings up my next question.  For fun, let's assume bryon44035v3 is correct; that the ASA is jumbling up the TCP sessions and sending the wrong packets to the wrong MAC addresses.

If that's the case, would the Windows Server RDP service actually play along?  Or would it say, "WHOA, that's the wrong client trying to connect to the wrong session" and prevent the connection?  

Seriously, if that is actually possible, that might explain this whole issue-- and it would be a HUGE security hole in the RDP service. (as in, a hole big enough to drive a Mac truck through)
0
B HCommented:
Well, without the setting that says 'from original client only', the server won't care... it matches that up by client workstation name I'm pretty sure.  Are the workstations all named the same perhaps?

0
EcomproAuthor Commented:
No, the workstations are named differently.

I also know it matches up by username, not workstation.  And the way I know this is, if I log in twice with the same username from 2 different PCs and a disconnection happens, the sessions can be swapped between the PCS-- but only if the same USERNAME was in use for both sessions.

Basically when the server has 2 disconnected sessions for the same username, and a client attempts to re-connect, it may (or may not) get the same session.  It may get the other.  

That's why I have pressed the client repeatedly about what usernames they are logging in with, trying to get them to admit they MAY have had multiple users on a single userID.  But they adamantly insist that is not the case.
0
B HCommented:
can you view the terminal server admin when they're logged in, look at the usernames?

if we could get 'from original client only' to work, and "reception" was logged in from "reception-pc" and got disconnected, and then someone at "accounting-pc" tried to log in as "reception" it would deny it because it's not the same client
0
EcomproAuthor Commented:
Yeah, that would be ideal but everything I've read, including articles at MSDN, say the "only from same client" option works only with the Citrix ICA client because it passes a serial number in addition to user credentials.  Ordinary RDP doesn't support it.
0
B HCommented:
so spy on the tsadmin session when they're logged in, see what usernames they're using
0
EcomproAuthor Commented:
Been there, done that.  I left that console open for several hours one day and glanced at it frequently, just to verify they weren't logging in more than 1x per username.  That's one of the things I did before posting here at E.E.

I'm just waiting for it to happen again-- if it ever does.  They have strict instructions to back away from the keyboard, don't touch a thing, and call me immediately the next time it occurs.  I want to have a close look at exactly who is logged in, one what usernames, and from what PCs.

But unfortunately I still haven't seen an answer.  I'd like to know *IF* this situation is even possible the way the client is describing it's happening, or if Microsoft has put in the proper security to guarantee a session swap could never happen if the users are doing things properly.
0
B HCommented:
for that last part, i dont think anyone can answer that... obviously it shouldnt happen, but neither should IE exploits...

we run 16 remote desktop servers for 300 users in 10 branch offices all day long, for 7 years from 2003 to 2008R2 and i've never heard of it happening ever.
0
EcomproAuthor Commented:
No further activity, problem not solved.  Please close question as unresolved.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
EcomproAuthor Commented:
Please close question with no grade, no solution.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.