Overriding the Authentication Provider Selection Page

In the first part of this series, we saw how we register and configure our SharePoint site to use Windows Live ID as an authentication provider.

Right now our site has two authentication providers, Windows authentication and Windows Live authentication. When you click the Sign in button, SharePoint will display a page giving you a chance to select the authentication provider you would like to use. 

Displaying such a page for the public website users would confuse the users, and also would be a security threat. The desired behavior would be to redirect the public users to Windows Live authentication page, and allow administrators to selectively display the SharePoint authentication provider selection page when they need to login using their Windows credentials.

To achieve this, we have to override the default selection page.

1. Make a backup copy of the default.aspx file in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IDENTITYMODEL\LOGIN folder.

2. In Microsoft Visual Studio, create a Windows Class Library project.

3. Add references to System.Web, Microsoft.SharePoint.dll, and Microsoft.SharePoint.IdentityModel.dll. The identity model assembly is in the global assembly cache. Therefore, I had to get a copy and place it in the root of my drive to add my references. For a suggestion about how to find and copy the assembly, see the blog post Writing A Custom Forms Login Page for SharePoint 2010 Part 1.

4. Strong name the assembly that you are creating, because you will place it the global assembly cache later.

5. Add a new ASPX page to your project. Copy a page from an existing ASP.NET web application project; copy the .aspx, .aspx.cs, and .aspx.designer.cs files all at the same time. Remember, in this case we want a file that is named "default.aspx", and it will be easier if there is no code written in it yet and there is minimal markup in the page.

6. In the code-behind file (.aspx.cs file), change the namespace to match the namespace of your current project.

7. Change the class so that it inherits from Microsoft.SharePoint.IdentityModel.Pages.MultiLogonPage.

8. Override the OnLoad event. When a user hits a site that has multiple authentication providers enabled, the user is first sent to the /_login/default.aspx page (the page described in step 1). On that page, a user selects which authentication provider to use and then the user is redirected to the correct page to authenticate. In this scenario, we always want to redirect the user to Windows Live authentication page. The easiest way to find the Windows Live Login URL is to choose Windows Live ID authentication from the authentication provider selection page, and then copying the URL that you were redirected to.  An example would be as follows

https://login.live-int.com/login.srf?wa=wsignin1.0&wtrealm=urn%3acontososharepoint%3aint&wctx=https%3a%2f%2fcontoso.com%2f_layouts%2fAuthenticate.aspx%3fSource%3d%252F&

If you step through a typical login process, the following steps occur:

a. You are first redirected to /_login/default.aspx.

b. You make your authentication provider selection.

c. You post back to /_login/default.aspx.

d. You are redirected to the correct login page.

On the page load event of the login page, we redirect to the Windows Live login page. Custom logic can be added which would display the authentication provider page in case a different authentication provider is needed. For example, administrators would like to use Windows authentication instead.

In this series of post I will talk about how to allow Windows Live users to login to an internet facing SharePoint 2010 site. Most of the information can be found online, but I am putting them here in a form of a series to make it easy for who ever wants to implement the integration to find the information easily.

The first part of the series would be how to register and configure the site to use Windows Live ID as an authentication provider.

Registering with Windows Live ID

To use Windows Live ID authentication, the site should be registered first using the Microsoft Service Manager web application located at http://msm.live.com. Below are the steps needed to register the website for Windows Live ID Authentication

1. In your browser, browse to http://msm.live.com

2. Login to the website using an already registered Windows Live ID. This Windows Live ID will be the main ID that will be used to manage the Windows Live ID registration.

3. In the left menu, click on Register Your Site

4. A page will open where you need to enter the name of the site and the DNS Name

5. Choose Windows Live ID

6. Click Submit

7. On the confirmation page, click Yes.

8. The below screen will appear

9. Click on Go to Manage your Site link.

10. In the drop-down list, select the site that was just registered and the click on Modify Editable Site Properties

 

11. In the next screen, check the Show advanced properties check box to enable more options
 

12. Enter the values in the fields that appear on the screen (Replace the below with your own domain)
Domain Name: contoso.com
DNS Name: urn:contososharepoint:int
Default Return URL: https://contoso.com/_trust/default.aspx
Expire Cookie URL: https://contoso.com/wlid/expirecookie.aspx

13. Scroll down until you see the Override Authentication Policy. Select MBI_FED_SSL from the dropdown.

14. Scroll up to the page and click the Submit button.

