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

Compare with Current View Page History

« Previous Version 13 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'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 (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.

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 (smile).

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 (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 certificates

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. Excerpt from /etc/nagios3/commands.cfg:

# Changed to include IPv6 flag 
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.

 

Microsoft SQL Server

FreeTDS library patch uitleggen

 

SSL certificate expiration date

RDP HTTPS check

 

 

  • No labels