SharePoint 2010 and ADFS 2.0 the complete Step-by-Step guide

SharePoint 2010 and ADFS 2.0 the complete Step-by-Step guide

A short intro.

As you know by now SharePoint 2010 comes with claims based authentication. It has a built in Identy Provider (security token service) which is working out of the box. It’s also possible to configure the SharePoint STS as a relying party for an other Identity Provider.
The purpose of the blogpost is to write a complete walkthrough for using SharePoint 2010 with ADFS 2.0 as an Identity provider in an production environment. No single server scenario or local service accounts, but a scalable 3 tier SharePoint environment and a scalable ADFS 2.0 farm with a Federation Server Proxy in a dmz.
This post will contain the index More content will be added once i have the documentation complete in the next few days. A lot of documentation concerning Sharepoint installation is already up for grabs on technet, so i’ll reference that when necessary.
The complete Step-by-Step contains the following steps

1. Infrastructure
2. Dns
3. Adfs Service Account
4. ADFS 2.0 installation
5. Certificates
6. Configuration wizard ADFS 2.0
7. Add Token Signing Certificate
8. Private key permissions
9. Trusted relying partner
10. Export Token Signing Certificate
11. SpTrustedIdenityTokenIssuer
12. Trusting Certificate Chain
13. Create Web Apps
14. Site collection administrators
15. Site permissions All Authenticated Users
16. User Profile Import
17. What’s next?

1. Infrastructure

For this example i’m using the following infrastructure.
Naming convention

• Domain fqdn : lan.contoso.com
• Domain netbios : contoso
• Intranet url : https://portal.contoso.com
• MySite url : https://mysite.contoso.com
• ADFS url : https://logon.contoso.com

Servers

• VSrvDc : Windows 2008 R2 DC / Certificate Authority
• VSrvSql : Windows 2008 R2 Member / Sql 2008 R2
• VSrvSpW : Windows 2008 R2 Member / SharePoint Server 2010 Web Server
• VSrvSpA : Windows 2008 R2 Member / SharePoint Server 2010 Application Server
• VSrvFs : Windows 2008 R2 Member / ADFS 2.0
• VSrvFsp : Windows 2008 R2 workgroup / ADFS 2.0

Already configured

• All servers are installed with the mentioned OS and are member of the contoso domain (exept the Federation Server Proxy).
• On the domain controller the Certificate Authority role is installed (with the web enrollment pages).
• SharePoint Server 2010 is installed on both the SharePoint application server and the SharePoint web server.
• The SharePoint 2010 Products configuration wizard has took place on the SharePoint application server.
• Finally the SharePoint web server was added to the farm by running the SharePoint 2010 Products configuration wizard on the web server.
• On the SharePoint application server the Configuration wizard has run using the default settings (with a dedicated service account)
• The Federation Server Proxy is placed in a DMZ and remains in a workgroup

2. Dns

In this configuration i’ll configure a web sso for internal and external use. So i’ll have to create records in two dns zones.
External DNS zone

• logon.contoso.com A record <public (NATed) ip address of Federation Server Proxy>
• portal.contoso.com A record <public (NATed) ip address of SharePoint web server>
• mysite.contoso.com A record <public (NATed) ip address of SharePoint web server>

Internal DNS zone
If your domain fqdn is not the same as your public domain, then you’ll have to create a DNS zone for this external domain in your internal DNS config. So in this example our domain fqdn is lan.contoso.com and our public domain is contoso.com. So i’ll first have to create a DNS zone with the fqdn contoso.com in our DNS.
Once i have the correct zone internally (matching the external domain) you create the same three A records in this zone.

• logon.contoso.com A record <private ip address of Federation Server>
• portal.contoso.com A record <private ip address of SharePoint web server>
• mysite.contoso.com A record <private ip address of SharePoint web server>

3. Adfs Service Account

When you install ADFS 2.0 you have the possibility to choose between a single server ADFS or a ADFS farm (can add servers to). It’s a good idea to configure a farm (even if you’re going to use a single server scenario, because it provides flexibility for the future). The difference with configuring is that for the farm config you’ll need an AD service account that has an SPN configured on it. That’s all!
So in this step we’ll create the service account and register the SPN.

• Open AD user and computers and create a user (in this example AdfsSvc)

There a two possible ways to add the SPN to the user

• command line : setspn -a host/logon.contoso.com AdfsSvc
• GUI : Enable Advanced Features view on AD users and computers. Rightclick the Service account. Select the Attribute Editor tab and scroll to servicePrincipalName and select edit. Add the SPN host/logon.contoso.com

4. ADFS 2.0 installation

Logon to the server which will function as Federation Server (VSrvFs). Download ADFS 2.0 RTW and start the installation by running AdfsSetup.exe. Choose Federation Server.
The installation wizard will also install some additional features (.net Framework, IIS). Once installation is complete the ADFS 2.0 console will open. Do not run the configuration wizard yet.

5. Certificates

Besides the certificates needed for SharePoint we’ll need two certificates for ADFS 2.0 web SSO

1. Service communications certificate.
   • This certificate is used for the logonpage provided by ADFS 2.0 (in this example it’s logon.contoso.com).
   • This certificate should be a public certificate since you’ll be using it for employees accessing the loginpage from externally
   • This should be an default SSL certificate
2. Token signing certificate.
   • This certificate is used for signing the tokens which will be provided to SharePoint. (in this example i used tokensigning.constoso.com issued by my internal CA)
   • This could be a public certificate or a certificate issued by your internal Certificate Authority
   • This could be any kind of certificate. I used an SSL certificate.
   • This should be an 2048-bits certificate. 1024-bits is possible but generates a warning in ADFS 2.0

If you’re configuring a Federated Web SSO you’ll need a thrid certificate for decrypting (outside the scope of this post)
Since the ADFS 2.0 wizard also installed IIS you can generate certificate request from the IIS console and request your certificates.
!! Note. Always export your certificates with their private keys and save them for future issues.
Once you have your certificates installed (they should show up in IIS) you’re ready to run the ADFS 2.0 configuration wizard.

6. Configuration wizard ADFS 2.0

