How to publish your intranet in a Microsoft® environment

I don't know if anybody is waiting for this post; seems pretty straightforward. Yet I've seen a lot of organizations struggle with authentication, proxy servers, name resolution, and other issues when they publish an intranet site or -application.

Here's a typical scenario:

• Client computers are members of an Active Directory domain, for example 'mydomain.local. The internal DNS domain name is 'mydomain.local'.
• The new intranet site should be published on Server01, an internal web server running IIS.
• A DNS A record exists for Server01, either in the 'mydomain.local' domain or in another one. Hence the Fully Qualified Domain Name of the web server is server01.mydomain.local, but it can also belong to a sub-domain, such as server01.resources.mydomain.local, or even in a separate domain like server01.servers.local. It doesn't matter as long as the FQDN of the server can be resolved from the workstations.
• The name of the new site will be 'intranet' (but it could also be 'wiki', 'blogs', or anything else). Its FQDN will be 'intranet.mydomain.local'.
• Windows Integrated Authentication will be used on the intranet site, which means users need to authenticate with the same credentials they use to logon to the Active Directory.

Internet Explorer, DNS , IIS, and Proxy, all need to be configured correctly for this to work. But as we will see this scenario works perfectly with default settings:

• First there's the DNS configuration of the workstation. By default, Windows is configured to "Append parent suffixes of the primary DNS suffix".

  

  In our example this means that Windows will automatically append 'mydomain.local' when the user types in 'intranet' in the address bar of the browser, and send a query for 'intranet.mydomain.com' to the DNS server.

  In more complex environments with multiple domains the DNS client is often configured to Append a manually entered list of DNS suffixes. This works fine too. In our scenario above, 'resources.mydomain.local', or 'servers.local' should be in the list of suffixes for workstations to find Server01.

  The important thing is that the client is configured to automatically append suffixes, because this works perfectly with the default Internet Explorer configuration.

• Internet Explorer by default is configured to logon automatically in the Intranet zone.

  

  The way IE identifies the Intranet Zone is important here. In KB174360 we read "By default, the Local Intranet Zone contains all network connections that were established by a Universal Naming Convention (UNC) path, and Web sites that bypass the proxy server or have names that do not include periods (for example http://local)".

  That's interesting. This means that if I only type in "http://intranet" or "intranet" in the address field of my browser, IE will automatically identify this as a site belonging to the Local Intranet Zone and pass my logon credentials to the server. There's no need to manually add the site to the Local Intranet zone.

• By the way, the "Bypass Proxy Server for local address" setting in IE Connection settings uses the same logic. It won't work unless you use host names instead of FQDNs. Cfr. KB262981. If you specified a Proxy server in your users' default IE configuration, better check this flag too.

  

That said, here's what we need to do to publish our intranet site in this scenario:

IIS

• Create a new web site in IIS on Server01. Name it whatever is convenient to you. The internal name is not as important as the bindings.

• Bind the site to host name "intranet". You can also create a binding to FQDN "intranet.mydomain.local" but make sure a binding also exists for just the host name.
  There is no need to give the site a dedicated IP address or a custom Port to distinguish it from other sites. Already since version 4.0 IIS can distinguish sites by IP address, by Port, or by Host Name.
  
  Figures 4 and 5 show this setting in IIS 6.0 and IIS7 respectively:

  

  

• Configure the site for Windows Integrated Authentication.

DNS

• Add a CNAME called "intranet" to zone "mydomain.com". Have it point at the FQDN of our web server, Server01.

That's it. All we have to do now is notify our users that they can find the new site at "http://intranet", or better yet: use a Group Policy to add it to their Favorites or set it as their home page. Here's what happens when they use this link:

• The DNS client appends the Primary DNS suffix -or a manually configured list of DNS suffixes- to the name, sending a query for "intranet.mydomain.local" to the DNS server.
• "intranet.mydomain.local" gets resolved to the IP address of Server01.
• IE identifies this as a Local Intranet site since we didn't include periods in the name. It passes the credentials of the locally logged on user together with the HTTP request to Server01, bypassing the proxy server.

Other approaches are possible, but I think this is the simplest and it works in most situations. There's no need to maintain a list of Local Intranet sites or Proxy Server exceptions, and it also works on dispersed networks where workstations reside on different subdomains (e.g. "europe.mydomain.local" or "sales.mydomain.local"). To move the intranet site to another server you only need to change the CNAME DNS record for "intranet".

Neat ;)

flip