15. On the next screen, note down all the information on the screen, and then click the Yes button.

 

Certificates

Claims based authentication uses certificates for encryption and signing and we have to trust the certificate of the IP on the SharePoint servers. The following steps must be done on all WFE's in the farm.

1. To get the IP Certificate, browse to the federation metadata URL
https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml

2. Select and copy the text from the first X509Certificate node

3. Make sure to select only the inner text, excluding the <X509Certificate></X509Certificate> tags.

4. Open Notepad application, paste the text and then save the file as LiveID-INT.cer. We now have the certificate in a file and we need to import it to the correct locations on the SharePoint Servers.

5. On the WFE server, press Window Key + R on the keyboard and then type mmc.exe and press enter to open up the management console.

6. Add the Certificates snap-in to the management console. Choose Computer Account to manage and then select to use the Local Computer as computer to manage

7. Expand the tree until your reach SharePoint > Certificates. Right click on the node and select All Tasks > Import…

8. In the import wizard, locate the LiveID-int.cer file we just created and then click Next > Next > Finish.

9. Repeat same procedure above to import the certificate to the Trusted Root Certificate Authority and Trusted People.

10. These procedures should be done on all WFE servers.

 

Create the STS Provider in SharePoint 2010

We need to create a Trusted Identity Token Issuer in SharePoint which will be configured to be used as the login provider for our Web Application.

1. On one of the SharePoint servers, fire up the Powershell console.

2. Execute the below powershell script

1: asnp microsoft.sharepoint.powershell 2: $realm = "urn:contososharepoint:int" 3: $certfile = "C:\Temp\LiveID-INT.cer" 4: $rootcert = Get-PfxCertificate $certfile 5: New-SPTrustedRootAuthority "Live ID INT Root Authority" -Certificate $rootcert 6: $emailclaim = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "http://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming 7: $upnclaim = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn 8: $authp = New-SPTrustedIdentityTokenIssuer -Name "LiveID INT" -Description "LiveID INT" -Realm $realm -ImportTrustCertificate $certfile -ClaimsMappings $emailclaim,$upnclaim -SignInUrl "https://login.live-int.com/login.srf" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"

3. After running the script, verify that the script executed correctly by going to Central Administration > Security > Manage Trust.

 

Create the Web Application

1. From Central Administration, go to Application Management > Manage Web Applications.

2. Click on Create a new Web Application

3. In the Create New Web Application page, choose Claims Based Authentication from Authentication providers list.

4. Choose Create a new IIS website. Use the following values to fill the IIS Web Site fields (Replace the below with values that correspond to your website)
Name: Contoso Public Portal
Port: 443
Host Header: contoso.com

5. Under Security Configuration, select Yes under Use Secure Sockets Layer (SSL)

6. Under Claims Authentication Types, check the Trusted Identity provider checkbox

7. Check the LiveID INT checkbox from the list

8. Click on Create Web Application button.

After following the above steps, your web application will be ready to authenticate against Windows Live ID.

In my previous post, we’ve seen how we can configure shared configuration for multiple IIS servers in a farm. We used a shared folder on one of the servers to save the configuration, and pointed the rest of the IIS servers to that folder.

The problem with this approach is that, if the server on which the shared folder resides goes down, the rest of the IIS servers will go down as well, since they will loose access to the configuration files.

There are multiple ways to tackle this issue, the most common being putting the configuration files on a highly available storage device, like a SAN. While this solves the problem, it adds costs and complexity to the farm.

Another solution is to make use of a Windows feature called Offline Files. Offline Files allows you to have the content of a UNC share available even if the share is not accessible.

To enable offline files on Windows Server 2008 R2, you have to do the following

First thing that needs to be done is to install the Desktop Experience feature

1. Open the Server Manager, click on Features, and then click on Add Features

2. Select Desktop Experience from the list of features, and then click Next. If it asks to add required features, click the Add Required Features button.

3. Click the Install button on the next screen.

4. After the install process finishes, restart the server.

5. After the server starts, open the control panel, and search for offline.

6. Click on Manage Offline Files. A window will open as seen below

7. Click on Enable Offline files button, and then click on the Ok button. The server will have to restart.

8. One the server restarts, open Windows Explorer and browse to the server hosting the shared folder.

9. Right click on the shared folder and click on Always available offline

10. Open the Control Panel if its not open and search for offline.

11. Click on Sync Center. In the window that opens, select Offline Files

 

12. Click on Schedule.

