SharePoint FBA per LDAP

In diesem Beitrag möchte ich euch gerne die SharePoint FBA (formularbasierte Authentifizierung) per LDAP ein bisschen näher erläutern. In einem meiner früheren Beiträge hatte ich das Vorgehen bereits für die SharePoint FBA in Verbindung einer SQL-Datenbank beschrieben. Das Vorgehen um die SharePoint FBA per LDAP zu konfigurieren ist dabei recht ähnlich, nur die Konfiguration der LDAP Verbindung unterscheidet sich logischerweise. Weiterhin möchte ich noch auf die Besonderheit eingehen, wenn nicht nur ein LDAP angebunden werden soll, sondern mehrere.

Die Nutzung der SharePoint FBA per LDAP hat den Vorteil, dass beliebige LDAP Systeme zur Authentifizierung an den SharePoint angebunden werden können. Dadurch benötigen wir nicht zwingend ein Active Directory zur Nutzerverwaltung. Natürlich können wir auch ein beliebiges Active Directory nutzen, dass der SharePoint überhaupt nicht kennt (SharePoint muss sich nicht in diesem Active Directory befinden oder eine Vertrauensstellung bestehen).

In diesem Beispiel nutzen wir als LDAP die bekannte OpenLDAP Implementierung. Die Struktur sieht folgendermaßen aus.

Zum Browsen des LDAP Systems wird LDAP Admin genutzt, ein nettes kleines Tool, was ich dafür sehr gerne nutze.

Die Konfiguration der SharePoint FBA muss an drei verschiedenen Stellen erfolgen:

1. web.config der SharePoint Webanwendung
2. web.config der SharePoint Security Token Dienstanwendung
3. web.config der SharePoint Zentraladministration (optional, wenn man z.B. Berechtigungen vergeben möchte)

Die Konfiguration von Punkt 1 enthält dabei den People Picker und die eigentliche Verbindung zu unserem OpenLDAP Server.

Beim People Picker müssen wir den Namen des noch zu erstellenden Membership Providers hinzufügen.

Nun müssen wir den Membership Provider und den Role Provider in der web.config hinterlegen. Die Stellen sind im nachfolgenden Bild markiert.

Nun geht es darum, was genau in der Konfiguration stehen muss. Zuerst sehen wir uns den Membership Provider an. Wichtig ist dabei, dass der Name immer identisch zu den anderen Stellen ist.

<add name="lstestmembership2" 
type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, 
Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
server="10.5.2.204" 
port="389" 
useSSL="false" 
userNameAttribute="uid" 
userContainer="dc=frank,dc=eisel" 
userObjectClass="posixAccount" 
userFilter="(&amp;(ObjectClass=posixAccount))" 
scope="Subtree" 
connectionUsername="cn=admin,dc=frank,dc=eisel" 
connectionPassword="nein" 
useDNAttribute="false" />

• Zeile 1-3: Dies ist immer gleich und für SharePoint 2016 & 2019 gültig (für ältere Versionen muss die Versionsnummer angepasst werden).
• Zeile 4: Die IP/Name unter der unser LDAP Server erreichbar ist.
• Zeile 5: Der Port unter dem der LDAP Server erreichbar ist.
• Zeile 6: In unserem Beispiel nutzen wir kein SSL
• Zeile 7: Das Attribut welches als Benutzername genutzt werden soll (Anzeigename). Dies ist der Name für den Login und die Darstellung im SharePoint. In unserem Beispiel wäre mein Login also frankeisel.
• Zeile 8: Definition wo sich unsere Benutzerobjekte befinden. Wir könnten dies auf die OU people beschränken, nutzen in diesem kleinen Beispiel aber die höchste Ebene.
• Zeile 9: Definition welche Objekttypen überhaupt Benutzer darstellen. Es befinden sich normalerweise noch ganz andere Objekte in einem LDAP, die uns an dieser Stelle aber nicht interessieren.
• Zeile 10: Wir möchten im People Picker natürlich auch nur die relevanten Objekttypen erhalten. Deshalb sollen nur Objekte vom Typ posixAccount zur Verfügung stehen.
• Zeile 11: Nachdem wir in Zeile 8 keine Einschränkung vorgenommen haben, durchsuchen wir den gesamten LDAP Baum.
• Zeile 12: Unser LDAP Server ist so konfiguriert, dass eine Vorauthentifizierung notwendig ist (was nicht unbedingt typisch ist). Hier wird der Benutzername definiert, der zur Abfrage genutzt werden soll.
• Zeile 13: Dass Passwort für den angegebenen Benutzer. Hier wurde ein ziemlich sicheres Passwort gewählt. 🙂
• Zeile 14: Für die Nutzung von nicht Microsoft Systemen hat sich das explizite setzen auf false bewährt.

Und nun kommen wir zum Role Provider.

