Es kann aus vielen Gründen praktisch oder erforderlich sein, SharePoint Anwendungen auf Forms Authentifizierung umzustellen. Entweder existiert kein Active Directory im Unternehmen oder man muss ein komplett eigenes Authentifizierungssystem anbinden, oder SharePoint soll in einer Art “Sandbox” Betrieb innerhalb eines Teams oder einer Abteilung getestet werden und es ist “Out-of-Scope” die bestehende AD Infrastruktur zu nutzen und anzupassen.
Durchsucht man das Internet nach den Begriffen “SharePoint Forms-Based Authentication” und ähnlichem landet man sehr viele Treffer. Leider sind viele Tutorials entweder einfach falsch oder unnötig kompliziert.
Deshalb soll hier so kurz wie möglich erklärt werden, wie man eine SharePoint Anwendung mittels ASP.NET SQL-Membership Provider auf Forms-Basierte Authentifizerung oder einen Mischbetrieb Forms/AD umstellt.
Los gehts mit dem Erstellen einer SQL Server Datenbank welche die User und Profile enthält. Wie aus ASP.NET bekannt wird dies mit dem Tool “aspnet_regsql” erledigt. Dazu wird die Visual Studio Command Prompt gestartet und aspnet_regsql.exe aufgerufen. Wird das Tool ohne Parameter gestartet bekommt man einen grafischen Wizard präsentiert der das Anlegen der User Datenbank erledigt. Hier wird die Option “Configure SQL Server for application Services” gewählt und danach noch der Datenbankserver und optional der Name der DB angegeben.
Abbildung 1 – Das Tool aspnet_regsql.exe
Ist die Datenbank angelegt wird die SharePoint Anwendung erzeugt. In der Central Administration wird im Application Management eine neue Anwendung angelegt. Wichtig hierbei sofort: Den Authentifizierungsmodus auf “Claims Based” einstellen (siehe Abb.2)
Abbildung 2 – Claims Based Authentifizierung aktivieren
Wählt man den Claims Based Modus, hat man nachfolgend die Möglichkeit den Membership und Role Provider zu wählen. Wie in Abbilung 3 ersichtlich. Wichtig: Die Namen für den Membershipprovider und den Role Provider müssen mit den Namen so wie sie später in die web.config Datei wandern übereinstimmen. Im Beispiel heissen die beiden Komponenten: Sql-Membership bzw. Sql-Role.
Abbildung 3: Namen des Membership/Role Providers angeben
Ebenfalls wichtig. Die Option “Enable Windows Authentication” sollte aktiviert bleiben, da man sich ansonst selbst aussperrt, BEVOR man irgendeinem User aus der SQL Server Userverwaltungsdatenbank Rechte geben kann.
Wurde die Anwendung erstellt folgt der mühsamste Teil. Insgesamt müssen 3 web.config Dateien angepasst werden. Die Konfiguration der Central Administration, damit man den Usern aus der DB Rechte auf Applikationsebene erteilen kann, die Konfiguration des Secure Token Services und natürlich die eben erstellte Webanwendung.
Um die entsprechenden web.config Dateien zu finden ist es am einfachsten im IIS Manager auf die entsprechende Site Rechts-Klicken und “Explore” wählen.
- Anpassen der Central Administration
Folgende Snippets in die web.config einfügen. Das erste Snippet direkt nach </configSections>. Der Name des DB Servers und der DB Name müssen natürlich entsprechend angepasst werden. Hier wird die Verbunding zur Authentifizierungsdatenbank erstellt
1: <connectionStrings>
2: <add connectionString="data source=.;
3: Integrated Security=SSPI;Initial Catalog=SqlAuthentication" name="FBAConnection" />
4: </connectionStrings>
Das 2. Snippet in die Sektion <system.web>. Hier wird der Membership Provider und der Role Provider eingestellt.
1: <roleManager defaultProvider="AspNetWindowsTokenRoleProvider" enabled="true" cacheRolesInCookie="false">
2: <providers>
3: <add connectionStringName="FBAConnection" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
4: </providers>
5: </roleManager>
6: <membership defaultProvider="SQL-MembershipProvider">
7: <providers>
8: <add connectionStringName="FBAConnection" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
9: </providers>
10: </membership>
- Anpassen der Secure Token Service Application
Die Konfigurationsdatei findet man im IIS Manager unter “SharePoint WebServices”/”SecureTokenServiceApplication”. Hier sieht die web.config etwas anders aus.Folgendes Snippet komplett nach der Sektion <system.net> einfügen.
1: <connectionStrings>
2: <add connectionString="data source=.;Integrated Security=SSPI;Initial Catalog=SqlAuthentication" name="FBAConnection" />
3: </connectionStrings>
4:
5: <system.web>
6: <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
7: <providers>
8: <add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
9: <add connectionStringName="FBAConnection" applicationName="/" description="Stores and retrieves roles from SQL Server" name="SQL-RoleManager" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
10: </providers>
11: </roleManager>
12: <membership defaultProvider="i">
13: <providers>
14: <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
15: <add connectionStringName="FBAConnection" passwordAttemptWindow="5" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" requiresUniqueEmail="true" passwordFormat="Hashed" description="Stores and Retrieves membership data from SQL Server" name="SQL-MembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
16: </providers>
17: </membership>
18: </system.web>
19: configuration>
Hier auch wieder die Werte im Connectionstring an den eigenen DB Server anpassen.
- Anpassen der Webanwendung
Die web.config der Anwendung wird genau gleich verändert, wie jene der Central Administration oben.
Voilá – die Änderungen sind vollbracht. Einmal Server neu starten oder Application Pools recyclen und los gehts.
Zunächst wird in der Central Administration der neuen Anwendung eine User Policy hinzugefügt. Hat man alles richtig gemacht, kann man hier schon User aus der SQL Server DB auswählen.
Im Beispiel wird mittels “Add Users” der Zone (Default) die Gruppe “All SQL-Membership Users” mit der Policy “Full Control” hinzugefügt. Das bedeutet alle User aus dem externen Authentifizierungssystem haben alle Rechte auf der Webanwendung – in Produktivsystem eher nicht zu empfehlen, für Beispielzwecke aber exemplarisch in Ordnung.
Ab jetzt kann mit Forms-Authentifizierung voll transparent in allen Site Collections, Sites und Listen der Anwendung gearbeitet werden. Gar nicht so schwer!
Andreas Aschauer
Mail: andreas.aschauer@codeforce.at
Twitter: www.twitter.com/CodeForceAT
Subscribe