ISA Firewall Site to Site VPN Quick Fix

If you’ve been trying to create a site to site VPN using 2004 ISA firewall using a pre-shared key only, I feel your pain. You’ve probably seen that it doesn’t work. The key is to not configure the pre-shared key in the Remote Site Wizard. Instead, leave the pre-shared key checkbox unchecked. Then click the VPN Clients tab in the Details pane, and click the Select Authentication Methods link on the Tasks tab in the Task Pane. On the Authentication tab in the Virtual Private Networks (VPN) dialog box, put a checkmark in the Allow customer IPSec policy for L2TP checkbox and enter the pre-shared key. Use the same procedures and the same key on all your VPN gateways. Keep in mind that remote access VPN clients and VPN gateways will be able to use this key — so if you can do anything about it, always try to use certificates instead of pre-shared keys. Remember, using pre-shared keys reduces the level of security provided by the ISA firewall to that of a lowly PIX packet filter!


HTH,
Tom

ISA Firewall Site to Site VPNs with Downlevel VPN Gateways

One of the things that drove us nuts with the 2000 ISA firewall was that problem of site to site VPNs. You could use PPTP or L2TP/IPSec to create a site to site VPN, but the problem was that most downlevel VPN gateways (PIX, Sonicwall, etc) use the less secure IPSec tunnel mode. The new ISA firewall fixes this problem with its support for IPSec tunnel mode. The problem is that each vendor has it own proprietary approach to creating a site to site VPN. Don’t worry! Microsoft has come to our recue with a bevy of very cool docs that show you how to create the site to site VPNs with a variety of downlevel VPN gateways — PIX, Astaro, SmoothWall and more! Check it out at:


http://www.microsoft.com/isaserver/techinfo/guidance/2004/vpn.asp


HTH,


Tom

The Evils of SSL Tunneling

As a firewall administrator your primary concern is access control. You want to control exactly what services internal network users can access on other networks, and you want exact control over what services external users can access on the internal network. That’s the reason you have a firewall. If you don’t want someone to access a specific service on the Internet, then you either do not allow it (the preferred method) or you explicitly block it (the less preferred method). This isn’t a radical approach and is something inherent in all good firewall policies.


Get the New Book!


For example, you have created a firewall policy allowing a specific group of users outbound access to only HTTP and HTTPS. You do this because you want this group of users to have access to Web sites on the Internet, so that they can see Web content and connect to secure Web sites to get business done. You do not allow them access to other protocols such as IRC, FTP, SSH, VPN, Telnet or any others, because your organization has determined that these protocols can put your network at risk when used by these users you have given access to only HTTP and HTTPS.


