Configure SharePoint

Contents
smas
 
Contents
 
 
 
2
 
 
 
Create Alternate Access Mappings
Alternate access mappings can direct users who request an external URL to a specific web application on your SharePoint servers. Create alternate access mappings between your external URLs and the web applications on your SharePoint servers.
The 
Single Sign On Agent for SharePoint
 uses proxy rules in a similar fashion. Users who authenticate through the 
Single Sign On Agent for SharePoint
 are redirected to the internal web application hosted in SharePoint.
 
Important!
 The proxy rules in the 
Single Sign On Agent for SharePoint
 must match the alternate access mappings for your SharePoint web application.
The following graphic describes how to create alternate access mappings:
Create Alternate Access Mappings
Create Alternate Access Mappings
Alternate Access Mappings
SharePoint central administration servers let you create alternate access mappings between external and internal URLs.
  • External URLs are those URLs that your customers, partners, or people outside of your organization access. For example, your customers and partners could log in to your network using www.sales.example.com.
  • Internal URLs correspond to the location of the web application in your SharePoint environment. For example, the login server that processes those requests could be named example.com.
An alternate access mapping creates an association in SharePoint between your external login URL and the login server in the back end. For example, the SharePoint server directs all the requests for www.sales.example.com to the example.com server and displays the sales/index.html page as shown in the following graphic:
Alternate Access Mapping Example
Alternate Access Mapping Example
Zones and Alternate Access Mappings
Alternate access mappings also support zones. Zones let you configure different access paths to a single web application on your SharePoint server. Creating alternate access mappings across different zones can accomplish the following goals:
  • Create different URLs for the same web application. For example, you could have one URL for external users and a different URL for internal users that both point to the same web application.
  • Allow customers read-only access to documents that are hosted on your SharePoint server, while granting full access to your employees.
  • Require secure (HTTPS) connections to a web application for external visitors, while allowing employee access to the web application using HTTP.
  • Index the content of your web application using the SharePoint search index (which requires NTLM access), while requiring another authentication method for users.
The following graphic describes how different zones permit different levels of access to the same document for external customers and internal employees:
Different Zones Allow Different Levels of Access
Different Zones Allow Different Levels of Access
The following graphic describes how multiple authentication methods apply to the same document by extending the associated web application to multiple zones:
Multiple Authentication Methods in Different Zones
Multiple Authentication Methods in Different Zones
To accommodate the SharePoint search index, the web application must be extended into one zone that uses NTLM authentication.
Obtain the Public and Internal URLs
The 
Single Sign On Agent for SharePoint
 runs on a proxy-server. The 
Single Sign On Agent for SharePoint
 forwards requests to the web applications in your SharePoint environment using proxy rules. These proxy rules direct traffic from the public URL (the server hosting 
Single Sign On Agent for SharePoint
) to your SharePoint web applications (the internal URLs).
For example, customers who access support.example.com are authenticated by the 
Single Sign On Agent for SharePoint
. Next the user is redirected to a SharePoint web application hosted on a server named support001.example.com. The web application serves 
the content
 from support001.example.com back to the user who requested the support.example.com page.
The following graphic describes the relationship between proxy rules and alternate access mappings from the previous example:
Relationship Between Proxy Rules and Alternate Access Mappings
Relationship Between Proxy Rules and Alternate Access Mappings
 
Follow these steps:
 
  1. Obtain the external URLs that are hosted on your 
    Single Sign On Agent for SharePoint
     server from your network administrator. In this scenario, the URL www.support.example.com is hosted on the 
    Single Sign On Agent for SharePoint
     server.
  2. Log in to the server hosting the 
    Single Sign On Agent for SharePoint
    .
  3. Create 
    a copy
     of the following file:
    Agent-for-SharePoint_home
    \proxy-engine\conf\proxyrules.xml
  4. Open the copy that you created in Step 3 with a text editor.
  5. Locate the line containing the nete:forward tags, as shown in the following example:
    <nete:forward>http://server2.company.com$1</nete:forward>
     In a typical environment, the URL in the Step 5 matches the Internal URL for your SharePoint web application.
  6. Record the public and internal URLs for future reference. You need these public and internal URLs to create your alternate access mappings.
  7. Repeat Steps 4 through 6 for to obtain any additional Internal URLs for other web applications.
Specify a Public URL for the Web Application
The public URL is an external URL through which your customers or external users connect to your organization. The public URL appears in the web browsers of your users.
When you use the 
Single Sign On Agent for SharePoint
 in front of your SharePoint server farm, use the URL of the server hosting your 
Single Sign On Agent for SharePoint
 as the public URL.
 The proxy rule settings of the 
Single Sign On Agent for SharePoint
 must match your alternate access mappings.
This procedure describes creating alternate access mappings for the default zone. Adding another type of authentication to a single internal URL with an alternate access mapping is described in a separate scenario.
 
