Caching Microsoft updates with ISA Server

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I used to use WSUS to update the machines on my home network but after a botched server upgrade, it all went screwy and I didn’t really want to have to pull all the updates down over my ADSL connection again (would probably blow away my month’s worth of “fair usage”). In any case all I was doing was blindly approving updates for installation so I might as well use the Microsoft Update servers instead.

The only downside of using the Microsoft Update servers to update several computers is that there is a lot of duplication in the network traffic. That’s why ISA Server 2006 includes a cache rule that enables caching of Microsoft updates using the Background Intelligent Transfer Service (BITS). For those who aren’t aware, BITS allows the transfer of large volumes of data without degrading network performance as it transfers the data in small chunks to utilise unused bandwidth as it becomes available and reassembles the data at the destination. The BITS feature is not available for any other ISA cache rule but the Microsoft Update Cache Rule is installed by default and all I needed to do was enable caching.

After setting up the cache rules and updating one of my servers, I wanted to see that the cache was being used. I’ve previously mentioned the cachedir.exe tool that can be used to examine ISA Server caches and I downloaded the latest version from Microsoft’s ISA Server 2006 tools page. After extracting the tool, I ran it and was presented with an error:

CACHEDIR.exe – Unable to Locate Component
This application has failed to start because msfpc.DLL was not found. Re-installing the application may fix the problem.

Then I remembered that cachedir.exe needs to be copied to the ISA Server installation folder (on my system that is %programfiles%\Microsoft ISA Server) – after moving the file to the correct folder, it fired up as expected. Just remember that this utility can only display the cache contents that have been written to disk. To flush the memory cache to disk you will need to restart the Microsoft Firewall service and re-run cachedir.exe to view the contents.

Removing phantom network adapters from virtual machines

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last night, I rebuilt my Windows Server 2008 machine at home to use the RTM build (it was running on an escrow build from a few days before it was finally released) and Hyper-V RC0. It was non-trivial because the virtual machines I had running on the server had to be recreated in order to move from the Hyper-V beta to the release candidate (which meant merging snapshots) and so it’s taken me a few weeks to get around to it.

The recreation of the virtual machine configuration (but using the existing virtual hard disk) meant that Windows detected new network adapters when I started up the VM. Where I previously had a NIC called Local Area Connection using Microsoft VMBus Network Adapter I now had a NIC called Local Area Connection 2 using Microsoft VMBus Network Adapter #2. The original adapter still configured but not visible. Ordinarily, that’s not a problem – the friendly name for the NIC can be edited but when I went to apply the correct TCP/IP settings, a warning was displayed that:

The IP address ipaddress you have entered for this network adapter is already assigned to another adapter Microsoft VMBus Network Adapter. Microsoft VMBus Network Adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. If the same address is assigned to both adapters and they become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the advanced dialog box?

That wasn’t a problem for my domain controller VM, but the ISA Server VM didn’t want to play ball – hardly surprising as I was messing around with the virtual network hardware in a firewall!

In a physical environment, I could have reinserted the original NIC, uninstalled the drivers, removed the NIC and then installed the new one, but that was less straightforward with my virtual hardware as the process had also involved upgrading the Hyper-V gues integration components. I tried getting Device Manager to show the original adapter using:

set devmgr_show_nonpresent_devices=1
start devmgmt.msc

but it was still not visible (even after enabling the option to show hidden devices). Time to break out the command line utilities.

As described in Microsoft knowledge base article 269155, I ran devcon to identify the phantom device and then remove it. Interestingly, running devcon findall =net produced more results than devcon listclass net and the additional entries were the original VMBus Network Adapters. After identifying their identifier for the NIC (e.g. VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}: Microsoft VMBus Network Adapter), I could use devcon to remove the device:

devcon -r remove "@VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}"

Result! devcon reported:

VMBUS\{20AC6313-BD23-41C6-AE17-D1CA99DA4923}\5&37A0B134&0&{20AC6313-BD23-41C6-AE17-D1CA99DA4923}: Removed
1 device(s) removed.

I repeated this for all phantom devices (and uninstalled the extra NICs that had been created but were visible, using Device Manager). I then refreshed Device Manager (scan for hardware changes), plug and play kicked in and I just had the NIC(s) that I wanted, with the original name(s). Finally, I configured TCP/IP as it had been before the Hyper-V upgrade and ISA Server jumped into life.

Just one extra point of note: the devcon package that Microsoft supplies in Microsoft knowledge base article 311272 includes versions for i386 and IA64 architectures but not x64. It worked for me on my ISA Server virtual machine, which is running 32-bit Windows Server 2003 R2, but was unable to remove the phantom device on my domain controller, which uses 64-bit Windows Server 2003 R2. I later found that devcon is one of the Support Tools on the Windows installation media (suptools.msi). After installing these, I was able to use devcon on x64 platforms too.