13. Choose the shared configuration folder that we just made available offline and click next.

14. In the next screen, choose the At a scheduled time option

15. In the next screen, choose the interval with which you want the sync to happen. It can go down to minutes if required. Click the Next button

16. Give a name to the schedule and then click Save schedule button.

 

After completing the above steps, you will have a shared folder that is available even if the host server goes down. This will give you some time to recover the failed server without bringing the whole farm down.

Making a website highly available requires that it gets deployed on multiple servers so that if one server fails for some reason, the other servers can still serve the website for the users. This setup is usually called a server farm.

On IIS 7, each website requires a set of configuration on the webserver for it function, like application pool configuration, host header configuration, security configuration, etc. Having multiple web servers means that these configuration should always be kept in sync on all servers, which requires effort.

IIS 7 includes a feature which makes this task easier. IIS 7 includes what is called Shared Configuration. IIS configuration can be shared by multiple servers, which means changing the configuration on one server will automatically change the configuration on the other servers in the farm.

Below are the steps required to configure Shared Configuration on multiple IIS servers.

We assume here that we have two servers in the farm. Lets call them Server1 and Server2

1. On Server1, open IIS manager, click on the server name in the Connections pane on the right. You will see the IIS server features on the left.

2. If you can’t see the Management section, scroll down. You will see the Shared Configuration icon in that section.

3. Double click on the Shared Configuration icon to open the settings screen

4. In the Actions pane, click on Export Configuration. This will open up the Export Configuration dialog box

5. In the Physical path text box, enter the path where you want the configuration to be saved. Enter a password for the encryption key. This will be saved a long with the configuration files.

6. Click the Ok button to do the export.

7. In the Shared Configuration properties, check the Enable shared configuration checkbox.

8. In the Physical Path text box, enter the path where you saved the exported configuration files.

9. In the User name and Password text boxes, enter the username and password of a user that has read/write access to the shared folder.

10. In the Actions pane, click the Apply button. When you do so, a dialog box will appear asking you to provide the encryption key password that you set when you exported the configuration.

11. Enter the password and click the Ok button. With this step you have exported the configuration files, and configured Server1 to used the shared configuration files.

12. Now you need to make the shared configuration folder accessible to all other servers in the farm. To do so you need to share the folder and give other servers access to it.

13. Perform steps 7 to 11 on Server2, but this time providing the UNC path of the Shared Configuration folder.

 

In previous posts , we have configured windows cluster, SQL cluster, and NLB for the WFE servers.

Part 1 - Prepare Windows Cluster

Part 2 - Install and configure SQL Cluster

Part 3 - Install and Configure NLB on WFE

In this post we will perform a farm installation and configuration to meet 3-tier farm topology described as shown in above figure

1- Make sure all servers have internet connectivity

2- Turn off firewall on all Application and web front end servers

3- Install windows updates on all servers.

4- Add the following Roles on each server

• IIS Role
• Application Server

5- Run SharePoint installation setup on all servers (except the db servers), start with App Server and configure Central administration there , then continue with WFEs as below.

6- run the default.hta –> prerequisites installer

7- The setup will run the following:

8- After pre requisites installation complete , run SharePoint setup:

9- enter SharePoint key

10- Make sure to select Server Farm as we are installing SharePoint on multiple servers for scalability, click next

11- Make sure to select complete, as standalone installation will install SharePoint under SQL Express

