In SharePoint Online kann es Situationen geben in denen neue Mitarbeitende korrekt berechtigt sind und sie trotzdem keine Berechtigung haben. Für Besitzer der Site eine unverständliche und oft frustrierende Situation. Der Grund kann ein gelöschter AD Account aus der Vergangenheit sein.
Hier am Beispiel von Adele. Sie wurde auf der SharePoint Site als Mitglied hinzugefügt und sollte berechtigt sein Inhalte zu bearbeiten.
Möchte Adele auf die Site zugreifen kann sie es nicht, Berechtigungsfehler. Selbst nach mehrmaligem Prüfen ist sichergestellt die Berechtigungen von Adele sind korrekt. Es hilft nicht die Berechtigung zu entfernen und neu berechtigen. Zugriff hat sie nicht. Es wird meist nur einzelne Sites betreffen.
In der Situation handelt es sich um einen Fall über einen AD Account den es in der Vergangenheit bereits gab und der ebenfalls Zugriff auf die SharePoint Site hatte. Ob auf die gesamte Site oder nur einzelne Inhalte spielt keine Rolle.
- Adele ihr Account wurde in der Vergangenheit auf der betroffenen Site oder einzelne Inhalte berechtigt.
- Adele ihr Account wurde in Azure AD gelöscht.
- Für Adele wurde in Azure AD ein neuer Account mit demselben User Principal Name (UPN) erstellt. Mögliche Gründe können sein neue Mitarbeiterin mit ähnlichem Namen, bei Wiedereintritt wurde nicht der übliche Weg gegangen den alten Account im Azure AD Papierkorb wiederherzustellen, der Account war nicht mehr über den Papierkorb wiederherstellbar,….
Äusserlich hat ein Site Besitzer in so einer Situation keine Möglichkeit zu erkennen es handelt sich beim Eintrag für Adele um einen Account den es in der Vergangenheit gab und heute nicht mehr aktuell ist.
Microsoft beschreibt diesen Fall:
This issue most frequently occurs when a user is deleted and the account is then re-created with the same user name. The account in the Microsoft 365 admin center or Active Directory (in directory synchronization scenarios) is deleted and re-created with the same user principal name (UPN). The new account is created by using a different ID value. When the user tries to access a site collection or their OneDrive, the user has an incorrect ID.
Mit ID ist die SID des Benutzeraccounts gemeint.
- Berechtigt ein Site Besitzer einen Account in SharePoint fügt es Daten wie den Loginname (= UPN) des Accounts in die lokale SharePoint Information List der Site ein und gibt dem Account eine fortlaufende ID. Unten am Beispiel von Adele. Ein Admin erkennt auch hier nicht sofort ob es sich um den neuen oder alten Account von Adele handelt. Je nach Anzahl der Benutzer erkennt es der Admin nach am ehesten an der ID. Wird ein neuer Account berechtigt sollte er eine höhere ID erhalten gegenüber einem der zb vor 2 Jahren hinzugefügt wurde.
- Wird ein Account in Azure AD gelöscht synchronisiert es die Löschung zum SharePoint User Profile Store. Dieser markiert den Account als gelöscht. Relevant ist das zb für den OneDrive Lifecycle Prozess.
- Pro Site werden die Daten von dem Account jedoch für immer in der lokalen SharePoint Information List verbleiben, oder bis es jemand manuell bereinigt.
- Vergibt ein Site Besitzer später für den neuen Account Berechtigungen auf der Site wird SharePoint immer zuerst die lokale SharePoint Information List auf einen passenden Loginname prüfen. Bei Adele findet es den Loginname und nimmt dadurch ID 20. Berechtigung abgeschlossen. SharePoint verifiziert mit dem Schritt nicht ob es den Account und SID im Verzeichnis noch gibt.
- Möchte Adele zugreifen wird SharePoint für die Authentifizierung die SID des Accounts verifizieren. Die SID des neuen Accounts stimmt nicht überein, Adele wird der Zugriff verweigert.
Ein Administrator kann es via PowerShell über den SharePoint User Profile Store erkennen, sofern man die Benutzerdaten von gelöschten Accounts protokolliert. Hier die Gegenüberstellung von Adele ihrem Account.
| Gelöschter Account (war initial berechtigt) |  |
| Neuer Account (wurde neu berechtigt) |  |
Am Beispiel ist erkennbar, es ist derselbe Accountname (= UPN), aber es sind unterschiedliche SIDs. So tritt der Berechtigungskonflikt mit SharePoint auf.
Wie kannst du es lösen und den Zugriff ermöglichen?
Es gibt zwei Möglichkeiten. Praktisch sind beide für einen Administrator einfach umsetzbar. Die 2. Möglichkeit solltest du laut Hilfe nur über eine Absprache mit Microsoft Support durchführen.
Möglichkeit 1
Anpassung User Principal Name (UPN)
Die Ursache ist der UPN. Es ist dadurch naheliegend den UPN des neuen Accounts anzupassen.
- Für die Demo änderte ich den UPN von adelev auf adelev2.
- Zur besseren Erkennbarkeit änderte ich den Displayname auf “Adele Vance (Account 2)”. So lässt es sich unterscheiden ob SharePoint durch die Änderung einen neuen Account erkannte.
Hinweis: Vergibst du den alten Displayname wird es in der Site zwei Accounts mit demselben Namen geben. - Die Mailadresse musst du nicht ändern. Für SharePoint ist der UPN relevant.
- Nach der Anpassung musst du warten bis die Änderung von Azure AD zu SharePoint synchronisiert wurde. Es kann bis zu 24 Stunden dauern, läuft meist aber innerhalb 60 Minuten.
- Prüfe im SharePoint User Profile Store ob der Sync abgeschlossen ist.
- Jetzt kann der Site Besitzer den Account erneut berechtigen und wird zusätzlich adelev2 in der Auswahl finden.
Erinnerung: Vergesst nicht, SharePoint prüft immer zuerst die SharePoint Information List. Gibt der Besitzer nur Adele ein wird es ihm weiterhin den alten Account aus der lokalen Liste zeigen. Erst wenn SharePoint niemanden in der Liste findet, oder mit der Auswahl “Verzeichnis durchsuchen” stellt es eine Anfrage an das globale Verzeichnis. In solchen Fällen sollte die vollständige Mailadresse angegeben werden.
 |  |
Du siehst die zwei unterschiedlichen Accounts bereits in den Berechtigungen. Kontrolliere trotzdem noch einmal via PowerShell die SharePoint Information List. Der Account von adelev2 wird eine neue ID zeigen. Ein eindeutiges Zeichen SharePoint hat den neuen Account korrekt erfassen können.
Die Kollegin wird zufrieden sein, sie hat jetzt mit Sicherheit Zugriff. 👍
Möglichkeit 2
Löschen des alten Accounts aus jeder SharePoint Site
Microsoft beschreibt den Vorgang hier und erwähnt den Hinweis über Support.
It should be used to troubleshoot Profile Property synchronization or mismatched ID issues only as advised by Microsoft Customer Support Services.
Du kannst über PowerShell den Account aus der SharePoint Information List löschen. Dadurch wird er komplett aus der Site gelöscht. Ein Site Besitzer kann den neuen Account berechtigen und SharePoint wird die korrekte SID erfassen. Hatte der alte Account in der Vergangenheit Zugriff auf mehreren Sites musst du den Schritt pro Site wiederholen. Am Beispiel mit dem alten Account von Adele (ID 20).
Auch dann wird die Kollegin zufrieden sein. Nachdem sie erneut berechtigt wurde hat sie Zugriff. 👍