ISA Server client software

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Fighting with ISA Server 2006, as I have been for the last few days, has given me an opportunity to refresh my knowledge of the various ISA Server clients. Actually, calling them clients is far more grandiose than is strictly necessary (only one of them involves the installation of client software), but the terminology that Microsoft uses is:

  • SecureNAT client. Any computer, with a working TCP/IP stack, pointing to the ISA Server for it’s default gateway (router) – or where the router (or series of routers) end with a router that uses the ISA server as its default gateway. This client operates at the network layer in the OSI model and therefore has no user-based access controls.
  • Web proxy client. A CERN-compliant web browser, with proxy server settings configured to point to the web proxy service on the ISA Server. This client operates at the application layer in the network stack and user-level authentication is optional.
  • Firewall client (formerly known as the WinSock proxy client). A computer running the ISA Server firewall client software to provide socket-based communications with the firewall service on the ISA Server. Operating at the transport layer, this client replaces the DLL for Windows socket (WinSock) connections so that communications between applications and their server components are routed via the the ISA Server (exceptions are configured in the local address table). It is possible to configure user-based access policy rules for firewall clients but the main advantage is that applications do not need to be firewall-aware; however there is a trade-off against the requirement to install the client software on each PC that requires access.

Further details of ISA client types are available in the Windows Server Tech Center.

Problems with Hyper-V, ISA Server 2006 and TCP offloading

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

For the last few days, I’ve been trying to get an ISA Server 2006 installation working and it’s been driving me nuts. I was pretty sure that I had my networking sorted, following Jim Harrison’s article on configuring ISA Server interface settings (although a colleague did need to point out to me that I didn’t have a static route defined on my ADSL router back to the ISA Server’s internal network – doh!) but even once this was checked there was still something up with the configuration.

My server has three NICs – a Broadcom NetXtreme Gigabit Ethernet card, connected to my Netgear ProSafe GS108 switch and two Intel PRO/100+ Management Adapters – one connected to a NetGear DS108 hub and the other disconnected at the moment but reserved for remote management of the server (the first two are both bound to Hyper-V) virtual switches.

The theory is that the Gigabit connection will be used for all my internal IT resources and the Fast Ethernet hub is just connected to the ADSL router. The server will run a few virtual machines (VMs) – the ISA Server (running with Windows Server 2003 R2 and connected to both virtual switches), another VM with Active Directory and DNS (also running Windows Server 2003 R2), my mail server and various test/development machines.

According to Microsoft:

“There are two rules to remember when setting up DNS on ISA Server. These rules apply to any Windows-based DNS configuration:

  • No matter how many network adapters you have, only assign DNS servers to a single adapter (it doesn’t matter which one). There is no need to set up DNS on all network adapters.
  • Always point DNS to either internal servers or external servers, never to both.”

[Configuring DNS Servers for ISA Server 2004]

Following this advice, my internal DNS Server is set to forward any requests that it can’t resolve to my ISP’s servers. The problem was that this DNS server couldn’t access the Internet through the ISA Server. ISA Server could ping hosts on all networks (so the network configuration was sound) and monitoring the traffic across the ISA Server showed the outbound DNS traffic on port 53 but nothing seemed to be coming back from the ISP’s DNS servers.

I checked another colleague’s working ISA Server 2006 configuration and found nothing major that was different (only an alternative DNS configuration – with the external NIC pointing to the internal DNS server where my external NIC has no DNS server specified – and the addition of the Local Host network in the source list for the Unrestricted Internet Access firewall access rule that is included in the Edge Firewall network template).

Then, after seeking advice from more colleagues and spending the entire day (and evening) on the problem, I finally cracked it…

Because the ISA Server was configured to use the internal DNS server for lookups (which, in turn, couldn’t get back through the ISA Server), nslookup domainname.tld didn’t work; however nslookup domainname.tld alternativednsserveripaddress did (e.g. nslookup www.google.com 4.2.2.2). HTTP(S) traffic seemed fine though – if I used IP addresses instead of domain names, I could access websites via the web proxy client.

Meanwhile, on the ISA Server, I could use nslookup for local name resolution but not for anything on the Internet. And pinging servers on the external side of the ISA server gave some very strange results – The first packet would receive a reply but not the subsequent ones.

After hours of Googling, I came across some good advice in a TechNet forum thread – download and run the ISA Server Best Practices Analyzer (BPA) tool. The ISA BPA presented me with a number of minor warnings (for example, that running ISA Server in a virtual environment can’t protect the underlying operating system) but two seemed particularly significant:

“Receive-side scaling (RSS) is enabled by the Windows Server operating system. If a network adapter installed on the local ISA Server computer supports RSS, ISA Server may function incorrectly. […]”

and:

“TCP-Acceleration (TCPA) is enabled by the Windows Server operating system. If a network adapter installed on the local ISA Server computer supports TCPA, ISA Server may function incorrectly. […]”

I made the registry edits to disable RSS and TCPA (Further details are available in Microsoft knowledge base articles 927695 and 936594), restarted the computer and crossed my fingers.

Even after this change, I still couldn’t successfully ping resources on the external side of the ISA Server from the private network, but I was sure I was onto something. I stopped looking for problems with ISA Server and DNS, and instead I focused my efforts on TCP Offload issues with Hyper-V. That’s when I found Stefaan Pouseele’s post about ISA Server and Windows Server 2003 service pack 2. Stefaan recommends not only disabling RSS and TCPA but also turning off TCP offload and the TCP chimney.

