Springe zum Inhalt

2 Berater online

SoftEd Blog – Aktuelle Fach­beiträge rund um die IT

· · Thema: SharePoint

SharePoint 2010 und Vertrauensstellungen

Der Betrieb von mehreren getrennten Domänen ist mittlerweile Standard – sei es aus Gründen von Firmenzusammenschlüssen, abgesetzten Ressourcendomänen oder ähnlichem. Auch die Berechtigungsvergabe über Domänengrenzen hinweg ist in einer reinen „Microsoft-Welt“ kein Thema – sollte man meinen! Es gibt schließlich Vertrauensstellungen mit denen man auf die Benutzerinformationen aus einer vertrauten Domäne zugreifen kann.

Bei Microsoft SharePoint 2010 ist alles anders.

Vergibt man in Webseiten Berechtigungen oder sucht man nach Benutzern im People-Picker, wird nur die Domänenstruktur durchsucht, in welcher sich der SharePoint-Server befindet – egal, ob die Domäne davor angegeben wird (<Domänenname><Benutzername>).

Der SharePoint-Umgebung muss explizit mitgeteilt werden, welche Domänen er durchsuchen soll/darf. Dies geschieht über folgendes Kommando:

stsadm -o setproperty -pn peoplepicker-searchadforests  -pv "domain:
<FQDN Domain 1>;domain:<FQDN Domain 2>" -url <URL der Web-Applikation>

Man kann in diesem Kommando beliebig viele Domänen aufzählen, jeweils durch ein Semikolon getrennt. An Stelle von domain:<FQDN Domain 1> kann man auch forest: <FQDN Domainforest 1> angeben, um eine AD-Gesamtstruktur mit mehreren Domänen zu durchsuchen. Ach ja, das Kommando stsadm findet man unter C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14BIN

Eine interessante Frage, die sich nun stellt: Unter welchem Konto werden die Domänen durchsucht? Dafür wird das Applicationpool-Konto der Web-Applikation verwendet. Was tun, wenn dieses in der vertrauten Domäne keine Leserechte hat und man ein spezielles Konto pro Domäne angeben muss? Man muss dem SharePoint für jede Domäne ein entsprechendes Zugriffskonto mitteilen.

Hinweis: Der spezielle Benutzer inkl. Kennwort wird in der Konfigurations-Datenbank des SharePoints gespeichert und alle Web-Frontend-Server müssen darauf zugreifen können. Nun kann man das Kennwort nicht einfach im Klartext ablegen, sondern muss es verschlüsseln und allen Web-Frontend-Servern den Zugriff gewähren.

Dazu muss man auf allen Web-Frontend-Servern folgenden Befehl zum Festlegen eines gemeinsamen Zugriff-Kennwortes ausführen:

stsadm -o setapppassword -password <Kennwort>

Damit wird das Kennwort lokal auf dem Web-Frontend-Server gespeichert. Dies geschieht in der Registrierung unter dem Schlüssel HKEY_LOCAL_MACHINESOFTWAREMicrosoftShared ToolsWeb Server Extensions14.0Secure. Dort muss die lokale Gruppe WSS_WPG mind. Leserecht haben – dies sollte man gleich kontrollieren.

Achtung: Sollte man die beiden Dinge nicht gewährleisten bekommt man bei der Kontosuche die sehr aussagekräftige Fehlermeldung „There was an error in the callback“.

Nun kann man auf einem beliebigen Web-Frontend-Server das obige Kommando wie folgt erweitern:

stsadm -o setproperty -pn peoplepicker-searchadforests  -pv "domain:
<FQDN Domain 1>,<Benutzer Domain 1>,<Kennwort>;domain:
<FQDN Domain 2>,<Benutzer Domain 2>,<Kennwort>" -url
<URL der Web-Applikation>

Und schon geht die Kontosuche auch über Domänengrenzen hinweg…

Kommentieren

Ihre E-Mail-Adresse wird nicht veröffentlicht.

fünfzehn + eins =