Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I am using SharePoint 2010 Server.

I am trying to understand (and test out) all the various options for using different authentication sources for internal and external users on a site that can be considered an "extranet".

It is similar to the "PartnerWeb" discussed here: http://technet.microsoft.com/en-us/library/cc262350.aspx#section6

I want to allow internal company users, customers, and other companies we are teaming with to access and collaborate in a site collection and allow varying levels of access (including no access) to some sites, list, libraries, pages, etc.

One of the current architectures I am leaning towards, has internal users being authenticated using the internal Active Directory and the external users being authenticated using an external source (an external AD, SQL accounts, or something like Windows Live, etc).

SP 2010 supports multiple Authentication sources per zone. So, unlike SP 2007, I can configure the one web app to use two separate sources of authentication without extending the web app into a second zone and creating a second URL for the the site.

My question is... is there any reason I would WANT to extend it to another zone? The permissions control at the zone level seems very high level (allow anonymous, read-only, etc) and it seems like for my use case I would have to configure permissions at a lower level anyway. (i.e. I could not specify for a site to "don't let anyone from the extranet zone see any content on just this site). I don't want to have anonymous access for the whole site and I want external users to be able to contribute (discussions, etc) and not have read-only access.

So although I can set up another URL (alternate access mapping) for external users, I am having trouble understanding how I would actually use that information within my sites to grant/deny access.

Update I did just see something in another thread, that points out that using two separate zones (and URLs) for the web app with two authentication sources will eliminate the drop down menu you get when you have multiple authentication sources configured on a single zone. I have been assuming I would be able to change that default login page and add some logic to it to prevent that without having to extend to another zone just to achieve the elimination of the drop down. I planned to have a more branded looking FBA page anyway.

sp login drop down

share|improve this question
    
I'm not 100% correct on how to word it, but a good scenario for extending a web app is public internet facing sites, one zone for anon and one for the content authors using windows auth. –  James Love Mar 7 '12 at 21:05
    
@JamesLove , yeah, the non-granular (all or none) type controls make sense for that use case. I am trying to understand if there is any reason or value to extending web apps in other, more collaborative situations in 2010. –  lwbecker2 Mar 7 '12 at 21:23
    
For collab? Good question, I'll find someone who should be able to shed some light.. –  James Love Mar 7 '12 at 21:25
add comment

1 Answer 1

It sounds as though you understand the concept of Web app extension so there isn't too much I can add really.

Something that hasn't been mentioned is the fact that extension creates an additional IIS site. You may wish to configure this site in a different manner to the original, e.g. configure an SSL certificate for access over the Internet or change logging settings. This doesn't necessarily mean a public facing Web site - it could mean users in another geographic location accessing the farm remotely.

Also, to expand a point that you have mentioned, I would consider it "cleaner" to provide additional URLs through Web app extension rather than simply sticking another AAM entry in manually via central admin.

IMO in practice, Web app extension from SP2010 onwards is something that will be used as an afterthought for intranet deployments that need to be exposed with a FQDN as opposed to the "http://sharepoint" type URLs that are commonly assigned initially. Personally I will be ensuring that our Web apps are created with a FQDN from the off.

I hope that is of some use.

EDIT I should add that using a non-FQDN URL for the default zone is not generally a good idea. The default zone should be the "most available" as administrative emails are sent with links from the default zone and you might otherwise end up with a scenario where external users are attempting to access your farm using a URL that is only available internally.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.