Open the ADFS 2.0 management console on the Federation Server (VSrvFs) and click ADFS 2.0 Federation Server Configuration Wizard.

• Create a new Federation Service
• New federation server farm
• Certificate : logon.contoso.com
• Service Account : Use the AD service account created in step 3 (contoso\AdfsSvc)

7. Add Token signing certificate

To add certificates to ADFS 2.0 we need to disable the AD FS automatic certificate rollover feature.
Open a powershell on the Federation Server (VSrvFs) and run the following commands

Add-PsSnapin Microsoft.Adfs.PowershellSet-ADFSProperties -AutoCertificateRollover $false

Next, select ADFS 2.0 management console Service > Certificates > Add Token-Signing Certificate
Select the tokensigning.constoso.com certificate and mark it as primary.

8. Private key permissions

The account we specified in step 3 needs permissions on the private key of the Token signing certificate.
Open an mmc on the Federation Server (VSrvFs) and add the certificates snap-in (connect to local computer)
Browse to personal > certificates. Rightclick tokensigning.contoso.com > All Tasks > Manage Private Keys
Give the service account (contoso\AdfsSvc) read permissions

9. Trusted relying partner

In this step we’ll also specify the claims we will sent to SharePoint. For SharePoint there is one unique claims identifing the user. You can send additional claims, but the unique identifier is required. All the documentation i could find on the internet used the emailaddress as the unique identifier. So i’ll use a different claim as unique identifier so you can see the difference.
I’ll use WindowsAccountName as unique identifier. It’s referenced as http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
You can search this blog to see where i used this unique identifier (and optionally replace it with your own, if you do you’ll need to adjust the claim mapping described in this step as well)
Open the ADFS 2.0 management console on de Federation Server (VSrvFs).
portal.contoso.com
Select Trust Relationships. Rightclick Relying Party Trusts and select Add Relying Party Trust.
Use the following settings in the wizard :

• Select Data Source : Enter data about the relying party manually
• Specify Display Name : portal.contoso.com
• Choose Profile : AD FS 2.0 profile
• Configure certificate : next (do not select a certificate)
• Configure URL : Enable support for the WS-Federation Passive protocol
• Relying party WS-Federation Passive protocol URL : https://portal.contoso.com/_trust/
• Relying party trust identifiers :
  • https://portal.contoso.com
  • urn:sharepoint:portal
  • Choose Issuance Authorization Rules : Permit all users to access this relying party
  • Review settings
  • Check : Open the edit Claims Rules Dialog for this relying party trust when the wizard closes

Next start the Edit Claims Rules Dialog. Select the tab Issuance Transform Rules and choose Add Rule
Use the following settings in the Add Transform Claims Rule wizard :

• Select Rule Template : Send LDAP Attributes as Claims
• Configure Rule :
  • Claim Rule Name : Pass-through LDAP Claims
  • Attribute Store : Active Directory
  • Ldap Attribute : SAM-Account-Name | Outgoing Claim Type : WindowsAccountName

Next we need to create a seconds Relying Party Trust
mysite.contoso.com
Select Trust Relationships. Rightclick Relying Party Trusts and select Add Relying Party Trust.
Use the following settings in the wizard :

• Select Data Source : Enter data about the relying party manually
• Specify Display Name : mysite.contoso.com
• Choose Profile : AD FS 2.0 profile
• Configure certificate : next (do not select a certificate)
• Configure URL : Enable support for the WS-Federation Passive protocol
• Relying party WS-Federation Passive protocol URL : https://mysite.contoso.com/_trust/
• Relying party trust identifiers :
  • https://mysite.contoso.com
  • urn:sharepoint:mysite
  • Choose Issuance Authorization Rules : Permit all users to access this relying party
  • Review settings
  • Check : Open the edit Claims Rules Dialog for this relying party trust when the wizard closes

Next start the Edit Claims Rules Dialog. Select the tab Issuance Transform Rules and choose Add Rule
Use the following settings in the Add Transform Claims Rule wizard :

• Select Rule Template : Send LDAP Attributes as Claims
• Configure Rule :
  • Claim Rule Name : Pass-through LDAP Claims
  • Attribute Store : Active Directory
  • Ldap Attribute : SAM-Account-Name | Outgoing Claim Type : WindowsAccountName

10. Export Token signing certificate

In the next steps we’ll need the token signing certificate to create a SpTrustedIdenityTokenIssuer in SharePoint.
Open IIS 7 manager on the Federation Server. Select the servername in the console and doubleclick the certificates feature. You shlould see the two certificates you configured earlier. Doubleklick the tokensigning.contoso.com certificate and select the details tab. Select copy to file.

• No do not export the private key
• DER encoded binary X.509 (.CER)
• save the file as c:\TokenSign.cer

11. SpTrustedIdenityTokenIssuer

