RE: A different question RE: Windows Remote Desktop
From: Shawn Jackson (sjackson_at_horizonusa.com)
Date: 01/16/04
- Previous message: Depp, Dennis M.: "RE: Windows Remote Desktop"
- Maybe in reply to: David Gillett: "A different question RE: Windows Remote Desktop"
- Next in thread: Gunn, Jeff: "RE: A different question RE: Windows Remote Desktop"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 16 Jan 2004 09:43:00 -0800 To: <gillettdavid@fhda.edu>, <security-basics@securityfocus.com>
From my terminal server experience I encountered that 'type' of
problem in the following situations.
1.) The program can't operate in a shared environment with
multiple instances open. Some programs just can work under TS properly
due to their use of static files, (INI's, config files, flat file db's,
etc). Could you have another instance running on the box that is
'locking' a file needed to be written to by the new instance?
2.) Service packs/updates/hotfixes are more 'pronounced' in a TS
environment and need to be looked at a lot more carefully. Even though
you install them days ago some file operations are saved for when the
system reboots, check your logs to see what updates were installed
recently.
3.) Communication errors, excessive latency or dropped packets
can mess up communication between the client and server and cause
'weird' TS error messages, usually (The server is too busy....).
4.) If it *is* a Terminal Services server and not a XP RDP box
make sure you are licensed properly, TS-CALS are demoed for 90 days or
so then become invalid, at which point you need to setup a licensing
server and install some TS-CALS.
5.) Make sure you don't have any 'phantom' sessions still open.
Set a timeout for disconnected sessions to ensure that they disappear.
For my servers I set this high for admin purposes but if it's an
end-user TS server I set this very low.
6.) Update your afflicted program or reinstall it, make *SURE*
you are running the install/update using the Add/Remove Programs
installation utility, no program on a TS server should be installed
without using Add/Remove programs utility.
7.) Reinstall your NIC drivers and use a multi-homed server.
Which seaming you're sniffing anyways you should be connected to a
'management' NIC and sniffing through another NIC.
8.) Double check permissions, TS for installed programs created
'shadow' copies of static files that the program writes, like
configuration files or databases. These might be damaged/missing or have
had their permissions removed/changed.
9.) When in Rome.... Remove TS->Reboot->Reinstall
TS->Reboot->Reinstall Program (From Add/Remove pgms util)->Reboot.
Shawn Jackson
Systems Administrator
Horizon USA
1190 Trademark Dr #107
Reno NV 89521
www.horizonusa.com
Email: sjackson@horizonusa.com
Phone: (775) 858-2338
(800) 325-1199 x338
-----Original Message-----
From: David Gillett [mailto:gillettdavid@fhda.edu]
Sent: Thursday, January 15, 2004 4:37 PM
To: security-basics@securityfocus.com
Subject: A different question RE: Windows Remote Desktop
We don't allow RDP to/from off-site locations, but we've
been using it to allow a couple of folks to, from their
office desktops, connect to strategically placed servers
to sniff specific network segments.
This worked fine from sometime in September until the
Christmas/New Year's break, during which we had a scheduled
power shutdown. Everything came back on after the shutdown,
and most boxes involved have been rebooted individually
since.
But although sniffing still works fine from the server
console, RDP clients get a general-purpose error message
that seems to indicate that they don't have the necessary
permissions, or there's some other kind of problem, with
the adapter that connects to the sniffed segment.
Since sniffing from the console works, we know it's not an
adapter or port configuration issue, or a switch port issue.
Since several privileged accounts, including Administrator,
*can* sniff from the console but not from an RDP session,
we're convinced it's not an account privileges issue.
And since it worked before the power shut-down, we know
it can be made to work.
Has anyone who works more extensively with RDP seen anything
similar? Or have you a useful theory that might help explain
what we're seeing?
Dave Gillett
------------------------------------------------------------------------
--- Ethical Hacking at InfoSec Institute. Mention this ad and get $720 off any course! All of our class sizes are guaranteed to be 10 students or less. We provide Ethical Hacking, Advanced Ethical Hacking, Intrusion Prevention, and many other technical hands on courses. Visit us at http://www.infosecinstitute.com/securityfocus to get $720 off any course! ------------------------------------------------------------------------ ---- --------------------------------------------------------------------------- Ethical Hacking at InfoSec Institute. Mention this ad and get $720 off any course! All of our class sizes are guaranteed to be 10 students or less. We provide Ethical Hacking, Advanced Ethical Hacking, Intrusion Prevention, and many other technical hands on courses. Visit us at http://www.infosecinstitute.com/securityfocus to get $720 off any course! ----------------------------------------------------------------------------
- Previous message: Depp, Dennis M.: "RE: Windows Remote Desktop"
- Maybe in reply to: David Gillett: "A different question RE: Windows Remote Desktop"
- Next in thread: Gunn, Jeff: "RE: A different question RE: Windows Remote Desktop"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
