Domain User Migration: SharePoint und SIDHistory

Eines der Grundprinzipien einer Migration von Active Directory Domains ist der Zugriff auf Ressourcen in der Quell Domain auf Basis der SIDHistrory Information des migrierten Benutzerkontos oder Gruppe. Die SID des Objekts in der Quell Domain wird in das SIDHistory Attribute des Objekts in der Ziel Domain geschrieben. Dies ermöglicht während einer Migrationsphase den Zugriff auf Ressourcen in der Quell Domain.

Leider bricht Microsoft bei SharePoint mit diesem Prinzip.

Das SharePoint und SIDHistory Problem

Microsoft SharePoint in den Versionen 2007, 2010 und 2013 unterstützen nicht den Zugriff auf SharePoint Inhalte basierend auf Berechtigungen welche durch die SIDHistory gegeben sind. Werden somit Benutzerkonten in eine andere Active Directory Domain migriert und die SharePoint Farm bleibt zunächst in der Quell Domain zurück, so können die migrierten Benutzerkonten nicht auf die SharePoint Inhalte zugreifen.

Natürlich können sich die Anwender auf der SharePoint Seite manuell mit dem Benutzerkonto der Quell Domain anmelden, dies kann allerdings nur als Workaround dienen.

Lösung 1 – STSADM

Eine Lösungsmöglichkeit für das SharePoint und SIDHistory Problem bietet der Austausch der Benutzerkonten innerhalb der SharePoint Berechtigungen. Bevor es die neuen Möglichkeiten per Powershell gab, konnte man sich dem Befehlszeilenwerkzeug STSADM bedienen:

Ein wichtiger Hinweis ist, dass hier ein Austausch der Benutzerkonten durchgeführt wird. Der Account der Quell Domain hat danach keinen Zugriff mehr auf die SharePoint Inhalte. Dies hat wesentlichen Einfluss auf Roll Out Planung und muss unbedingt berücksichtigt werden.

Lösung 2 – Powershell (ab SharePoint 2010 empfohlen)

Seit SharePoint 2010 empfiehlt Microsoft die Nutzung der PowerShell cmdLets für SharePoint. STSADM steht zwar weiterhin zur Verfügung, wird aber nicht mehr weiterentwickelt. Wahrscheinlich wird es mit einer der kommenden SharePoint Versionen eingestellt. Daher die Empfehlung sich mit Alternativen der PowerShell vertraut zu machen.

Das cmdLet “Move-SPUser” erstetzt weitgehend die Funktionen von “stsadm -o migrateuser“

Wenn man sich mit dem cmdLet “Move-SPUser” befasst, stößt man recht schnell auf weitere ähnliche cmdLets: get-SPUser und set-SPUser. Das cmdLet get-SPUser gibt eine Liste der Berechtigungen auf einer Site Collection aus. Mit ein wenig Phantasie lässt damit ein kleines Skript schreiben, welches die berechtigten Benutzerkonten einer Site Collection ausliest, den Domain Namen “alt” gegen “neu” austauscht und mit move-SPUser die neue Berechtigung setzt.

Liefert die berechtigten Benutzerkonten einer Site Collection. Je nach dem ob die Claims Based Authentication der Web Application aktiviert wurde oder nicht, stellt sich die Ausgabe so dar:

Migrationsskript

Die folgenden Skriptzeilen sollen als Anregung für ein Migrationsskript verstanden werden.

Link zur Microsoft Technet Seite “Move-SPUser“