You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

 

So, the time has come to retire our old Windows 2003 server. This box runs bookkeeping software (Exact Globe 2003, and BCS Delta), and is exclusively used internally by the accounting staff.

The first thought that came to mind: since we're running several Linux servers already on IPv6-only, would it be possible to run a Windows server also on IPv6?

While Windows Server 2012 has been released recently, we can not use it (yet), because the latest version of Windows that our current VMware setup (ESXi 4.1) supports as guest OS is Server 2008 R2.

So I'llgo for 2008 R2 and give it a shot.

Basics

IPv6-only VLAN

A dedicated VLAN was created for IPv6-only systems, so that building, testing and configuring would not interfere with any production networks. Configuring this VLAN with only IPv6 allows to use simpler IP Access Control Lists (ACLs), and start from scratch:

interface Vlan9
 description IPv6_only_Servers
 no ip address
 no ip proxy-arp
 ipv6 address 2001:610:148:BAD::1/64
 ipv6 nd prefix 2001:610:148:BAD::/64
 ipv6 traffic-filter ipv6_servers2_out in
 ipv6 traffic-filter ipv6_servers2_in out
end

I started out with IPv6 ACLs that disallow everything by default, and then open up specific things.

Addressing

Obviously, the first thing to do is to uncheck IPv4 in the interface configuration (smile). For IPv6 addressing I choose autoconfigured EUI64, no privacy extensions. The reason is that this is a server, and it will not be used for any web browsing activities. Static addresses also help configuring the (empty) IP ACLs. The idea is that during configuration and testing the IPv6 ACLs will be constructed, based on stuff that does not work. Eventually, when everything works, it might be an option to use privacy extensions.

Also, I disabled all tunnelling stuff (ISATAP, Teredo, etc). Combined script:

REM RFC 4941 privacy extensions (i.e. temporary address for outgoing connections)
netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent
 
REM Don't use random identifiers. This will result in EUI64 based adddresses
netsh interface ipv6 set global randomizeidentifiers=disabled store=active
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

REM disable unused tunneling protocols
netsh interface ipv6 6to4 set state disabled
netsh interface ipv6 isatap set state disabled
netsh interface ipv6 set teredo disabled

 

DNS

The DNS server addresses are statically assigned, and are picked from the SURFnet DNSSEC-validating resolvers.

The "Register this connection's addresses in DNS" option has been deselected, because this causes DNS registration requests to go out, which we do not want. Eventually things look like this:

 

NTP

At the time of writing, the default time server that is used by Windows 2008 R2 to sync its clock, time.windows.com, unfortunately is not (yet) reachable over IPv6.

But again, SURFnet comes to the rescue, because several of their NTP servers are IPv6-enabled. I picked chime3.surfnet.nl, which, according to the web interface, appears to be a Meinberg NTP server. Windows digs it all-right:

 

RDP

To manage the server, Remote Desktop Protocol (RDP) is used, which supports IPv6 without any configuration.

Windows Update

Unfortunately the Microsoft Update servers are also available only on IPv4 (sad).

I set-up a limiting HTTP proxy server that listens on IPv6, and added a number of regular expressions to allow Windows to download updates.

As can be seen from the lists, several other URLs also need whitelisting, such as CRLs and OCSPs.

Details of the proxy and the Windows configuration process are described on a separate page.

Exact Software

I phoned up Exact Software Netherlands to see if Exact Globe would support IPv6, but the help desk could not provide me with a definitive answer. So then, time for some testing. 

Exact Globe consists of a network share containing an installer, and an SQL Server. Clients map the network drive and install the software on their computer.

Windows 2008 R2 support SMB (File sharing) over IPv6-only without any problems:

 

Once installed, the software then initiates a connection to TCP port 1433 of an SQL Server. In our case this is the same server.

The old (Windows 2003) server runs SQL Server 2000, but starting from release 404 (July 2012), the Exact software does not support this any more. So I had to upgrade to SQL Server 2008 R2.

That software supports IPv6 just fine, but I was a bit wary of potential client side issues. All users in accounting all run Windows 7, so the operating system itself shouldn't be a problem.

While testing I quickly found out that the Exact application was using ODBC, which did support IPv6 right away, so the application works on IPv6 (smile).

 

Delta software

This is another piece of proprietary software, this time made by Dutch company BCS HRM en Salarisadministratie B.V..