12- Determine the installation path, and Data index files path (these index files will save index information regarding search, application server will push the index files regularly to the below location. Index files helps the WFE to find search queries and post search index result to the Search crawler to get the result faster.

13- After installation , we need to run the configuration wizard , this wizard should be executed first on the Application server, where SharePoint Central Administration going to be hosted

14- On application Server, run the configuration wizard, and select New Farm option, since this App server is the first farm in the farm.

15- Select the Cluster SQL instance name (created in Part2 of this series), the SharePoint admin account (SPSadmin) should be admin on database server.

Note: the SQL instance name above is abstracted from the windows cluster as below: (Refer to Post Part 1 &2)

16- Enter a Passphrase, make sure to save this password in some reachable place, this password is needed when ever a new server is going to be joined to the farm: 

17- Select some port to host the Central Administration web application

18- Review summary page, the click Next

19- The Central Administration URL is: http://[AppServerName]:100/

20- Open Central Administration run the Configuration wizard to configure SharePoint service applications:

Note: in more advanced scenarios you can create service applications one by one manually as per the farm requirements., in this post we will walk through creating the service applications as per the default settings

21- Check the services you need for this Farm, to create the required Service Applications:

22- Skip the Web application creation step ,as you want to create the web application on WFE NLB servers not on application server

Note : we will perform some additional configurations for the service applications in more details once we finish the installation for the rest of servers.

23- Now go to WFE Servers , Run Configuration wizard on both WFE servers selecting now the Join Farm option (not create new farm)., make sure to select Connect to existing farm

24- Enter the SQL Instance Cluster name, then press on Retrieve Database names

25- Make sure to supply the passphrase you entered previously while creating the farm on the application server

26- In the summary page , you can click on the advanced option to make sure that the WFE servers are not used to host the Central Administration Web Application (as its hosted on Application server only), then Click next:

 

 

Configure SharePoint Farm Server Roles

now we have installed and configured  SharePoint on all servers , we need to configure one of them as App server, and two of them as WFE servers, actually there is no dedicated configuration page to identify the server Roles explicitly ,alternatively the process of identifying the server roles is much dynamic and yet advanced, the trick here is that you identify the server role through the Manage Services page by identifying the appropriate services on each server, as below:

1. Open Central Administration

2. Click on Manage Service on the farm and make sure to perform the following

 

• WFE Servers should have the following services started on it to serve users requests only and to act optionally as query indexers for the search,  this is why we stated the search services but in a later step we will eliminate the search role here to act as query indexer only.

Note: the most important service to be started on WFE servers to identify them as WFE is Microsoft SharePoint Foundation web application

when starting the Search service for the first time , you might be prompted to configure the search service as below:

 

 

• Application server should have all the required services started on it, as below (some services are intentionally stopped as they are not needed in this farm

Note:  Microsoft SharePoint Foundation web application Service is stopped here

 

 

Search Service Topology configuration

in this section we will identify the search service role on each server, its true that the application server should be responsible for Search , but some components need to be there on WFE servers to handle search queries by client.

As a best practice, its better to install search components on the Web and application tiers in order to optimize performance by distributing the load placed on the servers in the farm. To distribute search components across the farm tiers, you must follow these steps:

• Move the query components to the Web tier
• Move the Crawl components to the App tier
• Keep the Database components to run on SQL Server.

Search is complicated enough that it has its own topology configuration settings. The services that need to be tuned are:

• Search Query and site settings
• SharePoint Server Search

You can use a special configuration page to place the query functionality on the WFE and to place the crawling\indexing functionality on the Application Server.

1. Defining the Search Topology, Go to Manage Service Application to configure the Search Topology , click on Search Service Application.

Click modify and make sure to have the following :

• App Server : change its role to be Crawler , click on the default Crawl component and change it to be assigned to application server.
• WFE Server: change its role to be Indexer, click the default Query component –> add mirror.

after you finish press on Apply topology

2. Click on content sources on the left menu –> click on the Scope you want to schedule:

3. Scroll down to Crawl Schedule –> create schedule

4. For low search latency and instant search crawling , The configuration is set is the below , which can be changed later on for by the admin as needed

• Full Crawl setting:

• Incremental crawl settings:

Note: the above configuration is set to run a full crawl once every night , and to run an incremental crawl every 5 minutes for 24 hours, the interval may vary incase no dedicated application server is there for search.

 

Create your First Intranet Web Application in the Farm

in this step we will be creating our intranet web application on the NLB URL

1. Go to Central Administration , click manage web applications

2. Create new web application (with NLB considerations) as the following:

Make sure to supply the NLB cluster name in the host header (created in post 3 of this series) , and proper Content database name, this content database will contain the intranet content (documents, lists, etc…

3. After Web application is created, create a site collection as the following:

note how the URL is appearing using the NLB cluster name instead of server name, this is because of the host record we supplied in the previous step.

note: make sure that your NLB cluster name and IP are added as host record to the Active Directory. 

 

Configure Alternate Access Mapping

In some situations users might need to request to have an easy name for the portal so when ever they want to access the portal, it will be easy to memorize it and type in the URL (e.g. myPortal)

1. Go to Central Administration –> Application management –> Configure Alternate Access Mapping

2. Press on edit public URLs

3. Add a new alternate access mapping

make sure to supply the name that you want users to use when accessing the portal (e.g. myPortal), this URL is then resolved to the NLB cluster URL automatically because of this configuration of this configuration we are doing now.

4. Add binding to the web application at the IIS

5. make sure to add “myPortal” as a host record to the AD