A big more googling and I found a TechNet Forum thread about ISA Server 2006 in a virtual environment where (Virtual PC Guy) Ben Armstrong and VistaGuyRay (Raymond Comvalius) had discussed disabling TCP offloading in the VM. As it happens, only yesterday, Ray blogged about how disabling TCP offloading in the virtual machine (not on the host) had resolved his problems with a Broadcom gigabit Ethernet adapter and Hyper-V (further details are available in Microsoft knowledge base article 888750). So, after making this change (but not doing anything with the TCP chimney) and a final reboot of my ISA server, I noticed that Windows wanted to apply some updates. That meant that name resolution was working, which in turn meant that the internal DNS server was successfully forwarding requests to the ISP servers via the ISA Server and my ADSL router. Result.

The final set of registry changes that I made were as follows:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableTCPA"=dword:00000000
"EnableRSS"=dword:00000000
"DisableTaskOffload"=dword:00000001

I’ve only made the registry changes on the ISA Server at the moment and the VM running AD/DNS seems to be fine, so this might not be an issue for all virtual machines connected to the Hyper-V virtual switch bound to the Broadcom NetXtreme NIC. What does seem reasonably certain though is that Hyper-V, ISA Server 2006 and TCP offloading don’t play nicely together in this scenario.

Forefront Security overview

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few weeks back, I spent some time learning about the Microsoft Forefront security products.  I’ve written before about Forefront Client Security and intend to write some more posts that go into some detail on the other Forefront products, but I thought I’d start by taking a look at the suite as a whole.

The Forefront suite of applications currently includes a number of products:

Looking first at the client, Forefront Client Security provides virus and spyware protection in a single product for client and server operating systems with updates received using Microsoft Update.  That all sounds OK but, for some critics, the natural question to ask is "what does Microsoft know about client security?".  Well, it seems that they know quite a lot:

  1. First, Microsoft purchased GeCAD Software – a respected Romanian anti-virus vendor.
  2. Next, Microsoft purchased GIANT Software – a respected anti-malware provider.
  3. The Microsoft Malicious Software Removal Tool provides more than just the ability to remove malware from PCs as he reporting information helps indicate how widespread a particular issue is.
  4. Microsoft also purchased FrontBridge Technologies, whose scanning technology protects many organisations from viruses and spam.
  5. Another Windows Live service that provides Microsoft with reconnaissance information is the Windows Live OneCare Safety Scanner (indeed the entire OneCare product range – although these consumer products have little in common with Forefront Client Security).
  6. Oh yes, and the fact that they run one of the world’s largest free e-mail services won’t hurt their ability to gather diagnostic information.

So that’s the client – what about the server products?  Based on the former Antigen products gained with Microsoft’s acquisition of Sybari Software there are currently two products carrying the Forefront brand name – plus Microsoft Antigen for Instant Messaging (to be replaced with an OCS-compatible product under the Forefront banner).  Making use of multiple anti-virus engines, the Forefront Server Security products provide realtime and manual scanning for messaging and collaboration products.

Finally, at the edge, ISA Server has been with us since 2000 (we had Proxy Server before then) and has become a well-respected application-level firewall and proxy server that is available in both software-only and appliance formats.  Intelligent Application Gateway (IAG) is a newer product, built around ISA Server by another company that Microsoft recently acquired – Whale Communications.  IAG provides SSL VPN capabilities, combined with a detailed understanding of how applications work (positive logic) in order to ensure that only valid traffic is allowed to cross the network boundary.  Whilst IAG is currently only available in appliance format, with Microsoft being a software company I can’t help feeling that a version of IAG will be released in software form at some point in the future.

Unfortunately, this mix of products from different backgrounds means that Forefront doesn’t feel as tightly integrated as some other product suites (e.g. Microsoft Office) but that is changing as the components are updated.  In addition, Microsoft has announced a product (codenamed Stirling) which they are touting as:

"[…] a single product that delivers unified security management and reporting with comprehensive, coordinated protection across clients, server applications, and the network edge. Through its deep integration with the existing infrastructure, such as Microsoft Active Directory and Microsoft System Center, customers can reduce complexity, making it easier to achieve a more secure and well-managed infrastructure."

For anyone looking at purchasing Forefront products, Software Assurance (SA) might not be a bad choice as there are new versions of IAG planned based on the forthcoming ISA Server codename Nitrogen and ISA Server codename Oxygen products (don’t quote me on this as information is a little sketchy on these!) and further updates planned across the Forefront suite.

IT security is no longer an afterthought and has become an integral part of any organisation’s IT infrastructure. I’m impressed by the range of options that Microsoft can provide in the Forefront suite and, if they can convince critics that they have a credible range of products (they are currently suffering from "the Škoda badge problem"), then over time I expect to see Microsoft take a dominant position in Windows Server security.

ISA Server 2004 “gotchas”

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