So what happens when a user uses the HTTP protocol to “tunnel” other application protocols? The popular GoToMyPC is a remote access application that the vendor claims “does not compromise the integrity of your firewall” (https://www.gotomypc.com/ourTechnology.tmpl). Oh really?


As a firewall administrator, I open outbound HTTPS to selected users so that they can go to secure Web sites. I do not open outbound access to HTTPS (SSL) so that they can use remote access technologies that enable them to connect to their home computer and then transfer virus infected files from their home computer (which isn’t under our administrative control). And because the GoToMyPC application runs in an SSL tunnel, virtually no firewall on the market today (including the ISA firewall) can inspect the contents of the SSL stream once SSL session is negotiated.


GoToMyPC is just one example of HTTP tunneling of non-Web applications. If you do a Google search of “HTTP tunnel” and you’ll come up with a slew of applications that allow users to subvert firewall policy by tunneling dangerous applications through an HTTP connection.


For example, near the top of the list on the Google search is HTTP-Tunnel. You can see a list of applications your users can use with this software at http://www.http-tunnel.com/html/support/user_guides.asp. As a firewall administrator, you enable users access to applications they have permission to access and they should not be able to use applications that they are not permitted to access. The HTTP tunneling software subverts firewall policy and security, and potentially violates corporate network access policies.



ISA Firewall Alert
If your corporate network access policy does not include explicit guidelines forbidding use of this type of software, then you need to get such as policy in line now. Otherwise, you’re going to be blank-faced when the CEO wants to know how a user was able to introduce a destructive worm into the corporate network by using one of these applications.


So what does all this have to do with Terminal Services? Microsoft has announced that it intends to provide an HTTP tunneled RDP client and server in the R2 release of Windows Server 2003. This purportedly is done to allow for Access Anywhere, so that users can create RDP sessions through “restrictive firewalls”. Maybe there’s a reason why those firewalls are restrictive! (you can find more information on this HTTPS tunneled RDP client over at http://www.brianmadden.com/content/content.asp?ID=61)


The next time you hear someone joke about TCP 80 and 443 being the “Universal Firewall Ports”, you’ll know what they mean. This also points out that the future of firewalls moves far beyond the conventional stateful filtering firewall (like most so-called “hardware firewalls” on the market today).


The future of network firewalls is the stateful application layer inspection firewall. The good news is that the ISA firewall is the poster boy of the stateful application layer inspection firewall. Only a stateful application layer inspection firewall is going to be able to completely take apart the HTTP/HTTPS communications and then validate them against firewall policy. One thing is for sure: its not going to be easy.



ISA Firewall Wish List
Because of the serious risks HTTPS tunneling can pose to the network, on the top of my wish list right now is that the ISA firewall development team implements a mechanism allowing us to perform SSL to SSL bridging for outgoing connections. We can do it now with Web Publishing Rules, but we can’t do it for outbound connections at this time. Those outbound HTTPS connections containing data hiding in the outbound SSL tunnel continue to pose a serious risk to your network’s overall security posture.

Using RADIUS Authentication with the ISA Firewall’s VPN Server (2004)

 
By Thomas W Shinder M.D.


Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=30;t=000170


Like the ISA Server 2000 firewall, the ISA firewall (ISA Server 2004) supports RADIUS authentication for VPN clients. RADIUS authentication is most useful when the ISA firewall is not a member of the Internal network domain.


Get the New Book!


Situations where you would not want to make the ISA firewall a member of the Internal network domain would include those where the ISA firewall is the Internet edge firewall and there are other back-end firewalls on the network. While it is completely acceptable to make the ISA firewall on the Internet edge a domain member in a single ISA firewall network, the preferred configuration in a multiple firewall setup is to make the back-end ISA firewall a domain member and let any front-end ISA firewalls remain standalone devices.


There are also circumstances where the corporate security officer, who does not understand firewalls in general, (and the ISA firewall in particular) requires that the ISA firewall, regardless of its location, not be a member of the domain. In this case, you can still authenticate VPN users against your internal network Active Directory domain database by using RADIUS authentication.


When the non-domain member ISA firewall uses RADIUS to authenticate VPN users, the ISA firewall forwards user credentials to a RADIUS server on the back-end. The Microsoft implementation of RADIUS is called the Internet Authentication Server (IAS). The RADIUS server forwards the user credentials to an authentication server. In an Active Directory environment, the authentication server is an Active Directory domain controller. The authentication server sends its response to the RADIUS Server and the RADIUS server sends the response to the ISA firewall. If the credentials are valid and the user has dial-in permissions, the VPN connection is allowed. If the credentials are not valid or if the user does not have dial-in permissions, then the connection is dropped.


The ISA firewall is a RADIUS client when it is configured to use RADIUS authentication. The ISA firewall must be configured to use one or more RADIUS servers and the RADIUS servers must be configured to communicate with the ISA firewall as a RADIUS client. So, both the ISA firewall and the RADIUS server must be configured to “know” each other in order for RADIUS authentication to work correctly.


In this article we will use the simple lab setup as seen in the figure below:



Notice the domain controller a RADIUS server. You could place the RADIUS server another machine in the same domain. You could also configure RADIUS proxies, but we’ll talk about those and how to use them in another article. The domain controller in this scenario is also a DHCP server, DNS server, WINS server and Certificate server. We will take advantage of each of this services except for the Certificate Server.


Will we discuss in detail the following procedures:



  • Configuring the RADIUS Server
  • Configuring the User Account for Dial-in Permission
  • Enabling and Configuring the ISA Firewall’s VPN Server
  • Configuring Firewall Policy to Control VPN Client Access
  • Making the VPN Remote Access Client Connection

Installing the RADIUS server is a basic procedure so we won’t discuss the step by step procedures for installing the Microsoft IAS Server.


Configure the RADIUS Server


You can start setting up the RADIUS Server right after installing it. There’s no need to restart the server. There are two things we need to do at this point: configure the RADIUS server to recognize the ISA firewall as a RADIUS client and then create a Remote Access Policy for the VPN clients.


Perform the following steps to configure the RADIUS server to use the ISA firewall as a RADIUS client:



  1. At the IAS Server machine, click Start and point to Administrative Tools. Click Internet Authentication Service.
  2. In the Internet Authentication Service console, right click the RADIUS Clients node in the left pane of the console and click New RADIUS Client.
  3. On the Name and Address page, enter a Friendly name for the ISA firewall. In this example the friendly name will be ISA Firewall. Enter the IP address on the internal interface of the ISA firewall in the Client address (IP or DNS) text box. Click Next.
  4. On the Additional Information page, confirm that the Client-Vendor option is set to RADIUS Standard. Enter a password in the Shared secret text box and confirm the password in the Confirm shared secret text box. Make the password complex, with more than 8 characters and a mix of upper and lower case letters, numbers and symbols. Put a checkmark in the Request must contain the Message Authenticator attribute checkbox. Click Finish.


The next step is to create a Remote Access Policy that is applied to the VPN clients. We will use a default VPN clients Remote Access Policy in this example.


Perform the following steps to create the VPN clients Remote Access Policy:



  1. In the Internet Authentication Service console, right click on the Remote Access Policies node in the left pane of the console and click New Remote Access Policy.
  2. Click Next on the Welcome to the New Remote Access Policy Wizard page.
  3. On the Policy Configuration Method page, select the Use the wizard to set up a typical policy for a common scenario option. Enter a name for the Remote Access Policy in the Policy name text box. In this example we will name the policy VPN Clients. Click Next.
  4. On the Access Method page, select the VPN option and click Next.
  5. On the User or Group Access page, select the Group option. Click the Add button.
  6. In the Select Groups dialog box, enter Domain Users in the Enter the object names to select text box. You can create your own custom domain Global Groups if you want to limit access to the ISA firewall’s VPN server. Click the Check Names button to confirm that you have entered the group name correctly. Click OK in the Select Groups dialog box.
  7. Click Next on the User or Group Access page.
  8. Leave the checkmark in the Microsoft Encrypted Authentication version 2 (MS-CHAPv2) checkbox. You might want to use EAP to provide stronger authentication, by selecting the Extensible Authentication Protocol (EAP) checkbox. We will not go over the details of using EAP authentication with the ISA firewall’s VPN server. There are detailed instructions on how to do this in the ISA 2004 VPN Deployment Kit. Click Next.
  9. On the Policy Encryption Level page, enable the checkboxes that are appropriate for your VPN clients. Since we use exclusively Windows XP and Windows 2000 clients (for security reasons), we will remove the checkmarks from the Basic encryption and Strong encryption checkboxes. Click Next.
  10. Click Finish on the Completing the New Remote Access Policy Wizard page.

Configure the User Account for Dial-in Permission


The next step is to enable the user account’s dial-in permission. If your Active Directory domain is in native mode or Windows Server 2003 mode, then you do not need to perform this step because the default dial-in permission setting for user accounts is to control dial-in access via Remote Access Policy.


In a mixed mode domain, each user account must be individually configured to allow dial-in permission. In this example we will configure the Administrator account so that it has dial-in permissions.


Perform the following steps to allow dial-in permissions fro the Administrator account:



  1. Open the Active Directory Users and Computers console.
  2. Expand the domain name in the left pane of the console and click the Users node.
  3. Double click the user name in the right pane of the console.
  4. Click on the Dial-in tab. Select the Allow access option.



  1. Click Apply and then click OK.

Enable and Configure the ISA Firewall’s VPN Server


Now we’re ready to enable and configure the ISA firewall’s VPN server component. The VPN server will be configured to allow remote access VPN client connections. A separate procedure is required to allow site to site VPN connections and we’ll examine the procedures required to accomplish that task in a future article on this site.


Perform the following steps at the ISA firewall to enable and configure the ISA firewall’s VPN Server:



  1. Open the Microsoft Internet Security and Acceleration Server 2004 management console and expand the computer name. Click the Virtual Private Networks (VPN) node.
  2. On the Virtual Private Networks (VPN) node, click the Tasks tab in the Task Pane. Click the Configure VPN Client Access link.
  3. In the VPN Clients Properties dialog box, put a checkmark in the Enable VPN client access checkbox. Enter a value in the Maximum number of VPN clients allowed text box. The Standard Edition of the ISA firewall can support up to 1000 concurrent VPN client connections.
  4. Click the Groups tab. This tab only applies to those organizations that run in Active Directory native mode or Windows Server 2003 mode. This is an interesting and confusing dialog box because it implies that if you don’t enter any groups here, then no groups will be allowed access! In addition, the ISA firewall needs to be a member of the Active Directory domain to have access to domain groups. Since we do not want to make the ISA firewall a member of the domain in this scenario, we do not need to add any groups on the Groups tab.
  5. Click on the Protocols tab. The default setting is to enable PPTP. If you want to support L2TP/IPSec VPN connections, put a checkmark in that checkbox. I always put a checkmark in that checkbox, even if I’m not ready to use L2TP/IPSec. However, if you have no plans to implement a PKI and distribute certificates, then do not put a checkmark in this checkbox. In this example we will enable only the PPTP option to keep things simple.
  6. Click the User Mapping tab. This is another one of those “what the heck does this thing do” tabs and its one that will get you into trouble if you don’t understand its functionality. The first and most important thing to know is: do not enable User Mapping if the ISA firewall is not a member of the domain. The ISA firewall must have access to the Active Directory database to map users who do not supply domain information (such as RADIUS clients) to the ISA firewall itself (the information is supplied to the RADIUS server, it is not given to the ISA firewall).



This actually sort of makes sense when you read the text on the User Mapping page. It says User mapping is used to map VPN clients from non-Windows namespaces (RADIUS or EAP authenticated users) to the Windows namespace. As a result, Access Rules applied to the Windows user sets are also applied to user from non-Windows namespaces. Since the ISA firewall in this scenario isn’t part of a Windows domain, there is no Windows domain namespace accessible to the firewall. The confusion primarily lies in the term Windows Authentication. What the heck is Windows Authentication? From what I can tell, it’s any type of authentication that isn’t RADIUS or EAP authentication ;-).


Even more problematic then trying to figure out what this dialog box means and does is the fact that if you enable user mapping on an ISA firewall that is not a domain member, and then configure the VPN server to use RADIUS authentication, no one can connect to the ISA firewall. You will see an error dialog box like the one below. If you do a Network Monitor trace, you’ll see that the VPN client sends a disconnect message to the ISA firewall.




However, as firewall administrators we need to get to the bottom line: do not use user mapping unless the ISA firewall is a member of an Active Directory domain. You will not be able to use the ISA firewall’s strong user/group based access control for VPN clients if the ISA firewall is not a member of the domain. Hopefully we’ll get some guidance on exactly how this feature works some time in the future and we’ll be able to use the ISA firewalls strong user/group based access controls.



    NOTE:
    I’ll be glad to recant the above statement and revise this article when Microsoft provides information on exactly what this feature does and how it works. Until then, DO NOT enable User Mapping if the ISA firewall is not a member of an Active Directory domain.


  1. Click Apply and then click OK.

Now we configure the RADIUS server the ISA firewall will use:



  1. Click on the Specify RADIUS Configuration on the Tasks tab of the Task Pane.
  2. On the RADIUS tab, put a checkmark in the User RADIUS for authentication checkbox. Put a checkmark in the User RADIUS for accounting (logging) checkbox.
  3. Click the RADIUS Servers button.
  4. In the RADIUS Servers dialog box, click the Add button.
  5. In the Add RADIUS Server dialog box, enter the IP address of the RADIUS server in the Server name text box. You could enter a name in the text box, but the ISA firewall would need to be able to resolve the name correctly. Since the IP address of a RADIUS server is unlikely to change over time, you’re fairly safe using an IP address.



  1. Click the Change button. Enter the same password you entered on the RADIUS server when you configured the RADIUS server to use the ISA firewall as a RADIUS client. Put a checkmark in the Always use message authenticator checkbox. Click OK.
  2. Click OK in the RADIUS Servers dialog box.
  3. Click Apply and then OK on the Virtual Private Networks (VPN) Properties dialog box.
  4. Click Apply to save the changes and update the firewall policy.
  5. Click OK in the Apply New Configuration dialog box.

Configure VPN Access Policy


You need to create an Access Rule allowing the VPN clients network access to the Internal network. Because we’re using RADIUS authentication on an ISA firewall that is not a member of the domain, we cannot apply strong user/group based access control over the VPN client connections. If you require this, then make the ISA firewall a member of the Active Directory domain. I strongly recommend that you do make the ISA firewall a member of the domain when appropriate, as discussed at the beginning of this article.


However, you can still control access to protocols and servers. The only limitation is that you will not be able to allow selective access to VPN clients based on user credentials.


For example, you might want to allow members of the OWA Users group access to the OWA Web site when connected to the VPN server. You won’t be able to do this because all users will be able to connect to the OWA server. The good news is that you can still allow access to a single protocol and server, which is still far better than most VPN servers on the market today.


In the following example we will create an Access Rule allowing VPN users access to the OWA site using SSL only. If the VPN users try to access the OWA server using any other protocol, the connection will be denied. If they try to access any other server on the network, the connection will be denied. Of course, if you want VPN users to access other protocols or servers, you create additional rules that will allow access. The only limitation when using RADIUS authentication is that you will not be able to control access on a user/group basis.


Perform the following steps to create the Access Rule:



  1. In the Microsoft Internet Security and Acceleration Server 2004 management console, click the Firewall Policy node and then click the Tasks tab in the Task Pane. Click the Create New Access Rule link.
  2. On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example we will name the rule VPN Clients to Internal. (the name of the rule doesn’t exactly match the purpose of this Access Rule, but I changed my mind about what this would do when writing this article). Click Next
  3. Select Allow on the Rule Action page.
  4. On the Protocols page, select the Selected protocols option in the This rule applies to list. Click Add.
  5. In the Add Protocols dialog box, click the Common Protocols folder and double click HTTPS. Click Close.
  6. Click Next on the Protocols page.
  7. On the Access Rule Sources page, click Add.
  8. In the Add Network Entities dialog box, click the Networks folder and double click VPN Clients. Click Close.
  9. Click Next on the Access Rule Sources page.
  10. On the Access Rule Destinations page, click Add.
  11. In the Add Network Entities dialog box, click the New menu. Click Computer.
  12. In the New Computer Rule Element dialog box, enter a name for the Computer in the Name text box. In this example we will name the computer OWA Site. Enter the IP address of the OWA site in the Computer IP Address text box. Click OK.
  13. In the Add Network Entities dialog box, click the Computers folder. Double click the OWA Site entry and click Close.
  14. Click Next.
  15. On the User Sets page, click Next.
  16. Click Finish on the Completing the New Access Rule Wizard page.
  17. Click Apply to save the changes and update the firewall policy.
  18. Click OK in the Apply New Configuration dialog box.

Make the VPN Remote Access Client Connection


Create the VPN connectoid on the VPN client computer and log on to the ISA firewall’s VPN server. After creating the connection you’ll find that you can access the OWA site using HTTPS only.


The log file has some interesting information in it. You can see the user name on the fourth line from the top, as the VPN connection is established. You can also see another line where a user name is included in the request in the 14th line from the top, where a DNS query is issued. This seems to indicate the ISA firewall has access to user information when requests are made for various protocols and servers. However, when using RADIUS authentication, you cannot use this information to create user or group based access controls. Even when you use RADIUS users in a Firewall Group. Very strange!


Note: the VPN client address assigned by the ISA firewall is 10.0.0.101.



If we look further down in the log we can see the connection request to the OWA site. In the 6th line from the top you can see the HTTPS request which is allowed by our VPN Clients to Internal rule. What happened to the user name?



I tried an FTP connection from the VPN client to the FTP server on the Internal network. Since there is no rule allowing FTP connections, I expected it to be denied, and it was. You can see in the 3rd, 4th and 5th lines from the top that the VPN client initiated an FTP connection to the FTP server at 10.0.0.2. Hey, we even have a user name here! There’s got to be a way to use this user name information to control access from RADIUS clients even when the ISA firewall is not a member of the domain. We just haven’t discovered it yet.


Get the New Book!


 



So, given the findings above, I’m hopeful that someone from Microsoft will beat me with a cluestick that provides the key piece of information required to allow strong user/group based access control over VPN client connections when the ISA firewall is not a member of the domain and clients use RADIUS authentication to connect.


Test Yourself



  1. What happens to VPN client connections when the non-domain ISA firewall uses RADIUS authentication?
  2. True or False: The RADIUS server must be on a domain controller
  3. True or False: When the ISA firewall is on the Internet edge of the network, it should never be made a member of the domain.
  4. Under what circumstances do you not need to configure Dial-in permission on a per-user basis?
  5. In this article, is the ISA firewall a RADIUS client, RADIUS server or RADIUS proxy?

Check out the forum discussion link at http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=30;t=000170 for the answers to these questions.


Summary


In this article we examined the procedures required to connect to an ISA firewall’s VPN server using RADIUS authentication. We configured the IAS RADIUS server to use the ISA firewall as a RADIUS client and we configured the ISA firewall to use the RADIUS server as its RADIUS server. We then enabled the ISA firewall’s VPN server and configured the VPN server components. We finished up by making the VPN connection to the ISA firewall and examined log entries that indicate that the ISA firewall does have user information in some circumstances.


This article will be updated if information becomes available providing guidance on how to allow a non-domain member ISA firewall to use RADIUS authentication to provide strong user/group based access control for VPN client connections.


I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=30;t=000170 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.

ISA 2004 HTTP Security Filter – Will It Meet Its Potential?

ISA 2004 firewalls include a very powerful HTTP Security Filter. This filter allows you to block virtually any HTTP connection attempt, based on the settings you configure in the filter. The HTTP Security filter allows you to configure the ISA 2004 firewall to perform detailed searches of the HTTP header and body, and block connections that match your criteria. When used properly, this has the potential to be the ISA 2004 firewall’s “killer app”.

However, most firewall admins have to do double, triple, quadruple and quintiple duties. They don’t have time to make the ISA 2004 firewall their avocation. They need to handle WinXP/Win9x/Win2000 clients, WinNT4/Win2003/Win2003 servers, SQL Servers, Exchange Servers, SharePoint Servers, Certificate Servers, RRAS Servers, IIS Servers, and lots more. There are only so many hours in a day, and the attraction to a firewall like ISA 2004 is that it appears easy to configure. And, on the whole, they would be right.

However, while the HTTP Security filter has a powerful and easy to use interface, the documentation of the feature is abysmal. What do I mean by “abysmal“? Search your dictionary for “tautology“ and then read the Help file and any other MS docs on this subject you might find.

Most firewall admins who opt for ISA 2004 firewalls do so because they want to take advantage of the unique protection provided by ISA 2004, especially for the ISA 2004 firewall’s one of a kind VPN and Exchange security features. This level of protection can be made even better if MS would actually explain and define the various components of this filter and how it works. Otherwise, the HTTP Security Fitler’s power and utility will end up in the dustbin of history like the H.323 Gatekeeper and possibly the VPN-Q feature (I’ll moan about VPN-Q in a future posting).

So the celebrity challange for MS is to come up with clear (not concise! concise usually means “I don’t have the time or inclination to fully explain the subject and explore implications), complete and useful documentation on the HTTP filter. This is how ISA 2004 firewalls can displace Checkpoint and PIX, and prevent users from adopting a Linux based solutution. After all, if I’m going to have to spend hours, days or weeks figuring out how to configure a key piece of a firewall, I don’t have to pay for it, I’ll just use Linux! :-)