Logon to the server running the Central Administration (VSrvSpA)
Copy the tokensign.cer you exported in the previous step to c:\ (of the current server)
Open the SharePoint 2010 Management Shell (powershell) and run the following powershell script
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:\tokensign.cer”)
$map1 = New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname” -IncomingClaimTypeDisplayName “Login” -SameAsIncoming
$realm = “urn:sharepoint:intranet”
$signinurl = “https://logon.contoso.com/adfs/ls/”
$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS20″ -Description “ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
$uri = new-object System.Uri(https://mysite.contoso.com)
$ap.ProviderRealms.Add($uri, “urn:sharepoint:mysite”)
$ap.Update()

Once completed you can request your changes with the following command

• get-SpTrustedIdentityTokenIssuer

12. Trusting Certificate Chain

In the example we used an certificate issued by an internal CA for the token signing. Because the SharePoint STS doesn’t trust the root of this CA we’ll need to add the Root certificate.
Get the root certificate from you’re internal CA and copy it to the c:\ of the SharePoint application server (VSrvSpa). Open the central administration website > Security > Manage Trust > Add
Give the Trust a name (contoso RootCA) and add the Root certificate from the c:\

13. Create Web Application

Create two web applications

• https://portal.contoso.com
• https://mysite.contoso.com

Configure the web applications with the following settings

• Authentication : Claims Based Authentication
• Create a new IIS website : portal.contoso.com (or mysite.contoso.com)
• Port : 443
• Host header : portal.contoso.com (or mysite.contoso.com)
• Path : <default>
• Allow anonymous : No
• Use Secure Socket Layers (SSL) : Yes
• Claims Authentication Types : Trusted Identity Provider (ADFS20)
• Configure the remaining settings as usual

Create a site collection on a template of your liking for https://portal.contoso.com
Create a site collection based on the MySite host for https://mysite.contoso.com
Enable self service site creation for the MySite web application and create a managed path with a wildcard inclusion as specified in the mysite setting (configured in the service app User Profile Service).

14. Site collection administrators

When you created the site collection you have configured a site collection administrator. Make sure you used a claim here. When you open the people picker and want to specify (for example) the domain administrator and you type administrator you get two results. Select the administrator provided by ADFS20

15. Site permissions all authenticated users

Before any other user can login you must specify the permission based on claims. To get you started you can give the all authenticated users read permissions. Login on the site collection with the site collection administrator. Go to the site permissions and add permissions, when the people picker opens, click on authenticated users on the left menu and select all authenticated users (this is a claim).

16. User Profile Import

Configure the user profile import as specified on technet. I’ll create a blogpost on this later. There a a few things to adjust when working with ADFS 2.0
Central administration > Service Apps > User Profile Service Application > Configure synchronization connection
Use the following settings :

• Connection name : Use your own
• Type : Active Directory
• Connection Settings
  • Forest name : lan.contoso.com
  • Auto discover domain controller
  • Authentication provider type : Trusted Claims Provider Authentication
  • Authentication provider instance : ADFS20
  • Account name : contoso\UseraccountConfiguredForProfileImport
  • Password : ********
  • Port :389 (or use LDAPS if you like)
• Select the OU you like to import

When you have created the connection you need to adjust one user profile mapping
Central administration > Service Apps > User Profile Service Application > Manage User Properties
You will see three properties with claims settings.

• Claim User Identifier
• Claim Provider Identifier
• Claim Provider Type

With the configuration of the synchronization connection the last two properties are populated.
The only thing we’ll need to change is the Claims User Indentifier. Select to edit the property. Scroll down to add new mapping and select the following settings:

• Source data connection : Use the synchronization connection you specified before in this step
• Attribute : samAccountName (since i used this as the unique identifier in step 11.)
• Direction : Import

Click add and OK.
Now import the user profiles. When done login to https://mysite.contoso.com and you’ll see that your profile is mapped to you’re spuser object.

17. What’s next

So now you’ve got web sso with ADFS 2.0, why use NTLM anymore you say. We’ll the are some disadvantages to this scenario as well.

• Exchange (up to 2010 sp1) is claims aware but only with the Microsoft Federation Gateway. So no web sso for OWA with SharePoint ;-(
• Since the People picker will accept any claim and validate it, there is no name resolution available in the people picker. This isn’t a problem if you only want to use it to set permissions on a high level, but assign a simple task to a user can create great confusion since it will accept anything and validate it. There are some blogpost by speschka on how to write a custom provider to do some name resolution on claims, but it’s still not possible to resolve usernames.

Microsoft is making some huge steps in the (right) claims based auth direction. It’s probably the auth scenarion for the future. But we’re implementing SharePoint now…. Depending on your scenario it might be just what you need

Read more »

Posted in: CRM 2011 and Sharepoint 2010,Sharepoint 2010 ADFS

Konfigurieren der Web-SSO-Authentifizierung mithilfe von ADFS (Windows SharePoint Services)

Konfigurieren der Web-SSO-Authentifizierung mithilfe von ADFS (Windows SharePoint Services)

Aktualisiert: 2008-04-10
Inhalt dieses Artikels:

• Informationen zu Verbundauthentifizierungssystemen
• Bevor Sie beginnen
• Konfigurieren von Extranetwebanwendungen zum Verwenden der Web-SSO-Authentifizierung
• Gewähren von Benutzerzugriff auf Extranetwebsites
• Verwenden der Personenauswahl
• Verwenden von E-Mail- und UPN-Ansprüchen
• Verwenden von Gruppen- und Organisationsansprüchen

Informationen zu Verbundauthentifizierungssystemen

In Windows SharePoint Services 3.0 werden Verbundauthentifizierungsszenarien unterstützt, wenn das Authentifizierungssystem sich nicht lokal auf dem Computer befindet, der Windows SharePoint Services 3.0 hostet. Verbundauthentifizierungssysteme sind auch als Web-SSO-Authentifizierungssysteme (Single Sign-On, einmaliges Anmelden) bekannt. Mit den Active Directory-Verbunddiensten (Active Directory Federation Services, ADFS) können Personen in einem Unternehmen mit ihren vorhandenen Active Directory-Konten auf Server zugreifen, die von einem anderen Unternehmen gehostet werden. ADFS stellt außerdem eine Vertrauensstellung zwischen den zwei Unternehmen her und ermöglicht das nahtlose Arbeiten der Endbenutzer mit nur einer Anmeldung. ADFS basiert auf 302 Umleitungen zu authentifizierten Endbenutzern. Benutzern wird nach der Authentifizierung ein Authentifizierungstoken (Cookie) ausgestellt.

Bevor Sie beginnen

Bevor Sie mit ADFS die Web-SSO-Authentifizierung für Ihre Extranetwebanwendung konfigurieren, sollten Sie sich mit den folgenden Ressourcen vertraut machen:

• Eintrag im Microsoft SharePoint Products and Technologies Team Blog (Teamblog zu Microsoft SharePoint-Produkte und -Technologien) zum Konfigurieren von mehreren Authentifizierungsanbietern (http://blogs.msdn.com/sharepoint/archive/2006/08/16/configuring-multiple-authentication-providers-for-sharepoint-2007.aspx).
• Schrittweise Anleitung für ADFS (http://go.microsoft.com/fwlink/?linkid=145396&clcid=0x407). Die in diesem Artikel verwendeten Servernamen und Beispiele basieren auf dieser Schritt-für-Schritt-Anleitung, in der das Einrichten von ADFS in einer kleinen Testlaborumgebung beschrieben wird. In dieser Umgebung wird der Struktur Trey Research ein neuer Server mit dem Namen Trey-SharePoint hinzugefügt. Befolgen Sie die Schritte in dieser Schritt-für-Schritt-Anleitung, um Ihre ADFS-Infrastruktur zu konfigurieren. Da in diesem Artikel jedoch das Konfigurieren von Windows SharePoint Services 3.0 in einem Ansprüche unterstützenden Anwendungsmodus beschrieben wird, müssen Sie nicht alle Schritte zum Erstellen der Windows NT-Tokenagentanwendungen implementieren, die in der Schritt-für-Schritt-Anleitung beschrieben sind.

Hinweis:
Wenn Sie Windows SharePoint Services 3.0 mithilfe der Personenauswahl Benutzer hinzufügen, werden die Benutzer in Windows SharePoint Services 3.0 anhand des Anbieters überprüft, in diesem Beispiel ADFS. Daher sollten Sie den Verbundserver vor dem Konfigurieren von Windows SharePoint Services 3.0 konfigurieren.

Wichtig:

Der Setupvorgang wurde in einer VBScript-Datei erfasst, mit der Sie für Windows SharePoint Services 3.0 die Verwendung von ADFS für die Authentifizierung konfigurieren können. Diese Skriptdatei ist in der Datei enthalten (SetupSharePointADFS.zip) und im Microsoft SharePoint-Produkte und -Technologien-Blog verfügbar, der im Abschnitt Attachments (Anlagen) aufgelistet ist. Weitere Informationen finden Sie auf der Blogseite Ein Skript zum Konfigurieren der Verwendung von ADFS für die Authentifizierung für SharePoint.

Konfigurieren von Extranetwebanwendungen zum Verwenden der Web-SSO-Authentifizierung

1. Installieren Sie den Web-Agent für Ansprüche unterstützende Anwendungen.
2. Laden Sie den Hotfix für ADFS herunter, der unter Der Rolle-Anbieter und der Mitgliedschaft-Anbieter können von Windows SharePoint Services 3.0 auf einem Windows Server 2003 R2-based Computer, auf dem ADFS und Microsoft Windows SharePoint Services 3.0 ausgeführt werden, nicht aufgerufen werden (http://go.microsoft.com/fwlink/?linkid=145397&clcid=0x407) beschrieben ist, und installieren Sie ihn. Dieser Hotfix ist in Windows Server 2003 Service Pack 2 (SP2) enthalten.
3. Installieren Sie Windows SharePoint Services 3.0, konfigurieren Sie alle Dienste und Server in der Serverfarm, und erstellen Sie anschließend eine neue Webanwendung. Standardmäßig wird diese Webanwendung so konfiguriert, dass sie die Windows-Authentifizierung verwendet. Außerdem stellt sie den Einstiegspunkt dar, über den Ihre Intranetbenutzer auf die Website zugreifen. In dem in diesem Artikel verwendeten Beispiel heißt diese Website http://trey-moss.
4. Erweitern Sie die in Schritt 2 erstellte Anwendung in eine weitere Zone. Klicken Sie dazu auf der Website für die SharePoint-Zentraladministration auf der Seite Anwendungsverwaltung auf Webanwendung erstellen oder erweitern und anschließend auf Vorhandene Webanwendung erweitern. Gehen Sie anschließend wie folgt vor:
   
   1. Erstellen Sie einen Hostheader. Dies ist der DNS-Name, unter dem die Website den Benutzern im Extranet bekannt sein wird. In diesem Beispiel lautet der Name extranet.treyresearch.net.
   2. Ändern Sie die Zone in Extranet.
   3. Geben Sie der Website einen Hostheadernamen, den Sie in DNS konfigurieren, damit er von den Extranetbenutzern aufgelöst werden kann.
   4. Klicken Sie auf Secure Sockets Layer (SSL) verwenden, und ändern Sie die Portnummer in 443. Für ADFS müssen Websites so konfiguriert sein, dass sie SSL verwenden.
   5. Löschen Sie im Feld Lastenausgleich-URL die Textzeichenfolge :443. Internetinformationsdienste (Internet Information Services, IIS) verwendet automatisch Port 443, da Sie diese Portnummer im vorherigen Schritt angegeben haben.
   6. Führen Sie die restlichen Schritte auf der Seite aus, um die Erweiterung der Webanwendung fertig zu stellen.
5. Vergewissern Sie sich auf der Seite Alternative Zugriffszuordnungen, dass die URLs denen in der folgenden Tabelle ähneln.
   

   Interne URL	Zone	Öffentliche URL für Zone
   http://trey-moss	Standard	http://trey-moss
   https://extranet.treyresearch.net	Extranet	https://extranet.treyresearch.net

6. Fügen Sie der Extranetwebsite in IIS ein SSL-Zertifikat hinzu. Stellen Sie sicher, dass dieses SSL-Zertifikat für extranet.treyresearch.net ausgestellt ist, da Clients diesen Namen für den Zugriff auf die Websites verwenden werden.
7. Führen Sie die folgenden Schritte aus, um für den Authentifizierungsanbieter für die Extranetzone in Ihrer Webanwendung die Verwendung von Web-SSO zu konfigurieren:
   
   1. Klicken Sie auf der Website für die Zentraladministration auf der Seite Anwendungsverwaltung auf Authentifizierungsanbieter.
   2. Klicken Sie in der rechten oberen Ecke der Seite auf Ändern, und wählen Sie anschließend die Webanwendung aus, für die Sie Web-SSO aktivieren möchten.
   3. Klicken Sie in der Liste der beiden Zonen, die dieser Webanwendung zugeordnet sind (beide sollten Windows verwenden) auf den Link Windows für die Extranetzone.
   4. Klicken Sie im Abschnitt Authentifizierungstyp auf Einmalige Webanmeldung.
   5. Geben Sie in das Feld Name des Mitgliedschaftsanbieters Folgendes ein:
      SingleSignOnMembershipProvider2
      Notieren Sie sich diesen Wert. Sie fügen ihn dem Name-Element des Abschnitts <membership> in den Dateien web.config hinzu, die Sie im Rahmen dieses Verfahrens später bearbeiten werden.
   6. Geben Sie in das Feld Rollen-Managername Folgendes ein:
      SingleSignOnRoleProvider2
      Notieren Sie sich diesen Wert. Sie fügen ihn dem Name-Element des Abschnitts <roleManager> in den Dateien web.config hinzu, die Sie im Rahmen dieses Verfahrens später bearbeiten werden.
   7. Stellen Sie sicher, dass die Option Clientintegration aktivieren? auf Nein festgelegt ist.
   8. Klicken Sie auf Speichern.

Für Ihre Extranetwebanwendung ist damit die Verwendung von Web-SSO konfiguriert. Zu diesem Zeitpunkt kann jedoch nicht auf die Website zugegriffen werden, da kein Benutzer Berechtigungen für diese Website hat. Im nächsten Schritt werden daher den Benutzern Berechtigungen zugewiesen, damit sie auf die Website zugreifen können.

Hinweis:
Nachdem Sie Web-SSO als Authentifizierungsanbieter ausgewählt haben, wird für die SharePoint-Website in IIS automatisch die anonyme Authentifizierung aktiviert (keine Benutzeraktion erforderlich). Diese Einstellung ist erforderlich, damit diese Website Zugriff nur mit Ansprüchen zulässt.

Gewähren von Benutzerzugriff auf Extranetwebsites

1. Öffnen Sie mithilfe eines Text-Editors die Datei web.config für die Website in der Standardzone, die die Windows-Authentifizierung verwendet.
2. Fügen Sie den folgenden Eintrag überall im Knoten <system.web> hinzu.
   <membership>
<providers>
<add name="SingleSignOnMembershipProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />
</providers>
</membership>

<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">
<providers>
<remove name="AspNetSqlRoleProvider" />
<add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />
</providers>
</roleManager>
3. Ändern Sie den Wert für fs-server Ihrem Ressourcenverbundserver (adfsresource.treyresearch.net) entsprechend. Stellen Sie sicher, dass Sie auf der Seite Authentifizierungsanbieter der Zentraladministration den richtigen Mitgliedschaftsanbieter und die richtigen Rollen-Managernamen eingegeben haben. Wenn dieser Eintrag der Datei web.config hinzugefügt wird, erkennt die Personenauswahl auf der Standardzonenwebsite, die die Windows-Authentifizierung verwendet, die ADFS-Anbieter und kann daher die ADFS-Ansprüche auflösen. Auf diese Weise können Sie Berechtigungen für die ADFS-Ansprüche Ihrer Website erteilen.
4. Erteilen Sie ADFS-Ansprüchen wie folgt Zugriff auf die Website:
   
   1. Wechseln Sie zu der Website in der Standardzone, die die Windows-Authentifizierung verwendet. Sie müssen Administrator der Website sein, um die folgenden Schritte ausführen zu können.
   2. Klicken Sie auf das Menü Websiteaktionen, zeigen Sie auf Websiteeinstellungen, und klicken Sie anschließend auf Erweiterte Berechtigungen.
   3. Klicken Sie auf Neu, und klicken Sie dann auf Benutzer hinzufügen.
   4. Geben Sie zum Hinzufügen eines Benutzeranspruchs im Abschnitt Benutzer/Gruppen die E-Mail-Adresse des Benutzers oder dessen Benutzerprinzipalnamen an. Wenn vom Verbundserver sowohl UPN- als auch E-Mail-Ansprüche gesendet werden, verwendet SharePoint den UPN zum Überprüfen gegen den Mitgliedschaftsanbieter. Bei Verwendung der E-Mail-Adresse müssen Sie daher auf Ihrem Verbundserver den UPN-Anspruch deaktivieren. Weitere Informationen finden Sie unter "Verwenden von E-Mail- und UPN-Ansprüchen".
   5. Geben Sie zum Hinzufügen eines Gruppenanspruchs den Namen des Anspruchs ein, der von der SharePoint-Website im Abschnitt Benutzer/Gruppen verwendet werden soll. Erstellen Sie zum Beispiel auf dem Verbundserver einen Organisationsgruppenanspruch mit dem Namen Adatum Teilnehmer. Fügen Sie den Anspruchnamen Adatum Teilnehmer der SharePoint-Website auf dieselbe Weise hinzu, wie Sie einen Windows-Benutzer oder eine Windows-Gruppe hinzufügen würden. Sie können diesen Anspruch Mitglieder von Home [Teilnehmen] zuweisen. Anschließend haben alle Benutzer, die mithilfe dieses Gruppenanspruchs auf die SharePoint-Website zugreifen, Teilnehmerzugriff auf die Website.
   6. Wählen Sie die entsprechende Berechtigungsstufe oder die SharePoint-Gruppe aus.
   7. Klicken Sie auf OK.
5. Öffnen Sie mithilfe eines beliebigen Text-Editors die Datei web.config für die Extranetwebsite, und fügen Sie den folgenden Eintrag im Knoten <configSections> hinzu.
   <sectionGroup name="system.web">
<section name="websso" type="System.Web.Security.SingleSignOn.WebSsoConfigurationHandler, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" />
</sectionGroup>
6. Fügen Sie dem Knoten <httpModules> den folgenden Eintrag hinzu.
   <add name="Identity Federation Services Application Authentication Module" type="System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" />
   

   Hinweis:
   Das ADFS-Authentifizierungsmodul sollte immer im SharePoint SPRequest-Modul im Knoten <httpModules> der Datei web.config angegeben werden. Es ist am sichersten, dies als letzten Eintrag in diesem Abschnitt hinzuzufügen.

7. Fügen Sie dem Knoten <system.web> den folgenden Eintrag hinzu.
   <membership defaultProvider="SingleSignOnMembershipProvider2">
<providers>
<add name="SingleSignOnMembershipProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</providers>
</membership>

<roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider2">
<providers>
<add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</providers>
</roleManager>

<websso>
<authenticationrequired />
<auditlevel>55</auditlevel>
<urls>
<returnurl>https://your_application</returnurl>
</urls>
<fs>https://fs-server/adfs/fs/federationserverservice.asmx</fs>
<isSharePoint />
</websso>
   

   Hinweis:
   Ändern Sie den Wert für fs-server in Ihren Verbundservercomputer, und ändern Sie den Wert von eigene_anwendung entsprechend der URL Ihrer Extranetwebanwendung.

8. Wechseln Sie als ADFS-Benutzer mit Berechtigungen für die Extranetwebsite zur Website https://extranet.treyresearch.net.

Informationen zur Verwendung der Zentraladministration

Sie können auch die Richtlinie der Zentraladministration zum Erteilen von Rechten für ADFS-Benutzer verwenden. Aus den folgenden Gründen wird diese Methode jedoch nicht empfohlen:

• Das Erteilen von Rechten mithilfe einer Richtlinie ist ein sehr grober Vorgang. Er ermöglicht die Situation, dass Benutzer (oder Gruppen) dieselben Berechtigungssätze in jeder Website, in jeder Websitesammlung der gesamten Webanwendung haben. Sie sollten dies nur nach sehr sorgfältiger Überlegung verwenden. In dem hier beschriebenen Szenario wird ADFS-Benutzern Zugriff erteilt, ohne diese Methode zu verwenden.
• Nachdem die Websites in einer Extranetumgebung verwendet wurden, sind die internen Benutzer sehr wahrscheinlich für das Erteilen des Zugriffs auf Websites und Inhalt verantwortlich. Da nur die Farmadministratoren Zugriff auf die Website für die Zentraladministration haben, ist es am sinnvollsten, dass interne Benutzer ADFS-Ansprüche aus der Standardzonenwebsite hinzufügen können, die die Windows-Authentifizierung verwendet.
• Wenn Sie Webanwendungen mit anderen Anbietern erweitern, können Sie einen oder mehrere dieser Anbieter so konfigurieren, dass sie Benutzer und Gruppen von verschiedenen Anbietern, die Sie für diese Webanwendung verwenden, suchen können. In diesem Szenario haben wir eine Website konfiguriert, die die Windows-Authentifizierung so verwendet, dass Benutzer dieser Website andere Windows-Benutzer, Windows-Gruppen und ADFS-Ansprüche von einer Website auswählen können.

Verwenden der Personenauswahl

Mit der Personenauswahl kann bei der Suche nach Rollen keine Suche mithilfe von Platzhalterzeichen ausgeführt werden. Wenn Sie eine Anbieterrolle mit dem Namen Leser für den Web-SSO-Rollenanbieter haben und Sie im Suchdialogfeld der Personenauswahl Lese eingeben, wird der Anspruch nicht gefunden. Wenn Sie Leser eingeben, wird er gefunden. Dabei handelt es sich nicht um einen Fehler. Sie können mit dem Rollenanbieter lediglich keine Suche mithilfe von Platzhalterzeichen ausführen.
Ausführbare Befehlszeilendateien wie stsadm.exe können ADFS-Ansprüche standardmäßig nicht auflösen. Wenn Sie beispielsweise der Extranetwebsite mithilfe des Befehls stsadm.exe –o adduser einen neuen Benutzer hinzufügen möchten, müssen Sie eine neue Konfigurationsdatei erstellen und dabei wie folgt vorgehen, um für Stsadm (oder eine andere ausführbare Datei) das Auflösen von Benutzern zu aktivieren:

• Erstellen Sie eine neue Datei stsadm.exe.config im selben Verzeichnis wie die Datei stsadm.exe (%programfiles%\Gemeinsame Dateien\Microsoft Shared Debug\Web Server Extensions\12\BIN). Fügen Sie der Datei stsadm.exe.config folgenden Eintrag hinzu:
  <configuration>
<system.web>
<membership defaultProvider="SingleSignOnMembershipProvider2">
<providers>
<add name="SingleSignOnMembershipProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />
</providers>
</membership>

<roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider2">
<providers>
<add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />
</providers>
</roleManager>
</system.web>
</configuration>
  

  Hinweis:
  Ändern Sie den Wert von fs-server in Ihren Ressourcenverbundserver (adfsresource.treyresearch.net).

Verwenden von E-Mail- und UPN-Ansprüchen

Führen Sie die im Folgenden beschriebenen Schritte aus, um zu konfigurieren, ob der Verbundserver E-Mail- oder UPN-Ansprüche an Windows SharePoint Services 3.0 senden kann.

Konfigurieren von E-Mail- und UPN Ansprüchen auf einem Verbundserver

1. Öffnen Sie das ADFS-Snap-In über Verwaltung auf Ihrem Verbundserver.
   

   Hinweis:
   Sie können das ADFS-Snap-In auch durch Eingeben von ADFS.MSC im Dialogfeld Ausführen öffnen.

2. Wählen Sie Ihren Windows SharePoint Services 3.0-Anwendungsknoten aus (Ihre Anwendung sollte bereits der Knotenliste hinzugefügt sein).
3. Klicken Sie auf der rechten Seite in der Liste der Ansprüche mit der rechten Maustaste auf E-Mail, und wählen Sie Aktivieren oder Deaktivieren aus.
4. Klicken Sie auf der rechten Seite in der Liste der Ansprüche mit der rechten Maustaste auf UPN, und wählen Sie Aktivieren oder Deaktivieren aus.
   

   Hinweis:

   Wenn sowohl UPN als auch E-Mail aktiviert sind, wird in Windows SharePoint Services 3.0 UPN zum Überprüfen des Benutzeranspruchs verwendet. Daher sollten Sie beim Konfigurieren von Windows SharePoint Services 3.0 darauf achten, welchen Benutzeranspruch Sie eingeben. Beachten Sie außerdem, dass der UPN-Anspruch nur einheitlich angewendet wird, wenn die vom Verbundserver akzeptierten UPN-Suffixe und E-Mail-Suffixe identisch sind. Dies liegt daran, dass der Mitgliedschaftsanbieter auf E-Mails basiert. Aufgrund dieser Komplexität beim Konfigurieren von UPN-Ansprüchen wird als Benutzeranspruchseinstellung für die Mitgliedschaftsauthentifizierung die E-Mail-Methode empfohlen.

Verwenden von Gruppen- und Organisationsgruppenansprüchen

In Windows SharePoint Services 3.0 können Rechte Active Directory-Gruppen zugewiesen werden, indem diese einer SharePoint-Gruppe oder direkt einer Berechtigungsstufe hinzugefügt werden. Die Berechtigungsstufe eines Benutzers für eine Website wird auf Grundlage der Active Directory-Gruppen, bei denen dieser Benutzer Mitglied ist, der SharePoint-Gruppen, zu denen er gehört, und allen Berechtigungsstufen ermittelt, denen der Benutzer direkt hinzugefügt wurde.
Wenn Sie ADFS in Windows SharePoint Services 3.0 als Rollenanbieter verwenden, ist dies anders. Der Web-SSO-Anbieter hat keine Möglichkeit, eine Active Directory-Gruppe direkt aufzulösen. Stattdessen wird die Mitgliedschaft mithilfe von Organisationsgruppenansprüchen aufgelöst. Wenn Sie ADFS mit Windows SharePoint Services 3.0 verwenden, müssen Sie einen Satz von Organisationsgruppenansprüchen in ADFS erstellen. Anschließend können Sie mehreren Active Directory-Gruppen einen ADFS-Organisationsgruppenanspruch zuordnen.
Sie müssen Sie die Datei web.config für die ADFS-Anwendung in IIS auf Ihrem ADFS-Server bearbeiten, damit Gruppenansprüche mit der aktuellsten Version von ADFS verwendet werden können.
Öffnen Sie die Datei web.config, und fügen Sie dem Knoten <FederationServerConfiguration> innerhalb des Knotens <System.Web> den Eintrag <getGroupClaims /> hinzu. Dies wird im folgenden Beispiel veranschaulicht.

Code kopieren

<configuration>
     <system.web>
          <FederationServerConfiguration>
               <getGroupClaims />
          </FederationServerConfiguration>
     </system.web>
</configuration>

Gehen Sie in Adatum (Kontostruktur) wie folgt vor:

1. Erstellen Sie eine Active Directory-Gruppe mit dem Namen Trey SharePoint Leser.
2. Erstellen Sie eine Active Directory-Gruppe mit dem Namen Trey SharePoint Teilnehmer.
3. Fügen Sie Alansh der Gruppe Leser und Adamcar der Gruppe Teilnehmer hinzu.
4. Erstellen Sie einen Organisationsgruppenanspruch mit dem Namen Trey SharePoint Leser.
5. Erstellen Sie einen Organisationsgruppenanspruch mit dem Namen Trey SharePoint Teilnehmer.
6. Klicken Sie mit der rechten Maustaste auf den Active Directory-Kontospeicher, und klicken Sie anschließend auf Neue Gruppenanspruchsextrahierung erstellen.
   
   1. Wählen Sie den Organisationsgruppenanspruch Trey SharePoint Leser aus, und ordnen Sie ihn der Active Directory-Gruppe Trey SharePoint Leser zu.
   2. Wiederholen Sie Schritt 6, und ordnen Sie anschließend den Gruppenanspruch Trey SharePoint Teilnehmer der Active Directory-Gruppe Trey SharePoint Teilnehmer zu.
7. Klicken Sie mit der rechten Maustaste auf Trey Research Account Partner, und erstellen Sie anschließend die ausgehenden Anspruchszuordnungen:
   
   1. Wählen Sie den Anspruch Trey SharePoint Leser aus, und ordnen Sie ihn dem ausgehenden Anspruch adatum-trey-leser zu.
   2. Wählen Sie den Anspruch Trey SharePoint Teilnehmer aus, und ordnen Sie ihn dem ausgehenden Anspruch adatum-trey-teilnehmer zu.

Hinweis:
Die Anspruchszuordnungsnamen müssen zwischen den Unternehmen abgesprochen sein und exakt übereinstimmen.

Starten Sie auf der Trey Research-Seite ADFS.MSC, und gehen Sie anschließend wie folgt vor:

1. Erstellen Sie einen Organisationsgruppenanspruch mit dem Namen Adatum SharePoint Leser.
2. Erstellen Sie einen Organisationsgruppenanspruch mit dem Namen Adatum SharePoint Teilnehmer.
3. Erstellen Sie eingehende Gruppenzuordnungen für Ihre Ansprüche:
   
   1. Klicken Sie mit der rechten Maustaste auf den Kontopartner Adatum, und klicken Sie anschließend auf Eingehende Gruppenanspruchszuordnung.
   2. Wählen Sie Adatum SharePoint Leser aus, und ordnen Sie es dem eingehenden Anspruchsnamen adatum-trey-leser zu.
   3. Wählen Sie Adatum SharePoint Teilnehmer aus, und ordnen Sie es dem eingehenden Anspruchsnamen adatum-trey-teilnehmer zu.
4. Klicken Sie mit der rechten Maustaste auf die Windows SharePoint Services 3.0-Webanwendung, und klicken Sie anschließend auf den Leser- und Teilnehmer-Ansprüchen auf Aktivieren.

Wechseln Sie als Websiteadministrator zur Website http://trey-moss auf der Trey Research-Seite, und gehen Sie anschließend wie folgt vor:

1. Klicken Sie auf das Menü Websiteaktionen, zeigen Sie auf Websiteeinstellungen, und klicken Sie anschließend auf Benutzer und Gruppen.
2. Klicken Sie auf die Gruppe Mitglieder für Ihre Website, sofern diese noch nicht ausgewählt ist.
3. Klicken Sie auf Neu, und klicken Sie anschließend auf der Symbolleiste auf Benutzer hinzufügen.
4. Klicken Sie neben dem Feld Benutzer/Gruppen auf das Symbol mit dem Adressbuch.
5. Geben Sie im Dialogfeld Personenauswahl in das Feld Suchen Folgendes ein:
   Adatum SharePoint Leser
   Wählen Sie unter Benutzer einer SharePoint-Gruppe hinzufügen den Eintrag Besucher von Homepage [Lesen] aus.
6. Geben Sie in das Feld Suchen Folgendes ein:
   Adatum SharePoint Teilnehmer
   Wählen Sie unter Benutzer einer SharePoint-Gruppe hinzufügen den Eintrag Mitglieder von Homepage [Teilnehmen] aus.

Herunterladen dieses Buchs

Dieses Thema wurde zum leichteren Lesen und Ausdrucken in das folgende Buch zum Herunterladen aufgenommen:

• Bereitstellung der Windows SharePoint Services 3.0-Technologie

Die vollständige Liste der verfügbaren Bücher finden Sie unter Bücher zum Herunterladen für Windows SharePoint Services.

Read more »

Posted in: CRM 2011 and Sharepoint 2010,Sharepoint 2010 ADFS

CRM 2011 – How to Setup SharePoint 2010 Integration

Brilliant article about the new CRM 2011 and Sharepoint integration from the Microsoft blog. I have to say when we integrated Sharepoint, apart from the initial problem, which you can read about here. Sharepoint integration was easy. This is a really powerful addition to CRM 2011 because in CRM 4 document management took a lot of effort and caused a few problems (especially when when it ballooned the database by keep all the documents versions!!).
I also have a useful document about the SharePoint architecture overview which you can read here
Here is the article

Microsoft Dynamics CRM with Microsoft SharePoint integration introduction

Now that the Microsoft CRM 2011 Beta is out, so is the much awaited feature of integration with Microsoft SharePoint. Microsoft SharePoint has nailed Document Management and the ability to collaborate on documents is very rich. The versioning control, simultaneous editing, checking in/out are some features in SharePoint that makes SharePoint as powerful as it is.
In CRM, there has been a constant need for a rich Document Management functionality as documents are commonly used in sales cycle and are associated with opportunities and quotes. Customers also associate documents with products and many other entities. In CRM4, the ability for associating documents with a record has been through attachments which have quite a few limitations. Attachments are a passive store which does not help in collaboration scenarios. Users really need to be able to access documents in context of a CRM record, add more documents, edit and share them.
In CRM2011, this problem is addressed. We have provided the ability to associate SharePoint Document locations to a CRM record and hence enabling the ability of accessing documents that are stored in SharePoint within the context of a CRM record. Users can:

a) Create a new SharePoint location(folder) to start storing their documents in
b) Use an existing SharePoint location where the documents are already stored.

We support SharePoint 2010 and 2007 and both MOSS and WSS flavors.

Automatic creation of SharePoint folders

For this to happen, you need SharePoint 2010 with the CRM list component for SharePoint installed. Once you have installed and configured the list solution (follow the readme instructions), here are the steps that you need to follow.
Settings area
The following needs to be done by the CRM admin or System customizer.
1) Go into the Settings area and click on “Document Management “ on the left navigation
2) Click on the “Document Management settings” link

3) Select the entities that you want to enable integration on( selecting this will make the “documents” tab appear in the left nav for records within the selected entity)
4) Enter a SharePoint 2010 Site Collection URL where you have installed the CRM List component.
5) Click on Next.

