none
SP2010 - Farm-Admin hat Zugriff auf ZentralAdministration, aber AccesDenied auf eine bestimmte SC RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Guten Tag,

    Ich hatte bei einem Kunden ein Problem, zu dem ich bisher keine Ursache gefunden habe:

    Mehrere Kunden-MA beschwerten sich über "Access Denied"-Meldungen auf dem Sharepoint.

    Als ich die Fehlersuche starten und mich mit dem Farm-Admin dort anmelden wollte, was normalerweise und auch bis eine halbe Stunde vorher problemlos funktionierte, erhielt ich ebenfalls ein "Access Denied".

    Der Zugriff auf ZA und eine in der gleichen WebApplikation installierte zweite SC funktionierte problemlos.

    Ein kurzfristig angesetzter IISRESET brachte schnell wieder Ruhe in das System und die Kunden konnten sich nach einer halben Stunde wieder anmelden.

    Nun möchte ich aber heraus finden, wo die Ursache zu diesem Fehler liegt, kann aber nichts finden.Im Sharepoint-Log kann ich nur die "AccessDenied"-Meldungen lokalisieren und sagen, wann diese zum ersten Mal auftraten.

    Im Windows-Log gibt es analog zu den Meldungen im SP-Log ebenfalls "Access Denied"-Meldungen, das war dann aber auch schon alles.

    Kennt jemand dieses Phänomen oder kann mir wenigstens weitere Ansatzpunkte nennen, an denen ich ansetzen kann?

    Was ich bisher bei meiner Recherche gefunden habe, betrifft nur ähnliche Fälle, deren Lösung aber nicht passen:

    Eine der gefundenen Konstellation ist, dass der Admin der SC keinen Zugriff hat, der Farm-Admin aber schon(nicht zurtreffend)

    eine andere betrifft den generell untersagten Zugriff für den Farm-Admin schon auf die ZA(trifft hier auch nicht zu)

    Wäre schön, wenn mir da jemand ein wenig unter die Arme greifen könnte, da ich schon gerne ein erneutes Auftreten ausschliessen möchte.

    Vielen Dank,

    G. Josupeit

    Donnerstag, 28. Februar 2013 11:05
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden
    Ich stehe aktuell wieder vor dem gleichen Problem, aber weder iisreset noch Server-Neustart haben irgendwas bewirkt!

    Anscheinend bezieht sich dieses Phänomen aber nur auf die Startseite selbst.

    Wenn ich andere Seiten direkt per URL aufrufe (zb.: /_layouts/users.aspx) habe ich vollen Zugriff.

    Samstag, 2. März 2013 19:31
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi Gaylord,
    hast Du mal geprüft, ob Kerberos eingestellt und richtig konfiguriert ist?
     
    --
    Peter Fleischer
    Samstag, 2. März 2013 20:15
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Peter,

    erstmal Danke für die Antwort!

     

    überprüft hab ich das noch nicht, kann mir aber irgendwie nicht vorstellen, dass es was mit Kerberos zu tun hat, weil es ja nur Auswirkungen auf Default.aspx hat. Alle anderen Seiten kann ich nutzen, sofern ich die URLS direkt eingebe.

    Im Übrigen erhalte ich seit heute auch folgende Meldungen im ULS-Log:

    03.02.2013 21:01:44.45 SPUCHostService.exe (0x087C) 0x0F5C SharePoint Foundation Sandboxed Code Service fe8b Medium -  - Unable to activate worker process proxy object within the worker process: ipc://cbeddc0d-e1dc-4276-a878-a918756ccd39:7000 
    03.02.2013 21:01:44.45 SPUCHostService.exe (0x087C) 0x0F5C SharePoint Foundation Sandboxed Code Service fe8c Medium -  - Error activating the worker process manager instance within the worker process. - Inner Exception: System.InvalidOperationException: Unable to activate worker process proxy object within the worker process: ipc://cbeddc0d-e1dc-4276-a878-a918756ccd39:7000     at Microsoft.SharePoint.UserCode.SPUserCodeWorkerProcess.CreateWorkerProcessProxies() 
    03.02.2013 21:01:44.45 SPUCHostService.exe (0x087C) 0x0F5C SharePoint Foundation Sandboxed Code Service ei0t Medium - Process creation/initialization threw an exception. Stopping this process. "ipc://aa02404c-3a66-4392-873b-f4de8ca59b51:7000" 
    03.02.2013 21:01:44.45 SPUCHostService.exe (0x087C) 0x0F5C SharePoint Foundation Sandboxed Code Service i0o2 Monitorable - Stopping shim process. Shim process name: "SPUCWorkerProcess" Shim PID: "0x2364" Shim service url: "ipc://aa02404c-3a66-4392-873b-f4de8ca59b51:7000" 
    03.02.2013 21:01:44.47 SPUCHostService.exe (0x087C) 0x0F5C SharePoint Foundation Sandboxed Code Service i0o3 Monitorable - Stopping proxy process. Proxy process name: "SPUCWorkerProcessProxy" Proxy PID: "0x1D68" Proxy service url: "ipc://cbeddc0d-e1dc-4276-a878-a918756ccd39:7000" 
    03.02.2013 21:01:44.47 SPUCHostService.exe (0x087C) 0x0F5C SharePoint Foundation Sandboxed Code Service fe87 Medium -  - Error activating the worker process manager instance within the worker process. - Starting worker process threw - Inner Exception: System.InvalidOperationException: Unable to activate worker process proxy object within the worker process: ipc://cbeddc0d-e1dc-4276-a878-a918756ccd39:7000     at Microsoft.SharePoint.UserCode.SPUserCodeWorkerProcess.CreateWorkerProcessProxies()  

    Einen Link dazu habe ich auch schon gefunden:

    http://www.avanadeblog.com/sharepointasg/2010/12/fix-unable-to-activate-worker-process-proxy-object-within-the-worker-process.html

    Die Registry-Einträge, die dort erwähnt werden, sind schon so gesetzt gewesen, als ich nach gesehen habe.

    Ich weiss auch nicht wirklich, was die Log-Einträge mit dem Access-Denied-Problem zu tun haben.

    Samstag, 2. März 2013 20:23
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi Gaylord,
    gibt es denn Sandboxed Solutions, die laufen müssen?
     
    Wenn Kerberos nicht richtig konfiguriert ist, dann arbeitet die WebAnwendung weiter mit NTLM. In diesem Fall können “Innereien” einer Seite ggf. Zugriffsverweigerungen bringen, was zu dem geschilderten Zustand führt. Andere Seiten mit anderen “Innereien” werden dagegen angezeigt, da bei Ihnen keine Zugriffsverletzungen auftreten. 
     
    --
    Peter Fleischer
    Sonntag, 3. März 2013 06:24
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Peter,

    Kerberos ist gar nicht aktiv, die ganze Farm arbeitet auf NTLM.

    Zu dem "Acces Denied"-Problem:

    Hier gibt es doch zwei verschiedene Problemumfelder, die mir vorher nicht bewußt waren.

    Mein erster Beitrag war tatsächlich ein Fehler im System, der bisher noch ungeklärt ist.

    Die zweite Meldung entstand anscheinend durch Migrations-Arbeiten, bei denen Inhalt von einer SC auf eine andere SC in der gleichen Farm übertragen werden sollte. Zu diesem Zweck hatten wir die Quell-SC auf "ReadOnly" gesetzt, was dann wohl für das "Access Denied" gesorgt hat. (Auch wenn ich mir selbst noch relativ sicher bin, dass ich nach dem Setzen auf "ReadOnly" trotzdem noch Zugriff auf die Startseite der Quell-SC hatte.)

    Zumindest war aber der Zugriff wieder vorhanden, nach dem wir den Schreibschutz entfernt haben.

    Hier stellt sich mir jetzt die Frage, ob dieses Verhalten so beabsichtigt ist. ReadOnly heißt für mich eigentlich: "Lesen Ja, Ändern, Hinzufügen oder Löschen Nein" und nicht "Ich mach mal die Startseite dicht und dann kommt schon keiner mehr auf die Idee was zu ändern!"

    Ist für mich alles immer noch nicht wirklich schlüssig :(

    Sonntag, 3. März 2013 12:30
    |