So, MS docs team — belly up to the bar and give the ISA 2004 firewall community what it needs, not what you think they need.

Thanks!
Tom

Disabling Spoof Detection in ISA 2004 Firewalls

Spoof detection in ISA 2004 firewalls is a handy feature that helps protect the firewall from spoof attacks. However, there are some circumstances that generate spurious spoofs , such as when implementing NLB. No problem! Here’s the fix, courtesy of our good friend, Barclay Neira:

284811 HOW TO: Disable the IP Spoofing Detection Feature in Internet Security and Acceleration Server

http://support.microsoft.com/?id=284811

Here is the location you would need to update. All other information is the same:

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/FwEng/Parameters

Thanks Barclay!

Protecting Microsoft Exchange with ISA Server 2004 Firewalls:Integrating the ISA Firewall into an Established Network Infrastructure

Protecting Microsoft Exchange with ISA Server 2004 Firewalls:
Integrating the ISA Firewall into an Established Network Infrastructure

By Thomas W Shinder M.D.

Nobody likes to start from scratch. This is especially true if you have a well established network and firewall infrastructure that’s working for you. Why would you want to go and change everything just to add a new application layer intelligent firewall to your setup? Things are working already and you haven’t been successfully attacked for at least 6 weeks.

This is something I come across a lot when recommending ISA firewalls to organizations that already have a firewall and network infrastructure in place that’s pretty much working for them. When they do come around to realizing that they’ll benefit from the added protection of an application layer intelligent firewall like ISA, they choose to install it in what I call “crippled” mode, where the ISA firewall acts only as a reverse proxy server to protect HTTP/HTTPS (SSL/TLS) communications. This configuration is like buying a Corvette and taking three tires off of it because it “goes too fast”.

