Ich habe ein Problem mit einer WSS 3.0-Instanz, bei der Benutzer jede Nacht ihre Upload-Zugriffsrechte verlieren.
Benutzer können die betreffende Site immer aufrufen und wie gewohnt Listen, Dokumentbibliotheken usw. durchsuchen, erhalten jedoch beim Versuch, Dokumente hochzuladen, eine Fehlermeldung mit der Meldung „Zugriff verweigert“. Dies kann behoben werden, indem die Zugriffsrechte in WSS erneut angewendet werden. Dies muss jedoch jeden Morgen erfolgen, sodass diese Lösung nicht praktikabel ist.
Dies ist ein dedizierter virtueller Server, auf dem keine anderen Anwendungen ausgeführt werden.
Hatte jemand ein ähnliches Problem bezüglich der WSS- und Sharepoint-Zugriffsrechte?
Antwort1
Ich habe dies nur dann passieren sehen, wenn benutzerdefinierter Code auf SharePoint zugreift und Benutzer entfernt. Überprüfen Sie die Serverprotokolle in inetpub, um festzustellen, ob eine Person oder ein Dienstkonto absichtlich Personen entfernt.
WSS wird nicht einfach willkürlich Leute entfernen, man muss ihm dies auch mitteilen.
Überprüfen Sie auch Ihre Timerjobs in der Zentralverwaltung.
Wenn es sich um eine kleine Anzahl von Benutzern handelt, kann ich Ihnen ein PowerShell-Skript bereitstellen, das ihnen planmäßig die Upload-Rechte erteilt.
Antwort2
Ich habe ähnliche Symptome in Fällen gesehen, in denen ein Active Directory-Benutzerkonto geändert wurde. Die Änderung betraf die Sicherheits-ID des Benutzerkontos. In SharePoint wird dann die vorherige SID im Profildienst gespeichert.
Das Symptom wird normalerweise sichtbar, wenn der Benutzer nach einer Weile Abwesenheit auf SharePoint zugreift und das tun kann, was er tun muss. Bis er sich ein Dokument in OWA ansieht. Wenn dann eine SID-Nichtübereinstimmung festgestellt wird, entzieht das System dem Benutzer den Zugriff.
Ich habe dieses Problem gelöst, indem ich den betroffenen Benutzer vollständig aus dem Profildienst und allen Sites, auf denen er sich befindet, gelöscht und ihn anschließend erneut hinzugefügt habe.