On a current project I had the requirement to publish the internal MOSS2007 Solution to the outside world. The problem I faced was that the servers sit on the LAN, which is sitting behind a Firewall and then all the internet traffic came in via a different Firewall. In the solution there are various servers in the LAN and then Firewalls that block the traffic coming into the LAN and in from the Internet. In the real world solution there is a whole host of "DMZ" services that are available and being published to the outside. For this example though I am only going to concentrate on the publishing of the MOSS2007 solution to the outside world, fronted by ISA2006 authentication. So to start with the basic process is as below:

1. Configure ISA2006 rule on external firewall to allow traffic in for requests to http://www.mywebsite.com
2. Route this traffic to the outside interface of the internal firewall; in this case we will say it is "192.168.1.1".
3. Configure a rule on the internal firewall for publishing the internal SharePoint
4. Configure this rule to "Listen" for requests for http://www.mywebsite.com
5. Configure this rule for "HTML Forms Based Authentication"
6. Ensure this rule is using both NTLM and Kerberos as the internal site is enabled for Kerberos

The process itself is very simple when you list it as steps; however the configuration just takes some time and goes through endless amounts of screens in ISA2006. So to begin with let's jump onto the "External" firewall and add a new rule. ISA has some great wizard driven menus and screens and these are very intuitive and simple to use. To add the rule, select the following option:

Notice at the outside Firewall we are not actually using the "SharePoint Site Publishing Rule" as we do not actually have access to SharePoint at this point. The wizard should then launch:

This option allows you to select the different types of publishing. For this example I have selected a single website.

You would probably want to use SSL at this point but for ease of configuration we will stay with standard HTTP traffic.

The two values that need to be added here are the actual URL you wish to present to the other firewall and the IP Address of the outside interface of the other firewall.

Make sure at this point that you use the same internal and public name as this is what you want to present to the other firewall. In a normal website publishing rule these would probably be different.

A "HTTP Listener" needs to be created so the traffic that hits the firewall can be picked up and sent onwards.

Selecting the correct network here is important, if you choose the incorrect network your listener will not hear the requests from the other server and will fail to route the traffic.

Notice here that we are not asking for any authentication at all. This is because we simply want to pass this traffic back to the other firewall that will then allow a "HTML Forms" authentication to take place. If we were to ask for authentication here we would not be able to seamlessly log into SharePoint as this server has no connection to the internal Active Directory.

Notice also that we are not doing any delegation.

Once this rule is created we can then go to the internal firewall and start creating the relevant rule. To do this; simply follow the same as above with a few changes:

Notice this time we will be selecting the "SharePoint Site Publishing" option. This is because this firewall has access to the domain and can see the actual SharePoint servers this allows us to use this rule properly.

We will publish a single site as before.

Now when we come to map the URLs we need to use the internal URL instead of the external one we specified on the other server. Also we need to ensure that we point it to the correct IP address which in this case would be the VIP or Virtual IP Address that is used by the Load Balanced web front ends. This could be a single server IP Address if you don't have NLB Servers.

When it comes to the accepting the incoming traffic, remember that the other firewall will be presenting the external address not the internal address we specified above. We need to ensure that this rule will accept the external URL and translate it to the internal server we need to access.

As before we need to create another "HTTP Listener" that is slightly different to the previous one we created. This is due primarily to the authentication settings.

Notice here we are telling ISA to use HTML Forms as the authentication and this is liked to our Active Directory. This should then present us with an Outlook Web Access (OWA) like login screen when accessed.

The internal servers are running Kerberos from end-to-end. This includes all of the MOSS2007 servers and the SQL Servers. To facilitate this from ISA we are going to specify that "Negotiate (Kerberos/NTLM)" is used as part of the authentication delegation. We are also going to specify what the Service Principle Name (SPN) should be when passing credentials to the internal servers.

And finally the last option, Alternate Access Mappings (AAM) needs to be configured within MOSS2007 or WSS 3.0 for this to work. I won't explain how this needs to be done as this is well documented. If you need any help on this topic let me know. J

So now we have our rules in place the steps that take place before you login are:

1. External URL hits the outside interface of the External Firewall
2. HTTP Listener and ISA Rule accept the request for http://www.mywebsite.com
3. This request if sent to the outside interface of the Internal Firewall
4. Internal Firewall Listener accepts this request
5. Internal Firewall sends back an authentication request via the Forms Authentication method
6. User then adds credentials which are passed back via the ISA server using Kerberos Delegation to the MOSS2007 server
7. MOSS2007 is then presented to the user

The login screen looks as below:

Once logged in the site should load as normal. If you look at the "Welcome" web part it should show your logged in name as shown below:

As you can see using ISA Server as the front server for your SharePoint infrastructure you are able to securely present this to your users. In the real solution there are some minor changes such as not publishing to the internal server but to "DMZ" versions of the internal servers and using port based controls to the SQL Databases as well as IPSec policies.