If you’ve ever been under the mistaken impression that the RDP client controls the color settings for remote connections, then you came to the right place for help.
Windows XP and Windows 2003 servers won’t show more than 16-bit color depth to RDP clients requesting 24-bit or better color. You can confirm this by looking at the display settings in the control panel of the remote server. As a result, black text looks like funny shades of purple, photos look slightly posterized, and any color-critical tasks may be impossible to accomplish by remote control.
To fix this problem, you must enable the following policy:
Computer Configuration > Administrative Templates > Windows Components > Terminal Services > Limit maximum color depth
Set the Color Depth field to 24 bit and click OK.
I can’t explain why Windows would be limited in this way by default, but it is.
Client certificates are a cool technology that, once setup, eliminate the need to use your password on your own website from your own devices.
This article wont run through the entire procedure for setting up a web server, Windows domain, file permissions, server certificates, or a certificate authority. I just want to convey some of the configuration pitfalls that exist in IIS 6.
Back in August, I mentioned the importance of disabling most versions of PPTP for security reasons, and included my own tutorial for How to Secure a Windows VPN with PEAP. That solution works great for Windows, but is not compatible with iPads.
Now I will offer a solution that works great for iPad, but may not work on Windows computers. In addition, I will explain how to get the two solutions to work together securely so that both Windows and iPad computers will be able to connect to a Windows VPN simultaneously without using the insecure versions of PPTP.
The Layer 2 Tunneling Protocol (L2TP) is an obvious choice for the iPad because it is the only supported protocol other than the insecure PPTP option. On the server side, however, there are some implementation nuances that could easily discourage the use of L2TP. I took the time to research L2TP in more depth before writing this article, because I felt that a generic recommendation could leave readers totally confused about the security issues involved. So before delving into a new tutorial, I want to explain two new concepts: L2TP Pre-Shared Key, and L2TP NAT Traversal.
A careful reading of the Microsoft recommendation against NAT-T will reveal that the underlying security problem with NAT-T is not a server problem but a client problem. In other words, Microsoft recommends that Windows XP computers not attempt to use NAT-T to connect to privately-addressed servers. The Windows 2003 server itself fully supports NAT-T out of the box and doesn’t even need to be configured to use it. This is perfect for iPad users, because iPad also supports NAT-T out of the box, and this almost eliminates the address translation challenges of using L2TP.
In light of last month’s announcement by Moxie Marlinspike and David Hulton that they developed a method for decrypting Windows VPN traffic in under 24 hours, it is now important to stop using MS-CHAPv2 as a means of authenticating VPN passwords.
There is a relatively simple fix for this. Microsoft VPN servers have the ability to authenticate passwords using another protocol called PEAP, also known as PEAP-EAP-MSCHAPv2. The only reason one might avoid using PEAP in the first place is that the Microsoft documentation is confusing and describes a requirement for Public Key Infrastructure (PKI) deployment. The PKI as described in Deploying Remote Access VPNs requires anywhere from one to three servers just to issue certificates. However, it only specifies the PKI requirement for a slightly different protocol called EAP-TLS.
To be clear, PEAP does not require a full-blown PKI or even an internal Certificate Authority. You can, in fact, use the same certificate that has been, or would be, issued to a web server for SSL encryption. There is no reason to add a second certificate just for a VPN server. This also means there is no investment required in PKI if a free certificate issuer is used, such as startssl.com.
Below is a brief tutorial for configuring an existing RRAS installation with PEAP-MS-CHAPv2.
I’ve stumbled upon a seemingly undocumented authentication error in the Windows VPN system.
Error 691: Access was denied because the username and/or password was invalid on the domain.
This can be caused simply by elevating the VPN server’s LM authentication level to 5, which refuses the NTLM protocol. According to KB823659 requiring NTLMv2 should not break Windows XP connections unless older systems are involved. However, this configuration does cause client and server authentication errors.
Anyone who has attempted a Virtual Private Network (VPN) connection in Windows XP has run into this problem: You want to have access to computers at your home or office, but Windows accomplishes this by routing all of your activity to the home network. If your work involves transferring files to a server and surfing the Internet, then your Internet activity has to piggyback on the VPN and travel twice within your limited home bandwidth. This means your slow VPN is even slower when you load a website, and any interruption of the VPN will break all of your connections to FTP sites, IM services, etc.
You may have tried to coerce Windows into routing your traffic to two different gateways, but quickly realized it wasn’t designed to do that. Adding entries to the local routing table can solve the problem temporarily, but doing so requires administrative privileges and ugly dynamic logic to handle a gateway address that changes every time you connect the VPN.
My solution for this scenario comes in two parts: 1. A static address for the VPN client computer, and 2. A persistent route for the VPN client’s static address. This is a bit easier said than done, so the following tutorial includes screenshots and details.
At 2:45 this morning, my home office / techie practice server suffered a catastrophic failure of its primary slave disk. Among other things, that disk was responsible for storing the Active Directory log file for the server’s Windows 2003 domain controller. The device itself was a Maxtor 20 gig model going on 12 years of age. It was still in service after the server’s motherboard overhaul because of the Windows 2000 Active Directory Services recommendation: “For best performance, place the database and the log file on separate hard disks.”