The reason for this “crippling” is usually because they think its easier to place the ISA firewall on their network using this method. In this “reverse proxy mode”, the ISA firewall does not need to be in the inbound or outbound path, and they don’t need to worry about “zero-day” exploits against Windows operating systems. These are some valid concerns, primarily related to ISA Server 2000 installations. Fortunately, the concerns they had with ISA Server 2000 melt away with ISA Server 2004 firewalls.

The problem with ISA Server 2000 firewalls was that they had a simple view of the networks to which they were attached. A network was either trusted (and included in the Local Address Table or LAT) or it was untrusted (not in the LAT). All communications between LAT hosts were not inspected by the ISA Server 2000 firewall. In addition, all communications between LAT and non-LAT hosts were NAT’d. You could not route requests between LAT and non-LAT hosts. Even if you set up a DMZ segment, where you could route, simple stateful packet filters and not the full range of application layer firewall stateful inspection that the ISA Server 2000 firewall provided, controlled the communications.

The great news is that ISA Server 2004 firewalls are completely different than ISA Server 2000 firewalls. Firewall rules are applied to all interfaces and there is no more LAT. There are no “trusted” networks; all networks are untrusted and all communications moving through the ISA Server 2004 firewall are exposed to firewall policy. Creating DMZs is a simple affair now. Unlike ISA Server 2000, you can now easily place your front-end Exchange Servers on a DMZ segment and apply firewall policy to secure communications between the front-end and back-end Exchange Servers.