6) The URL will get validated
7) Select if you want to make the creation entity centric.

a. Entities related to accounts

• Structure: <DefaultSite>/Accounts/<accountname>/<EntityName>/<recordname>
• Example: Opportunity called 100WheelRims related to REI accounthttp://SPServer/Accounts/REI/Opportunity/100WheelRims

b. Entities related to Contacts

• Structure: <DefaultSite>/ Contacts /<accountname>/<EntityName>/<recordname>
• Example: Opportunity called 100WheelRims related to REI Contacts http://SPServer/Contacts/REI/Opportunity/100WheelRims

c. For entities not related to Acounts/ Contacts

• Structure:<DefaultSite>/<EntityName>/<recordname>
• Examples:

o Opportunity called 100WheelRimshttp://SPServer/Opportunity/100WheelRims
o Quote called REICyclesSep related to REI accounthttp://SPServer/Quotes/REICyclesSep

d. If you haven’t selected anything

• Structure:<DefaultSite>/<EntityName>/<recordname>
• Examples:

o Opportunity called 100WheelRimshttp://SPServer/Opportunity/100WheelRims
o Quote called REICyclesSep related to REI accounthttp://SPServer/Quotes/REICyclesSep

Click on Next.

9) Document Library creation happens here to speed up the end user experience. You might get the confirmation dialog based on the number of entities that you have selected on the 1^st screen.