After having to abort last week’s attempt to replace an aging Microsoft Proxy Server 2.0 installation with Microsoft Internet Security and Acceleration (ISA) Server 2004, last night I had another go and I’m pleased to say that the ISA Server is now up and running. There are still some minor issues that I need to resolve, but here’s a summary of the key points that affected me:

  • It’s important to configure the underlying network correctly – i.e. check the binding order of the various network interfaces, disable unwanted services on the external interface, only configure one interface with a default gateway (the external interface), only configure one interface for DNS and check that there is a valid route configured back to each internal network. Jim Harrison has written an excellent article on configuring ISA Server interface settings.
  • By default, ISA Server 2004 will not let any traffic pass (on any interface) – i.e. it is secure by default.
  • Do not configure the ISA Server to use both internal and external DNS servers. The ideal solution is to configure DNS forwarding from the internal DNS server(s) to the ISP’s DNS servers and create an access rule to allow outbound DNS traffic. If DNS is configured incorrectly, then the server may have difficulties contacting Active Directory which will have a consequential effect on authentication.
  • Configure individual access rules to allow all required outbound network services and consider the order of the rules (i.e. is one rule denying access before another is processed). Multiple rules can be configured for different user sets and schedules.
  • In general, access rules are used to allow outbound access whilst internal resources are “published”.
  • When publishing HTTP(S) servers, make sure that there is an appropriate web listener configured.
  • When publishing SMTP (or other) servers, there is no web listener, but there must be an appropriate network listener configured. Generally, internal SMTP servers will be configured only to allow mail to be received from certain hosts, so it may be necessary to make the traffic appear as if it originated from the ISA Server. Thomas Shinder has written an excellent article on troubleshooting SMTP server publishing rules.
  • If restricting access to certain users, ensure that integrated authentication is enabled and authentication is required.

Configuring network connections for ISA Server 2000/2004 (aka when proxy server migrations turn bad)

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

It was supposed to be so easy. The new server was already built, with the same IP addresses as the old one. All I had to do was disconnect the NT 4.0 Proxy Server from the network and power on the new Windows Server 2003 R2 box with Internet Security and Acceleration (ISA) Server 2004 on it, then configure and test a few filter rules; but I had forgotten the first law of IT consultancy – nothing is ever straightforward – which is why I’m writing this post on the train to work after rolling back the migration and getting just 4 and a half hours sleep last night…

Firstly, I decided that the ISA Server should be joined to the Active Directory. My original plan had been that leaving it in a workgroup would be secure, but as I didn’t want to allow unrestricted anonymous (i.e. unmonitored) Internet access I’d be limited with my authentication options (either set up a RADIUS server to handle authentication or mirror the user accounts on the ISA Server). I wasn’t confident that ISA Server would work well if it was joined a domain after installation so I uninstalled ISA Server, joined the computer to the domain, and reinstalled ISA Server, plus service pack 2 and other updates.

It only took a few seconds to configure the cache and set up a firewall policy rule to allow all ports outbound access (just as a test, I could lock it down again later), add all the internal networks and enable the web proxy client, following which Internet access from the local network was restored. The trouble was that none of the machines on remote sites could access the Internet.

Suspecting a DNS issue, I began to investigate name resolution problems and (here was my mistake) questioning why no forwarders were configured on the internal DNS server (because DNS monitoring showed that the simple queries were fine, but recursive lookups were failing). If I’d been thinking clearly, I would have realised that the internal network doesn’t need to have a recursive DNS path to the ISP’s DNS servers (the proxy server should handle that on behalf of the clients) – although I do think that having a clear path from clients to the internal DNS and onwards to the ISP’s DNS is the most straightforward configuration, supporting both internal (Active Directory) and external (Internet) name resolution (and Microsoft’s advice is to configure only internal or external DNS on the ISA Server – not both).

The problem was the network configuration on the ISA server. Jim Harrison’s excellent article on configuring ISA Server interface settings is my bible when configuring the network cards on an ISA server, but I hadn’t set up the routes from the external network to my internal networks correctly. The local LAN was fine, but ISA Server was rejecting requests from remote internal networks because it didn’t understand the underlying network path (flagging a configuration error alert warning that the address range of an ISA Server network should match the address ranges routable through the associated network adapter as defined in the routing table). When I monitored the traffic flow, I could see incoming requests that were denied with no rule was given as the reason – another clue that there was a problem with the network rules.

Although the configuring ISA Server interface settings article points out that a route will be required to each internal network, I’d set the next hop as the internal interface of the ISA server, rather that the local router (the internal NIC doesn’t have a default gateway if configured correctly). Adding persistent routes for each of the internal networks (route -p add remoteinternalnetwork mask subnetmask routeripaddress) fixed the issue, after which nslookup (and web access) began to work from all sites.

Unfortunately, by the time I’d worked this out, it was too late to set up and test the various filter rules that are needed to ensure correct (authenticated) HTTP(S) and FTP browsing, SMTP e-mail, access to OWA, etc., so I decided to back out and reconnect the legacy proxy server. At least now I know that the connectivity problems are resolved, I can attempt the migration again another evening.

Configuring and troubleshooting services and applications with Proxy Server 2.0

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve spent a lot of time over the last few days struggling to configure a Microsoft Proxy Server 2.0 running on Windows NT 4.0 and Internet Information Server (IIS) 3.0 to reverse proxy (i.e. publish) an HTTPS website. Eventually I had to admit defeat (I’m trying to convince my client to upgrade to ISA Server 2004); however I did find a useful resource for Proxy Server 2.0 information that should be worth a look next time I’m trying to administer/troubleshoot a Microsoft Proxy Server configuration.