Speaking of Microsoft Exchange, it’s clear that ISA Server 2004 should be considered the firewall for protecting Microsoft Exchange Servers. ISA Server 2004 includes a number of technologies aimed at specifically protecting Microsoft Exchange Servers. These include:

  • Forms-based authentication
  • Delegation of basic authentication
  • SSL to SSL bridging (SSL termination)
  • Advanced HTTP Security Filtering
  • URL protection
  • OWA/OMA/ActiveSync wizards that create secure publishing rule by default
  • Secure Exchange RPC filtering
  • And lots more!

A key feature in ISA Server 2004 Exchange deployment scenarios is that it provides sophisticated application layer protection for Microsoft networking services and services regardless of where you place it on the network. You can benefit from ISA Server’s ability to protect against:

  • HTTP application layer attacks: Code Red, Nimda, HTR overflows, directory traversal attacks, buffer overflow attacks, chunked transfer encoding attacks, cross-site scripting attacks, malicious URLs, malicious HTTP content, high-bit encoding attacks, WebDAV attacks.
  • SMTP application layer attacks: spam flood attacks, malicious attachment attacks, SMTP buffer overflow attacks, SMTP disk flood DoS attack, spammer open relay attack, brute force closed relay attack, all worms and worm variants
  • DNS application layer attacks: DNS zone transfer from untrusted sources, DNS buffer overflow attacks, DNS malformed query attack, DNS malformed packet attacks
  • POP3 application layer attacks: POP3 buffer overflow attacks, POP3 malformed command attacks
  • RPC application layer attacks: Microsoft BLAST, Microsoft Blaster variants, Nachi, RPC worm variants and morphs.

In addition, in each scenario, the ISA Server 2004 firewall enables you to:

  • Block access to all Windows executables
  • Block access to Web sites based on keywords on Web pages and URLs
  • Block access to Web sites based on signatures in Request and Response headers and data
  • Enforce encrypted channel for remote access secure Exchange RPC Outlook clients
  • Block FTP downloads or enable FTP downloads for specified users
  • Allow only the HTTP methods (PUT, GET, etc) you want to allow; block all others for everyone, or on a user/group basis – granular control is yours
  • Enforce strict RPC compliance to halt RPC worms as soon as they arrive at the ISA 2004 firewall; this also has the added benefit of stopping DCOM from moving through the ISA 2004 firewall into and out of the corporate network

Only when the ISA Server is configured in a single-NIC configuration is the full array of sophisticated application layer protections not available. In the limited single-NIC configuration scenario, the ISA Server protects only against HTTP related attacks.

In this article, we will discuss a number of network topologies that demonstrate placement options available to you. These topologies include:

  • High-speed packet filtering firewall at the Internet edge with a back-end ISA Server 2004 firewall. The back-end ISA Server 2004 firewall protects the front-end and back-end Exchange Servers, both of which are located on an Internal network segment
  • High-speed packet filtering firewall at the Internet edge, with a front-end Exchange Server on a perimeter network segment between the front-end firewall and the ISA Server 2004 firewall on the back-end. The back-end Exchange Server is located on the protected Internal network segment behind the ISA Server 2004 firewall machine
  • High-speed packet filtering firewall at the Internet edge, with an ISA Server 2004 firewall on the back end. The multihomed back-end ISA Server 2004 firewall includes an External interface, an Internal interface and a perimeter network interface. The front-end Exchange Server is located on the perimeter network segment directly connected to the ISA Server 2004 firewall and the back-end Exchange Server is located on the Internal network segment
  • High-speed packet filtering firewall at the Internet edge, and a non-ISA general-purpose firewall working on the back end. An ISA Server 2004 firewall is configured to work in Web Proxy mode to provide reverse Web proxy services that enables access to OWA, OMA and ActiveSync sites located on Exchange Servers on Internal networks located behind the non-ISA firewall on the back-end
  • High-speed packet filtering firewall on the front-end. ISA Server 2004 firewalls located in a back-to-back configuration behind the high-speed packet filter. Firewall and Web Proxy chaining are configured to provide a level of security not typically available with non-ISA firewalls. The front-end and back-end Exchange Servers are both located on the Internal network behind the back-end ISA firewall
  • High-speed packet filtering firewall on the front-end and a non-ISA firewall on the back end. ISA Server 2004 application intelligent firewalls protect dedicated services segments containing front-end and back-end Exchange Servers

