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?
Last year my intern Joris Claassen has proved that it was possible to run a basic VMware Vsphere cluster on IPv6 only, and that included a Windows box as well. So things look bright.
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'll go 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 
. 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 
.
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.
File sharing
Windows 2008 R2 does SMB (File sharing) over IPv6-only without any problems:
Windows Internet Name Service (WINS) does not work with IPv6. But because this was a piece of junk anyway, nothing is lost here.
SQL Server
Once installed, the Exact 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.
This supports IPv6 just fine. All users in accounting all run Windows 7, so the operating system itself shouldn't be a problem, but I was a bit wary of potential client side application issues. 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 .
Delta software
This is proprietary software 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.
Sybase SQL AnyWhere
The database is a Windows Service, based on a file called dbeng11.exe. It's not stated as such in the BCS documentation, but this is an instance of SQL AnyWhere Personal Server:
The BCS support desk had no clue what IPv6 was, so I did some research myself.
There is a nice and very clear PDF that explains SQL AnyWhere networking essentials. According to this document, SQL AnyWhere supports IPv6 from version 10, which is from 2006. Version 11 and 12 support it explicitly. These docs came in handy because they list some special connection options that I needed.
Since we only have one instance of SQL Anywhere, which is running in a different network than the clients, I figured it didn't make much sense to implement the broadcast/multicast stuff that is needed for the service discovery. Instead, I hardcoded the server FQDN, which worked fine. After opening up TCP port 2638 the software worked
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.
Note that I did this on one of our Ubuntu system because those already have OpenSSL. The same things are perfectly possible on Windows as well.
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 I combined all certificates into one file, and created a PFX from it:
cp server.pem all.pem cat chain.pem >> all.pem openssl pkcs12 -export -inkey server.key -in all.pem -out server.pfx
After copying the PFX file to the Windows server, I ran mmc and added the Certificates snap-in. When it asked for who to manage certificates, I selected the "Local System" account, because I was running the snap-in as Administrator.
Then expand: Console Root -> Certificates (Local Computer) -> Personal.
Right-click -> All Tasks -> Import. Navigated to the pfx file and imported 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.
Since we don't need this, any future malicious export attempts 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
According to this Howto, the name of the certificate must be the fully qualified domain name (FQDN) of the computer. Since the TCS certificates we use can only contain a valid FQDN as the Subject's Common Name (CN), this had to be 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
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, RDP 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.
Previously 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:
IPv6 service monitoring with Nagios
All of this stuff is very nice, but what good is a service when it is not being monitored?
We already run a Nagios-3.2 instance on an Ubuntu system in a remote data centre, and my goal is to monitor as much services on my new Windows host as possible.
Host alive
The check-host-alive test is a basic test from the nagios-plugins-basic package, and is based on check_ping, which can do IPv4 and IPv6, and defaults to IPv4. It is defined in /etc/nagios-plugins/config/ping.cfg. Interestingly, there are checks to deal with dual stack monitoring:
####
# use these checks, if you want to test IPv4 connectivity on IPv6 enabled systems
####
# 'check-host-alive_4' command definition
define command{
command_name check-host-alive_4
command_line /usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w 5000,100% -c 5000,100% -p 1 -4
}
Since our host's FQDN only has a AAAA DNS records, the default check is OK.
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.
Microsoft SQL Server
There is no Nagios plugins in any Ubuntu package that can check the status of SQL Server, but Nagios Exchange does list a number of them. They are written in various languages (Perl, Python, PHP), and they all rely on FreeTDS, a set of libraries for Unix and Linux that allows programs to natively talk to Microsoft SQL Server and Sybase databases. The bad part is that this library does not support IPv6, hence none of the plugins work with my server .
After asking around on the FreeTDS mailing list, a guy called Peter Deacon wrote a patch that adds IPv6. I did some testing with Perl and after forcefully installing a newer version of DBD::Sybase I was able to successfully connect to my SQL Server .
With the FreeTDS library now support IPv6 connections, I went to the Nagios Exchange and picked check_mssql_health, which can do rather elaborate checks on all sort of SQL Server properties.
SSL certificate expiration date
Now that the server has an SSL certificate, it should be monitored so that we get a warning when it is about to expire in about 3 years. The way I usually do this is by using a Nagios plugin to monitor a service that uses the certificate, and then pick the certificate expiration option of the plugin. For example the check_smtp plugin has this option:
-D, --certificate=INTEGER
Minimum number of days a certificate has to be valid.
The common way to test this sort of stuff is with OpenSSL's s_client, but unfortunately that does not support IPv6. Off then to GnuTLS.
Connecting to SQL Server on port 1433 does not do anything, so that's a dead end. Connecting to RDP on port 3389 however happens with a nice TLS 1.0 handshake
bofh@nagios:~$ gnutls-cli hayek.terena.org -p 3389 --x509cafile /etc/ssl/certs/ca-certificates.crt Processed 142 CA certificate(s). Resolving 'hayek.terena.org'... Connecting to '2001:610:148:bad:250:56ff:fe86:9:3389'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=NL,O=TERENA,OU=CFO,CN=hayek.terena.org', issuer `C=NL,O=TERENA,CN=TERENA SSL CA', RSA key 2048 bits, signed using RSA-SHA, activated `2013-01-23 00:00:00 UTC', expires `2016-01-23 23:59:59 UTC', SHA-1 fingerprint `513523a823b8d5c15c30a80f2772e58d826605ba' - Certificate[1] info: - subject `C=NL,O=TERENA,CN=TERENA SSL CA', issuer `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key 2048 bits, signed using RSA-SHA, activated `2009-05-18 00:00:00 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `3a881764472b6441ddb3afdd47c6b8b76ee7ba1d' - Certificate[2] info: - subject `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 2048 bits, signed using RSA-SHA, activated `2005-06-07 08:09:10 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `3d4b2a4c64317143f50258d7e6fd7d3c021a529e' - The hostname in the certificate matches 'hayek.terena.org'. - Peer's certificate is trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed
This indicates that it possible to monitor the certificate the same way as with HTTPS web sites. I tested this and it works
Concluding, this is what the monitoring looks like in the end:
