Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2)

Understanding the concept of Network Rules.

• Published: Jan 13, 2009
• Updated: Jan 13, 2009

If you missed the first part in this article series please read Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real-Time Article Update newsletter.

Introduction

In our last article on ISA and TMG firewall networking, I talked about how ISA and TMG firewalls use Networks to control traffic moving through and to the firewall. To recap, ISA and TMG Firewall Networks are collections of IP addresses located behind a specific NIC on the firewall. The addresses can be on and off-subnet for the specific NIC, but in order for a client behind any NIC on the TMG or ISA firewall to reach a destination through the firewall, that client’s IP address must be included in the definition of the ISA or TMG Firewall Network from which it connects. If the client’s IP address is not part of the ISA Firewall Network definition for the NIC that receives the request, the connection will be dropped as spoofed.

If you have not read part 1 of this series on ISA and TMG Networking, or want to brush up on what ISA/TMG Firewall Networks are all about, click here.

Now that you understand the details of ISA/TMG Firewall Networks, the next step is to understand how to connect those Networks. In order a host on one ISA/TMG Firewall Network to connect to a host on another ISA/TMG Firewall Network, the source and destination Networks must be connected. The way you connect ISA/TMG Firewall Networks is by creating a Network Rule.

Network Rules connect ISA/TMG Firewall Networks in one of two ways: NAT or Route. When you connect ISA/TMG Firewall Networks to each other, you also define the route relationship between the Networks.

Note:
Pay attention to the capitalization when I refer to networks. A “network” with a lower case “n” is a generic network, while a Network with an upper case “N” is an ISA/TMG Firewall Network.

When you define a NAT relationship between the source and destination Network, all IP addresses on the source Network are hidden from the destination host. The destination host sees the source IP address as the primary IP address on the external interface of the ISA/TMG firewall. The primary IP address is the IP on top of the IP address list (when there is more than one IP address bound to the external interface of the ISA/TMG firewall). A NAT route relationship is one-way. When you NAT from source to destination, you do not NAT from destination to source. For example, when you NAT from the default Internal Network to the default External Network, you do not NAT from the default External Network to the default Internal Network.

In general, when there is a NAT relationship between the source and destination Network, you create Access Rules to allow connections from the NATed to the non-NATed Network (for example, from the default Internal Network to the default External Network) and Publishing Rules to allow connections from the non-NATed Network to the NATed Network (for example, from the default External Network to the default Internal Network).

When you define a route relationship between two ISA/TMG Firewall Networks, the route relationship is reciprocal. That is to say, if you create a route relationship from source to destination Network, then there is also a route relationship between the destination and source Network. When there is a route relationship, no IP addresses are hidden, and the source IP address is always preserved.

In general, you use Access Rules to allow traffic in both directions when there is a route relationship between source and destination Networks. For example, if you have a route relationship defined for connections from the default Internal Network to a DMZ Network, then you can use Access Rules to allow connections from the default Internal Network to the DMZ Network, and you can use Access Rules to allow connections from the DMZ Network to the default Internal Network.

An example Network Rule appears in figure 1 below. In this example, there is a Network Rule that connects the DMZ Network to the default Internal Network and the route relationship is Route.

Figure 1

Remember, there must always be a Network Rule that connects the source and destination Network. Even if you create an Access Rule that allows a connection from a host on one Network to a host on another Network, the connection attempt will fail because the Networks are not connected by a Network Rule. This problem can be hard to troubleshoot because when you check the ISA/TMG firewall’s log files, you will see that the connection attempt is denied, but there would not be any information indicating that the problem is a missing Network Rule. Well, that’s been true for ISA firewalls. I have not yet tested this with TMG firewalls. However, the problem should be less frequent with TMG firewalls, since when creating a new TMG Network, you are asked to define the Network Rule before the Network is created. In contrast, with the ISA firewall, you could create a Network without creating a Network Rule.

Network Rule Examples

To get a better understanding of how Network Rules work in connecting ISA/TMG Firewall Networks, let’s look at a few examples. In figure 2 below, you will see a typical configuration for an ISA/TMG firewall with a default Internal and default External Network. In this example, there is a Network Rule connecting the default Internal and External Networks, and the Network Rule defines a NAT relationship between the Networks.

When clients on the default Internal Network try to connect to hosts on the default External Network, the source IP address seen by the host on the default External Network is going to be the primary IP address on the external interface of the ISA/TMG firewall. In effect, the ISA/TMG firewall is “hiding” the IP address of the source client.

Figure 2

ISA and TMG firewalls can be configured with multiple NICs. There is no limit on the number of NICs you can install in an ISA or TMG firewall. In fact, you can even create virtual NICs using 802.1q VLAN tagging, as long your NICs and NIC drivers support this configuration. When you have multiple NICs installed on the ISA firewall, you can create an ISA/TMG Firewall Network for each of the NICs (recall our discussion of ISA/TMG Firewall Networks in part 1 of this article series, where each NIC represents the “root” of each ISA/TMG Firewall Network).

In the figure below, you can see that there are three NICs installed on the ISA firewall. One NIC is connected to the default External Network one NIC is connected to the default Internal Network, and one NIC is installed on a DMZ Network. There are two Network Rules configured on the ISA Firewall:

• A Network Rule connecting the default Internal Network to the default External Network, and the route relationship is NAT
• A Network Rule connecting the default Internal Network to the DMZ Network, and the route relationship is Route

In this configuration, connections from the default Internal Network to the default External Network will be NATed, and the destination hosts will see the source IP address of the connection as the primary IP address on the external interface of the ISA firewall. When hosts on the default Internal Network connect to hosts on the DMZ Network, the destination hosts on the DMZ Network will see the source IP address as the actual IP address of the host on the default Internal Network. Likewise, since the route relationship is reciprocal, when a host on the DMZ Network tried to connect to a host on the default Internal Network, the host on the default Internal Network will see the source IP address as the actual IP address of the host on the DMZ Network.

In this next example (figure 3), connections from the default Internal Network to the default External Network are allowed by using Access Rules. Connections from the default External Network to the default Internal Network are allowed by publishing rules (either Web or Server Publishing Rules). Connections from the DMZ Network to the default Internal Network, and from the default Internal Network to the DMZ are allowed using Access Rules.

Figure 3

What do you think will happen if a host on the DMZ Network tries to connect to a host on the default External Network? Since there is no Network Rule in place connecting hosts on the DMZ Network to the default External Network, the connection attempt will be denied, as seen in figure 4 below. Even if there is an Access Rule allowing the connection, the connection attempt will fail because there is no Network Rule connecting the Networks.

Figure 4

Let us say that we create a Network Rule that connects the DMZ Network to the default External Network and define the route relationship as NAT. When there is a NAT relationship, we can use either public or private addresses on the source Network. Connections from hosts on the DMZ Network to the default External Network are allowed by using Access Rules, and connections from the default External Network to the DMZ network are allowed by using publishing rules.

Figure 5

Figure 6 below shows a slight alteration in the configuration. In this case, there is a route Network Rule connecting the DMZ Network to the default External Network. Because there is a route relationship, we must use public addresses on the DMZ Network, because private addresses are not routable over the Internet. We can use Access Rules to allow connections from the DMZ Network to the default External Network, and we can also use Access Rules to allow connections from the default External Network to the DMZ Network.

Up to this point, I’ve been telling you that when you have a route relationship, you can use Access Rules to control traffic in both directions. However, it is possible to use publishing rules. In the case or Web Publishing Rules, the route relationship isn’t an issue, because the connections are always proxied from the source and destination Network, so no actual “routing” at an IP level actually takes place. However, the situation is a little different with Server Publishing Rules.

When there is a route relationship between the source and destination Network, you can allow incoming connections using either an Access Rule or a Server Publishing Rule. In some cases, you might want to use a Server Publishing Rule instead of an Access Rule, because application layer inspection filters are bound to some Server Publishing Rules that can’t be bound to access rules.

For example, in the example configuration noted in the above figure 5, there is a route relationship because the default External Network and the DMZ Network. Suppose you have an SMTP server on the DMZ Network. You want to allow incoming SMTP messages from the Internet to the SMTP server on the DMZ Network. In this case, you could create an Access Rule to allow incoming SMTP connections from the default External Network to the DMZ Network, or you could create a Server Publishing Rule that publishes the SMTP server on the DMZ Network.

The advantage of using a Server Publishing Rule in this scenario is that the SMTP filter can be bound to the “SMTP Server” protocol. “Server” protocols are for inbound connections only. The SMTP filter can’t be bound to the “SMTP” protocol, which is used for Access Rules. Thus, a Server Publishing Rule using the SMTP Server protocol allows us to apply application layer inspection on the incoming connections.

I should note here that when you do use Server Publishing Rules to publish servers in a scenario where this is a route relationship between the source and destination Network, you still publish the machine using the actual IP address of the published server. However, the ISA or TMG firewall then performs a bit of magic to intercept the connection so that application layer inspection can be performed. The firewall does what is called “port stealing” on the Server Publishing Rule, so that when connections destined to the actual IP address of the published server are made, the firewall “steals” the connection and passes it to the application layer inspection filters. If the connection passes inspection, then it is forwarded to the published server. If the connection does not pass inspection, then it is dropped.

Figure 6

Now let us change our focus and look at the connectivity between the DMZ Network and the default Internal Network. In figure 7 below, you can see that we have a Network Rule connecting the default Internal Network to the DMZ Network, and the route relationship is NAT. Because the route relationship is NAT, when hosts on the default Internal Network try to connect to hosts on the DMZ Network, the DMZ Network hosts will see the source IP address of the connection to the be primary IP address on the DMZ NIC.

To allow connections to the DMZ Network from the default Internal Network, you need to create Access Rules. To allow connections from hosts on the DMZ Network to hosts on the default Internal Network, you need to create publishing rules. What you cannot do when there is a NAT relationship from the default Internal Network to the DMZ Network is create Access Rules allowing connections from the DMZ Network to the default Internal Network.

Figure 7

Figure 8 shows a reversal of the Network Rule connecting the DMZ Network to the default Internal Network. In this case, the Network Rule defines a NAT relationship from the DMZ Network to the default Internal Network. When hosts on the DMZ Network try to connect to hosts on the default Internal Network, the hosts on the default Internal Network will see the source IP address of the connection request as the primary IP address on the Internal Network NIC. Access Rules are allow connections from hosts on the DMZ Network to the default Internal Network and publishing rules allow connections from hosts on the default Internal Network to the DMZ Network. You cannot create Access Rules to allow connections from the default Internal Network to the DMZ Network because the hosts on the default Internal Network are on the non-NATed Network.

Figure 8

The next scenario looks at a scenario that is a common point of confusion: the back to back ISA/TMG firewall configuration. In a back to back firewall configuration, there is a front-end ISA/TMG firewall that is connected to the Internet, and there is a back-end ISA/TMG firewall that is connected to a DMZ behind the front-end firewall and an internal network behind the back-end firewall.

In the typical case, the front-end ISA/TMG firewall has a NAT route relationship between the DMZ network behind the front-end firewall and the default External Network. The back-end ISA/TMG firewall has a NAT relationship between the default Internal Network and the default External Network.

What you should appreciate here is that in this typical scenario, the DMZ network in front of the back-end ISA/TMG firewall is part of the back-end ISA/TMG firewall’s default External Network. Because it is part of its default External Network, the route relationship is going to be NAT. Therefore, if hosts behind the back-end ISA/TMG firewall need to connect to machines on the DMZ network between the firewalls, then you will create Access Rules to enable those connections. If there are machines in the DMZ network between the firewalls that need to connect to hosts behind the back-end ISA/TMG firewall, then you will need to create publishing rules to enable those connections.

Figure 9

Now let’s look a variation of the above scenario. In this case, on the back-end ISA/TMG firewall we create an ISA/TMG Firewall Network for the DMZ between the firewalls. Then we create a Network Rule that connects the default Internal Network on the back-end ISA/TMG firewall to the DMZ Network and define a Route relationship between the Networks. Now when hosts connect to resources on the DMZ Network, an Access Rule is used to allow the connection and the hosts on the DMZ Network see the source IP address as the original client IP address. This configuration also allows you to create Access Rules to allow hosts on the DMZ Network to connect to hosts on the default Internal Network behind the back-end ISA/TMG firewall.

This scenario is important because many people would like to terminate VPN connections at the front-end firewall. When VPN clients are terminated at the front-end ISA/TMG firewall, they are given IP addresses that are part of the DMZ Network. Thus, they act as DMZ Network hosts. You can then create Access Rules that allow the VPN clients access to resources on the default Internal Network behind the back-end ISA/TMG firewall. The take home point is that since the VPN clients are given IP addresses that belong to DMZ Network definition on the back-end ISA/TMG firewall, you can use Access Rules instead of publishing rules due to the route relationship between the two Networks.

There is one more thing you should be aware of in this back to back configuration where there is a route relationship between the back-end ISA/TMG firewall’s default Internal Network and the DMZ Network. When hosts on the back-end ISA/TMG firewall’s default Internal Network try to connect to the Internet, the connections must go through both firewalls. When the front-end ISA/TMG firewall receives the outbound connection request from hosts on the back-end ISA/TMG firewall’s default Internal Network, the source IP address is going to be the actual IP address of the host making the request.

Normally, the default Internal Network for the front-end ISA/TMG firewall will include the IP addresses on the DMZ Network. However, since there is a route relationship between the DMZ Network and the back-end ISA/TMG firewall’s default Internal Network, you need to include the addresses in the back-end ISA/TMG firewall’s default Internal Network in the addresses that define the front-end ISA/TMG firewall’s default Internal Network. If you fail to do this, the front-end ISA/TMG firewall will see the source address as one that doesn’t belong to it’s default Internal Network and will drop the connection as spoofed.

Figure 10

Summary

In this, part two in our series about ISA/TMG Network concepts, I went over some scenarios that were designed to help you understand the concept of Network Rules. Network Rules are required to connect Networks. If source and destination Networks are not connected, no communications will be allowed between those Networks, even if there are Access Rules configured to allow the connections. When defining a Network Rule to connect a source and destination Network, you also define the route relationship. The route relationship can be either NAT or Route. Access Rules and publishing rules are supported in a different way, depending on the route relationship between the source and destination Networks.

Next week we will look at a case study where we had to have a good understanding of how ISA/TMG firewall Networks work in order to get a working solution. This case study involves migrating an old ISA 2000 firewall to ISA 2006. Not only that, but the migration also includes changing over from a unihomed ISA firewall to a dual-homed firewall. As you might imagine, there were several network issues that needed to be addressed. You find out what the problems where and how we solved them in the next article. See you then! –Tom.

If you missed the first part in this article series please read Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real-Time Article Update newsletter.

About Thomas Shinder

Dr. Thomas W. Shinder is an MCSE, MCP+I, and MCT. He has worked as a technology trainer and consultant in the Dallas-Ft. Worth metro area, assisting in development and implementation of IP-based communications strategies for major firms such as Xerox, Lucent and FINA.

Click here for Thomas Shinder's section.

Share this article

Receive all the latest articles by email!

Get all articles delivered directly to your mailbox as and when they are released on ISAserver.org! Choose between receiving instant updates with the Real-Time Article Update, or a monthly summary with the Monthly Article Update. Sign up to the ISAserver.org Monthly Newsletter, written by ISA expert Dr. Tom Shinder, containing news, the hottest tips, ISA links of the month and much more. Subscribe today and don't miss a thing!

• Real-Time Article Update (click for sample)
• Monthly Article Update (click for sample)
• Monthly Newsletter (click for sample)

Latest articles by Thomas Shinder

• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)
• ISA Firewall Web Caching Capabilities
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 2)
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 1)
• X-Forwarded-For and the ISA Firewall: Track your Originating Client through a Web-proxy Chain and on Your IIS

Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2)

Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)

What ISA/TMG firewall Networks are about and how the firewall uses these networks to perform several key functions.

• Published: Dec 16, 2008
• Updated: Dec 16, 2008

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real-Time Article Update newsletter.

Last week I did a blog post asking our ISAserver.org members what kind of content they would like to see on the site. I expected the typical stuff, such as “more articles on integrating with other networking equipment vendors” and “more information on how NLB works” and “more articles on how to make ISA and TMG work with Exchange 2007, SharePoint and OCS” and maybe even “more stuff about ISA and TMG add-ons”. I was not disappointed. I did get requests for all of that kind of content.

There was also another comment that I thought was interesting. Someone wrote to me and said that what he would like is some information on the basics. For example, the basics of ISA networking. This fellow said that many Microsoft admins who use ISA have a basic understanding of TCP/IP networking but do not have a good grip on how the ISA firewall see the networked world and any information that would help along those lines would be very helpful.

The comment was a timely one for me, as it dovetailed with some other experiences I was having last week. Therefore, in the spirit of this request for some return to the basics and my experiences last week, we will go over some of the basics of ISA/TMG firewall networking.

ISA/TMG Firewall Networks

NOTE:
Pay close attention to the capitalization I use in this article. Network with a capital “N” refers to an ISA/TMG Firewall Network – which is a network objects that the firewall uses to define collections of IP addresses directly accessible from a specific network interface. In contrast, when a lower case “n” is used for network, I am referring to a generic network or network segment.

ISA and TMG firewalls see the networked world based on the concept of the Network network object. The Network network object defines traffic that moves through the firewall. All traffic that moves to or through the firewall must source from one Network and have a destination to another Network. If the source and destination traffic are on the same Network, then the traffic doesn’t move through the firewall. However, there are times when traffic with the same source and destination Network can bounce off the firewall. We will take a look at this example later.

What is an ISA Firewall Network? An ISA/TMG Firewall Network is a collection of IP addresses that can directly reach a NIC on the firewall without having to traverse the firewall. For example, consider a simple scenario where the ISA firewall has two NICs: an internal interface with an IP address of 10.0.0.1 and an external interface with a public IP address. There is a host connected to the same network as the firewall’s internal interface and that client has an IP address of 10.0.0.2. In this example, the internal interface and the client at 10.0.0.2 are part of the same network, since the client can directly reach that interface without crossing the firewall. In addition, the client can’t be on the same network as the external interface of the firewall, since it would have to cross the firewall to reach that interface.

The figure below depicts this example. The internal interface has the IP address 10.0.0.1 and the client behind that interface has IP address 10.0.0.2. The client behind the internal interface can reach the internal interface directly. The client behind the internal interface cannot reach the external interface directly. Therefore, the client could never be a member of the ISA Firewall Network that the external interface belongs to.

Figure 1

As I mentioned earlier, an ISA Firewall Network is defined as a collection of IP addresses that can be reached directly through one of the interfaces on the ISA or TMG firewall. However, this does not mean that all of those IP addresses have to be on the same network ID as the interface on the ISA firewall.

For example, in the figure above, the internal interface of the ISA firewall was on network ID 10.0.0.0/24 and the client was an “on subnet” client that was also on network ID 10.0.0.0/24. The ISA Firewall Network defined for that interface was 10.0.0.0-10.0.0.255.

What if there is a router behind the ISA firewall’s internal interface and there are remote network IDs that need to connect to the Internet through the ISA Firewall’s internal interface? For example, in the figure below you see that I have added a router and a remote network ID behind that router, which in this case is 192.168.1.0/24. Will the ISA Firewall need to see connections from the 192.168.1.0/24 network ID as being on the same ISA Firewall Network as connections from the 10.0.0.0/24 network ID?

The answer is YES. The reason for this is that both 10.0.0.0/24 and 192.168.1.0/24 in this example have to connect to and through the ISA firewall using the same NIC. Since the ISA Firewall see each NIC as the root of an ISA Firewall Network, all connections made directly to and through the firewall on that interface are part of the same ISA Firewall Network.

Figure 2

However, in order to make this work, you need to add those addresses to the definition of the ISA Firewall Network. In this example, the definition of the default Internal Network would include the addresses 10.0.0.0-10.0.0.255 and 192.168.1.0-192.168.1.255. All of these IP addresses are part of the default Internal Network and reach the ISA firewall through the same network interface card.

Figure 3

The reason we need to include all the addresses that are behind a specific NIC on the firewall is that if there is a host that tries to connect through the ISA firewall on that NIC from a source IP address that is not part of that ISA Firewall Network, the connection request will be dropped as a spoof attempt. The ISA or TMG firewall sees the connection attempt as a spoof because the IP address is not part of the definition of that ISA Firewall Network.

For example, check out the figure below. We have defined the default Internal Network in this example as all IP addresses in the 10.0.0.0/24 and 192.168.1.0/24 ranges (note that I have included all the addresses in each network ID – that is not a requirement. I could have included only a subset of those IP addresses if I wanted to). What if a host with the IP address 172.16.0.2 tried to connect to the ISA Firewall through the NIC that represents the “root” of the default Internal Network?

The connection attempt would fail. The reason why it would fail is that 172.16.0.2 is not part of the definition of the default Internal Network in this example. Since the ISA Firewall does not recognize this source IP address as part of the default Internal Network, it will not allow the connection through the NIC that defines the “root” of the default Internal Network. It will call out this connection as a spoof attempt. All spoof attempts are blocked by the firewall.

Figure 4

What if you wanted to allow connections from that host at 172.16.0.2? It is a simple matter of adding that IP address to the definition of the ISA Firewall Network that this host uses to connect to and through the ISA firewall. In this case, you could add just that IP address, or if you have other hosts on that network ID, you could add the IP addresses of those hosts, or you could add all the addresses in that network ID.

You define that addresses that belong to a specific ISA Firewall network in the Properties dialog box for that Network. In the figure below, you can see the addresses tab for the default Internal Network. This default Internal ISA Firewall Network includes all addresses on the network ID 192.168.1.0/24.

Figure 5

You can create multiple ISA Firewall Networks on a single ISA Firewall. For example, suppose you wanted to create an ISA Firewall Network for wireless guest computers to connect to the Internet. In this case, you would add a third NIC to the ISA firewall (the other two interfaces are for the external interface and the internal interface). The third NIC would become the “root” of a new ISA Firewall Network. You would then assign addresses to that ISA Firewall Network. Each NIC on the ISA firewall needs to be on a different network ID, so after installing the third NIC, we assign it an IP address on a network ID that is different than the other two NICs. Then we assign IP addresses for the new ISA Firewall Network. In the figure below, you can see that all addresses on network ID 192.168.0.0/24 are part of the Guest ISA Firewall Network.

Figure 6

It is important to remember that an IP address can participate on a single ISA Firewall Network. You can not assign the same IP address to two different ISA Firewall Networks. If you do, you will receive an error message.

Out of the box, the ISA or TMG firewall will have the following Networks defined:

• The default External Network – the default External Network is defined by all IP addresses that are used by any other ISA Firewall Network. Any address that is not used by any other ISA Firewall Network will automatically be included as part of the default External Network. The NIC that defines the default External Network is usually the NIC with the default gateway bound to it. ISA and TMG MBE firewalls support a single default gateway
• The default Internal Network – this is the network you define during setup that represents your primary internal network. You can have multiple internal networks if you like, but there is only one default Internal Network which you set up during installation of the ISA firewall. The default Internal Network typically contains your key infrastructure services, such as DNS, DHCP and Active Directory domain services. The default Internal Network is important because much of the ISA and TMG firewall’s System Policy is configured to access resources on the default Internal Network
• The Local Host Network – The Local Host Network is defined by the IP addresses bound to all NICs on the ISA or TMG firewall. For example, if the firewall had two interfaces, one with IP address 2.2.2.2 bound to it and the other with 10.0.0.1 bound to it, then IP addresses 2.2.2.2 and 10.0.0.1 are members of the Local Host Network. Note that this breaks one of the rules of ISA/TMG Networks – in that these IP addresses are also members of the Networks to which those NICs are connected. The 2.2.2.2 is likely a member of the default External Network and the 10.0.0.1 is a member of the default Internet Network.
• VPN Clients Network – The VPN Clients Network contains the IP addresses of connected VPN clients. There are two ways to assign IP addresses to VPN clients: using a static address pool and using DHCP. If you assign IP addresses to VPN clients using a static address pool, then you must remove those IP addresses from any other Network that might contain them. For example, if you want to assign on-subnet addresses to VPN clients (such as 192.168.1.200-192.168.1.225/24 when the internal interface is on 192.168.1.1/24), you must remove those addresses from the definition of the on-subnet network.
  In contrast, if you want to use DHCP to assign IP addresses to VPN clients, then you do not have to remove those addresses from the definition of any other Network that might also be using those addresses. It makes sense, since when you use DHCP to assign these addresses; you know that no other host should be able to use the same IP address on any other Network. In contrast, if you assign static addresses to VPN clients, you do not know for sure that there might be an error that would lead you to use the same addresses on another Network. Addresses are automatically added and removed from the VPN clients Network when they are used and released by the VPN clients. Note that this represents a second exception to our rule that an IP address can belong to a single Network – since you use DHCP to assign IP addresses to VPN clients, those addresses can belong to another ISA/TMG Firewall Network.
• Quarantined VPN Clients Network – The Quarantined VPN Clients Network contains the IP addresses of VPN clients that have not yet passed VPN quarantine control. This is configured as a separate Network from the VPN Clients Network because you might want to create Firewall Rules that allow quarantined VPN clients access to resources on a Protected Network (a Protected Network is any ISA/TMG Network that isn’t the default External Network) or even on the Internet so that they can remediate themselves. IP addresses are automatically moved from the Quarantined VPN Clients Network to the VPN Clients Network when the VPN client passes quarantine control checks.

Figure 7

Summing up what we know at this point:

• ISA/TMG Firewall Networks are used for spoof detection. If a source IP address arrives at an interface that is a root of an ISA Firewall Network that isn’t an IP address defined for that Network, then the connection attempt is dropped as a spoofed connection attempt
• An IP address can be assigned to a single ISA/TMG Firewall Network. The only exceptions to this rule are seen with the Local Host Network and the VPN Clients and Quarantined VPN Clients Networks when you use DHCP to assign addresses to VPN clients.
• An ISA/TMG Firewall Network can contain IP addresses from multiple network IDs. What all these IP addresses have in common is that if they need to connect to and through the ISA or TMG firewall through the same NIC

ISA/TMG Firewall Networks also are used to do one more important task: define whether connections are routed or NATed from the systems on a particular Network to another Network. In order to hosts on a Network to communicate with hosts on another Network, the two Networks must be connected using a Network Rule. The Network Rule accomplishes two things:

• Enables communications between the two ISA/TMG Firewall Networks
• Sets a routing relationship between the two Networks

I’ll go into more details on Network Rules and connecting Networks to one another in the second part of this series on ISA/TMG firewall networking.

Summary

In this article, we went over what ISA/TMG firewall Networks are about and how the firewall uses these networks to perform several key functions. We saw that an IP address can belong to only a single Network, with the exception of the Local Host Network and the VPN Clients and Quarantined VPN Clients Networks. We then finished off with a brief overview of the default ISA/TMG Firewall Networks. Next week I will continue the story by showing you how ISA/TMG Networks are used to connect hosts on one Network to another, and how Networks are used to define a route relationship between source and destination. See you then! –Tom.

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real-Time Article Update newsletter.

About Thomas Shinder

Dr. Thomas W. Shinder is an MCSE, MCP+I, and MCT. He has worked as a technology trainer and consultant in the Dallas-Ft. Worth metro area, assisting in development and implementation of IP-based communications strategies for major firms such as Xerox, Lucent and FINA.

Click here for Thomas Shinder's section.

Share this article

Receive all the latest articles by email!

Get all articles delivered directly to your mailbox as and when they are released on ISAserver.org! Choose between receiving instant updates with the Real-Time Article Update, or a monthly summary with the Monthly Article Update. Sign up to the ISAserver.org Monthly Newsletter, written by ISA expert Dr. Tom Shinder, containing news, the hottest tips, ISA links of the month and much more. Subscribe today and don't miss a thing!

• Real-Time Article Update (click for sample)
• Monthly Article Update (click for sample)
• Monthly Newsletter (click for sample)

Latest articles by Thomas Shinder

• Overview of ISA and TMG Networking and ISA Networking Case Study (Part 2)
• ISA Firewall Web Caching Capabilities
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 2)
• Auditing the Initial Configuration of the EBS TMG Firewall (Part 1)
• X-Forwarded-For and the ISA Firewall: Track your Originating Client through a Web-proxy Chain and on Your IIS

Overview of ISA and TMG Networking and ISA Networking Case Study (Part 1)

December 22, 2008 11:57 AM PST

The great paradigm shift of cloud computing is not self-service...

Posted by James Urquhart

There has been significant discussion over the short life of the term "cloud computing" about how little it differs from concepts like managed hosting and ASPs. And there is some truth to these observations; if you really look closely, what are the key differences between EC2 and a more traditional managed hosting provider? Some would say multi-tenancy, self-service and pay-per-use (including billing and elastic capacity). With specific regard to EC2, I would tend to agree.

(I would also hasten to point out that Amazon provides some very PaaS-like services in conjunction with EC2, such as Simple Queuing Service (SQS) and SimpleDB.)

However, if this is the great "paradigm shift" of cloud computing, as offered by smart people like Krishnan Subramanian of CloudAve, then let me offer that these basic extensions to existing hosting models will be peanuts next to a shift that will create one of the most significant market opportunities since the explosive growth of the Internet itself. I'm not dealing in hyperbole here; I honestly believe that there is a clear evolutionary step to the cloud occurring well after stand-alone self-service clouds are mainstream (which they arguably are today) that will inspire massive innovation.

That game changing technology disruption will be the federation of disparate clouds, and the distribution of software, data and billing across commercial and private cloud boundaries. In other words, the introduction of secure, reliable workload mobility in an extension of the Internet itself--an "Intercloud", so to speak.

Workload mobility is one of the key innovations of the virtual server world (though it borrowed heavily from its technical ancestry). Technologies like VMotion and other live migration technologies allow system administrators to move running workloads from one machine to another, but today they are generally limited to one subnet.

However, expand the reach of VM motion to cross not only subnet boundaries, but even organizational boundaries, and you get an interesting new world of possibilities. Some of these have been anticipated for some time, but as I talk to more and more people about what could happen here, more and more use cases crop up. For example:

• Follow the Sun: Move workloads to where they are being most utilized at a given time, usually the "day" side of the planet.
• Follow the Moon: Move workloads to where power is cheapest, usually the "night" side of the planet.
• Follow the Law: Move workloads to where the legal and regulatory environment is optimal for the task being executed or the data being stored.
• Optimize Latency: Move workloads to where network routing is optimized for a system of components.
• Optimize Utilization: Move workloads to where the optimal use of compute and/or storage utilization is achieved.
• Optimize Cost: Move workloads to where the cost of computing is as cheap as possible for the workload at hand.

There must be several, perhaps even dozens, of ideas workload mobility would trigger for entrepreneurs and established service providers alike beyond these. I won't deign to have thought through all of the possibilities. The truth is, though, we will probably end up creating complex assemblies of basic sets of policies, mixing and matching as required to meet service levels.

To get to this level of workload mobility, four key areas need to be addressed:

• The mechanism behind workload mobility itself. We've got a great headstart from the likes of VMWare VMotion, but there needs to be more motion aware infrastructure to make this happen ubiquitously. For example, how do you handle what I like to call impedence mismatches between different infrastructure providers, such as one using AMIs and another kvm guest images?
• Integrated and ubiquitous security and control mechanisms. Security for the obvious reasons, but giving the illusion of control is a big part of the workload mobility story. To the owner of the workloads, they should always have the illusion that they are running in their own data center, regardless of where the workload is actually running--though they should control that too.
• Service Level Automation. This is a critical aspect of trust, perhaps the most illusive enterprise requirement in the cloud today. Define service levels at least in part in terms that automation systems can use to tweak elasticity, availability and resource consumption. That automation, in turn, guarantees within reason that customer service levels will be constantly adhered to. Without service level automation across organizational boundaries, it will be impossible to trust systems that become distributed among multiple providers.
• Integration and interoperability protocols and services. We long ago left the world in which production software can be moved around in units called "applications". Almost any system today is comprised of multiple end user applications and back-end services that must coordinate to complete their respective functions. This does not even take into account the management backplane that exists to support those complex systems, that also must coordinate across the same organizational boundaries. All of this has to be available on the shared network in which workload is mobile. If we want workload to be mobile across the Internet, then it must exist as protocols or services on the Internet itself.

The final step of the cloud computing maturity model requires that these requirements be addressed. There is some debate about from what part of the compute landscape these services should be delivered, and how the various "impedence mismatches" of disparate cloud platforms will be handled (or even if they can be handled). Of course, I believe that the network will play a major role, but others see options in pure server software or virtual appliance implementations.

Any way you cut it, though, if you think self-service changed computing and created opportunities, wait until you see the "Intercloud".

James Urquhart is a seasoned field technologist with almost 20 years of experience in distributed systems development and deployment, focusing on service-oriented architectures, cloud computing, and virtualization. James is currently market manager for the Data Center 3.0 strategy at Cisco Systems. He is a member of the CNET Blog Network and is not an employee of CNET.

Topics:

Cloud Computing,

IAAS (infrastructure as a service),

PaaS (platform as a service)

The great paradigm shift of cloud computing is not self-service... | The Wisdom of Clouds - CNET News

Gartner Releases Data on Hot Enterprise Topics

Gartner's 27th annual datacenter conference is producing research related to energy consumption, virtualization, cloud computing. Here are some of the most interesting numbers revealed at the conference.

Forty-two percent of IT professionals polled at the Gartner conference operate three or more datacenters in North America.

Forty-five percent are expanding or planning to expand datacenters in the next two years, while 43 percent are consolidating.

A standard 9,000 square foot, Tier 3 datacenter that supports 150 watts per square foot will cost approximately US$21.3 million (about Rs 105 crore) to build, with $1 million (about Rs 5 crore) in annual electrical costs.

Green IT practices that minimize use of chiller plants, fans and pumps, lighting and power supplies can more than halve the power costs of running a datacenter.

An aggressively "green" enterprise will pay $560,000 (about Rs 2.8 crore) in annual electrical expenses for a datacenter with a 500 kilowatt IT load. Enterprises with archaic datacenter practices will pay as much as $1.3 million (about Rs 650 lakh).

In a conventional datacenter, 35 percent to 50 percent of electrical energy is devoted to cooling. With best practices, that proportion is reduced to 15 percent.

Twenty-six percent of conference attendees buy green products only when they lower costs, save space or defer datacenter construction.

Thirty-four percent will buy green products even if they increase costs.

Storage spending is growing almost three times faster than the IT budget as a whole. From 2007 to 2011, storage spending will increase more than 7 percent a year, compared with annual IT budget growth of only 2.5 percent.
By 2012, users will install 6.5 times the amount of terabytes they installed in 2008.

Server virtualization, one of the key technologies driving costs down in datacenters, is suitable for about 70 percent of workloads.

Today, only 12 percent of x86 server workloads are running in virtual machines.
By 2013, that number will be 61 percent.

One out of every four x86 workloads deployed or redeployed in 2008 is being installed in a virtual machine. Still, vendor licensing, pricing and support plans are limiting virtualization efforts, according to 21 percent of conference attendees.

About 70 percent of virtual machines today are used in production. Just a few years ago, most were used only in test and development roles.

The server virtualization market will grow 30 percent a year through 2013, reaching $6.8 billion (about Rs 34,000 crore).

Desktop virtualization will also take off, with the number of virtualized PCs growing from less than 5 million in 2007 to 660 million by 2011.

Only two major server operating systems will experience significant growth through 2010 -- Windows and Linux. But lightweight operating systems will take off with double-digit growth, including JeOS, a variant of Ubuntu configured specifically for virtual appliances.

Thirty-eight percent of conference attendees are using some type of external cloud computing service.
By 2012 at least 14 percent of the infrastructure at Fortune 1000 companies will be service-oriented, scalable and elastic -- operated as if it they were "private clouds" for each company's users.

Source : Network World

Jon Brodkin

CIO India - Gartner Releases Data on Hot Enterprise Topics

December 04, 2008 | Comments: (1) | TrackBacks: (0)

Server virtualization: Gartner's view through 2011

Gartner predicts some game-changing numbers for server virtualization as the mass market adopts the technology into production environments

TAGS: Server Virtualization

This week in Las Vegas, Gartner's VP Distinguished Analyst Thomas Bittman delivered the keynote address at the 27th annual Gartner Data Center Conference. And as expected, one of the hot topics of discussion was server virtualization.

Bittman stated that only two or three years ago, server virtualization was mostly being used for test and development purposes. But now, the technology is being accepted into production environments to the tune of about 70 percent of all datacenters using virtual machines in some sort of production role.

[ To learn more about server virtualization, check out this InfoClipz video. ]

Bittman also announced three remarkable predictions about the virtualization industry:

• By 2012, at least 14 percent of the infrastructure and operations architecture of Fortune 1000 companies will be managed and delivered much like a cloud-computing provider, internally. These "private clouds" are essentially flexible computing networks designed to be like the solutions being offered by public providers such as Google and Amazon.
• Between 2007 and 2011, Bittman expects that the installed base of virtual machines will grow more than tenfold.
• And by 2012, he believes that the majority of x86 server workloads will be running within a virtual machine.

When talking about this hot virtualization technology, Bittman adds, "our key advice is to look beyond simple consolidation and cost savings. Virtualization can be the catalyst to drive many fundamental important changes in architectures, processes, and cultures. Even if short-term attention needs to be given to cost-savings, make sure you build a foundation that can be leveraged in a few years. Virtualization 'unlocks' cloud computing potential internally and externally."

Posted by David Marshall on December 4, 2008 07:15 AM

Server virtualization: Gartner's view through 2011 |Virtualization Report | David Marshall | InfoWorld

How to migrate Microsoft ISA Server 2006 to Microsoft Forefront TMG

ISA Server 2006: Migrating to Forefront Threat Management Gateway.

• Published: Nov 25, 2008
• Updated: Nov 25, 2008
• Section: Tutorials :: Configuration - General
• Author: Marc Grote

Introduction

Microsoft Forefront TMG (Threat Management Gateway) is the upcoming successor of ISA Server 2006 and will be available in 2009. This article is based on a beta version of Microsoft Forefront TMG. If you want to evaluate Forefront TMG, a public beta is available at the following website: Forefront TMG. If you want to have a look at a special version of Microsoft Forefront TMG which is already RTM, you should evaluate Microsoft Windows Essential Business Server 2008 which contains Forefront Threat Management Gateway, Medium Business Edition. But keep in mind that this is not the same version of TMG which Microsoft will publish in 2009 as a standalone product.

See the full article at the source.

Source: How to migrate Microsoft ISA Server 2006 to Microsoft Forefront TMG

Thomas Shinder Blog RSS

All Blogs  »  Thomas Shinder Blog  »  News ISA Central  »  Blog article: Jim Harrison LIVE (sort of) - Virtualize Your ISA or Forefront TMG Servers

Jim Harrison LIVE (sort of) - Virtualize Your ISA or Forefront TMG Servers

From the site:

“In the past, ISA has had very limited or no support on Microsoft’s virtualization platform.  Now, ISA and Forefront Threat Management Gateway (TMG) is supported .  I met up with Jim Harrison to get some guidance on what you need to think about when you virtualize your ISA/TMG servers.  We quickly dive into a whiteboard session on the various ways you can configure Hyper-V / virtual server to work with ISA/TMG and dig into the advantages and disadvantages of each network configuration such as:

• Performance
• Management
• Administration
• Security

Some other things we talk about:

• Why placing TMG on the parent is a bad idea and how you should configure the parent partition
• Configuration options of the actual ISA/TMG server
• Failover, Clustering, and Quick Migration with ISA / TMG in a virtual environment
• Configuration changes you should make for any host which faces the Internet

View the security considerations for virtualized ISA / TMG deployments guide / whitepaper Jim wrote.

See KB article 957006 which states ISA (and other) products are officially supported on Hyper-V.”

=====================================

Head on over to http://edge.technet.com/Media/Virtualize-your-ISA-...rvers/ to watch and listen to Jim Harrison’s great presentation on deploying an ISA or TMG firewall in a virtualized environment. You’ll be glad you did!

HTH,

Tom

Thomas W Shinder, M.D., MCSE
Sr. Consultant / Technical Writer
Prowess Consulting www.prowessconsulting.com
PROWESS CONSULTING documentation | integration | virtualization
Email: tshinder@isaserver.org
MVP — Forefront Edge Security (ISA/TMG/IAG)

This entry was posted on Sunday, October 12th, 2008 at 9:54 am and is filed under News, ISA Central. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Thomas Shinder Blog » Blog Archive » Jim Harrison LIVE (sort of) - Virtualize Your ISA or Forefront TMG Servers

Virtual vs. Physical Appliances: 4 Compelling Reasons for Change

by Ronan Kavanagh, CEO, SpamTitan

Be the first to comment | I like it!
Tags: anti-spam, email, security, spam, virtual appliances, VMware

October 10, 2008, 12:26 PM —  SpamTitan — 

Virtual v’s Physical Appliances – 4 compelling reasons for change

Executive Summary

Virtual Appliances have appeared on the horizon as an unstoppable force. Where traditional appliances supplanted the office and data centre server, the virtual appliance has taken this to a new level and in turn rendered the incumbent effectively obsolete. Where appliances addressed critical needs not addressed by office servers, they also introduced further complexities and difficulties which are easily resolved by virtual servers. This white paper takes a look at the advantages of virtual appliances in comparison with physical appliances and addresses some of the key benefits. Benefits which include ease of evaluation and testing, ease of deployment, streamlined redundancy and backup, and the key benefits of scalability and mobility....

The Need for Scaleable Architecture

Most organizations today spread their applications across servers based on functional
boundaries. Both large and small companies use email servers, file servers, web servers
and so on. Over time, the trend has been to dedicate a specific server for each function.
This allows for a scaleable, highly flexible architecture. As the organization grows, greater demands are placed on the infrastructure. Not just from an increase in the number of users, but also in terms of the geographic footprint. Branch offices will require their own servers for certain applications. Fault tolerance also plays a part, driving larger installations towards multiple, duplicated servers in preference over a single monolithic system.

As servers don’t generally require user interaction, the trend has been to use vendor supplied appliances for certain types of applications. An appliance allows for a relatively small footprint and also provides more of a plug and play infrastructure over the traditional server application experience. As load increases, new appliances can be brought on-stream and the load distributed evenly. The system administrator can maintain a surplus of similar appliances and install these in the event of failure or increased load. Dividing the application base into component parts and spreading these components across multiple appliances is a tried and tested method of delivering a scaleable architecture.

However, industry research by VMware shows that the system usage per appliance can be as low as 15% of the available processing power.† Effectively, the server budget is over six hundred percent higher than necessary. Maintaining a pool of idle servers on standby in case of increased load or for failure recovery, can adversely affect the efficiency even further. Amalgamating applications on each server can go a long way toward resolving the usage issues but at a cost. Running different applications on the same server loses the scalability of the appliance solution and can create security issues.

In addition, maintaining a homogenous environment of appliances is extremely difficult if not impossible. Complicating this is the need to upgrade different applications at different times. A new appliance can have a different platform configuration which will make it difficult to migrate users from an older appliance to a new one.

Virtual Appliances

A virtual appliance is one which subdivides the physical hardware into multiple virtual machines. Each virtual machine provides a ...  See more at the source

Source - Virtual vs. Physical Appliances: 4 Compelling Reasons for Change | ITworld

Announcing: Forefront Threat Management Gateway, Medium Business Edition

I am pleased to announce that the first version of the new Forefront Threat Management Gateway (TMG) has been released to manufacturing as part of the Windows Essential Business Server 2008 (EBS) release. As I first blogged in April of this year, Forefront TMG is a new era for the ISA Server product line. It is taking us and our customers into new and innovative protection directions based on the ever-increasing threats we are seeing on the Internet today.

Forefront TMG, Medium Business Edition is fully integrated in Windows Essential Business Server and installed by default. One of the unique capabilities of this edition is the simplified setup and configuration – without taking away the ability for customers or value added service providers to provide the customization or control they may require for their specific environments. We took a specific approach in this release by asking the administrator what he/she wants to achieve, not how to do it. The end result is a server pre-configured with best practices for the most common security and access needs including Internet access, remote access and common firewall rules.

Not only does Forefront TMG include a fully featured and highly rated corporate firewall capability, but it adds a Unified Threat Management (UTM) capability to the EBS installation. It truly provides a comprehensive, all-in-one integrated edge security solution, for both the headquarters and the branch offices. The real value comes through the tight integration of the different UTM components, as well as with the other applications and solutions encompassing EBS. The integrated anti-virus subscription services provide administrative relief to IT professionals from having to constantly monitor the security threats and changing edge policies. The “Am I Secure?” page provides an easy, at a glance view of the security state and statistics of the system avoiding the need for complex understanding and expertise to provide protection for the business.

As our software, hardware and appliance partners announce exciting value–add offerings, I will keep the community informed. In addition, I will be announcing future details around the public beta for the next edition of TMG later this year on this blog. I think you will be excited and surprised and certainly well worth the wait when we announce. Stay tuned to this channel for continual updates!

David B. Cross

Product Unit Manager

Published Tuesday, September 16, 2008 1:13 PM by isablog

Forefront TMG (ISA Server) Product Team Blog : Announcing: Forefront Threat Management Gateway, Medium Business Edition

ISA 2006 SP1 and IAG 2007 Supportability Statement

Introduction

Occasionally you find the combination of two things that result in something better than the sum of the individual parts. Some combinations that come to mind are peanut butter and chocolate, steak and lobster, and ISA Server 2006 and IAG 2007. You can’t eat ISA and IAG but combined in the IAG 2007 product they create an awesome SSLVPN with rich features. Just like a good soup, IAG 2007 benefits from high quality ingredients. For more information on this “better together” approach review the articles below:

http://www.microsoft.com/forefront/edgesecurity/iag/en/us/secure-remote-access.aspx

http://www.microsoft.com/Forefront/edgesecurity/iag/en/us/faq.aspx

Real World Experience

Recently, I began seeing questions about the addition of ISA 2006 SP1 on customers IAG 2007 systems. After some research it turned out that Windows update was detecting the lack of ISA 2006 SP1 and prompting administrators to install the service pack on their IAG 2007 servers. If you are familiar with IAG 2007 predecessor eGap 3.6 you will remember that the internal server was protected by a SCSI interface that shuttled between the external and internal servers. In IAG 2007 the external server and SCSI interconnect have been removed and replaced by ISA 2006. In this configuration ISA 2006 protects the external interface of IAG 2007 amongst other things.

Since SP1 for ISA 2006 includes feature updates as well as security updates, just like any other windows application it is essential to make sure there is no security vulnerability that might affect the ISA application. Hence it is important to make sure the ISA server is also updated from time to time.

When you first initialize the IAG 2007 system you will notice that ISA server 2006 is installed as well. As applications are added to the portal trunk, rules are created in ISA 2006 to allow the specific traffic types that IAG 2007 will publish. If IAG 2007 is configured for automatic updates or you visit the Windows update site, SP1 for ISA 2006 will be queued for installation if it is not already installed. You can review the benefits of SP1 for ISA 2006 by following this link: http://blogs.technet.com/isablog/archive/2008/05/23/isa-server-2006-service-pack-1-features.aspx

As you can see from reading the list we fixed a few things in ISA 2006 with SP1. In addition, patch management is part of the Desktop, Device, and Server security process best practices that IT professionals should be following. Recently, while testing IAG 2007 SP2 our product group tested with ISA 2006 SP1 installed and found no issues related to this service pack. So go ahead and add ISA 2006 SP1 to your IAG 2007 system. I bet you will find it’s a great combination and is a high quality ingredient in your security soup.

Author
Dan Watson
Security Support Engineer –IAG Team
Microsoft – NC

Technical Reviewers
Yuri Diogenes
Security Support Engineer – ISA/IAG Team
Microsoft – Texas

Mohit Saxena
Security Technical Lead – ISA/IAG Team
Microsoft – Washington

Published Thursday, September 18, 2008 8:02 PM by edgeaccessblog
Filed under: Intelligent Application Gateway, ISA Server 2006 SP1

Intelligent Application Gateway Product Team Blog : ISA 2006 SP1 and IAG 2007 Supportability Statement

Independent research firm recognizes Microsoft NAP as a leader in Network Access Control

Published 18 September 08 12:45 AM | Forefront Blogger

Microsoft’s Network Access Protection (NAP) solution was cited as a leader (the top category) in a recent independent report, “The Forrester Wave: Network Access Control, Q3 2008.”  Microsoft was one of the many network access control (NAC) vendors invited to participate in the report.

Forrester placed a lot of emphasis on different access control scenarios for the evaluation and the different vendors were evaluated around twelve different scenarios as well as strengths across technology, strategy and market presence.

“Microsoft has the strongest NAC product for managed endpoints,” the report stated. The report goes on to state that even though its official product has only been shipping since the inception of Windows Server 2008, Microsoft has already established itself as a critical thought leader and contributor to the standardizations of NAC. “Microsoft has the overall highest score among the 12 scenarios we evaluated,” the report added.

Microsoft Network Access Protection ships with Windows Server 2008 and Windows Vista and XP SP3, and has a framework that provides interoperability with over 100 different vendors. The NAP statement of health (SOH) has also been adopted as a standard by the Trusted Computing Group’s Trusted Network Connect (TNC).

More information about Microsoft NAP can be found here http://www.microsoft.com/nap

Forefront Team Blog : Independent research firm recognizes Microsoft NAP as a leader in Network Access Control

Publishing Exchange 2007 Services with ISA Server 2006 - Creating the Publishing Rule for Outlook Anywhere with Transparent Windows Authentication

One of the most popular questions we get regarding the ISA firewall and Exchange Server is how to get transparent authentication for the Outlook client. Most users prefer to store their passwords and don’t want to enter their passwords each time they open Outlook. The problem is that if you use basic authentication at the client and at the ISA firewall’s Web Listener, you will always need to enter credentials when Outlook starts up.

Thomas Shinder Blog » Blog Archive » Publishing Exchange 2007 Services with ISA Server 2006 - Creating the Publishing Rule for Outlook Anywhere with Transparent Windows Authentication

Tales from the Edge is Online

Today we are launching in the Forefront Edge Community page a new session called: Tales from the Edge. Jim Harrison and I will host articles about Forefront Edge Suite bringing real world scenarios and documenting things that were not documented yet. In this new wave we are going to release four brand new articles with very precious information about Edge products. Visit the new Forefront Community Page at:

http://technet.microsoft.com/en-us/forefront/edgesecurity/bb687298.aspx

Filed under: ISA Administration

Yuri Diogenes's Blog : Tales from the Edge is Online