IT Forum ’05 highlights: part 1

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Microsoft UK IT Forum Highlights
A few years back, I used to try and persuade my employer to send me to Microsoft TechEd Europe each year, on the basis that lots of 75 minute presentations on a variety of topics provided a better background for me than a few days of in depth product training (I can build experience later as I actually use the technology). The last time I attended TechEd was back in 2001, by which time it had become more developer-focused and the IT Forum was being positioned as the infrastructure conference (replacing the Microsoft Exchange Conference). For the last couple of years, I haven’t been able to attend the IT Forum due to family commitments (first it clashed with my the birth of my son and then subsequently its been in conflict with his birthday, as it is again this year) but luckily, Microsoft UK has been re-presenting the highlights from IT Forum as free-of-charge TechNet events (spread over two days) and I’ve managed to take some time out to attend them.

Yesterday’s event covered a variety of topics. Unfortunately there was no concept of different tracks from which I could attend the most relevant/interesting sessions, so some it went completely over my head. One of those topics was upgrading to SQL Server 2005, so apologies to the presenter – I was the guy nodding off on the front row.

In the next few paragraphs, I’ll highlight some of the key points from the day.

Upgrading to SQL Server 2005
Presented by Tony Rogerson, SQL Server MVP and UK SQL Server Community leader, this session gave useful information for those looking at upgrading from SQL Server 2000 (or earlier) to SQL Server 2005. I’ve blogged previously with a SQL Server 2005 overview, why SQL Server 2005 is such a significant new product and on the new management tools but the key points from Tony’s presentation were:

  • Upgrades (in-place upgrades) are supported, preserving user data and maintaining instance names in a largely automated fashion, as are side-by-side migrations (mostly manual, copying data from an old installation to a new and then decommissioning the old servers).
  • SQL Server versions prior to 7.0 cannot be migrated directly and SQL Server 7.0/2000 need to be updated to the latest service pack levels before they can be migrated. For SQL Server 2000 that is SP4, which might break some functionality for SP3A users, so the upgrade needs to be carefully planned.
  • The database engine (including subcomponents like the SQL Agent, tools, etc.), analysis services, reporting services and notification services can all be upgraded, and data transformation services can be migrated to integration services.
  • All product editions can be upgraded/migrated (32/64-bit, desktop, workgroup, personal, standard, developer or enterprise editions), as can all SQL Server 7.0/2000 released languages.
  • A smooth upgrade requires a good plan, breaking tasks into:
    • Pre-upgrade tasks.
    • Upgrade execution tasks.
    • Post-upgrade tasks (day 0, day 30, day 90).
    • Backout plan.
  • Microsoft provides the SQL Server 2005 Upgrade Advisor as a free download to analyse instances of SQL Server 7.0 and SQL Server 2000 in preparation for upgrading to SQL Server 2005. This can be used repeatedly until all likely issues have been resolved and the upgrade can go ahead.
  • Migration provides for more granular control over the process that an upgrade would and the presence of old and new installations side-by-side can aid with testing and verification; however it does require new hardware (although a major investment in a SQL Server upgrade would probably benefit from new hardware anyway) and applications will need to be directed to the new instance. Because the legacy installation remains online, there is complete flexibility to fail back should things not go to plan.
  • Upgrades will be easier and faster for small systems and require no new hardware or application reconfiguration; however the database instances will remain offline during the upgrade and it’s not best practice to upgrade all components (e.g. analysis services cubes).
  • Upgrade tips and best practices include:
    • Reduce downtime by pre-installing setup pre-requisites (Microsoft .NET Framework 2.0, SQL Native Client and setup support files) – some of these are needed for the Upgrade Advisor anyway.
    • If planning a migration using the copy database wizard, place the database in single-user mode (to stop users from modifying the data during the upgrade) and make sure that no applications or services are trying to access the database. Also, do not use read-only mode (this will result in an error) and note that the database cannot be renamed during the operation.
    • Be aware of the reduced surface attack area of SQL Server 2005 – some services and features are disabled for new installations (secure by default) – the surface area configuration tools can be used to enable or disable features and services.

Leveraging your Active Directory for perimeter defence
Presented by Richard Warren, an Internet and security training specialist, I was slightly disappointed with this session, which failed to live up to the promises that its title suggested. After spending way too much time labouring Microsoft’s usual points about a) how packet filtering alone is not enough and ISA Server adds application layer filtering and b) ISA Server 2004 is much better and much easier to use than ISA Server 2000, Richard finally got down to some detail about how to use existing investments in AD and ISA Server to improve security (but I would have liked to have seen more real-world examples of exactly how to implement best practice). Having been quite harsh about the content, I should add that there were some interesting points in his presentation:

  • According to CERT, 95% of [computer security] breaches [were] avoidable with an alternative configuration.
  • According to Gartner Group, approximately 70% of all web attacks occur at the application layer.
  • Very few organisations are likely to deploy ISA Server as a first line of defence. Even though ISA Server 2004 is an extremely secure firewall, it is more common to position a normal layer 3 (packer filtering) firewall at the network edge and then use ISA Server behind this to provide application layer filtering on the remaining traffic.
  • Users who are frightened of IT don’t cause many problems. Users who think they understand computers cause most of the problems. Users who do know what they are doing are few and far between. (Users are a necessary evil for administrators).
  • Not all attacks are malicious and internal users must not be assumed to be “safe”.
  • ISA Server can be configured to write it’s logs to SQL Server for analysis.
  • Active Directory was designed for distributed security (domain logon/authentication and granting access to resources/authorisation) but it can also store and protect identities and plays a key role in Windows managability (facilitating the management of network resources, the delegation of network security and enabling centralised policy control).
  • Using ISA Server to control access to sites (both internal and external), allows monitoring and logging of access by username. If you give users a choice of authenticated access or none at all, they’ll choose authenticated access. If transparent authentication is used with Active Directory credentials, users will never know that they needed a username and password to access a site (this requires the ISA Server to be a member of the domain or a trusted domain, such as a domain which only exists within the DMZ).
  • ISA Server’s firewall engine performs packet filtering and operates in kernel mode. The firewall service performs application layer filtering (extensible via published APIs) and operates in user mode.
  • SSL tunnelling provides a secure tunnel from a client to a server. SSL bridging involves installing the web server’s certificate on the ISA Server, terminating the client connection there and letting ISA server inspect the traffic and handle the ongoing request (e.g. with another SSL connection, or possibly using IPSec). Protocol bridging is similar, but involves ISA server accepting a connection using one protocol (e.g. HTTP) before connecting to the target server with another protocol (e.g. FTP).

Microsoft Windows Server 2003 Release 2 (R2) technical overview
Presented by Quality Training (Scotland)‘s Andy Malone, this session was another disappointment. Admittedly, a few months back, I was lucky to be present at an all day R2 event, again hosted by Microsoft, but presented by John Craddock and Sally Storey of Kimberry Associates, who went into this in far more detail. Whilst Andy only had around an hour (and was at pains to point out that there was lots more to tell than he had time for), the presentation looked like Microsoft’s standard R2 marketing deck, with some simple demonstrations, poorly executed, and it seemed to me that (like many of the Microsoft Certified Trainers that I’ve met) the presenter had only a passing knowledge of the subject – enough to present, but lacking real world experience.

Key points were:

  • Windows Server 2003 R2 is a release update – approximately half way between Windows Server 2003 and the next Windows Server product (codenamed Longhorn).
  • In common with other recent Windows Server System releases, R2 is optimised for 64-bit platforms.
  • R2 is available in standard, enterprise and datacenter editions (no web edition) consisting of two CDs – the first containing Windows Server 2003 slipstreamed with SP1 and the second holding the additional R2 components. These components are focused around improvements in branch office scenarios, identity management and storage.
  • The new DFSR functionality can provide up to 50% WAN traffic reduction through improved DFS replication (using bandwidth throttling remote differential compression, whereby only file changes are replicated), allowing centralised data copies to be maintained (avoiding the need for local backups, although one has to wonder how restoration might work over low-speed, high latency WAN links). Management is improved with a new MMC 3.0 DFS Management console.
  • There is a 5MB limit on the size of the DFS namespace file, which equates to approximately 5000 folders for a domain namespace and 50,000 folders for a standalone namespace. Further details can be found in Microsoft’s DFS FAQ.
  • Print management is also improved with a new MMC 3.0 Print Management console, which will auto-discover printers on a subnet and also allows deployment of printer connections using group policy (this requires use a utility called pushprinterconnections.exe within a login script, as well as a schema update).
  • Identity and access management is improved with Active Directory federation services (ADFS), Active Directory application mode (ADAM – previously a separate download), WS-Management and Linux/Unix identity management (incorporating Services for Unix, which was previously a separate download).
  • For many organisations, storage management is a major problem with typical storage requirements estimated to be increasing by between 60% and 100% each year. The cost of managing this storage can be 10 times the cost of the disk hardware and Microsoft has improved the storage management functionality within Windows to try and ease the burden.
  • The file server resource manager (FSRM) is a new component to integrate capacity management, policy management and quota management, with quotas now set at folder level (rather than volume) and file screening to avoid storage of certain file types on the server (although the error message if a user tries to do this just warns of a permissions issue and is more likely to confuse users and increase the burden on administrators trying to resolve any resulting issues).
  • Storage manager for SANs allows Windows administrators to manage disk resources on a SAN (although not with the granularity that the SAN administrator would expect to have – I’ve not seen this demonstrated but believe it’s only down to a logical disk level).
  • In conclusion, Windows Server 2003 R2 builds on Windows Server 2003 with new functionality, but with no major changes so as to ensure a non-disruptive upgrade with complete application compatibility, and requiring no new client access licenses (CALs).

Management pack melee: understanding MOM 2005 management packs
Finally, a fired up, knowledgeable presenter! Gordon McKenna, MOM MVP is clearly passionate about his subject and blasted through a whole load of detail on how Microsoft Operations Manager (MOM) uses management packs to monitor pretty much anything in a Windows environment (and even on other platforms, using third-party management packs). There was way too much information in his presentation to represent here, but Microsoft’s MOM 2005 for beginners website has loads of information including technical walkthoughs. Gordon did provide some additional information though which is unlikely to appear on a Microsoft website (as well as some that does):

  • MOM v3 is due for release towards the end of this year (I’ve blogged previously about some of the new functionality we might see in the next version of MOM). It will include a lightweight agent, making MOM more suitable for monitoring client computers as well as a Microsoft Office management pack. MOM v3 will also move from a server-centric paradigm to a service-centric health model in support of the dynamic systems initiative and will involve a complete re-write (if you’re going to buy MOM this year, make sure you also purchase software assurance).
  • There are a number of third-party management packs available for managing heterogeneous environments. The MOM management pack catalogue includes details.
  • The operations console notifier is a MOM 2005 resource kit utility which provides pop-up notification of new alerts (in a similar manner to Outlook 2003’s new mail notification).

A technical overview of Microsoft Virtual Server 2005
In the last session of the day, Microsoft UK’s James O’Neill presented a technical overview of Microsoft Virtual Server 2005. James is another knowledgeable presenter, but the presentation was a updated version of a session that John Howard ran a few months back. That didn’t stop it from being worthwhile – I’m glad I stayed to watch it as it included some useful new information:

  • Windows Server 2003 R2 Enterprise Edition changes the licensing model for virtual servers in two ways: firstly, by including 4 guest licenses with every server host licence (total 5 copies of R2); secondly by only requiring organisations to be licensed for the number of running virtual machines (currently even stored virtual machine images which are not in regular use each require a Windows licence); finally, in a move which is more of a clarification, server products which are normally licensed per-processor (e.g. SQL Server, BizTalk Server, ISA Server) are only required to be licensed per virtual processor (as Virtual Server does not yet support SMP within the virtual environment).
  • The Datacenter edition of the next Windows Server version (codenamed Longhorn) will allow unlimited virtual guests to be run as part of its licence – effectively mainframe Windows.
  • Microsoft is licensing (or plans to licence) the virtual hard disk format, potentially allowing third parties to develop tools that allow .VHD files to be mounted as drives within Windows. There is a utility to do this currently, but it’s a Microsoft-internal tool (I’m hoping that it will be released soon in a resource kit).
  • As I reported previously, Microsoft is still planning a service pack for Virtual Server 2005 R2 which will go into beta this quarter and to ship in the Autumn of 2006, offering support for Intel virtualization technology (formerly codenamed Vanderpool) and equivalent technology from AMD (codenamed Pacifica) as well as performance improvements for non-Windows guest operating systems.

Overall, I was a little disappointed with yesterday’s event, although part 2 (scheduled for next week) looks to be more relevant to me with sessions on Exchange 12, the Windows Server 2003 security configuration wizard, Monad, Exchange Server 2003 mobility and a Windows Vista overview. Microsoft’s TechNet UK events are normally pretty good – maybe they are just a bit stretched for presenters right now. Let’s just hope that part 2 is better than part 1.

Wireless security and secure remote access

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last night, I attended Steve Lamb‘s Microsoft TechNet UK briefing on wireless security and secure remote access. I won’t repeat the entire content here, because Steve has an article in the November/December issue of Microsoft TechNet magazine, entitled improve your web security with encryption and firewall technologies, which, when combined with Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article, just about covers the content of the event. Having said that, there were a few more snippets that came out during the presentation, which I’ve plagiarised (and extended) in the rest of this post…

Wireless Security

Anyone who needs to secure a Wireless network at home should check out Steve Lamb’s blogcast on securing a wireless router and Windows XP and, although I’ve already linked it above, I’ll repeat that Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article is also worth a read. Further information is also available on the Microsoft website.

Some additional notes that I took during Steve’s presentation were that:

  • Wireless network keys can be stored on a USB token.
  • Wired equivalent privacy (WEP) is often considered insecure but consider the name – the equivalency part indicates that it offers the same level of security as a wired network. Yes, it can be broken into, but so can a wired network with public access to the building). Wi-Fi Protected Access (WPA) (or preferably WPA2) is better and dynamic WEP is a half-way house, but whatever security is employed, the wireless network still needs to be easy to use.
  • There are sites on the ‘net that will show you how to break a wireless (or other) connection (if you think it’s irresponsible of me to link that site, you could also find it using a search engine, so I figure that it’s better that the methods are well known, than only being known by the bad guys).
  • Contrary to popular belief, there is no point in securing the SSID for a network as it is transmitted unencrypted (even on a network secured with WPA or WPA2). Ditto for media access control (MAC) addresses, which are easily spoofed.
  • Even WPA doesn’t do anything to prevent a denial of service (DoS) attack and WPA2 (802.11i) doesn’t stop all DoS attacks.
  • 802.1x is port-based authentication and applies equally to both wired and wireless networks. It does have weaknesses, including that it will only authenticate the initial connection. In a wireless configuration, man-in-the-middle (MitM) attacks can be guarded against by requiring the WAP to identify itself using certificates (using a group policy object).
  • WEP requires Windows XP. WPA requires Windows XP SP1, WPA2 requires Windows XP SP2 and a hotfix (see Microsoft knowledge base article 893357).
  • The Windows 2000 Internet authentication service (IAS) can be used as the RADIUS server component in a secure wireless deployment; however Windows Server 2003 supports auto-enrolment (which when used for computer and user certificates will make life much easier).
  • Windows XP will (by default) allow access to its nearest access point, even if it is not secure.