Recently we bought a server license, and after some research I found out that is made up of a network share with files, and a database component.

 The network share can do IPv6 as mentioned earlier. The database component turns out to be an instance of Sybase SQL AnyWhere version 11.

Again the vendor had no clue what IPv6 was, so I did some research myself, and it actually looked good right away.

Apparently Sybase does support IPv6 already for years. The earliest doc I could find was for version 10 (from 2006).

Version 11 and 12 support it explicitly. These links were handy, because the software needed some custom connection options.

After opening up TCP port 2638 to the appropriate IPv6 addresses, the software worked (smile)

 

 

Crypto

I wasn't really sure if the SQL Server traffic was plain text or not, and after running Wireshark it turned out that is wasn't...

Because we are part of the TERENA Certificate Service, we have access to 'free' SSL certificates from SURFnet.

Generating key material

I did this on a host with OpenSSL. Also possible on the Windows host but I will write about that later.

openssl req -new -keyout server.key -out server.csr -subj /CN=hayek.terena.org/

I submitted the signing request to the SURFnet web site, and after a few hours, and jumping through the Domain Control Validation hoops, I got a signed certificate (cert-11988-hayek.terena.org.pem) back, and the chain, which consists of 3 certificates concatenated into one file (chain-11988-hayek.terena.org.pem).

Then combined all certificates into one file, and created a PFX from these materials:

cp server.pem all.pem
cat chain.pem >> all.pem
openssl pkcs12 -export -inkey server.key -in all.pem -out server.pfx

Adding the key and materials

Copy this file to the Windows server, and run mmc, then add the Certificates snap-in.

When it asks for who to manage certificates, select an account that the SQL Server has access to.

In our case that was the "Local System" account, and we were running the snap-in as Administrator, so all is well.

Expand: Console Root -> Certificates (Local Computer) -> Personal.

Right-click -> All Tasks -> Import.

Now navigate to the pfx file and import it. Include all extended properties.

I kept Mark this key as exportable unchecked, as I already have the key material in PEM format in a different place.

We don't need this, and any malicious export attempt will be more difficult this way.

 

Configuring MS SQL Server to use the certificate

Run the SQL Server Configuration Manager, expand the SQL Server Network Configuration, and right-click Protocols for MSSSQLSERVER (or whatever your instance is called).

On the Certificate tab you should be able to see your certificate.

In my case nothing would show up (sad)

According to How to: Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager), the name of the certificate must be the fully qualified domain name (FQDN) of the computer. The TCS certificates we use can only contain a valid FQDN as the Subject's Common Name (CN), so this was correct. I checked permissions and those seemed to be OK as well.

It turned out that the server did not have a Full Computer Name yet... duh.

After fixing that the certificate showed up in the SQL Server Network Configuration. Then I forced encryption, checked again with Wireshark and indeed no more plain text queries (smile)

 

 

RDP Crypto

Since we now have a nice server certificate in the Windows Certificate Store, I figured I might as well use it to secure more services that run of this machine. The most obvious service is of course the channel by which the machine is managed: Remote Desktop Protocol (RDP). Based on the docs for Remote Desktop Services (RDS), this service does support SSL (TLS1.0). The installed certificate can be configured with the Remote Desktop Session Host Configuration. While at it, I also selected to only use SSL (TLS 1.0), and High Encryption level:

Using Wireshark it is again easy to spot that the session is encrypted.

 

Then I noticed one thing. Up until now I would always get this warning upon connecting to a Windows server:

 

 

After installing a real certificate, this warning isn't shown any more, and a nice little lock is shown on the RDP status bar, which shows the certificate information if clicked:

 

 

 

 

Service monitoring

All of this stuff is very nice, but it's no good without monitoring.

We run a Nagios 3.x instance in a remote data center, and ideally I'd want to monitor all services that this hosts runs.

Host alive

Modified version of the default host alive check, with IPv6 flag. From /etc/nagios3/commands.cfg:

 

# Changed to include IPv4 flag - DV 2010-12-04
define command{
        command_name    check-host-alive6
        command_line    /usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -6 -w 5000,100% -c 5000,100% -p 1
}

 

Disk usage

This can be done with the standard check_disk_smb_host_user, because that relies on the smbclient binary, which is part from the samba-3.4.7 package, which supports IPv6.

 

 

 

  • No labels