Microsoft Office Tutorials and References
In Depth Information
down the AD users qualified for access. For example, if the user field for department were
filled out in AD, you could customize the authentication to include an added filter of all
people in a certain department who can authenticate, but others can’t. It takes considerable
customization, but it can be done. Otherwise, Claims-based authentication can simply be
configured to use Windows Authentication, with the added bonus of supporting more than
one authentication method, such as NTLM and Kerberos.
You cannot select Classic as the type of authentication for the web application and then try
to do forms-based, either on that web application or any of its extended web applications. If
you are planning on using forms-based authentication for a web application’s extended web
application, make sure the original web application is using claims-based (even if you are
actually going to select NTLM as the authentication method for that one).
Self-Service Site Creation Ironically, the Self-Service Site Creation setting doesn’t actually
give users the ability to create their own sites—it gives them the ability to create site collections .
For this reason, this setting is a bit misnamed. The web application set to enable Self-Service Site
Creation allows users to create their own site collections, with all the autonomy that implies.
The settings box for this link has only three settings in the Enable Self-Service Site Creation
section: On or Off (the default) and Require Secondary Contact (which is always a good idea).
See Chapter 10 for more on self-service site creation. This setting is one of those that is also
listed elsewhere in Central Administration and opens in a page of its own (if you prefer pages
to boxes) under Security General Security Configure Self-Service Site Creation.
THE SHARED HOST NAME WARNING
At the top of the Self-Service Site Creation page you’ll see the warning “Self-Service Site Creation
will create sites under a shared host name.” What does that mean?
When you enable Self-Service Site Creation, it lets users create their own site collections in a web
application. They will all be located in the same web application and therefore use the same base
address, like http://spf2/sites. So, user 1 and user 2 will have their site collection addresses
at http://spf2/sites/user1 and http://spf2/sites/user2. These addresses are basically
sharing their “host name” or host web application’s root URL. Because of this, if user 1 gives user
2 read permission to their site and user 2 opens a file from user 1’s site in the browser that has a
dangerous script in it, that script will run in user 2’s account context and cause damage.
Of course, this can happen to anyone on any site. But IE is supposed to help avoid “cross-site scr
ipting” exploits. As far as it’s concerned, both user 1 and user 2’s sites are just pages in the same
website, so to speak. And since http://spf2 is a trusted site, then it doesn’t do any cross-site script
blocking of the two user site collections, apparently.
To avoid the possible yelling and screaming from administrators, Microsoft displays the warning in
the Self-Service Site Creation form, with a link to an online document about the issue. It is also why
Browser Handling in General Settings is set by default as Strict, so even if user 2 did click a
dangerous script in user 1’s site, it would prompt to download rather than running (although, wouldn’t
that endanger user 2 if they ran it locally anyway?).
So, now you know what that warning means, and you have a better idea whether you should allow
self-service site creation in your environment. For me, the fact that users can make as many site
collections in the web application as they want, all with a full site collection’s quota, gives me more
pause than shared host names.