NOTE: This article has been updated with a correction to the NetSH commands. Previously I documented the “forwarding” should be enabled on the interfaces, but “weak host receive” and “weak host send” is more accurate, as documented here:
Recently we had a problem with a web applicaiton configured for SSL-offload on our Load Balancers. Our F5 Guru (Ben Coddington) recommended that we swich to a “Layer 4 forwarding” configuration. In this mode, the F5 will forward TCP packets from the client directly to the web server without altering packet content, which is just what we needed.
Making this work on Server 2008 took a bit of extra leg work, though. Here are the bones of it:
- On the F5, create a new Virtual Server using the Type category “Performance (Layer 4)”. Make sure that address translation and port translation are disabled.
- Create a new F5 Pool that uses a simple port 443/ssl health monitor. You could use any of a number of load balancing methods, but I cose “Round Robin” because it is in keeping with the “simpler is better” school of thought.
- On the Server 2008 system, add a “loopback adapter” in the Device Manager. (At the root of the MMC console, right-click the computer and select “Add legacy device”. It will be of type “network adapter”, from manfacturer “Microsoft”, and have a name containing “loopback adapter”).
- Assign the load balanced IP to the loopback adpater with netmask “255.255.255.255”.
- Here is the trick… you must now allow “weak host receive” on all network interfaces involved with load balancing on the Server 2008 system, and “weak host send” on the loopback interface. If this step is skipped, the Windows server will drop all packets destined for the load balancer address:
- Make sure you have a vaild SSL certificate configured on all RDGateway systems in your farm.
That’s about it… The F5 will forward all packets sent to the load balanced IP to the next pool member in the rotation (barring persistence). The Server 2008 host will receive the packet, and forward it to the loopback adapter (following TCP/IP routing logic). The Server 2008 host will reply directly to the client. Amazingly, it all seems to work.
I have been having some “fun” this week in exploring two-factor authentication possibilities for Macintosh and Windows 7 clients when connecting to Server 2008 and Server 2003 resources, especially via RDP. Findings so far:
All Smart Cards are not created Equal:
- Microsoft released a new Cryptographic API (CNG) with Vista/Server 2008. This API allows Smart Cards to use the “Microsoft Smart Card Key Storage Provider” CSP (which, apparently, is part of the MS “Base CSP”), instead of a vendor-specific CSP, when generating certificates for Smart Card-based logon. You must still install a driver for each Smart Card, but very often these drivers are available though Windows Update.
- Aladdin/SafeNet eTokens do not support CNG, so you cannot use CNG-based Certificate Templates (i.e. Server 2008-compatible templates) when issuing Smart Card Logon certificates to Aladdin eTokens. Thus, you must make sure that any Certificate Template that you use for Smart Cards are compatible with Server 2003 or earlier. You also will need a software stack including the eToken CSP and drivers before you will be able to perform Smart Card login using an eToken.
- Gemalto .NET Smart Cards do support CNG, so you can use CNG certificate templates with these Smart Cards.
- RSA SecurID Hybrid Authenticators do not appear to support CNG, according to their (dated) product data sheet, so I expect you would need a custom CSP to use these for Windows Logon, too.
- PGP Desktop can be configured to use keys stored on a Smart Card to unlock PGP-WDE encrypted drives. However, only a few vendor’s Smart Cards are supported in this capacity, probably because PGP has hard-coded in support for only a few CSPs:
- Aladdin eToken devices are supported both for WDE sign-on and for Administrator Key storage.
- RSA Smart Cards are supported for WDS sign-on only
- Gemalto Smart Cards are not supported at all.
Web Service Enrollment was dead:
- Most how-to sites you visit on certificate enrollment and smart card logon (including one in Tech Net) state that you should set up a Certificate Enrollment Agent Workstation to use the Web Services interface on your MS Certificate Server. Guess what? The procedures do not work anymore on Server 2008:
- Server 2008 R2 has a new Web Enrollment interface that supports Smart Card enrollment from Vista/Win7 workstations. Ban the use of Server 2008 R1!
- Use the “Certificates” MMC snap-in in place of web enrollment if you must run Server 2008 (R1).
RDGateway – Smart Card Authentication requires trust:
- Smart Card auth to our Remote Desktop Gateway Load Balancing cluster (based on F5) was failing. Apparenly something about the SSL-offload configuration was creating a trustworthiness problem, and this was preventing Kerberos/Smart Card authentication from working. We switched to a TCP/Layer-4 forwarding config, and now Smart Card authorization works just fine. Note that the config that works is not the one that was recommended by F5. They are big into TCP offload over there. The thing is, for Kerberos and Smart Cards to work in an SSL-offload config, you need F5’s expensive Advanced Client Authenticaiton module. I do not need more cost and complexity, so we will keep things simple this time.
Configuring IPv4 on the Local network interface:
- To set your IP address:
netsh interface ip set address name=”Local Area Connection” static <ip address> <netmask> <default gateway>
(Note: If you are using netsh on a platform earlier than Server 2008 (i.e. Server 2003) you may nned to provide more explicit parameters such as:
netsh interface ip set address name”Local Area Connection” source=”static” addr=”<addr>” mask=”<mask>” gateway=”<gateway>” gwmetric=”1″)
- To set your first DNS server:
netsh interface ip set dns “Local Area Connection” static <DNSServerIP>
(NOTE: You may want to set DNS info first if you need your interface to be functional as soon as the IP address comes online.)
- To set your first WINS server:
netsh interface ip set wins “Local Area Connection” static <WINSServerIP>
- Setting up additional WINS and DNS servers:
- run “netsh”
- go to the context “interface ip”
add dns "Local Area Connection" <DNSServerIP> index=2then
add wins "Local Area Connection" <WINSServerIP> index=2
Verify settings with:
"ipconfig /all" or "netsh interface ip show config"
Installing VMWare Tools:
- In the ESX console, initiate “Install VMWare Tools”
- At the server console, switch to D:, run setup.exe with typical options, wait wait wait wait, affirm that you want to install the updated help files, reboot.
Changing the console resolution:
- use regedit.exe
- navigate to:
(or whichever GUID key have the subkey of “0000” named “VolatileSettings”)
- Change “DefaultSettings.XResolution” and “DefaultSettings.YResolution” to your desired values in decimal format.
Enabling remote desktop:slmgr
- cscript C:WindowsSystem32Scregedit.wsf /ar 0
- netsh advfirewall firewall set rule group=”Remote Desktop” new enable=yes
Activating a KMS:
- After networking is configured, use SLMGR.vbs to activate your KMS
- For you sanity, you may wish to perform “cscript //H:cscript” to set the command line script interpreter as the default script handler.
- run “slmgr.vbs -ipk <KMS product key>”
- run “slmgr.vbs -ato” to activate the KMS
- run “Netsh advfirewall firewall set rule group=“Key Management Server” new enable=yes” to allow KMS client traffic through the firewall (more on this below)
- run “slmgr.vbs -dlv” to monitor KMS activity.
Allowing Remote Administration:
- Netsh advfirewall firewall set rule group=“<rule group>” new enable=yes
- <rule group> can include:
Now that I have remote access via MMC, I see that the group “Key Management Service” is also available. Also see the “Remote Desktop” group, above.
- Remote Event Log Management
- Remote Service Management
- File and Printer Sharing
- Remote Scheduled Tasks Management
- Performance Logs and Alerts
- Remote Volume Management
- Windows Firewall Remote Management