A key feature in each of these scenarios is that the current firewall and routing infrastructure is left in place. Reconfiguration of firewalls and routers is kept at a minimum. The ISA Server 2004 firewall placement relatively transparent. This transparency is critical because the high-speed packet filter based firewalls at the Internet edge must be kept in their current locations. High speed packet filters are able to meet throughput requirements for multigigabit connections to the Internet.

The front-end high-speed packet filters can quickly “pass packets” to perimeter or backbone networks. The high-speed packet filters pass packets to multiple devices located behind them after performing rudimentary network layer stateful filtering. Packet load is distributed among a greater number of back-end devices. This configuration where high speed packet filters handle high volume traffic and multiple back-end devices distribute the high volume into multiple smaller volumes allows the back end devices to provide the higher level of security required to protect servers and services located behind the secondary firewalls. The back-end devices do not need to meet the same performance requirements as the front-end devices because they do not handle the same level of traffic.

Let’s take a closer look at each of these ISA Server 2004 firewall topologies.

High Speed Packet Filter Firewall at Internet Edge/ISA Server 2004 Firewall as Back-end Firewall Protecting Microsoft Exchange

The first scenario has the high-speed packet filter based firewall on the front-end and a sophisticated application layer filtering ISA Server 2004 firewall on the back-end. The ISA Server 2004 firewall provides the advanced application layer protection required for the Microsoft Exchange Server.

This network topology is straightforward. The front-end high-speed packet filters move data inbound and outbound through the corporate network very quickly. Between the high-speed packet filters is a perimeter network segment separating the front-end firewalls from the back end firewalls. The figure below shows a back-end ISA Server 2004 firewall in front of a network services segment containing front-end and back-end Exchange Servers.

Only a minimum amount of configuration is required on the front-end firewalls. The front-end firewalls should be configured to:

  • Forward all inbound requests for the Exchange OWA sites to the external address of the ISA Server 2004 firewall
  • Forward all inbound SMTP messages for the Exchange organization to the external address of the ISA Server 2004 firewall
  • Forward all inbound requests for IMAP4 services to the external IP address of the ISA Server 2004 firewall
  • Forward all inbound requests for POP3 services to the ISA Server 2004 firewall
  • The ISA Server 2004 firewall is configured is configured to use an upstream router that forwards Internet bound requests to the front-end packet filters
  • An optional configuration, which confers a high level of security, is for the front-end high-speed packet filters to forward all mail related (HTTP/HTTPS/SMTP/IMAP3/POP3/RPC) connections to the ISA Server 2004 firewall. While the advanced application layer filtering ISA Server 2004 firewall cannot provide the same throughput as high speed packet filters, the ISA Server 2004 firewall provides a superior level of security.
  • In each of these configurations, the back-end ISA Server 2004 firewall publishes the front-end Exchange Server

As you can see from the figure below, the ISA Server 2004 firewall can be easily placed on the edge of the services segment or an Internal network segment with only minimal configuration on the front-end high-speed packet filtering firewalls.

Figure 1: Front-end High Speed Packet Filter Firewalls/Back-end ISA Server 2004 firewalls

 

Front-end High Speed Packet Filter/Back-end ISA Server 2004 Firewall and Front-end Exchange Server in the perimeter network Segment

This scenario describes a network topology where the front-end packet filtering firewalls remain on the Internet edge, while the ISA Server 2004 machine acts as a back-end firewall protecting the back-end Exchange Server. The front-end Exchange Server is located on a perimeter network segment between the front-end packet filter and the back-end ISA Server 2004 application intelligent firewall. In this scenario, you must take extra care to harden the front-end Exchange server because the only simple stateful packet filters protect it from Internet attackers..

This configuration requires very little reconfiguration on the front-end high-speed packet filters. Changes to be made include:

  • The front-end packet filter forwards inbound connections for the OWA Web site to the IP address used by the front-end Exchange Server in the perimeter network segment
  • The front-end packet filter forwards inbound connections for Exchange SMTP services to the front-end Exchange Server in the perimeter network segment
  • The front-end packet filter forwards inbound POP3 connections to the front-end Exchange Server in the perimeter network segment
  • The front-end packet filter forwards inbound IMAP4 connections to the front-end Exchange Server in the perimeter network segment
  • The front-end Exchange server is a member of the same domain as the back-end Exchange Server. The back-end ISA Server 2004 firewall is configured to allow intradomain communications through the firewall, as well as allowing the SMTP, POP3, IMAP4 and HTTP/HTTPS communications to the back-end Exchange Server. Security can be added between front-end and back-end Exchange Server by using IPSec for front-end/back-end communications.

This is a popular configuration. The front-end Exchange Server provides a unified namespace and a single point of entry for back-end Exchange Servers. A measure of security is realized because the front-end Exchange Server does not contain user mailboxes.

However, placing the front-end Exchange server on the perimeter network segment introduces an enhanced security risk because:

  • The high speed packet filter on the Internet edge cannot provide the high level of application layer security required to protect modern networking services, such as those hosted on the front-end Exchange Server
  • The front-end Exchange Server is a member of the Internal network domain that contains user accounts and Active Directory. Extending the security zone represented by the Active Directory into a lower security perimeter network segment is generally considered poor security practice

Figure 2: Front-end Packet Filter/Back-end ISA Server 2004 firewall and Front-end Exchange in perimeter network

 

Front-end High Speed Packet Filter/Back-end Multihomed ISA Server 2004 Firewall with Front-end Exchange on Trihomed Perimeter Network Segment

In this scenario, the front-end high speed packet filter remains on the Internet edge and the ISA Server 2004 application intelligent firewall remains on the back end. The difference between this scenario and the last one is the front-end Exchange Server is placed on a trihomed perimeter network segment connected to the back-end ISA Server 2004 firewall. This network design provides a higher level of firewall protection for the front-end Exchange Server. In contrast to the rudimentary packet filters on the front-end high-speed packet filtering device, the ISA Server 2004 firewall’s sophisticated application layer filtering and stateful inspection protects the Exchange Server.

The perimeter network segment on which the front-end Exchange Server is located can have either a route or NAT relationship with the perimeter network between the front-end high-speed packet filters and the back-end ISA Server 2004 firewall. The advantage of the NAT relationship is that it hides the IP address used by the front-end Exchange Server.

