email

I wrote this some time ago but never got around to blogging it.  Much of the content is similar to information already out there but I think there is enough that is different to still warrant a quick blog... In particular I'd like to thank ANdrew Connel for his excellent post on th esame subject, much of which is replicated here.  Between Andrew Connels post and others I've picked out all the best bits and added steps in where I felt a stupid person (me) might go wrong!

The Small to Medium Business (SMB) market is large. Microsoft Office SharePoint Server 2007 (MOSS 2007) is taking a foothold. SMBs, especially those that make use of the old Microsoft Content Management Server (CMS) product which is now encompassed in MOSS 2007 and not available as a separate product, will increasing be looking to MOSS 2007 as a natural progression. These smaller businesses are looking to deploy a single MOSS 2007 server farm to provide access:

· internally, as an intranet replacement

· externally with partners, as an extranet

· and increasingly as their public facing internet site.

To an IT company used to working with some of the largest businesses in the world this may seem like a bad idea – employees, partners and the public all using the same server, all accessing the same data. Security wise too, although users only have access to what their credentials allow and content is protected by Access Control Lists (ACLs) there are obvious implications for a breech in security. However, for SMBs this may be deemed an acceptable situation, especially when considered alongside the financial savings of reduced licenses (multiple products superseded by MOSS 2007 new functionality), reduced servers...

Of course this is a hypothetical scenario and there may be many more legitimate reasons why a customer may want multiple access methods for a single MOSS 2007 implementation.

So, how would we go about setting up MOSS 2007 to allow this? Let’s take our hypothetical case and configure a solution. Firstly let’s look at intranet users and make the assumption that we are working with a Microsoft based architecture using Active Directory (AD) as their directory services model. Next we need partners to be able to access the MOSS 2007 server but let’s assume that the client has a great many partners and doesn’t want to allocate them each an AD account on their domain, even if that account were locked down. Architecturally, the most obvious solution is Forms Based Authentication (FBA) using a role and membership provider to allocate and authenticate credentials. And finally let’s supply internet users with anonymous access to the server. Of course, we will have planned the security groups within which the access accorded to each of our types of user (intranet, extranet, internet) is restricted and have strict governance of how and when access is granted between these groups. So an internet user may have access to published pages but not to the collaborative working areas of the site. Extranet users may only have access to dedicated partner sites in which they have been explicitly granted access and any general partner sites. Intranet users will have access to general staff areas an any site explicitly granted to them.

So we have 3 authentication methods:

1. NTLM through AD – intranet

2. Forms Based Authentication – extranet

3. Anonymous access - internet

To demonstrate this scenario I have used a simple single server installation of MOSS 2007 on a Virtual PC (VPC) image. The steps that follow describe the exact settings you will need to prove this concept. You would obviously not use SQL Express in a production environment, however there is little consideration in using it for test purposes. However for the purposes of illustration the following achieves our goal:

We need a data store in which to hold our membership profiles and roles:

1) Install SQL Express

a. Create a DB called: Users_and_Roles

b. Use LocalSystem account and mixed mode authentication

c. Accept default throughout the rest of the install

Now that we’ve created the database we will need to create a membership and role provider. Fortunately Visual Studio will do this for us. This is unlikely to be extensive enough for a live implementation but is perfectly suitable to demonstrate this process:

2) Create a new Web site project in Visual Studio 2005 to add users

a. Open Visual Studio 2005 and select File -> New -> Web Site

b. Select ASP.NET Web Site

c. Right click the project in “solution explorer”

d. Add a new item -> choose Web Config File

i. Alter the configuration tag to represent:

<connectionStrings>

<add name="ConnectionString"

connectionString="server=HP_SERVER

;database=Users_and_Roles;Integrated Security=SSPI;"

providerName="System.Data.SqlClient"/>

</connectionStrings>

Figure 1: Connection String

ii. And within the system.web tag add the following

<!-- membership provider -->

<membership defaultProvider="AcAspNetSqlMembershipProvider">

<providers>

<add name="AcAspNetSqlMembershipProvider"

type="System.Web.Security.SqlMembershipProvider,

System.Web, Version=2.0.0.0, Culture=neutral,

PublicKeyToken=b03f5f7f11d50a3a"

connectionStringName="ConnectionString"

enablePasswordRetrieval="false"

enablePasswordReset="true"

requiresQuestionAndAnswer="false"

applicationName="/"

requiresUniqueEmail="false"

passwordFormat="Hashed"

maxInvalidPasswordAttempts="5"

minRequiredPasswordLength="1"

minRequiredNonalphanumericCharacters="0"

passwordAttemptWindow="10"

passwordStrengthRegularExpression=""/>

</providers>

</membership>

<!-- role provider -->

<roleManager enabled="true"

defaultProvider="AcAspNetSqlRoleProvider">

<providers>

<add name="AcAspNetSqlRoleProvider"

type="System.Web.Security.SqlRoleProvider,

