Willkürliche Berechtigungsprobleme

Andi Fandrich Als Antwort am 28 Jan. 2014 12:01

S. Antwort im anderen Thread.

chnollu Als Antwort am 28 Jan. 2014 12:04

Danke schonmal dafür, habe ich gesehen... Aber hier ist sicher der richtige Platz :-)

meine Antwort dazu:

Das Problem taucht auch auf wenn die User direkt mit Namen berechtigt sind...

Wie kann ich denn herausfinden ob es am erreichen der Domaincontoller liegt? Und wie kann es sein das User A gestern Zugriff hatte und heute im selben Büro mit dem selben Rechner plötzlich keinen mehr?

Andi Fandrich Als Antwort am 28 Jan. 2014 12:08

[quote user="chnollu"] Aber hier ist sicher der richtige Platz :-)[/quote]

Da hast Du wohl Recht. Inzwischen habe ich aber schon wieder im anderen Thread geantwortet. Irgendwie taucht der immer zuerst auf...

chnollu Als Antwort am 28 Jan. 2014 12:33

[quote user="Andi Fandrich"]Der SharePoint-Server braucht Zugriff auf die Domaincontroller, um das übergebene Usertoken zu validieren. Durch DNS-Probleme kann es sein, daß er den DC mal findet und mal nicht. Ich kenne soclhe Probleme vor allem in Zusammenhang mit IPv6, das sich seit ein paar Windows-Generationen nicht mehr wirklich abschalten läßt.

[/quote]

Diesmal meine Antwort hier ;-)

OK. Ich bin da leider kein Experte, gibt es eine Möglichkeit zu testen/überprüfen, ob es an  der Auflösung liegt?

Andi Fandrich Als Antwort am 28 Jan. 2014 13:02

ping <Domäne>

Verwende statt <Domäne> natürlich den FQDN, also den vollen Namen der Domäne, wie z.B. firma.local

chnollu Als Antwort am 28 Jan. 2014 13:23

dies aber vom Rechner des Users aus, nicht vom SharePoint-Server, richtig?

Olaf Didszun Als Antwort am 28 Jan. 2014 13:41

Nein. Der SharePoint-Rechner greift auf das Active Directory und damit auf den Domain Controller zu, nicht der Client.

Grüße

Olaf

chnollu Als Antwort am 28 Jan. 2014 14:03

dies funktioniert "leider" ohne Probleme....

Tobias Wolter Als Antwort am 28 Jan. 2014 17:57

Hallo chollu,

das Problem kenne ich leider nur zu gut. Im Dezember hatte ich einen Rollout bei dem ich 5h vor der Rollout-Mail an die Belegschaft die Gruppe AD\Jeder in meine Intranet_Reder(auch AD Gruppe) Gruppe aufgenommen habe. Die Mail ging raus – die Hotline kocht – alle bekommen ein „Diese Seite wurde für Sie nicht freigegeben..“.

Mein erster Verdacht war, dass bei den Personen im Kerberos Ticket die Gruppe nicht enthalten ist. Nach mehreren Neustarts des Clients war klar, dass die Gruppe vorhanden ist und das AD keine Probleme macht. Auch max. Anzahl Gruppen/Ticketsize konnte ausgeschlossen werden.

Mir war auch bekannt, dass MS ganz bewusst den onprem Kunden verärgern möchte:

http://blogs.myfirstsharepoint.de/technikblog/sharepoint-claims-authentifizierung-und-ad-gruppen-wenn-berechtigungen-erst-nach-10h-angewendet-werden

Der Artikel ist soweit sehr gut – in meinem Fall hat auch der IISRESET nichts gebracht. Ich habe dann über alle SCs temporär die Gruppe Jeder anstelle meiner Intranet_Reader Gruppe berechtigt  - danach ging es. Ein paar Tage später habe ich dann wieder die die AD\Jeder durch meine Internet_Reader ersetzt.

Meinem Kunden habe ich  jetzt mitgeteilt, dass für die Übernahme von Berechtigungen mindestens 24h vergehen müssen. Da im Portal zukünftig nie Personen, sondern immer aus SAP (HR Org Modul / Organisationsstelle/ Funktionsstelle) generierte AD Gruppen berechtigt werden, ist das bei diesem einen Kunden vermutlich kein Problem.

Momentan werden auch Suchresultate angezeigt, die der Benutzer auf der Basis seiner Rechte nicht sehen dürfte (Beim Klick auf das Ergebnis kommt ein „Zugriff verweigert“.

Gute Nerven für SharePoint 2013+ Viel Erfolg, Tobias