Changes on the front-end high-speed packet filter include:

  • If a route relationship is used between the trihomed perimeter network segment and the perimeter network segment between the front-end and back-end firewalls, then the high speed packet filters on the front end can be configured to forward SMTP, POP3, IMAP4 and OWA, OMA and RPC over HTTP connections to the actual IP address of the front-end Exchange Server on the trihomed perimeter network segment
  • If a NAT relationship is used between the trihomed perimeter network segment and the perimeter network segment between the front-end and back-end firewall, then the high-speed packet filters on the front end can be configured to forward SMTP, POP3, IMAP4, OWA, OMA and RPC over HTTP connections to the IP address on the external interface of the ISA Server 2004 firewall.
  • The ISA Server 2004 firewall is configured with a default gateway on its external interface that forwards Internet bound packets to a router that forwards them through the high speed packet filters

This configuration works well with ISA Server 2004 firewalls because:

  • Firewall Policy is applied to all interfaces on the ISA Server 2004 firewall.
  • You can place a domain member computer on the trihomed perimeter network segment and allow the intradomain communications between the perimeter network and Internal network segment without allowing access to all protocols.
  • You can configure either a route or NAT relationship between the perimeter network and Internal network segment. In a route relationship, you configure Access Rules allowing the front-end server to communicate with the back-end; in a NAT relationship, you configure Web and Server Publishing rules. In general, Access Rules provide a higher level of flexibility and route relationships provide a higher level of protocol support; not all protocols/applications work properly through NAT devices

The downside of this design is that the Internal network security zone containing the user database and Active Directory is extended into a relatively lower network security zone. However, this design still represents an improvement over the previous scenario because the ISA Server 2004 firewall protects the front-end Exchange Server.

Figure 3: Back-end ISA Server 2004 firewall in Trihomed perimeter network Configuration

 

Front-end High Speed Packet Filtering Firewall/Back-end Non-ISA Firewall and ISA Server 2004 Firewall in Web Cache Configuration in the Perimeter Network

In this scenario, the front-end high-speed packet filters remain on the Internet edge. The back-end firewalls are non-ISA general purpose firewalls. Between the front-end high-speed packet filters and the back-end non-ISA firewalls is an ISA Server 2004 firewall in a unihomed cache configuration. The figure below shows the firewall placements for this configuration.

This configuration provides an organization with an existing financial investment in front-end and back-end firewalls the advanced application layer inspection and unique protection for Microsoft Exchange Services provided by the ISA Server 2004 firewall. The unihomed (single NIC) ISA Server 2004 firewall is configured in “cache mode”. This configuration disables the majority of the strong application layer protection provided by the ISA Server 2004 firewall, but leaves the HTTP application intelligence intact.

The unihomed ISA Server 2004 firewall in cache configuration can act as a reverse (and forward, if you wish) Web proxy and provides support for remote access connections to Exchange OWA, OMA, ActiveSync and RPC over HTTP services. You will not be able to reverse proxy incoming SMTP, POP3 or IMAP4 connections because publishing these protocols requires the ISA Server 2004 firewall to be configured as a firewall.

Although the bulk of firewall functionality is removed from the ISA Server 2004 firewall when it is configured in a unihomed cache configuration, incoming and outgoing Web connections continue to be exposed to the deep HTTP inspection provided by the HTTP security filter, and inbound SSL to SSL bridging can be configured to provide stateful application layer inspection for SSL connections. SSL to SSL bridging prevents hackers from hiding exploits in SSL tunnels.

Configuration of the front-end high-speed packet filters includes:

  • Forwarding inbound HTTP and HTTPS communications to the IP address of the unihomed ISA Server 2004 firewall in cache configuration
  • Not
  • forwarding SMTP, POP3 or IMAP4 connections to the unihomed ISA Server 2004 firewall in cache configuration

The unihomed ISA Server 2004 firewall in cache configuration should be configured to:

  • Publish the front-end Exchange Server. If there is a NAT relationship between the perimeter network and the front-end Exchange Server, then forward the connection to the external address of the back-end non-ISA firewall. If there is a route relationship between the perimeter network and the front-end Exchange Server, then forward the connection to the actual IP address of the front-end Exchange Server
  • The ISA Server 2004 firewall does not need to be configured with a default gateway if the front-end high speed packet filtering firewalls NAT between the Internet and the perimeter network. If the high speed packet filters route between the Internet and the perimeter network, then the unihomed ISA Server 2004 firewall’s default gateway should be configured with a gateway that routes Internet bound requests back to the high speed packet filters

The back-end non-ISA firewall should be configured to:

  • Route the inbound connection from the ISA Server 2004 firewall to the front-end Exchange Server if there is a route relationship between the perimeter network and Internal network
  • If there is a NAT relationship between the perimeter network and the Internal network, then configure the non-ISA firewall to publish or perform a reverse NAT to forward the connection to the front-end Exchange Server
  • The back-end non-ISA firewall does not need to be configured to use the unihomed ISA Server 2004 firewall as its default gateway. This allows you to leave the current default gateway configuration on the back-end firewall as is, without changes.

This configuration is ideal for organizations with a heavy investment in front-end and back-end firewalls who want the benefits of a powerful ISA Server 2004 application intelligent firewall.. In addition, the front-end and back-end Exchange Server at both on the Internal network, so the internal network security zone isn’t extended into the perimeter network. This provides much better security then when the Internal network security zone is extended into a lower security zone.

Figure 4: Unihomed ISA Server 2004 firewall in Cache Configuration in perimeter network

 

Front-end High Speed Packet Filters with Back to Back ISA Server 2004 Firewalls on the Back End

In this scenario, the high-speed packet filters on front end remain at the Internet edge. ISA Server 2004 firewalls are placed in series behind the front-end packet filters to create a back-to-back ISA Server 2004 firewall configuration. This setup allows the front-end packet filters to pass packets quickly, while providing a highly secure perimeter network segment between the ISA Server 2004 firewalls and Internal network segment behind the back-end ISA Server 2004 firewall.

This design is useful for those organizations with an existing front-end firewall infrastructure, but no strong back-end firewall infrastructure providing intelligent application layer protection to a public access services segment that communicates with networking services on a secure Internal network. A back-to-back ISA Server 2004 firewall configuration located behind the current firewall infrastructure can provide this level of security.

Configuration on the front-end packet filters includes:

  • Forwarding all communications for OWA HTTP and HTTPS services to the external address of the front-end ISA Server 2004 firewall
  • Forwarding all communications for Exchange hosted SMTP, POP3 and IMAP4 services to the external interface of the front-end ISA Server 2004 firewall