Very importantly – if (like I did), you think that your wireless network (e.g. at home) doesn’t need to be secured because there’s no data of value to be had and anyway, you have bandwidth to spare which you don’t mind your neighbours using, consider the implications of someone using your wireless network to access the Internet and perform illegal activities, which your ISP can trace back to you via your IP address. Having thought about that, I’ll be buying a new wireless access point very soon.

Secure Remote Access

Microsoft are positioning virtual private networking (VPN) technology as no longer the best solution for providing corporate remote access and I tend to agree. The idea of giving an untrusted computer an IP address from the internal network fills me with fear (unless some quarantining is in place). VPNs “blur” the network edge and anyway, do remote users need full network access? I’ve often accidentally printed a document in the office whilst working at home and then had to ask a colleague to retrieve and dispose of it for me (wasting paper, printer resources and somebody else’s time). Some solutions will use VLAN technology to limit the network access for VPN users – there are other methods too, especially when considering that 90% of VPN users only really want to read their e-mail. For example, Outlook Web Access, whilst having improved it’s interface capabilities dramatically with each new release, is still not really a great solution for access from outside the corporate firewall (it’s good for allowing users to access mail without setting up a MAPI profile, but is heavily reliant on ActiveX controls, which may not be allowed in an Internet cafe, and is also a risk if the remote client has a keylogger installed) – full client Outlook using HTTPS over RPC on a notebook/tablet PC is a far better option – totally transparent from an end user perspective (although still a problem if access is required if an e-mail links back to internal resources to retrieve a document).

Steve Lamb’s TechNet magazine article (and my previous post on securing the network using Microsoft ISA Server 2004) elaborate on the need for application layer firewalling rather than blindly allowing HTTP and HTTPS traffic through the firewalls. Other measures employed include pre-authentication and URL scanning.

SSL VPNs are another method of providing remote access (even though they are not really VPNs, but are actually just remote desktops in a browser). Windows Terminal Services can provide basic SSL VPN functionality, which can also be extended with products from Citrix.

Operating over the remote desktop protocol (RDP), which is based on the International Telecommunications Union (ITU) T.120 protocol family and is therefore independent of network and transport protocols, these solutions use compression and caching to reduce bandwidth requirements and support network load balancing. Windows Server 2003 brings a number of terminal services enhancements (over Windows 2000) including:

  • Connection to the console session (in remote administration mode).
  • Control of RDP options via group policy.
  • WMI provider for scripted terminal services configuration.
  • ADSI provider for access to per-user terminal services profiles.
  • Improvements to the terminal server manager MMC snap-in (reduced automatic server enumeration).
  • Ability to limit users to a single session.
  • Improved security:
    • Remote Desktop Users security group (which can be used in place of the Everyone group to fine tune access control.
    • 128-bit RC4 encryption.

Securing terminal services comes back to the well-known principle of defence in depth:

  • A physically secure terminal services server.
  • A secure operating system configuration.
  • A secure terminal services configuration.
  • Network path security.
  • Using the registry to fine-tune control over terminal server sessions (probably overkill, but using group policy to control access is a similar principle).

Using the remote desktop web connection ActiveX control, terminal services can be provided across the web (and optionally secured using HTTPS). The initial client contact is to http(s)://servername/tsweb/ and the ActiveX control is downloaded over HTTP (TCP port 80) or HTTPS (TCP port 443). Once the browser has the ActiveX control installed, the user can connect to the terminal server over TCP port 3389.

If full VPN access is still required (and hopefully the methods above will avoid the requirement for this), then VPN server placement must be carefully considered. Running an encrypted PPTP or L2TP+IPSec VPN connection through a standard packet filtering firewall effectively bypasses the firewall as the VPN port will be open on internal and external firewalls and the traffic inside the connection will not be inspected.

Most network administrators will be alarmed if you propose the installation of ISA Server as the corporate firewall even though ISA Server 2004 has now achieved common criteria evaluation assurance level 4+. ISA Server 2004 is a perfectly good firewall (assuming that the underlying Windows platform is also well-managed), but it will probably be easier to justify to network administrators by using ISA as an additional server in the DMZ, or as the inner firewall (between the DMZ and the internal network). This way, the encrypted connection can be terminated at the ISA server and the firewall can inspect the inbound traffic.

Finally, if a VPN connection must be used to extend the corporate network to remote clients, then network quarantine controls should also be put in place. Full network access protection (NAP) is expected with the next version of Windows Server (codenamed Longhorn) but even now, Windows Server 2003 SP1 routing and remote access service (RRAS) allows for the provision of network access quarantine control for remote clients. The current Microsoft implementation involves using the connection manager administration kit (CMAK) to construct a custom RRAS client which includes a number of post-connection actions. Until these are passed, then vendor-specific options remain in place which prevent the remote VPN client from accessing the network. Unfortunately it is also possible for a technically able user to spoof the message which allows the vendor-specific attributes to be removed, but in reality this is a small risk. Microsoft’s NAP and Cisco’s network access control (NAC) will make this far more effective, extending the scope of control to include wired and wireless clients (as well as VPN clients).