<< CodeFest meets Eric Swift | Pragmatischer Einsatz von Team Foundation Server 2010–19. Jan 2010 in Wien >>

Real-World SharePoint Entwickung: RunWithElevatedPrivileges() verstehen

12. December 2010 00:14

Eins der bekanntesten Konstrukte, das jeder SharePoint Entwickler täglich braucht ist vermutlich SPSecurity.RunWithElevatedPriviliges( () => {…});

Der Aufruf dient dazu einen Codeblock unter erhöhten Rechten auszuführen, was oft dienlich ist, da natürlich jeglicher Code sonst unter den Rechten des aktuell angemeldeten Users ausgeführt wird, welcher meist nur eingeschränkte Rechte hat.

Was tut RunWithElevatedPrivileges() eigentlich?

Es führt den übergebenen Code unter dem Account “System Account” aus. Dieser User ist ein SharePoint internes Benutzerkonto welches sozusagen im “God-Mode” arbeitet und alles darf.

So weit, so gut. Doch in der Praxis sieht das anders aus. Oft treten, trotz dem Aufruf, Exceptions auf, welche besagen, dass man nicht genügend Rechte hat eine Operation auszuführen. Wie kann das sein?

Der “System Account” wird auf ein echtes AD Benutzerkonto gemapped, nämlich standardmässig auf die Application Pool Identity. Dieses Konto kann man in IIS Manager einsehen und einstellen. Siehe Abbildung 1 & 2

Abbildung 1 – Application Pool / Advanced Settings

Abbildung 2 – Advanced Settings Dialog mit Application Pool Identity

Um das Pseudo-Konto SHAREPOINT\system auf ein selbst definiertes AD Konto zu mappen muss lediglich in der Zentraladministration unter Application Management –> Manage Web Applications –> User Policy ein Konto editiert oder neu hinzugefügt werden mit der Einstellung “Account operates as System” und “Full Control”.

Hoffentlich lösen sich mit diesem kurzen Tipp einige der Dinge, auf die man im täglichen Entwickeln mit SharePoint stösst.

Andreas Aschauer

General | Web-Development | Server Development

Tags: sharepoint

Real-World SharePoint Entwicklung: Logging mit der SharePoint Guidance LibraryIm Ankündigungspost für die SharePoint 2010 Guidance Library habe ich die verschiedenen fertigen Kom...Real-World SharePoint Entwicklung: Arbeiten mit dem ServiceLocator aus der SharePoint Guidance LibraryIm letzen Post “Logging mit der SharePoint Guidance Library” wurde, um einen Logger für SharePoint z...Real-World SharePoint Entwicklung: Logging und Fehlerbehandlung in SharePoint 2010– Teil 1Als SharePoint Entwickler ist man es gewohnt umfangreiche Trace Logs und und das Windows Event Log d...

Comments (5) -

12/12/2010 3:04:37 AM #

Naja eigentlich erklärt das ganze nur was RunWithElevatedPrivileges() ist. Beleuchtet aber weder wann und wie ich es richtig einsetze, noch welchen Sinn es wann wo macht. Als Real World Example wurde ich das ebenfalls nicht bezeichnen.

Mir würden da eine Menge real real world Beispiele einfallen die mehr Sinn machen würden, als eine einfache Umgehung von SharePoint Mechanismen die in der beschrieben Art auch nicht wirklich Sinn machen.

So eine akademische Betrachtungsweise ist weder sinnvoll noch hilfreich für irgendjemanden.

Stefan Bauer

12/12/2010 3:06:44 PM #

EDIT: Titel geändert um den Inhalt besser zu repräsentieren. Danke für das Feedback

Ad Betrachtungsweise: Aus meiner täglichen Erfahrung kann ich sagen, dass ich RunWithElevatedPrivileges() oft einsetze(n) (muss), und ich daher als wichtig erachte was passiert wenn man einen CodeBlock an den Aufruf übergibt - nämlich dass Code unter dem "System Account" ausgeführt wird. Das Argument der "akademischen Betrachtungsweise" kann ich daher nicht ganz nachvollziehen.

Die akademische Betrachtungsweise zum Thema passend wäre eine Abhandlung über "Elevation of Privileges und/oder Impersonation"

Andreas Aschauer

12/13/2010 8:38:29 AM #

Mich würde interessieren, in welchem Fall beispielsweise die Exceptions von denen du gesprochen hast auftreten. Praktische nach sechs Jahren intensiver SharePoint Entwicklung hab ich diese Problem nicht feststellen können, ohne das irgendwo im Code der Fehler lag.
Die Änderung ist meiner Meinung nach nur ein workaround.
Hast du vielleicht ein kurzes Bespiel wo diese Anpassung notwendig wäre?

Du hast recht akademisch war vielleicht ein wenig zu übertrieben. sorry.

Stefan Bauer

12/15/2010 3:12:14 PM #

Was mir adhoc einfällt ist zum Beispiel das Auslesen gewisser Eigenschaften aus dem UserProfil.

Beim Zugriff auf den UserProfile Manager tritt oftmals folgende Excpetion auf:
"No User Profile Application found to service the request"

Um dies zu umgehen muss man den User der zugreifen will entsprechend auf die Service Application berechtigen -> um das zu vermeiden wird RunWithElevetedPrivileges() um den Code gewrapped und schon funktionierts (man muss nur mehr das gemappte Systemkonto auf den Service berechtigen)

CODE:

SPSecurity.RunWithElevatedPrivileges(() =>
           {
                 var profile = GetProfile(user, site);
                 property = profile[propertyName].Value.ToString();
             });

Und die Methode GetProfile dazu:

public static UserProfile GetProfile(SPUser user, SPSite site)
        {
            var ospServerContext = SPServiceContext.GetContext(site);
            var ospUserProfileManager = new UserProfileManager(ospServerContext);

            return ospUserProfileManager.GetUserProfile(user.LoginName);
        }

Andreas Aschauer

12/17/2010 1:51:10 AM #

Für das Auslesen eines Benutzerprofils ist es nicht notwendig, dies mit SPSecurity.RunWithElevatedPrivileges aufzurufen. In der Regel bei richtig konfigurierten Berechtigungen also auf dem User Profile Service, kann jeder Benutzer die Daten anderer Benutzer lesen. Also kann man dies an dieser Stelle auch weg lassen.

Problem hat man nur wenn wirklich alle Eigenschaften eines Benutzers ausgelesen werden sollen, Also auch jene die der Benutzer als "Only Me" gekennzeichnet hat.

In der Praxis wird RunWithElevatedPrivileges leider viel zu oft verwendet, auch an Stellen an denen es eigentlich nicht notwendig ist. Aus Sicherheitsgründen sollte auch SPSecurity nur sehr sparsam verwendet werden. Wird das Auslesen eines Benutzerprofils mit dem aktuellen Benutzer ausgeführt, der natürlich die Berechtigungen hat dies zu tun, läuft man erst gar nicht in das von dir beschriebene Problem.

Generell hab ich mir die angewöhnt RunWithElevatedPrivileges nicht zu verwenden und es erst dann einzusetzen, wenn es nicht anders geht oder ich schon von vorhinein sagen kann das es nicht anders funktionieren wird. Dies erhöht die Sicherheit des Codes.

Die Fehlermeldung kommt auch davon das System keinen Zugriff auf den User Profile Service hat und nicht weil auf der Web Applikation ein Active Directory Account fehlt. Der aufrufende Benutzer hat jedoch diese Berechtigung.

Lg
Stefan

Stefan Bauer

Add comment

Name* Required Please choose another name

E-mail*

Country Country flag