10) Once the creation is done, Click Finish.
CRM record
Now this can be done by anyone who has access to the CRM record. If you have not associated any SharePoint location with the CRM record, follow the following steps.
1) Go to the CRM record for which you want to create a folder and start storing documents in.
2) Click on “Documents” on the left navigation
3) Click OK on the Confirmation dialog that pops up.

4) A folder will get created in SharePoint where the users can store the documents in.

If you want to add another SharePoint location to the same CRM record, follow the following steps
1) Go to the CRM record for which you want to create a folder and start storing documents in.
2) Click on “Add location” in the ribbon.
3) Select the 2^nd radio button where it says “Create a SharePoint folder”
4) Select the parent URL( if you want to change it or use the default)
5) Change the folder name to the desired folder.

6) Click OK on the Confirmation dialog that pops up.

7) A folder will get created in SharePoint where the users can store the documents in.

Work with existing location

If you have an existing SharePoint location that you want to associate from within a CRM record, you have to do just 2 steps.
1) Go to the CRM record where Document Management is enabled and click on “Documents” on the left navigation.
2) Just copy and paste the SharePoint URL into the Add location dialog that will pop up.

You are done. The location will show within the context of the CRM record. If the CRM list component for SharePoint is installed on the SharePoint server URL and the SharePoint Site Collection is in the CRM system, then the UI will look like the following.

If the CRM List component is not installed, we will show the SharePoint location in an IFrame.

This is just a sneak peek into the SharePoint integration functionality. Look out for more blogs that dwell into the details of each of these flows.

Read more »

Posted in: CRM 2011 and Sharepoint 2010