Remote desktop gateway connections failing when KB2592687 installed.

While setting up a lab running Remote Desktop Gateway on Windows Server 2012 R2 I came across a strange problem. I was able to connect through the RD Gateway using some machines but not others.
On the machines that were failing I got the following message when trying to connect:
"Your computer can't connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance."

After much pulling of hair I narrowed it down to something to do with the KB2592687 update. This update installs RDP version 8.0 on Windows 7 SP1 machines. This update was present on both the machine I was trying to connect to and on the clients that were failing. There is a list of known problems in knowledge base article but none of them applied to my setup.

More searching found loads of red herrings, then I discovered this post. It mentions LAN manager authentication level settings (Local security policy->Local Policies->Security Options->Network Security: LAN Manager authentication level). On the failing client it was set to "Send LM & NTLM - user NTLMv2 session security if negotiated." Changing it to "Send NTLMv2 response only" (which seems is the default on Vista and above) made the connection work.

Extending disks on a Windows VM

Extend disks on a Windows Server 2008 R2 machine (and probably Windows 7 as well).

Extend the hard drive in VM Settings, this can be done while Windows is running but I was unable to get Windows to see the new size until after I rebooted the VM.

GUI
Server manager->Storage->Disk management, right click on the drive and choose "Extend Volume..." select size to expand to then click next.

Command line way
Start->Run and type diskpart.
At the disk part prompt type:

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online           40 GB  5121 MB

This will show you a list of the disks in the system, once you have identified the disk you want by it's number (I only have disk 0 (zero) in the example above).
We now need the volume number:

DISKPART> list volume

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   CD           CDFS   DVD-ROM      112 MB  Healthy    
  Volume 1         System Rese  NTFS   Partition    101 MB  Healthy    System
  Volume 2     C                NTFS   Partition     40 GB  Healthy    Boot

Now "select" the volume you want to extend (in this case I am extending my C drive so it is volume 2).

DISKPART> select volume 2

Volume 2 is the selected volume.

Now tell diskpart to extend the volume into the all the free space on disk 0:

DISKPART> extend disk=0

DiskPart successfully extended the volume.

That is it, all done.


Another easy way to extend disk sizes (as well as many other useful functions) is to run a live CD of gparted. This will also works with other operating systems such as Linux. In fact it should work any file system that gparted understands, check out there features page.

Setting up a branch office VPN between a Watchguard XTM505 and a Debian linux box.

Lets us say you have two sites and want to build a VPN between them. The first site has a Watchguard XTM device has a public IP address of 99.99.99.99 which protects a private IP address range of 10.0.1.0/24 and your second site has just a Debian Linux box which has a dynamic IP address that protects a private IP address range of 10.0.2.0/24


Debian side

Install needed packages:

# apt-get install ipsec-tools racoon

            Choose "direct" for racoon setup

Edit /etc/ipsec-tools.conf

#!/usr/sbin/setkey -f

# NOTE: Do not use this file if you use racoon with racoon-tool

# utility. racoon-tool will setup SAs and SPDs automatically using

# /etc/racoon/racoon-tool.conf configuration.

#

## Flush the SAD and SPD

#

# flush;

# spdflush;

spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec

           esp/tunnel/99.99.99.99-10.0.2.254/require;

spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec

           esp/tunnel/10.0.2.254-99.99.99.99/require;

Edit /etc/racoon/psk.txt and add the line

99.99.99.99   Somerandomkey

Edit /etc/racoon/racoon.conf

# Simple racoon.conf

#

#

# Please look in /usr/share/doc/racoon/examples for

# examples that come with the source.

#

# Please read racoon.conf(5) for details, and alsoread setkey(8).

#

#

# Also read the Linux IPSEC Howto up at

# http://www.ipsec-howto.org/t1.html

#

path pre_shared_key "/etc/racoon/psk.txt";

path certificate "/etc/racoon/certs";

remote 99.99.99.99 {

        exchange_mode aggressive,main;

        dpd_delay 20;

        dpd_maxfail 5;

        my_identifier user_fqdn "something@company.com";

        proposal {

                lifetime time 28800 second;

                encryption_algorithm 3des;

                hash_algorithm sha1;

                authentication_method pre_shared_key;

                dh_group modp1024;

        }

}

sainfo address 10.0.2.0/24 any address 10.0.1.0/24 any {

        lifetime time 28800 second;

        pfs_group modp1024;

        encryption_algorithm 3des;

        authentication_algorithm hmac_sha1;

        compression_algorithm deflate;

}

Watchguard side

I have simply taken screen shots for the configuration for the watchguard side:

You will need to ensure that the preshared random key is the same as you used in the /etc/racoon/psk.txt file you created above.

VMs, snapshots and domain computer accounts.

Have you ever had the problem where you have reverted a VM's snapshot to find that it's computer password is out of sync with the domain? I have, loads of times. This is often seen with the following message when you attempt to log in: "Windows cannot connect to the domain, either because the domain
controller is down or otherwise unavailable, or because your computer
account was not found."

The problem is that Windows machines on a Domain change their computer account passwords with a Domain controller every 30 Days. If a machine changes it's computer password with a domain controller and you then revert to a snapshot that was taken before the password was changed the computer account will no longer be able to authenticate on the network and domain users won't be able to logon.

How do you get around this? One way is in Microsoft's KB article 154501.

This can reduce the security on your domain, or at least the security between the DC and the workstation you make the following registry changes on but if you have a testing setup like I do this is not much of a problem and the convenience easily outweighs any security issues (in my opinion :).
You can set the DisablePasswordChange registry entry to 1 in :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

That has now stopped this machine from changing it's domain password every 30 days. Now we need to get the machine back onto the domain, to achieve this do one of the following:

A. Remove the computer from the domain and add it back in again. Easy enough you say. I have a lot of test machines floating about that don't always have the same local administrator password. So it is a good idea to make sure that you know a local administrators password before you remove the machine from the domain otherwise you will end up with a machine you cannot access via windows (all is not necessarily lost, trinity rescue kit can help here).

B. Remove and rejoin the machine to the domain using the netdom.exe command:

netdom remove <machine name> /Domain:<domain name> /userd:<domain name>\<domain administrator account name> /passwordd:<domain administrator password>

Wait for the response:

The command completed successfully.

Then run:

netdom join <machine name> /Domain:<domain name> /userd:<domain name>\<domain administrator account name> /passwordd:<domain administrator password>

Again we are looking for the response:

The command completed successfully.

It is probably best to reboot the machine at this point, it is a windows machine after all we were messing with the domain membership and I simply would trust a machine in this state to function as expected unless it is rebooted.