Follow these steps:
 
  1. Click Start, Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Central Administration.
    The Central Administration home page appears.
  2. Click Application Management.
    The Application Management page appears.
  3. Click Configure alternate access mappings.
    The Alternate Access Mappings page appears with a list of available web applications.
     If the web application that you want is not listed, click the Alternate Access Mapping Collection drop-down list. Pick the web application that you want.
  4. Click Edit Public URLs.
    The Edit Public URLs page appears.
  5. Locate the field for the zone that contains the internal URL for your web application. For example, if you created a web application named http://support001:27975 in the default zone, then locate the Default (zone) field with that URL.
  6. Replace the internal URL in Step 5 with the public URL that you want. For example, if you are mapping from the internal URL http://supportp001:2975 to support.example.com, then replace the internal URL in the field with support.example.com.
  7. Click Save.
Specify an Internal URL for the Web Application
This procedure allows the SharePoint Administrator to map the public URL (http://support.example.com) to the SharePoint internal URL (http://support001.example.com).
 
Follow these steps:
 
  1. Click Start, Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Central Administration.
    The Central Administration home page appears.
  2. Click Application Management.
    The Application Management page appears
  3. Click Configure alternate access mappings.
    The Alternate Access Mappings page appears with a list of available web applications.
  4. Click Add Internal URLs.
    The Add Internal URLs page appears.
    Note:
     If the mapping collection that you want edit does not appear, then select one from the Alternate Access Mapping Collection list.
  5. Enter the internal URL as http://support001.example.com in the Add Internal URL section, in the URL protocol, host, and port field.
  6. Click Save.
    The Alternate Access Mappings page appears with the saved settings. The following table describes how the alternate access mappings appear in SharePoint using the examples in this procedure:
 
Internal URL
 
 
Zone
 
 
Public URL for the Zone
 
http://support001.example.com
Default
http://support.example.com
http://support.example.com
Default
http://support.example.com
 
Configure the Trusted Identity Provider
The Windows Identity Framework in SharePoint 2010 supports multiple authentication providers. Create a Trusted Identity Provider in SharePoint to establish runtime integration with 
Single Sign On Agent for SharePoint
. To configure the trusted identity provider follow these steps:
  1. Verify the following prerequisites before continuing:
  2. Run the modified PowerShell Script on your SharePoint Central Administration Server.
Copy the Policy Server Signing certificate to the SharePoint Central Administration Server
The Policy Server signing certificate that you exported from your key store on a Policy Server is required to create a trusted identity provider. This certificate lets the SharePoint claims provider verify the authentication claims (tokens) that the Policy Server sends.
 
Follow these steps:
 
  1. Navigate to the directory on your Policy Server to which you exported your certificate from the central key store.
  2. Locate the Policy Server signing certificate file that you exported, and then copy it to a directory on your SharePoint central administration server.
Copy the Powershell Script to the SharePoint Central Administration Server
The PowerShell script created by the SharePoint connection wizard on your Agent for SharePoint host is required to create a trusted identity provider. Copy it from your Agent for SharePoint host to your SharePoint central administration server.
 
Follow these steps:
 
  1. Navigate to the following directory on your 
    Single Sign On Agent for SharePoint
     server:
    Agent-for-SharePoint_home
    \sharepoint_connection_wizard\
  2. Locate the PowerShell script created by the SharePoint connection wizard. The script uses the connection name you chose while running the wizard as the file name. For example, if your connection name was my_connection, the name of the script is my_connection.ps1.
  3. Copy the PowerShell script to a directory on your SharePoint central administration server.
Modify the PowerShell Script
To create a trusted identity provider on your SharePoint central administration server, edit the PowerShell script to include the following information about your SharePoint environment:
  • The full path to the root certificate (typically from a third-party Certificate Authority) that signed your certificate.
  • Create a trusted root authority in SharePoint for the certificate authority which signed your certificate.
  • The full path to your signing certificate.
  • Friendly names for each of the claim mappings.
  • The SharePoint realm name (to identify the trusted identity provider).
    Note:
     This value appears in SharePoint Central Administration under the list of available trusted identity providers.
  • A friendly description for the trusted identity provider.
The specific modifications to the PowerShell script vary according to the type of certificates you want to use with your 
CA SiteMinder®
 trusted identity provider. The following scenarios exist:
  • You are using a certificate that is signed by an external certificate authority, and the certificate authority is 
    not 
    trusted by your SharePoint server.
  • You are using a self-signed certificate and the certificate authority is 
    not 
    trusted by your SharePoint server.
  • You are using a certificate, and the certificate authority is trusted by your SharePoint server. Check with your SharePoint administrator to confirm that the proper certificate authority is trusted.
 
Follow these steps:
 
Modify the PowerShell Script for Certificates Signed by an Un - Trusted External Certificate Authority
If your signing certificate is signed by an external certificate authority, modify the PowerShell script to do the following tasks:
  • Import the certificate authority certificate (root certificate) into SharePoint.
  • Create a SharePoint trusted root authority that is based on the certificate authority certificate.
  • Import the signing certificate.
 
Follow these steps:
 
  1. Open the PowerShell script with any text editor.
  2. Locate the following text:
    "<full path to Root certificate file>"
  3. Replace the previous text with the full path to your root certificate. For example, if the full path to your certificate is C:\certificates\sharepoint\certificate_authority_certificate.cer, the updated line matches the following example:
    "C:\certificates\sharepoint\
    certificate_authority_certificate
    .cer"
  4. Locate the first occurrence of the following text:
    <Trusted root authority name>
  5. Replace the previous text with a friendly name for the new trusted root authority in SharePoint. For example, if the name you want is SPCAAuth, the updated line matches the following example:
    "SPCAAuth"
  6. Locate the following text:
    "<full path to Signing certificate file>"
  7. Replace the previous text with the full path to your Signing certificate. For example, if the full path to your certificate is C:\certificates\sharepoint\signing_certificate.cer, the updated line matches the following example:
    "C:\certificates\sharepoint\signing_certificate.cer"
  8. Locate the second occurrence of the following text:
    <Trusted root authority name>
  9. Replace the previous text with a friendly name for the new trusted root authority in SharePoint. For example, if the name you want is SPSigningAuth, the updated line matches the following example:
    "SPSigningAuth"
  10. Locate the following text:
    "<Name of the trusted identity provider>"
  11. Replace the previous text with the name of your SharePoint realm (the realm name follows $realm = in the PowerShell script). For example, if the name of your SharePoint realm is $realm="urn:moss2O1O-wsfed1-casm", the updated line could match the following example:
    "moss2O1O-wsfed1-casm"
  12. Locate the following text:
    "<Description for the Trusted Identity Provider>"
  13. Replace the previous text with a description for your trusted identity provider. For example, if you want to describe the trusted identity provider as "
    CA SiteMinder®
     Provider," the updated line could match the following example:
    "
    CA SiteMinder®
    Provider"
     The LDAP directory and Active Directory charts contain additional examples of possible names.
  14. If your certificate chain contains 
    more than one
     certificate authority certificate, add the other certificate authority certificates to the script. If your script contains 
    one 
    certificate authority certificate, go to the next step.
  15. Save your changes and close your text editor.
    The PowerShell script is modified.
Modify the PowerShell Script for Un - Trusted Self-Signed Certificates
If you are using a self-signed certificate that is issued by a certificate authority which is not explicitly trusted by your SharePoint server, modify the PowerShell script to do the following tasks:
  • Import the certificate authority certificate (root certificate) into SharePoint.
  • Create a SharePoint trusted root authority that is based on the certificate authority certificate.
  • Import the signing certificate.
 
Follow these steps:
 
  1. Open the PowerShell script with any text editor.
  2. Locate the following text:
    "<full path to Root certificate file>"
  3. Replace the previous text with the full path to your root certificate. For example, if the full path to your certificate is C:\certificates\sharepoint\certificate_authority_certificate.cer, the updated line matches the following example:
    "C:\certificates\sharepoint\
    certificate_authority_certificate
    .cer"
  4. Locate the first occurrence of the following text:
    <Trusted root authority name>
  5. Replace the previous text with a friendly name for the new trusted root authority in SharePoint. For example, if the name you want is SPCAAuth, the updated line matches the following example:
    "SPCAAuth"
  6. Locate the following text:
    "<full path to Signing certificate file>"
  7. Replace the previous text with the full path to your Signing certificate. For example, if the full path to your certificate is C:\certificates\sharepoint\signing_certificate.cer, the updated line matches the following example:
    "C:\certificates\sharepoint\signing_certificate.cer"
  8. Locate the second occurrence of the following text:
    <Trusted root authority name>
  9. Replace the previous text with a friendly name for the new trusted root authority in SharePoint. For example, if the name you want is SPSigningAuth, the updated line matches the following example:
    "SPSigningAuth"
  10. Locate the following text:
    "<Name of the trusted identity provider>"
  11. Replace the previous text with the name of your SharePoint realm (the realm name follows $realm = in the PowerShell script). For example, if the name of your SharePoint realm is $realm="urn:moss2O1O-wsfed1-casm", the updated line could match the following example:
    "moss2O1O-wsfed1-casm"
  12. Locate the following text:
    "<Description for the Trusted Identity Provider>"
  13. Replace the previous text with a description for your trusted identity provider. For example, if you want to describe the trusted identity provider as "
    CA SiteMinder®
     Provider," the updated line could match the following example:
    "
    CA SiteMinder®
    Provider"
     The LDAP directory and Active Directory charts contain additional examples of possible names.
  14. If your certificate chain contains 
    more than one
     certificate authority certificate, add the other certificate authority certificates to the script. If your script contains 
    one 
    certificate authority certificate, go to the next step.
  15. Save your changes and close your text editor.
    The PowerShell script is modified.
 
Modify the PowerShell Script for Certificates Issued by a Trusted Certificate Authority
If you are using a certificate signed by a certificate authority that is trusted by the SharePoint server, modify the PowerShell script to do the following tasks:
Skip the step to import the certificate authority certificate.
  • Skip the stop to create a new SharePoint trusted root authority.
  • Import only the signing certificate.
 
Follow these steps:
 
  1. Open the PowerShell script with any text editor.
  2. Comment the first two lines in the PowerShell script, as shown in the following example:
    #$rootcert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<full path to Root certificate file>")
    #New-SPTrustedRootAuthority -Name "<Trusted root authority name>" -Certificate $rootcert
  3. Locate the following text:
    "<full path to Signing certificate file>"
  4. Replace the previous text with the full path to your Signing certificate. For example, if the full path to your certificate is C:\certificates\sharepoint\signing_certificate.cer, the updated line matches the following example:
    "C:\certificates\sharepoint\signing_certificate.cer"
  5. Locate the second occurrence of the following text:
    <Trusted root authority name>
  6. Replace the previous text with a friendly name for the new trusted root authority in SharePoint. For example, if the name you want is SPSigningAuth, the updated line matches the following example:
    "SPSigningAuth"
  7. Locate the following text:
    "<Name of the trusted identity provider>"
  8. Replace the previous text with the name of your SharePoint realm (the realm name follows $realm = in the PowerShell script). For example, if the name of your SharePoint realm is $realm="urn:moss2O1O-wsfed1-casm", the updated line could match the following example:
    "moss2O1O-wsfed1-casm"
  9. Locate the following text:
    "<Description for the Trusted Identity Provider>"
  10. Replace the previous text with a description for your trusted identity provider. For example, if you want to describe the trusted identity provider as "
    CA SiteMinder®
     Provider," the updated line could match the following example:
    "
    CA SiteMinder®
    Provider"
     The LDAP directory and Active Directory charts contain additional examples of possible names.
  11. Save your changes and close your text editor.
    The PowerShell script is modified.
Add Additional Certificate Authority Certificates to the PowerShell Script
The PowerShell script created by the SharePoint connection wizard accommodates the following certificates:
  • A certificate authority certificate (also named a root certificate)
  • One SSL certificate.
The trusted identity provider requires that all certificates in the certificate chain are included. If an intermediate certificate authority signed your certificate instead, modify the PowerShell script to include both certificate authority certificates.
The following illustration describes the differences between the default PowerShell script, and a PowerShell script that accommodates multiple certificate-authority certificates:
Add Additional Certificates to the PowerShell Script
Add Additional Certificates to the PowerShell Script
 
 
Follow these steps:
 
  1. Copy the following section from your PowerShell script:
    $rootcert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<full path to Root certificate file>")
    New-SPTrustedRootAuthority -Name "<Trusted root authority name>" -Certificate $rootcert
  2. Copy the following section from your PowerShell script:
  3. Add a new line after the section you copied, and then paste the copied into the new line.
  4. Edit the pasted section using the changes shown in the following table as a guide:
 
Change this value:
 
 
To this value:
 
$rootcert
$rootcert2
<full path to Root certificate file>
<full path to additional certificate authority certificate file>
<Trusted root authority name>
Name of the additional trusted root authority
  1. To add additional certificate authority certificates, repeat Steps 1 through 4.
  2. Save your changes and close your text editor.
    The PowerShell script is modified.
Run the modified PowerShell Script on your SharePoint Central Administration Server
Run the modified PowerShell script to create a trusted identity provider on your SharePoint central administration server.
 
Follow these steps:
 
  1. Click Start, All Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Management Shell
  2. Navigate to the directory containing your edited PowerShell script.
  3. Run the script with the following command:
    .\
    your_connection_name
    .ps1
    For example, if you named your connection "my_sharepoint" when you ran the connection wizard, the command would be .\my_sharepoint.ps1.
    The trusted identity provider is created.
Verify That the Trusted Identity Provider Is Registered
After running the PowerShell script to create your trusted identity provider, verify that it is registered in your SharePoint central administration server.
 
Follow these steps:
 
  1. From your SharePoint central administration server, click Start, All Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Management Shell.
    The Microsoft PowerShell command prompt appears.
  2. Enter the following command:
    Get-SPTrustedIdentityTokenIssuer
    A list of the trusted identity providers that are configured on the SharePoint central administration server appears.