The front-end ISA Server 2004 firewall is configured to:

  • Publish the OWA site on the front-end Exchange Server using a Web Publishing Rule
  • Publish the SMTP, POP3 and IMAP4 services on the front-end Exchange Server using Server Publishing Rules
  • Configure the front-end ISA Server 2004 firewall’s default gateway to use a router that routes Internet bound requests back to the front-end high speed packet filtering firewalls

The back-end ISA Server 2004 is configured to:

  • Publish the OWA site on the back-end Exchange Server using a Web Publishing Rule
  • Publish the SMTP, POP3 and IMAP4 services on the back-end Exchange Server using Server Publishing Rules
  • Configure the back-end ISA Server 2004 firewall’s default gateway as the internal IP address of the front-end ISA Server 2004 firewall

This configuration provides enhanced protection for the front end Exchange Server located on the perimeter network segment located between the two ISA Server 2004 firewalls. In addition, the Internal network segment benefits from an even higher level of protection because it is protected by two application layer firewalls.

Even if the front-end ISA Server 2004 firewall were to fail, the back end ISA Server 2004 firewall continues to protect the internal network. The drawback of this configuration is the Internal network security zone is extended into the perimeter network segment, which represents a lower security zone than the Internal network security zone.

Figure 5: Back to Back ISA Server 2004 Firewalls Behind Fast Packet Filters

 

Front-end High Speed Packet Filters on the Front-end, non-ISA Firewalls on the Back End and ISA Server 2004 Firewalls Protecting Department LANs and Services Segments

The scenario incorporates a three or more tiered firewall topology. At the front end, high-speed packet filtering firewalls perform initial packet filter based screening. Located behind the high-speed packet filter firewalls are the non-ISA general purpose firewalls. The network between the front-end high-speed packet filters and the back-end non-ISA firewalls is a low security corporate backbone or perimeter network segment. Low security hosts, such as honeypots or IDS systems might be placed on this segment.

A second security zone is located behind the back-end non-ISA firewalls and the ISA Server 2004 firewalls. This represents a public access or anonymous access security zone where public access servers can be place. This segment may also represent a secondary corporate backbone.

ISA Server 2004 firewalls are placed on the edge of departmental LANs and network services segments and provide strong inbound and outbound user/group based access control and superior application layer security for Microsoft Exchange and other Microsoft network services. This is a highly secure configuration because it takes advantage of a well worn military concept that the level of defense should increase as you get closer to the highest security core services.

Because it is protected only by high-speed packet filter based firewalls, the outermost network perimeter has the weakest level of firewall security. The second perimeter is protected by a non-ISA general-purpose firewall, which provides a higher level of security than the fast packet filters. These secondary firewalls might provide a rudimentary level of application layer filtering. The ISA Server 2004 firewalls are placed near the innermost security zones, where the highest level of protection is required. This layered approach insures that the highest level of protection where it is needed most: at the perimeter of the network client and services segments.

Configuration of the fast packet filters and second-tier firewalls varies from network to network. However, this scenario is consistent all other scenarios covered in this paper: it is quite easy to drop the ISA Server 2004 firewall behind existing non-ISA firewalls. This allows ISA Server 2004 firewalls to be placed deep in the network behind the secondary backbone or perimeter network and in front of the high value targets deep within the corporate network.

Figure 6: Multi-tiered Firewall Configuration with ISA Server 2004 Firewalls Providing Application Layer Protection

 

Conclusion

ISA Server 2004 is an advanced application layer firewall that includes a number of features that make it a compelling option for protecting Microsoft Exchange Servers. This article described several scenarios demonstrating that an ISA Server 2004 firewall can be placed virtually any where on the corporate network with minimal disruption to the current firewall and network topology. A common theme in each of the six firewall topologies discussed is that the ISA Server 2004 firewall works well with existing firewall setups. Only a handful of rules need to be changed on the fast packet filters. Even in infrastructures that have invested heavily in a front-end and back-end firewall configuration, an ISA Server 2004 firewall can be easily added to provide the needed application layer security demanded on networks subjected to todays sophisticated hacker attacks.

Fixes for Instant Messenger Related Problems

One of the most common problems seen on the Web boards and mailing lists are Instant Messenger related issues. How do you get them to work? How do you make them stop working? My solution is to remove the dreaded IM’ers from the users machines :-)

However, if you want more information on how to get these things to work, check out:

Microsoft ISA Server Message Boards: Tips for msn,yahoo,kazaa: http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=14;t=000096

Lots of very useful tips and tricks there.

HTH,
Tom

Cool Script for Auto Failover and Failback for Windows 2003 ISA Firewalls

A frequent request on the ISA boards is a script or other free method that you can use to fail over and fail back if you have multiple external interfaces. Custler, a frequently posted on the http://forums.isaserver.org message boards has posted a very nice script to get you started. Jim Harrison may jump in with a fix that will help it work in Windows 2000.

Check it out here:
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000012#000011

Thanks guys!

Tom

The Mystery of the ISA 2004 Beta Newsgroups

I wrote to Jerry Bryant about putting some beta newsgroups for ISA 2004 on the msnews.microsoft.com Web site. Silly me, there were already ISA 2004 beta 2 newsgroups. The problem is that they’re very effectively hidden from public view! This explains why the level of activity in the “public” newsgroups for ISA 2004 is so much less than what I saw during the ISA 2000 beta.

Anyhow, if you’re interested in getting invovled with the public ISA 2004 Beta 2 newsgroups, here’s the secret sauce:

Viewing these Newsgroups with an NNTP Newsreader

Since these are private newsgroups, your server will require you to logon using the following information:

  • Server: privatenews.microsoft.com
  • Account name: privatenews\ISA2004
  • Password: BetaPassword
  • Note that the password is case-sensitive.

Viewing these Newsgroups through Outlook Express

  1. Launch Outlook Express
  2. Select Tools – Accounts
  3. Select Add & click News
  4. Enter Your Name
  5. Enter an alias (you may want to consider avoiding posting with your real e-mail alias, as these newsgroups are exposed publicly through the web interface. More about e-mail aliases and privacy.)
  6. Internet News Server Name Page – enter privatenews.microsoft.com and check “My news server requires me to log on”. Click “Next”.
  7. Enter Account name – privatenews\ISA2004
  8. Enter password (case-sensitive): BetaPassword
  9. Click Next & Finish
  10. Close and download the newsgroups.

Of course, you can go to http://forums.isaserver.org and we have a very active discussion going on regarding ISA 2004 firewalls.

HTH,
Tom