SharePoint PeoplePicker mit mehreren Domänen

By Henning Eiben in SharePoint 0 Comment

Hier ein Update zu meinem Post, in dem ich schon mal beschrieben habe, wie man von einem SharePoint System eine andere Domäne mit durchsucht. Ich kannte bis dato nur den Weg über das gute alte STSADM; aber natürlich geht es auch mit PowerShell!

Und sogar noch viel besser. Mit der PowerShell kann ich in SharePoint mehr als eine Domäne durchsuchen. Und so geht es:

$wa = Get-SPWebApplication http://sp2013.dev-acme.local 

$adsearchobj = New-Object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain
$userpassword = ConvertTo-SecureString "MeinPasswort" -AsPlainText – -Force
$adsearchobj.DomainName = "acme.local"
$adsearchobj.ShortDomainName = "ACME Corporation"
$adsearchobj.IsForest = $false #$true for Forest, $false for Domain
$adsearchobj.LoginName = "devlookup"
$adsearchobj.SetPassword($userpassword)

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($adsearchobj)
$wa.Update()

Das ist zwar insgesamt etwas länger, aber deutlich verständlicher als die Zeile

STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "domain:acme.local,acme\devlookup,MeinPasswort" -url http://sp2013.dev-acme.local

SharePoint und Domänen mit einseitiger Vertrauensstellung

By Henning Eiben in Infrastruktur, SharePoint 1 Comment

In komplexeren Systemumgebungen kann es schon mal vorkommen, dass es mehr als eine Active Directory Domäne gibt.

In meinem Fall gibt es neben der Produktiven Domäne acme.local noch eine Domäne für den Entwicklungsbereich dev-acme.local. Zwischen den beiden Domänen gibt es eine einseitige Vertrauensstellung, so dass man sich mit seinem Account eiben@acme.local auch an dev-acme.local anmelden kann, nicht aber mit deinem dev-acme Account an der acme Domäne. Soweit alles klar.

Was aber, wenn ich in der dev-acme.local Domäne einen SharePoint stehen habe, auf den ich auch mit den acme.local Accounts zugreifen will? Wenn in SharePoint Berechtigungen vergeben werden, dann schlägt SharePoint den Account in der Domäne nach. In diesem Fall ist der SharePoint in der dev-acme.local Domäne installiert und läuft natürlich auch mit entsprechenden Service-Accounts (wie dev-acme\spAppPool). Dieser kann aber aufgrund der Vertrauensstellung keine Accounts aus acme.local nachschlagen, da dieses nachschlagen ja unter der Identität des Application-Pools der Web-Anwendung stattfindet (und die Domäne acme.local kann aus Sicherheitsgründen nur von Authentifizierten Benutzern abgefragt werden).

Was nun?

Zum Glück kann man SharePoint zu genau diesem Zweck sagen, dass für den Zugriff auf eine bestimmte Domäne ein anderer Account verwendet werden soll. Somit kann ich also auch auf andere Domänen zugreifen.

Wie geht das also?

Zunächst brauche ich einen Account in der acme.local Domäne, mit dem ich Benutzerkonten nachschlagen kann. Dafür reicht ein normaler Benutzer, der eigentlich keine besondere Rechte benötigt (außer dass er halt auf das AD zugreifen können muss). Ich habe den mal devlookup genannt.

Bevor ich SharePoint diesen Account für die Lookups beibringen kann, muss ich noch einen Verschlüsselungsschlüssel erstellen.

STSADMstsadm.exe -o setapppassword -password MeinGeheimerSchluessel

Nun kann ich SharePoint mitteilen, dass für die Web-Application mit der URL sp2013.dev-acme.local beim Zugriff auf die Domäne acme.local das Konto acme\devlookup verwendet werden soll:

STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "domain:acme.local,acme\devlookup,MeinPasswort" -url http://sp2013.dev-acme.local

Unglaublich, dass diese Einstellung nur mit dem guten alten STSADM geht. Aber so ist es halt nun mal – auch in Zeiten von PowerShell.