Unlike earlier versions of Microsoft Windows Server, the 2008 version gives you a default logon screen that is very similar to Vista. Instead of the the interactive dialog box that prompts you for a username, password, and sometimes domain, users will find a “push button” screen displaying all users with login permissions. To log into an account all the users will now need to know is the password. This makes things much easier for hackers as the only thing they will now need to guess is the password.

There are a couple of ways to resolve this problem. First, the server administrator can set the local security policy to not display the last username and disable fast user switching. Second, in the System Remote Settings dialog, the remote desktop options can be set to allow computers with Remote Desktop that support Network Level Authentication.

Since the first method is covered in a few blogs, I’ll limit myself to discussing the second method. In the latest versions of Remote Desktop Connection client (version 2.0 for Mac and the version shipped with Windows Vista), Network Level Authentication is supported. This means users must send the username and password before Windows 2008 accepts the connection. Earlier versions of RDC (like the one found in many installations of Windows XP) don’t support NLA. So technically, users will only need to supply the IP or domain name of the remote Windows server, leave the username and password blank, and interact with the logon process that is provided at connection time. Windows 2008 servers that do not have the NLA option set for remote desktop connections are vulnerable since the interactive logon screen (post-connection) is displayed to users using earlier versions of RDC.

This last point may be of significance to service providers offering Windows 2008 dedicated servers. If the server is set up with default settings, the NLA option is disabled and new users will by default be made to change passwords on first logon. Users using new versions of RDC will not be able to logon because the initial password change sequence on first logon is not compatible with NLA. The server will return an incorrect password message to the RDC client even though the user has provided the correct username and password. The only way to establish first connection is thus to use a non-NLA supporting version of RDC so that the user can establish connections without supplying credentials and then going through the password change wizard during the initial login. But as mentioned, having NLA disabled on server side is not an ideal practice at this point.

So there are a couple ways to do this. The service provider should disable the “change password on next logon” option during the user creation process and get user to manually change the password after logon. Or alternatively, assist the client/user in changing passwords through the console internally.