Bei SharePoint handelt es sich um kein neues Thema. Betroffen können Organisationen sein, wenn ihr Identity Team in Entra oder einem lokalen AD einen UserPrincipalName (für SharePoint Online) mehrmals nutzt. Für SharePoint Server betrifft es im AD-Konto den SAMAccountName.
Während ein Konto besteht kann ein UserPrincipalName / SAMAccountName kein zweites Mal genutzt werden. Eine andere Situation ist es bei einem Wiedereintritt oder identischen Namen und der Nutzung von einem in der Vergangenheit bereits vergebenen UserPrincipalName. In solchen Situationen können in absehbarer Zeit in SharePoint Online Konflikte mit Berechtigungen auftreten.
Content
Wann kann deine Organisation betroffen sein?
- Ein UserPrincipalName wurde in der Vergangenheit genutzt, gelöscht (bei Austritt) und wird später erneut verwendet (Beispiel Wiedereintritt).
- Handelt es sich um unterschiedliche Personen (Beispiel Person mit identischen Namen), kann die mehrfache Verwendung des UserPrincipalName zu falschen Metadaten in SharePoint führen, siehe Workaround am Ende.
- In SharePoint werden Inhalte direkt mit dem neuen Konto geteilt.
Nicht betroffen ist ein Konto,…
- wenn der Inhalt an eine Microsoft 365 Gruppe geteilt und das Konto Mitglied der Gruppe ist.
- wenn die SharePoint Site an “Jeder, ausser externe Benutzer” geteilt ist und für den Inhalt die Berechtigung nicht unterbrochen wurde .
SharePoint erkennt bei letzteren Fällen es handelt sich um neues Konto und ersetzt das Konto in der User Information List. Eine Berechtigung an “Alle Personen in der Organisation” löst das Problem nicht.
Wie wirkt es sich in SharePoint aus?
Teilt jemand in SharePoint an das neue Konto einen Inhalt (Seite, Ordner, Datei,…) wird die Berechtigung ohne Probleme erteilt. Die Person wird per E-Mail informiert, und hat dennoch keinen Zugriff.
Eine Kontrolle bestätigt die Berechtigung für meine Kollegin.
Auf Inhalte in der Site Collection wird sie keine Berechtigung erhalten. Besitzer und Mitglieder der Site Collection können die Ursache nicht selbstständig erkennen. Über die interne IT wird mit grosser Wahrscheinlichkeit ein Supportticket erstellt. Die Ursache ist für ihr Konto wurde der UserPrincipalName erneut genutzt.
Ursache
Seit ewig nutzt SharePoint pro Site Collection eine User Information List. Über die Url <SiteUrl>/_catalogs/users/simple.aspx zeigt es im Browser die User Information List.
Öffnet ein Konto das erste Mal eine Site Collection legt SharePoint für das Konto einen Eintrag in der User Information List an. Mit PnP PowerShell lässt es sich überprüfen.
Import-Module PnP.PowerShell
Connect-PnPOnline -url <SiteUrl> -Interactive
$SPOSiteUser = Get-PnPUser | ?{$_.LoginName -like "*[email protected]" }
Über die User Information List zeigt es optional wann das Konto in der Site Collection erstellt wurde.
$UserHiddenListItem = Get-PnPListItem -List "User Information List" -Id $SPOSiteUser.id
$UserHiddenListItem.FieldValues.GetEnumerator() | ?{ $_.Key -in "Title", "UserName", "Created" }
In der Praxis aktualisiert sich die User Information List selbstständig und bezieht die Daten aus dem SharePoint User Profile Service. Wird ein Konto gelöscht und der UserPrincipalName später erneut genutzt ist es für die User Information List kein neues Konto. User Profile Service aktualisiert die Daten in der Liste nicht.
Verknüpfung von User Information List zu SharePoint User Profile Service
Ob der Eintrag in der User Information List mit dem Konto im User Profile Service und Entra ID übereinstimmt ist an einem Property erkennbar. NameId aus der UserId des Eintrags.
NameId ist Teil der SID aus dem SharePoint User Profile Service.
Zur Überprüfung frage ich das Konto im User Profile Service ab.
$SPOUPSAccount = Get-PnPUserProfileProperty -Account "[email protected]"
$SPOUPSAccount.GetEnumerator() | ?{$_.Key -in "AccountName", "UserName", "SID", "msOnline-ObjectId" }
Ein Vergleich der SID zeigt es handelt sich um unterschiedliche Konten.
- Durch den UserPrincipalName ist es für die User Information List kein neues Konto.
- Durch die SID stimmt das Konto nicht mit dem User Profile Service und Entra ID überein.
- Das Ergebnis ist die SharePoint Site Collection verweigert den Zugriff.
Beim Property msOnline-ObjectId handelt es sich um die Object ID des Entra ID Kontos. Eine Überprüfung bestätigt es.
Lösung / Workaround
Lösung
Im besten Fall nutzt deine Organisation in SharePoint einen UserPrincipalName / SAMAccountName nicht mehrfach. Dann benötigst du keinen Workaround und das Thema hat sich erledigt.
Workaround
Sollte dein Identity Team bedauerlicherweise kein Interesse an Veränderungen zeigen hast du alternativ vier Möglichkeiten. Es löst die eigentliche Ursache nicht. Für Möglichkeit 3 und 4 ist das PnP.PowerShell oder SharePoint Online Modul erforderlich.
Bei den Workarounds bleiben am Ende Metadaten (wie Erstellt von, Informationen über Versionen,…) erhalten.
- Kann SharePoint das Konto später wieder über den UserPrincipalName zuordnen, leitet es auf das neue Profil der Person weiter und verknüpft die Metadaten des alten mit dem neuen Profil. In dem Fall könnte eine Person mit identischem Namen fälschlicherweise die Metadaten des alten Profils übernehmen.
- Gibt es das Konto in der User Information List nicht wird SharePoint bei Metadaten einen Fehler ausgeben. SharePoint möchte das Profil in der Liste öffnen und findet es nicht.
Workaround 1
Ergänze die Berechtigungen der Site Collection temporär mit der Berechtigung für Jeder… Beim ersten Zugriff sollte SharePoint erkennen es handelt sich um neues Konto. SharePoint ersetzt das Konto in der User Information List. Nach dem ersten Zugriff kannst du den Zugriff für Jeder wieder entfernen und das neue Konto auf einzelne Inhalte in der SharePoint Site berechtigen.
Workaround 2
Für eine group-connected Teamsite, füge das Konto als Mitglied in das Team / die Gruppe ein. Beim ersten Zugriff sollte SharePoint erkennen es handelt sich um neues Konto. SharePoint ersetzt das Konto in der User Information List. Nach dem ersten Zugriff kannst du das Konto wieder aus dem Team entfernen und auf einzelne Inhalte in der SharePoint Site berechtigen.
Workaround 3
Benutzerkonto über PowerShell manuell aktualisieren. SharePoint wird das alte Konto entfernen und mit dem neuen Konto ersetzen. Das neue Konto erhält eine neue ID und die SID wird aktualisiert. Das Konto muss auf die Inhalte neu berechtigt werden.
In manchen Fällen funktioniert es über PnP.PowerShell nicht. Nutze in dem Fall das SharePoint Online PowerShell Modul.
# With PnP.PowerShell
Connect-PnPOnline -Url <SiteUrl> -Interactive
New-PnPUser -LoginName <UserPrincipalName>
(Get-PnPUser | ?{$_.LoginName -like "*<UserPrincipalName>" }) | Select-Object id -ExpandProperty UserId
# OR with SharePoint Online PowerShell
Connect-SPOService -Url "https://<Tenant>-admin.sharepoint.com"
Set-SPOUser -Site <SiteUrl> -LoginName <UserPrincipalName>
Das Konto wurde erfolgreich ersetzt, wenn die ID und das NameId Property angepasst sind.
In meinem Beispiel war ID 63 das alte Konto. Mit ID 64 hat es SharePoint in der User Information List neu erstellt und die SID aktualisiert.
Ein erneuter Vergleich im User Profile Service bestätigt die SID aus ID 64. Das Konto kann in der SharePoint Site Collection wieder berechtigt werden.
Workaround 4
Benutzerkonto aus der User Information List entfernen. Das Konto wird aus der Liste entfernt und beim nächsten Zugriff neu angelegt. Das Konto muss auf die Inhalte neu berechtigt werden.
# With PnP.PowerShell
Connect-PnPOnline -Url <SiteUrl> -Interactive
(Get-PnPUser | ?{$_.LoginName -like "*<UserPrincipalName>" }) | Remove-PnPUser
# OR with SharePoint Online PowerShell
Connect-SPOService -Url "https://<Tenant>-admin.sharepoint.com"
Remove-SPOUser -Site <SiteUrl> -LoginName <UserPrincipalName>