...
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 exclusively 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.
...
To manage the server, Remote Desktop Protocol (RDP) is used, which supports IPv6 without any configuration.
...
Microsoft Update
Unfortunately the Microsoft Update servers are also available only on IPv4 
.
I set-up a dual-stack limiting HTTP proxy server, and added a number of regular expressions to allow Windows updates to happen.
Details of the proxy and the Windows configuration process are described on a separate page.
According to Microsoft, Windows 8 will use IPv6, if available, to download Windows Updates. They will works with Content Delivery Networks (CDNs) to extend IPv6 support later. So at this time, for Windows Server 2008 R2, the update servers are accessible only through IPv4.
As a solution I set-up a dual-stack limiting HTTP proxy server, and added a number of regular expressions to allow Microsoft Updates to happen.
Details of the proxy and the Windows configuration process are described on a separate page.
As can be seen from the lists, several other URLs also need whitelisting, such as CRLs and OCSPs.
Windows Activation
Same story here. Activating Windows is done by several HTTP POSTs to URLs in the go.microsoft.com domain, which is not (yet) accessible through IPv6:
http://go.microsoft.com/fwlink/?LinkID=88342 | Processor Certificate URL |
| http://go.microsoft.com/fwlink/?LinkID=88343 | Machine Certificate URL |
| http://go.microsoft.com/fwlink/?LinkID=88345 | Use License URL |
| http://go.microsoft.com/fwlink/?LinkID=88344 | Product Key Certificate URL |
Since the proxy server was already in place, I just needed to add this domain to the proxy whitelist, and then the Windows activation succeeded.
As can be seen from the lists, several other URLs also need whitelisting, such as CRLs and OCSPs.
Secunia CSI
This tool monitors installed software for vulnerabilities. We have the corporate version CSI 6. This is a service that registers itself at Secunia to download patch lists, upload results, etc.
...
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 software does not support this any more. So I had to upgrade, preferably to the latest supported version, which is SQL Server 2012. Because such an upgrade needs an intermediate step, I decided it was OK to use SQL Server 2008 R2 for now.
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 While testing I quickly found out that the Exact application was using ODBC, which did support IPv6 right away, so the application works worked on IPv6 
.
Delta software
This is proprietary software made by Dutch company BCS BCS HRM en Salarisadministratie B.V..Recently we bought a server license, and after some research I found out that is and 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 According to this document, SQL AnyWhere supports IPv6 from version 10, which is from date back to 2006. Version The docs for version 11 and 12 support it explicitlystate is even more explicitly with some examples. These docs came in handy because they list some special all the connection options that , which 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 properly implement the service discovery. Instead , I hardcoded the server FQDN, which worked fine. After After opening up TCP port 2638 the software worked
Crypto
I wasn't really sure how safe this SQL Server traffic was, but running Wireshark revealed plain text SQL queries on the wire . I think it's good practice to encrypt traffic containing personal data, even though it's inside our own network. SQL Server 2008 R2 supports SSL encryption, and because because we get "free" SSL certificates through through SURFnet (which is part of the TERENA Certificate Service), we should be good to go!
I created the cryptographic materials on one of our Ubuntu systems because those already have OpenSSL installed. All of this is also perfectly possible on Windows, but you do need some extra bits such as Microsoft Visual C++ 2008. I just didn't want to pollute my Windows system with extra software that is already installed elsewhere in our network.
| Code Block |
|---|
openssl req -new -keyout server.key -out server.csr -subj /CN=hayek.terena.org/ |
...
| Code Block |
|---|
cp cert-11988-hayek.terena.org.pem all.pem cat chain-11988-hayek.terena.org.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 and added the Certificates snap-in. When When it asked for who to manage certificates, I selected the selected the "Local System" account, because I was running the snap-in as Administratorthat's what the SQL Server was configured to run as.
Expand: Console Root -> Certificates (Local Computer) -> Personal.
Right-click -> All Tasks -> Import. Navigated to Navigated to the pfx file and imported it, including all extended properties.
I kept "Mark this key as exportable" unchecked, as I already have the key materials in a different place. I figured that since it is not needed on this machine, we might as well disable it, so any future malicious export attempts will be impossible (or at least more difficult).
Configuring MS SQL Server to use the certificate
...
In my case nothing would show up
According to this Howto, the 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.
...
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 off this machine. The most obvious service is of course the channel by which the machine is managed: Remote Desktop Protocol (RDP). Based 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.
...
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 It is defined in /etc/nagios-plugins/config/ping.cfg. Interestingly Interestingly, there are checks to deal with dual stack monitoring:
| Code Block | ||||
|---|---|---|---|---|
| ||||
####
# 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
}
|
...
With the FreeTDS library now support supporting IPv6 connections, I went to the Nagios Exchange and picked check_mssql_health, which can do rather elaborate checks on all sort sorts of SQL Server properties.
...
Now that the server has an SSL certificate, it should be monitored so that we the admins get a warning when it is about to expire in about 3 years. The . 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 For example the check_smtp plugin has this option:
| Code Block |
|---|
-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 anythingyielded nothing, the handshake wasn't establisched, so that's a dead end for now. Connecting to RDP on port 3389 however happens with a nice TLS 1.0 handshake
| Code Block | ||||
|---|---|---|---|---|
| ||||
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:
...