Encryption News


Remote Desktop Gets a Bit More Secure

At first glance, Remote Desktop for Vista looks pretty much identical to RD on XP. But a slightly closer look shows a small but important change in security. You can see this in the Remote tab of the System property page. Get to it like so:

  1. Click the Start button.

  2. In the resulting menu, right-click Computer and choose Properties.

  3. In the Control Panel page that appears, look at the Tasks list on the left-hand side of the page. Choose "Remote settings." You'll see a property page like Figure 1.6.

image from book
Figure 1.6: Configuring Remote Desktop in Vista

As I said, this looks similar to the corresponding page in XP, but notice that instead of two options-"enable or disable remote desktop"-there is a third offering, "Allow connections only from computers running Remote Desktop with Network Level Authentication."

To understand this, think about what's happened every time you've tried to use Remote Desktop to remote into a system. You start up the Remote Desktop Connection (RDC) app in XP or 2003 and tell the app to connect you to some system. RDC goes out and, assuming that Remote Desktop's enabled for that system and they've got their firewall set up so that people can remote in, you get a logon screen from the remote system. Now, from the point of view of a particularly paranoid security person, this is interesting: you haven't authenticated to this system yet, but it's responded to your command for its attention nonetheless. In other words, Remote Desktop is a little bit more trusting than it could be, as the sequence of events is (1) request a Remote Desktop connection from the remote system, (2) the remote system stops what it's doing and creates a remote session to your computer, and (3) you log on.

By choosing the new third setting under Remote Desktop, you tell Remote Desktop to switch steps (2) and (3). When you try to log onto a remote system that supports this approach, which Microsoft calls "Network Level Authentication," you don't see a remote standard Windows logon dialog sitting atop a remote desktop; instead, you get a dialog box like the one in Figure 1.7.

image from book
Figure 1.7: A Network Level Authentication logon dialog

But does this mean that a Network Level Authentication logon only works against Vista systems at the moment? Apparently yes. As I write this in September 2006, Microsoft has released a package called "Remote Desktop Connection 6.0" for XP SP2, 2003 SP1, and the ×64 versions of XP and 2003. They did not release it to the general public, and it was only available from Microsoft's beta software site, but I'd be surprised if it weren't either generally available with Vista's release, or might even end up on the Vista DVD. But even with this updated RDP client, you cannot do a Network Level Authentication against a Vista system or, if you can, I've not figured out how.

What if you still want older systems to be able to remote into your system, but you'd like any Vista systems trying to log in to use Network Level Authentication? Then choose the second radio button. Vista clients will still use Network Level Authentication even if the Vista system they're remoting into doesn't require it. Is it a bad idea to enable the second radio button? Well, of course. On the one hand, enabling it means that you can RD into your Vista box from a wider variety of clients; on the other hand, the whole point of Network Level Authentication was to lessen the chance that someone could tie up your computer's CPU with bogus attempts at Remote Desktop sessions, and the second radio button leaves open that possibility. Once again, security and compatibility are sometimes tradeoffs.

Oh, hey, I almost forgot my favorite new Remote Desktop feature. You can cut and paste files across a Remote Desktop connection. Want to deliver a folder from your desktop to the computer that you're remoting into? Just right-click it, choose Copy, and then left-click on some folder in the remote system, right-click, and choose Paste. Quite nice, although as far as I can see, the revised RDP client for XP and 2003 doesn't support this. The revised RDP client looks as if it'll manage that drag and drop, but when you drop, nothing happens.

NTFS and the Registry Are Transaction Based

This falls in the category of a good surprise, in fact a really nice one. Both the file system and the Registry are now transaction based in Vista. This surprised me because it was supposed to appear in Server 2007 but it's in Vista. "Transaction based" means that you can take a number of separate files, copy, move, or whatever operations you need, and essentially package them up so that they're all or nothing. If one of the operations fails, then you just "roll back" and everything done so far is undone. Here's an actual example run:

 Microsoft Windows [Version 6.0.5456] (C) Copyright 1985-2005 Microsoft Corp. C:\Users\mark>transaction /start A transaction has been successfully started. Transaction ID: {} C:\Users\mark>md newfiles C:\Users\mark>copy con newfiles\test hi there ⁁Z 1 file(s) copied. C:\Users\mark>dir newfiles Volume in drive C has no label. Volume Serial Number is 4834-858C Directory of C:\Users\mark\newfiles 07/17/2006 06:48 PM <DIR> . 07/17/2006 06:48 PM <DIR> .. 07/17/2006 06:48 PM 10 test 1 File(s) 10 bytes 2 Dir(s) 15,731,507,200 bytes free C:\Users\mark>transaction /rollback The current transaction has been rolled back. C:\Users\mark>dir newfiles Volume in drive C has no label. Volume Serial Number is 4834-858C Directory of C:\Users\mark File Not Found C:\Users\mark> 

Here, I start a transaction, then create a new folder and put a file in that folder. But then I cancel the transaction, and it's all undone; asking for a directory listing of the new folder yields "File Not Found." In contrast, typing transaction /commit would have said "transaction's over, make it all permanent." Where will this be useful? Well, File and Registry-based transactions will be pretty useful for applying patches. Heck, you could actually install and test a piece of software, and then uninstall it via a transaction rollback. But that'd only work if the software didn't require a reboot; any reboots act as a transaction /rollback. I suspect we'll find plenty of pretty valuable uses for this. (I've got to say it again: the word "patches" keeps coming to mind.)

Warning 

Unfortunately around RC1, Microsoft took the transaction command out of Vista. Apparently the under-the-hood support for transaction-based NTFS and Registry is still there, but the command itself posed some theoretical problems and so Microsoft decided that letting regular users like you and me set up transactions would be a bad idea. So unless they change their minds, then transactions will be something that only programmers can set up. (Which might make sense; it's just a shame.)

Undelete Comes to Windows for Real!

If you've ever used System Restore for XP, then you know how useful it can be. System Restore takes periodic snapshots of the state of your operating system and lets you roll back to before you installed the Driver from Hell or that antivirus application that seems to work by crashing your system, which is of course one way to keep you from getting malware, although not the optimal one. Now, with Vista, System Restore does the same thing for your files. Right-click any file or folder and choose Properties, and you'll see a dialog box like Figure 1.8.

image from book
Figure 1.8: Previous Versions tab in a file's Properties page

Note the tab named Previous Versions. That's right, version s with an "s." Decided that your version of the Great American Novel was better two days ago and you didn't back up? No worries; check out Previous Versions and just grab the version from a couple of days ago. As before, you get a System Restore point once a day by default, or whenever you tell System Restore to create one.




Administering Windows Vista Security. The Big Surprises
Administering Windows Vista Security: The Big Surprises
ISBN: 0470108320
EAN: 2147483647
Year: 2004
Pages: 101

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net