Microsoft Office Tutorials and References
In Depth Information
The default zone users are those in the local office. Their web application doesn’t need SSL,
they may be allowed anonymous access (to read their co-workers’ blogs), and using the server’s
computer name as the URL is fine. The intranet users could be the ones in adjoining buildings,
maybe part of the campus, but not in the office; they should authenticate to access the site
collections they are members of, and they need to use a URL that resolves outside of the office. The
extranet could be the commuting users, accessing content over the Internet; they too need to
use an external URL and authenticate to access their content, but they also need SSL to protect
their transactions. Finally, Internet users could be customers or partners also accessing the web
application’s content over the Internet, while requiring anonymous access and SSL. To access
the same data by a different URL but apply different security and access settings, you need to
use different IIS Web Sites pointing to the same content databases. Then the users can access the
same information but use different URLs, with different security applied. Zones can be used
just to use different URLs to resolve to the same web application, but what they’re really used
for is extended web applications, whose addresses are zones and are used to access the same
web application’s content but use different URLs and other IIS Web Site settings (such as
requiring SSL or allowing anonymous).
Notice that anonymous access is being offered to certain kinds of users depending on the zone they
are using to access the same web application. That is why, even though anonymous access can be
enabled at the web application level, it is additionally allowed or disallowed at the site collection
level. Those site collections meant to contain private company data would never enable
anonymous on any site, list, or library therein, despite the option being available depending on what URL
accesses the site collections.
To create a new, public URL for accessing a web application using different security settings
than the original, that web application needs to be extended to a different IIS Web Site. As you
know from creating a new web application, the IIS Web Site determines the URL for the web
application, either by setting a custom port for the main URL (such as http://spf2:8080) or by
using a host header to give the web application a custom URL (such as http://tech.dem0tek
.com). The IIS Web Site also determines which kind of authentication is to be used (NTLM,
Kerberos, allowing anonymous access) and if SSL is going to be used.
Extending a web application creates a new IIS Web Site based on an existing web
application’s content. This new IIS Web Site uses the same application pool and the same content
database as the existing web application. But extending a web application lets you add another URL
and other IIS Web Site–based settings to access that content. This allows you to create a new
public URL for the web application and adjust the security settings for that public URL without
changing the existing security settings for your web application’s default public URL.
For the example, we can take the blogging site collection, running in the web application
http://spf2:8080, and extend it to the public URL of blogs.dem0tek.com, which, in this
example, is accessible from the outside world through the firewall. While we’re at it, we can
set the new URL so that it doesn’t permit anonymous access. This way, only people with login
accounts (the company’s employees) will be able to access the blogs from outside the firewall.
The default, internal URL settings (for http://spf2:8080) will stay the same, and anonymous
access will be permitted there.