<add name="lstestroleManager2" 
type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, 
Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" 
server="10.5.2.204" 
port="389" 
useSSL="false" 
groupContainer="dc=frank,dc=eisel" 
groupNameAttribute="cn" 
groupMemberAttribute="uniqueMember" 
userNameAttribute="uid" 
dnAttribute="" 
groupFilter="(&amp;(ObjectClass=groupOfUniqueNames))" 
userFilter="(&amp;(ObjectClass=posixAccount))" 
scope="Subtree" 
connectionUsername="cn=admin,dc=frank,dc=eisel" 
connectionPassword="nein" 
useUserDNAttribute="false" />

• Zeile 1-3: Dies ist immer gleich und für SharePoint 2016 & 2019 gültig (für ältere Versionen muss die Versionsnummer angepasst werden).
• Zeile 4: Die IP/Name unter der unser LDAP Server erreichbar ist.
• Zeile 5: Der Port unter dem der LDAP Server erreichbar ist.
• Zeile 6: In unserem Beispiel nutzen wir kein SSL
• Zeile 7: Definition wo sich unsere Gruppenobjekte befinden. Wir könnten dies auf die OU groups beschränken, nutzen in diesem kleinen Beispiel aber die höchste Ebene.
• Zeile 8: Das Attribut welches als Gruppenname (Anzeigename) genutzt werden soll.
• Zeile 9: Das Attribut welches die Gruppenmitglieder beinhaltet.
• Zeile 10: Das Attribut wie die einzelnen Gruppenmitglieder aufgelöst werden können.
• Zeile 11: Lassen wir bei OpenLDAP leer
• Zeile 12: Definition welche Objekttypen überhaupt Gruppen darstellen. Es befinden sich normalerweise noch ganz andere Objekte in einem LDAP, die uns an dieser Stelle aber nicht interessieren.
• Zeile 13: Definition welche Benutzer als Gruppenmitglieder berücksichtigt werden sollen (wenn die Gruppen auch noch andere Objekte beinhalten können).
• Zeile 14: Nachdem wir in Zeile 7 keine Einschränkung vorgenommen haben, durchsuchen wir den gesamten LDAP Baum.
• Zeile 15: Unser LDAP Server ist so konfiguriert, dass eine Vorauthentifizierung notwendig ist (was nicht unbedingt typisch ist). Hier wird der Benutzername definiert, der zur Abfrage genutzt werden soll.
• Zeile 16: Dass Passwort für den angegebenen Benutzer. Hier wurde ein ziemlich sicheres Passwort gewählt. 🙂
• Zeile 17: Für die Nutzung von nicht Microsoft Systemen hat sich das explizite setzen auf false bewährt.

Diese Anpassungen müssen wir auch noch analog in der web.config Datei der Zentraladministration durchführen.

Die gerade beschriebene Konfiguration müssen wir nun auch noch in der web.config Datei der SharePoint Security Token Dienstanwendung (STS) vornehmen. Dazu können wir die Einträge einfach kopieren.

In dieser web.config sind alle vorhandenen Provider aufgelistet, die in der SharePoint Farm genutzt werden können. In diesem Fall haben wir zwei unterschiedliche Provider, die unterschiedliche LDAP Systeme ansprechen.

Und nun kommen wir auch zu einer Besonderheit, wenn hier mehr als ein zusätzlicher Provider konfiguriert wurde. Diese haben wir bereits korrekt beachtet, aber dies ist so wichtig, dass ich es hier noch einmal im Detail zeigen möchte.

Wir müssen vor der Definition noch ein explizites <clear/> einfügen. Vereinfacht muss man sich vorstellen, dass alle Provider in eine Liste gespeichert werden, ohne bestimmte Reihenfolge. Und das ist ziemlich schlecht, wenn man mehrere Provider definiert hat.

So eine falsche Reihenfolge kann auch im SharePoint ULS Log nachvollzogen werden. Wenn wir z.B. die Berechtigungsprüfung im SharePoint ausführen, können folgende Einträge auftreten.

10/30/2020 12:42:15.57 	w3wp.exe (0x139C)                       	0x2AB4	SharePoint Foundation         	Claims Authentication         	anpw8	Verbose 	GetRolesForUser returned null for role provider 'AspNetSqlRoleProvider' and username 'frankeisel'.

Hier wird versucht die Rollen (Gruppen) eines Benutzers aufzulösen, die allerdings den falschen Provider nutzt. Dadurch erhält man dann nicht das erwartete Ergebnis.

Um die Konfiguration noch komplett zu vervollständigen, muss der Provider noch in den Einstellungen der Webanwendung in der Zentraladministration hinterlegt werden.

Somit ist die LDAP Konfiguration für unsere SharePoint Webanwendung fertig.

In diesem Sinne,

Happy SharePointing 🙂