System.Web, Version=2.0.0.0, Culture=neutral,

PublicKeyToken=b03f5f7f11d50a3a"

connectionStringName="ConnectionString"

applicationName="/" />

</providers>

</roleManager>

Figure 2: Role and Membership Providers

e. Go to the website menu and select configure asp.net

f. Click security, choose authentication type -> “from the internet”

g. Create a users and a roles

h. Add users to roles

That’s it for the profile store! Now what we need to do is create the MOSS 2007 sites that we’ll use to prove authentication against. Using host header allows us to specify multiple web applications pointing to the same content. Each web application will have a unique identifier and will be associated with a security zone (internet, extranet, intranet...). The following steps will create a single MOSS 2007 site with two entry points – connect and connectXtra, the intranet and extranet respectively:

3) In Central Admin:

a. Create the intranet site...Application Management -> Create or Extend Web Application > Create

i. Set the Description

ii. Set the Port [80]

iii. Set the Host Header to [connect ]

iv. Pick NTLM as the Authentication Provider

v. Specify Anonymous Access to No

b. Click the hyperlink, Create Site Collection

c. Enter values as appropriate, for the test I used the publishing template

4) Back in Central Admin

a. Create the extranet site...Application Management -> Create or Extend Web Application > Extend

i. Set the Description

ii. Set the Port [80]

iii. Set the Host Header to [connectXtra]

iv. Pick NTLM as the Authentication Provider (we’ll change this later)

v. Specify Anonymous Access to No (and this!)

vi. Set the Load Balanced URL Zone to [connectXtra]

vii. Set the zone to extranet

b. Go back to Application Management and choose Authentication providers

c. Click on the Windows authentication provider link and

i. Make sure anonymous access is ticked

ii. Change the authentication to Forms

iii. Add the following as the membership provider: AcAspNetSqlMembershipProvider

iv. Add the following as the role provider: AcAspNetSqlRoleProvider

v. Save

vi. Note: Disabling client integration will remove features which launch client applications. Some authentication mechanisms (such as Forms) don't work well with client applications. In this configuration, users will have to work on documents locally and upload their changes.

In your test environment you may not have access to the DNS server but in simple terms, to make the host headers work you will need to tell your environment how to resolve the host header names (connect and connectXtra)

5) Add the host headers to DNS / hosts file!

a. For DNS (if you have access) add resolvers for connect and connectXtra. They should both resolve to the IP address of your MOSS 2007 server.

b. If you don’t have access to the DNS server edit your hosts file to resolve the addresses.

i. Open the hosts file in notepad, this exists in the [C:\Windows\System32\drivers\etc] directory, assuming Windows is your OS directory.

ii. Make the changes to reflect the following

[MOSS Server IP Address] connect

[MOSS Server IP Address] connectXtra

We would now be able to access the site via either of the URLs http://connect or http://connectXtra but before we do, we should configure the portal to understand the membership and role provider we specified:

6) Modify the web.config files:

a. Open the web.config for the intranet site

i. You will find the web.config file in the c:\inetpub\wwwroot unless you have configured a different home directory location. The parent directory name should be similar to [80_connect]

b. Add the <connectionstrings> above immediately after the </SharePoint> tag

c. Add the <membership> and <roleManager> tags immediately after the <system.web> tag

d. Open the web.config for the extranet site

i. The parent directory name should be similar to [80_connectXtra]

e. Repeat steps 6b & 6c

f. Open the web.config for central admin

i. Open central admin and note the port number, the parent directory name should be similar to [port_number]

g. Repeat steps 6b & 6c but replace AcAspNetSqlRoleProvider with AspNetWindowsTokenRoleProvider

Now we’re ready to test our installation:

7) On the top level web site [connect]:

a. Add the user created in step 2g to the site

8) On the extranet web site [connectXtra]

a. Accessing the URL will redirect you to the login page

b. Log in

c. Verify access to the site

9) Adding anonymous access

a. Make the FBA user as admin

i. In central admin -> application management

ii. Select Policy for web application

iii. Select Add Users and add the user created in 2g with full control

b. Load the portal page [connectXtra] and login

c. The portal sites’ first page [connect] prompts you to enable anonymous access

i. Click the link

ii. For simplicity, select ‘entire web site’

d. You can now access the home page as an anonymous user (internet user)

10) You may now wish to experiment with creating sites and adding custom permissions, for example:

a. Create a site that only logged in NTLM authenticated or FBA users have access

b. Create a site that only NTLM authenticated users have access

c. Etc!

That’s it we now have 3 access mechanisms to the same MOSS 2007 portal.

· http://connect requiring NTLM challenge response credentials

· http://connectXtra either through anonymous access or by logging using FBA

We may wish to extend this further to give anonymous users an alternative URL via which to access the portal by extending the site again but in the internet zone this time. However this is a mute point and simple to implement in practice now that we have done the hard work!

---

Posted 07-04-2007 2:52 PM by Andrew Noon