I would never recommend the "start program at logon" as anything other than a convenience to users. I can see how one might mistake it for a "security feature," but it is not (never was), and to my knowledge, has not been presented as one. It seems a bit obvious to me that when you say "start this program at logon," that's all that is happening. When you close it, it logs you out- but again, as a convenience. You can always hit the background processes unless you've specifically locked them down. When using a profile that launches an app at RDP logon, I've always just done a Ctrl+Alt+End and run Explorer (or whatever) via Task Manager if I ever needed to run another app while still in that session. Case in point is where I used to RDP into a TS app server with a special account if I wanted TSAdmin to run. No problem: log in, immediately get the TSAdmin list of users, disconnect people just to be irritating, and then close the app, automatically ending my session. It's really a pretty efficient way of doing things, especially if you TS in from your PDA or need quick, specific access. But, if I wanted to hit another app, I just did a quick Ctrl+Alt+End, T, Alt+F, N and run whatever I wanted. Got to where I could do it way faster than using the UI and I still got the convenience my "quick app" in and out. To me, it is totally expected (and necessary) behavior. That being said, these days I pretty much just hit the desktop, as I've typically got lots of other things to do. If you really want to limit what users can do while in an RDP session, you need to properly secure the box via configurations, not by a simple "start program at logon." The article you reference is a good start. I hope there are not a lot of deployments out there using startup apps as a security mechanism- but if there are, hopefully your post will show them the error of their ways ;) t On 8/16/06 9:56 AM, "pedantic1 (at) gmail (dot) com [email concealed]" <pedantic1 (at) gmail (dot) com [email concealed]> spoketh to all: > Author: Bill Littlejohn > > http://wklpc.blogspot.com/2006/08/easy-ms-terminal-server-desktop-hack.h tml > > > There is a vulnerability in Microsoft Terminal Server when an application is > specified for the user instead of a full Windows Desktop. It is possible to > easily cause an error in explorer.exe and to gain access to a full Desktop. > > This is an issue for anyone publishing applications through TS to domain users > who also logon to full desktops either on the TS or on another machine. > > > Tested on: > > Windows 2000 server SP4 TS in an NT4 domain > > Windows 2003 server SP2 TS in 2003 server AD domain > > > Microsoft has confirmed this to be a feature and has said they will not be > fixing it. > > The workaround given is to apply the steps in the TS lockdown article at > http://support.microsoft.com/default.aspx?scid=kb;en-us;278295 > > > Note that this workaround can only be applied to a TS in a full Active > Directory domain. > > > Simple test: (Note that there are other ways to exploit this) > > 1. Set your user to run notepad.exe when logging onto the Terminal Server. > > 2. Logon to TS as that user. Marvel at notepad.exe. > > 3. Press [ctlr]+O to open file. > > 4. Right-click on some folder and choose "Explore". > > 5. Notice the neat error message, taskbar, and Desktop that's now available. > > >