Denn das:
Öhm ... also
ImpersonateLoggedOnUser gibt in der Tat dem
Thread die Rechte des Nutzers dessen Identität man annimmt. Himitsu erwähnte es bereits.
widerspricht dem:
Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.
Nein, es widerspricht sich nicht. Beide Aussagen - wie ich in meiner (vorletzten?) Antwort herausgearbeitet habe, haben ihre Berechtigung. Sie beziehen sich auf verschiedene Aspekte.
MIC ist der Grund warum du scheiterst. Somit ist der Rat vom schönen Günter korrekt, daß du es in einen anderen Prozeß auslagern mußt, um diese "Security Boundary" zu überbrücken.
Die Frage, der bisher alle geflissentlich ausgewichen sind, ist: wie definiert ihr Adminrechte/Admin-Fähigkeiten. Denn auch mit Impersonate lassen sich durchaus noch diverse Dinge tun, die vor dem Annehmen der Adminidentität so nicht möglich gewesen wären. Daß das für die Erstellung eines Verzeichnisses an dem besagten Ort nicht reicht, hat mit MIC zu tun.
Heißt das jetzt, dass die Funktion Impersonate lediglich dazu verwendet werden kann ein fremden Userkontext zu laden, oder könnte man tatsächlich systemweit als dieser Benutzter handeln, sprich eben Dinge tun, die dem Administrator vorbehalten sind.
MIC gibt es "erst" seit Vista oder so. Davor reichte Impersonate durchaus um so gut wie alles als der jeweilige Benutzer zu machen.
Kurzfassung: starte die Erstellung des Verzeichnisses in einem anderen Prozeß mit höherem Integritätslevel. Es reicht dazu, wenn du bspw. dein Programm über eine Befehlszeilenoption nochmal selbst - diesmal als Admin auf entsprechendem Integritätslevel - startest.