Anonymer Zugriff auf eine Pipe eines Windows 7
![Martin Richter [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWQxpu-dTprptuDetmEqv8xMzotahZyK4QkrAqMQZDi=s40-c)
Martin Richter [MVP]
Ich habe mir folgendes Sample gezogen um mein Problem zu veranschaulichen.
http://support.microsoft.com/kb/813414/en-us
Ich habe einen Dienst der eine Pipe fï¿œr Read/Write zur Verfï¿œgung stellt.
Eben auch fï¿œr anonymen Zugriff.
Ich habe das Sample also geï¿œndert und die Pipe wird jetzt vom Client
Read/Write geï¿œffnet. Der Pipemode wurde auf Duplex geï¿œndert.
Das Sample auf meinem 2003 R2 Server gestartet als Server und der
Zugriff von einem anonymen Client geht.
Das Sample auf meinem Window 7 Rechner gestartet und wieder Zugriff von
einem anonymen Client geht nicht.
ï¿œndere Ich das Sample wieder so, dass nur Read Access vom Client
gefordert wird, geht es sowohl auf dem 2003 R2 Server als auch auf dem
Windows 7 Rechner.
Was ist hier anders?
BTW: Was bedeutet der Eintrag AdjustedNullSessionPipes, der hat auf
meinem Server den Wert 1 auf meinem Windows 7 Rechner den Wert 3?
--
Martin Richter [MVP] WWJD http://blog.m-ri.de
"A well-written program is its own heaven; a poorly written
program is its own hell!" The Tao of Programming
FAQ: http://www.mpdvc.de Samples: http://www.codeproject.com
Andreas Heyer
Bei meinem Vista Business gibt es in den lokalen Gruppenrichtlinien dafï¿œr
Punkte:
gpedit.msc
Computerkonfiguration->Windows-Einstellungen->Sicherheitseinstellungen->Lokale
Richtlinien->Sicherheitsoptionen
Netzwerkzugriff: Anonymen Zugriff auf Named Pipes und Freigaben
einschrï¿œnken -> Aktiviert
Netzwerkzugriff: Named Pipes, auf die anonym zugegriffen werden kann ->
netlogon,lsarpc,samr,browser
Kï¿œnnte sein, dass du deinen Pipenamen noch in der zweiten Einstellung
eintragen musst oder aber den ersten Punkt deaktivierst.
MfG
Andreas
PS: So richtig lustig finde ich das sowieso nicht mehr, die Mischung aus ACL
und einer obskuren, ï¿œberschreibenden Richtlinie wird im Netzwerkbereich
langsam undurchschaubar. Das hat aber schon mit XP (SP2) begonnen, wie viele
Anfragen gab es da wegen DCOM?
Ab Vista kann ich auch nicht mehr auf die administrativen Shares (C$)
zugreifen, selbst wenn ich mich mit einem gï¿œltigen Admin-Account anmelde.
Als Work-Around wird im Netz das Setzen von "LocalAccountTokenFilterPolicy"
empfohlen, aber schaltet das nicht effektiv UAC fￜr Admins aus?! Der Scheiￜ
wird immer komplexer... Entschuldigt, wenn ich mich jetzt zum x-ten Mal ï¿œber
MS aufrege. Aber wahrscheinlich setzen wir hier in der Gruppe aufs falsche
Pferd, Cloud rules
(http://www.heise.de/newsticker/meldung/Google-veroeffentlicht-den-Quelltext-von-Chrome-OS-Update-864431.html).
Oder aber wir werden mal gefragte Anachronismen wie heutige Cobol-Altnutzer.
:-)
Stefan Kuhr
Andreas Heyer wrote:
> <snip>
> Ab Vista kann ich auch nicht mehr auf die administrativen Shares (C$)
> zugreifen, selbst wenn ich mich mit einem gï¿œltigen Admin-Account
> anmelde. Als Work-Around wird im Netz das Setzen von
> "LocalAccountTokenFilterPolicy" empfohlen, aber schaltet das nicht
> effektiv UAC fï¿œr Admins aus?! [...]
Nein, "LocalAccountTokenFilterPolicy" hat ueberhaupt nichts mit UAC zu
tun. Mit "LocalAccountTokenFilterPolicy"!=0 wird nur erreicht, dass der
Rechner ueber RPC over named pipes erreichbar wird. Die Admin Shares
(C$, D$, ...) sind davon nur ein Artefakt, andere sind remote registry,
remote administration des service control managers, remote WMI, cfgmr32,
... also alles, was remote administrierbar ist ueber RPC. Und dieser
value muss auch nur haendisch gesetzt werden, wenn die Maschine in einer
Workgroup ist. Ist die Maschine einer Domain joined, dann ist dieser
Wert schon automatisch gesetzt, IIRC.
--
S
Martin Richter [MVP]
> Bei meinem Vista Business gibt es in den lokalen Gruppenrichtlinien
> dafï¿œr Punkte:
>
> gpedit.msc
> Computerkonfiguration->Windows-Einstellungen->Sicherheitseinstellungen->Lokale
> Richtlinien->Sicherheitsoptionen
>
> Netzwerkzugriff: Anonymen Zugriff auf Named Pipes und Freigaben
> einschrï¿œnken -> Aktiviert
> Netzwerkzugriff: Named Pipes, auf die anonym zugegriffen werden kann ->
> netlogon,lsarpc,samr,browser
Das entspricht
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters
den Werten von restrictnullsessaccess und NullSessionPipes.
Das Sample bedient diesen Registry Eintrag korrekt.
Ohne das wï¿œrde nciht mal nur lesend zugegriffen werden kï¿œnnen.
Nur Lesen geht ja, Aber warum keine Lesen/Schreiben.
Andreas Heyer
"Martin Richter [MVP]" <martin....@mvps.org> schrieb:
> Das Sample bedient diesen Registry Eintrag korrekt.
> Ohne das wï¿œrde nciht mal nur lesend zugegriffen werden kï¿œnnen.
>
> Nur Lesen geht ja, Aber warum keine Lesen/Schreiben.
Und die ACL ist auch korrekt? pipelist.exe zeigt nur die Namen und
winobj.exe kennt Pipes gar nicht, accesschk.exe macht aber seinen Job:
accesschk \pipe\myname
Sollte sich da noch nichts Ungewï¿œhnliches ergeben, kï¿œnnte man doch die
ï¿œberwachung von Windows zuschalten: SACL der Pipe geben und in den
Gruppenrichtlinien die ï¿œberwachungsrichtlinien fï¿œr z.B.
Objektzugriffsversuche und Rechteverwendung aktivieren. Das Log im
Eventviewer ï¿œberprï¿œfen.
MfG
Andreas
Andreas Heyer
"Stefan Kuhr" <kust...@gmx.li> schrieb:
> Nein, "LocalAccountTokenFilterPolicy" hat ueberhaupt nichts mit UAC zu
> tun.
Das habe ich offensichtlich mit "FilterAdministratorToken" verwechselt.
> Mit "LocalAccountTokenFilterPolicy"!=0 wird nur erreicht, dass der Rechner
> ueber RPC over named pipes erreichbar wird.
> Und dieser value muss auch nur haendisch gesetzt werden, wenn die Maschine
> in einer Workgroup ist. Ist die Maschine einer Domain joined, dann ist
> dieser Wert schon automatisch gesetzt, IIRC.
Also offensichtlich will MS selbst bei Vista Business nicht, dass man in der
Workgroup Remote Admin spielt? Langsam wird es absurd!
Und was ich nicht ganz verstehe: Sind die Namen der nicht zu erreichenden
Objekte fest einkodiert? Denn zu einem eigenen Share oder einer Pipe in der
Arbeitsgruppe kann ich auch ohne Setzen dieses Eintrages verbinden. Wie ich
vorhin schon schrieb: x Policies, die sich irgendwie ï¿œberschneiden, aber
das, was ich wirklich einstellen will, ist nicht vorhanden. Pushen die so
ihre Schulungen zum Systemadmin (MCSA)?
MfG
Andreas
Martin Richter [MVP]
> "Martin Richter [MVP]" <martin....@mvps.org> schrieb:
>> Das Sample bedient diesen Registry Eintrag korrekt.
>> Ohne das wï¿œrde nciht mal nur lesend zugegriffen werden kï¿œnnen.
>>
>> Nur Lesen geht ja, Aber warum keine Lesen/Schreiben.
>
> Und die ACL ist auch korrekt?
Muss es, oder warum funktioniert es perfekt zwischen anonymen XP und
2003 Server. Aber nicht mit dem selben Programm zwischen anonymen XP und
Windows 7?
An dem Programm selbst habe ich ja nichts geï¿œndert.
Ich habe genau dieses Sample genommen und nur die Rechte auf
Lesen/Schreiben erweitert-.
Stefan Kuhr
Andreas Heyer wrote:
> Hallo Stefan!
>
> "Stefan Kuhr" <kust...@gmx.li> schrieb:
>> Nein, "LocalAccountTokenFilterPolicy" hat ueberhaupt nichts mit UAC zu
>> tun.
>
> Das habe ich offensichtlich mit "FilterAdministratorToken" verwechselt.
>
>> Mit "LocalAccountTokenFilterPolicy"!=0 wird nur erreicht, dass der
>> Rechner ueber RPC over named pipes erreichbar wird.
>> Und dieser value muss auch nur haendisch gesetzt werden, wenn die
>> Maschine in einer Workgroup ist. Ist die Maschine einer Domain joined,
>> dann ist dieser Wert schon automatisch gesetzt, IIRC.
>
> Also offensichtlich will MS selbst bei Vista Business nicht, dass man in
> der Workgroup Remote Admin spielt? Langsam wird es absurd!
>
Das hat nichts damit zu tun, ob man Administrative Taetigkeiten
ausfuehren will oder nicht, auch auf RPC server, die man nicht im
Interesse der Administrierung erreichen will, kommt man dann nicht.
Beispielsweise auch remote desktop.
> Und was ich nicht ganz verstehe: Sind die Namen der nicht zu
> erreichenden Objekte fest einkodiert? Denn zu einem eigenen Share oder
> einer Pipe in der Arbeitsgruppe kann ich auch ohne Setzen dieses
> Eintrages verbinden.
Bist Du sicher? Das wuerde mich jetzt wundern, wenn das ginge...gleich
mal abchecken.
> Wie ich vorhin schon schrieb: x Policies, die sich
> irgendwie ï¿œberschneiden, aber das, was ich wirklich einstellen will, ist
> nicht vorhanden. Pushen die so ihre Schulungen zum Systemadmin (MCSA)?
>
Du hast schon einen Hang zur Polemik, nicht wahr? :-)
Schurz beiseite: Ich mache mir da nix draus, ich weiss, dass ich den
Wert setzen muss und gut ist, wenn ich in der Workgroup auf die Maschine
remote draufwill. Und bei unbedarften Home Usern isses gut, dass die
erstmal mit diesem standardmaessig nicht gesetzten Schalter vor
Angriffen geschuetzt sind, wenn mal wieder ein Bug im RPC Code exploitet
wird und ihnen vorher irgendein schlauer Mensch geraten hat, die
Firewall abzuschalten.
--
S
Andreas Heyer
"Stefan Kuhr" <kust...@gmx.li> schrieb:
> Das hat nichts damit zu tun, ob man Administrative Taetigkeiten ausfuehren
> will oder nicht, auch auf RPC server, die man nicht im Interesse der
> Administrierung erreichen will, kommt man dann nicht. Beispielsweise auch
> remote desktop.
So meinte ich es auch nicht! Es ging mir darum, dass dieser Wert scheinbar
nicht mir einem UI-Schalter oder einer Gruppenrichtlinie korrespondiert,
oder? Ich schalte also den Remote Desktop in meinem Vista Business in einer
Arbeitsgruppe ein, checke auch noch mal die Firewall etc. pp. und trotzdem
verbindet es nicht!? Das ist doch unlogisch und IMHO frustrierend. Frag
Martin!
> Bist Du sicher? Das wuerde mich jetzt wundern, wenn das ginge...gleich mal
> abchecken.
Nun ja, z.B. das Share der gemeinsamen Dateien kann man ja ganz einfach im
Netzwerk- und Freigabecenter einschalten, und es funktioniert auch in der
Workgroup. Zumindest ich musste dieses Registry-Flag nicht manuell setzen,
und es wurde bei mir (1 Vista Business, 2 Home Premium) auch nicht gesetzt!
Irgendwie muss da noch ein Unterschied zu z.B. den administrativen Shares
bestehen.
Laut dieses KB-Eintrages
(http://support.microsoft.com/?scid=kb%3Ben-us%3B942817&x=&y=) gehï¿œrt diese
Policy aber offenbar doch zur UAC! Kï¿œnnte es sein, dass ï¿œber das Netzwerk
nur die administrativen Accounts gefiltert werden (so wie lokal eben),
deshalb kein Zugriff auf C$ trotz Admin-Rechten mï¿œglich ist? Die
selbsterstellten Shares kï¿œnnten eine niedrigere Verbindlichkeitsstufe
verlangen, sodass die ACL zum tragen kommt.
> Du hast schon einen Hang zur Polemik, nicht wahr? :-)
Nein, ganz das Gegenteil! Ich habe mich hier schon mehrfach dahingehend
geï¿œuï¿œert, dass ich UAC und Co. zusammen mit Unmengen an Policys fï¿œr den
vollkommen falschen Ansatz halte. Die Komplexitï¿œt ist IMHO nicht mehr
durchschaubar, sieht man ja an diesem Beispiel hier. Ich kann nur immer
fragen: Wozu hat man ACLs, wenn man alles durch obskure Settings, die eben
nicht in der Win-API abgebildet werden, ï¿œberschreibt?
> Schurz beiseite: Ich mache mir da nix draus, ich weiss, dass ich den Wert
> setzen muss und gut ist, wenn ich in der Workgroup auf die Maschine remote
> draufwill.
Siehst du ja, wie genau wir Bescheid wissen: jeder hat eine andere
Erfahrung. Mï¿œchtig deterministisch! ;-)
> Und bei unbedarften Home Usern isses gut, dass die erstmal mit diesem
> standardmaessig nicht gesetzten Schalter vor Angriffen geschuetzt sind,
> wenn mal wieder ein Bug im RPC Code exploitet wird und ihnen vorher
> irgendein schlauer Mensch geraten hat, die Firewall abzuschalten.
Genau dies ist mein Kritikpunkt: Diese Art von Argument scheint sich trotz
Security Development Lifecycle immer mehr bei MS einzuschleichen. Anstatt
man einfach die Services abschaltet oder ACLs restriktiv setzt, wird eine
Policy davorgeknallt. Das ist bescheuert: Statt die Leute nicht mehr als
Admin arbeiten zu lassen, bleiben sie weiterhin in der Admin-Gruppe, aber
man filtert das Token!??? Anstatt seit Jahren bewï¿œhrte Konzepte richtig zu
nutzen, fï¿œgt man einfach einen komplexen Layer ein, der im Endeffekt nicht
mehr, sondern eher weniger Sicherheit bringt.
Dazu kommt noch, dass z.B. die Home-Versionen eben kein gpedit.msc
mitliefern. Wenn man mal ein Problem hat, steht man werkzeuglos da. Das mag
fï¿œr die Entwickler, die nur im Geschï¿œftsumfeld tï¿œtig sind, ohne Relevanz
sein, aber es gibt auch noch Leute, die SW fï¿œr die breite Masse schreiben.
Da gibt es eben keine Admins, die irgendwas mal soeben freischalten kï¿œnnen.
MfG
Andreas
Andreas Heyer
"Martin Richter [MVP]" <martin....@mvps.org> schrieb:
> Muss es, oder warum funktioniert es perfekt zwischen anonymen XP und 2003
> Server. Aber nicht mit dem selben Programm zwischen anonymen XP und
> Windows 7?
Beim Antworten auf Stefans Posting ist mir noch eine Idee gekommen: die
Verbindlichkeitsstufe! Wenn die Pipe mit hohem Integrity-Level abgesichert
ist, werden alle niedrigeren Level maximal nur Lesen kï¿œnnen, egal was die
ACL sagt. Du mï¿œsstest also mit mindestens dem gleichen Level verbinden, was
bei einem annonymen Zugriff ï¿œber das Netzwerk wohl schwierig wird.
Zusï¿œtzlich zur RW-ACL solltest du also noch der Pipe das niedrigste
Integrity-Level verpassen, wie das geht, weiￜ ich allerdings nicht.
Fï¿œr Dateien kann man das mit icacls machen, und so wie ich es verstehe, ist
das Integrity Level auch nur ein ACE in der DACL. Mit accesschk habe ich
jetz ein paar Pipes aus pipelist auf meinem Vista Business ï¿œberprï¿œft: Die
Pipes, die annonymen Zugriff ï¿œber das Netz erlauben (z.B. wkssvc -
Bestandteil vom SMB-Server?), habe nur eine niedrige Verbindlichkeitsstufe,
lokale Pipes die Standardstufe Mittel.
MfG
Andreas
Andreas Heyer
"Stefan Kuhr" <kust...@gmx.li> schrieb:
> Das hat nichts damit zu tun, ob man Administrative Taetigkeiten ausfuehren
> will oder nicht, auch auf RPC server, die man nicht im Interesse der
> Administrierung erreichen will, kommt man dann nicht. Beispielsweise auch
> remote desktop.
So meinte ich es auch nicht! Es ging mir darum, dass dieser Wert scheinbar
nicht mir einem UI-Schalter oder einer Gruppenrichtlinie korrespondiert,
oder? Ich schalte also den Remote Desktop in meinem Vista Business in einer
Arbeitsgruppe ein, checke auch noch mal die Firewall etc. pp. und trotzdem
verbindet es nicht!? Das ist doch unlogisch und IMHO frustrierend. Frag
Martin!
> Bist Du sicher? Das wuerde mich jetzt wundern, wenn das ginge...gleich mal
> abchecken.
Nun ja, z.B. das Share der gemeinsamen Dateien kann man ja ganz einfach im
Netzwerk- und Freigabecenter einschalten, und es funktioniert auch in der
Workgroup. Zumindest ich musste dieses Registry-Flag nicht manuell setzen,
und es wurde bei mir (1 Vista Business, 2 Home Premium) auch nicht gesetzt!
Irgendwie muss da noch ein Unterschied zu z.B. den administrativen Shares
bestehen.
Laut dieses KB-Eintrages
(http://support.microsoft.com/?scid=kb%3Ben-us%3B942817&x=&y=) gehï¿œrt diese
Policy aber offenbar doch zur UAC! Kï¿œnnte es sein, dass ï¿œber das Netzwerk
nur die administrativen Accounts gefiltert werden (so wie lokal eben),
deshalb kein Zugriff auf C$ trotz Admin-Rechten mï¿œglich ist? Die
selbsterstellten Shares kï¿œnnten eine niedrigere Verbindlichkeitsstufe
verlangen, sodass die ACL zum tragen kommt.
> Du hast schon einen Hang zur Polemik, nicht wahr? :-)
Nein, ganz das Gegenteil! Ich habe mich hier schon mehrfach dahingehend
geï¿œuï¿œert, dass ich UAC und Co. zusammen mit Unmengen an Policys fï¿œr den
vollkommen falschen Ansatz halte. Die Komplexitï¿œt ist IMHO nicht mehr
durchschaubar, sieht man ja an diesem Beispiel hier. Ich kann nur immer
fragen: Wozu hat man ACLs, wenn man alles durch obskure Settings, die eben
nicht in der Win-API abgebildet werden, ï¿œberschreibt?
> Schurz beiseite: Ich mache mir da nix draus, ich weiss, dass ich den Wert
> setzen muss und gut ist, wenn ich in der Workgroup auf die Maschine remote
> draufwill.
Siehst du ja, wie genau wir Bescheid wissen: jeder hat eine andere
Erfahrung. Mï¿œchtig deterministisch! ;-)
> Und bei unbedarften Home Usern isses gut, dass die erstmal mit diesem
> standardmaessig nicht gesetzten Schalter vor Angriffen geschuetzt sind,
> wenn mal wieder ein Bug im RPC Code exploitet wird und ihnen vorher
> irgendein schlauer Mensch geraten hat, die Firewall abzuschalten.
Genau dies ist mein Kritikpunkt: Diese Art von Argument scheint sich trotz
Martin Richter [MVP]
> Beim Antworten auf Stefans Posting ist mir noch eine Idee gekommen: die
> Verbindlichkeitsstufe! Wenn die Pipe mit hohem Integrity-Level
> abgesichert ist, werden alle niedrigeren Level maximal nur Lesen kï¿œnnen,
> egal was die ACL sagt. Du mï¿œsstest also mit mindestens dem gleichen
> Level verbinden, was bei einem annonymen Zugriff ï¿œber das Netzwerk wohl
> schwierig wird. Zusï¿œtzlich zur RW-ACL solltest du also noch der Pipe das
> niedrigste Integrity-Level verpassen, wie das geht, weiￜ ich allerdings
> nicht.
Danke fï¿œr den Hinweis. Werde mal suchen was es mit diesem Integrity
Level auf sich hat.
> Fï¿œr Dateien kann man das mit icacls machen, und so wie ich es verstehe,
> ist das Integrity Level auch nur ein ACE in der DACL. Mit accesschk habe
> ich jetz ein paar Pipes aus pipelist auf meinem Vista Business
> ï¿œberprï¿œft: Die Pipes, die annonymen Zugriff ï¿œber das Netz erlauben (z.B.
> wkssvc - Bestandteil vom SMB-Server?), habe nur eine niedrige
> Verbindlichkeitsstufe, lokale Pipes die Standardstufe Mittel.
Das Sample aus der KB, lï¿œsst ï¿œbrigens nicht zu, dass ich auf meinem
Windows7 Rechner die Rechte mit accesschk auf diese Pipe anzeige.
Ich bekomme die Meldung Zugriff verweigert. Komisch, weil ich mit dem
selben Benutzer Zugreife, der das Programm startet und dieser einen
GENERIC_ALL Access hat. Hierbei spielt aus ï¿œbriegnds keine Rolle welche
Art von Zugriff ich verwende (Readonly/ReadWrite).
Martin Richter [MVP]
> Beim Antworten auf Stefans Posting ist mir noch eine Idee gekommen: die
> Verbindlichkeitsstufe!
Ich finde nur das: AddMandatoryAce
http://msdn.microsoft.com/en-us/library/aa965464(VS.85).aspx
Aber was ich in der Doku lese hat nichts damit zu tun.
Hier geht es ja eher um eine weitere Einschrï¿œnkung.
Stefan Kuhr
Andreas Heyer wrote:
>
> <snip>
>> Bist Du sicher? Das wuerde mich jetzt wundern, wenn das ginge...gleich
>> mal abchecken.
>
> Nun ja, z.B. das Share der gemeinsamen Dateien kann man ja ganz einfach
> im Netzwerk- und Freigabecenter einschalten, und es funktioniert auch in
> der Workgroup. Zumindest ich musste dieses Registry-Flag nicht manuell
> setzen, und es wurde bei mir (1 Vista Business, 2 Home Premium) auch
> nicht gesetzt! Irgendwie muss da noch ein Unterschied zu z.B. den
> administrativen Shares bestehen.
>
Unglaublich. Bei einem selbst erstellten Share spielt es keine Rolle ob
dieser Value gesetzt ist. Das ist mir bisher noch nie aufgefallen.
> Laut dieses KB-Eintrages
> (http://support.microsoft.com/?scid=kb%3Ben-us%3B942817&x=&y=) gehï¿œrt
> diese Policy aber offenbar doch zur UAC! Kï¿œnnte es sein, dass ï¿œber das
> Netzwerk nur die administrativen Accounts gefiltert werden (so wie lokal
> eben), deshalb kein Zugriff auf C$ trotz Admin-Rechten mï¿œglich ist? Die
> selbsterstellten Shares kï¿œnnten eine niedrigere Verbindlichkeitsstufe
> verlangen, sodass die ACL zum tragen kommt.
>
Hhhm ja. Hat man ein administrative Shares wie c$, D$,... Admin$
gemountet, sorgt das eben immer dafuer, dass jeder andere Zugriff auf
einen RPC-Server der remote Maschine mit dem administrativen user
stattfindet, der nicht unbedingt derselbe sein muss wie der interaktiv
eingeloggte. Daher haben administrative Shares eine Sonderrolle und das
erklaert auch warum der Value fuer nicht-administrative Shares (die man
selber angelegt hat, s.o.) keine Rolle spielt.
Das kann man sehr leicht pruefen indem man eine Remote Registry
Verbindung macht zu einer Vista Box. Hat man vorher den
LocalAccountTokenfilterPolicy auf 1 gesetzt so hat man Schreibrechte in
HKLM der remote Maschine, genauso, wenn man ein Administratives Share
mountte. Ohne das hat man nur Leserechte. Es sieht fuer mich so aus, als
ob mit LocalAccountTokenfilterPolicy gleich 0 der Token der
Netzwerklogonsession auf der Remotemaschine dann ein restricted token
ist. Da ist dann auch eine Koinzidenz mit der Wortwahl in dem von Dir
zitierten Artikel ("...how to change the settings for the Remote User
Account Control...").
Naja, vielleicht gibt's ja doch irgenwo oder irgendwann eine offizielle
Erklaerung, was LocalAccountTokenfilterPolicy gleich 0 oder 1 nun
wirklich bewirken. Und ich gebe Dir recht: Eine rein phaenomenologische
Untersuchung der Sache ist nicht so wirklich befriedigend. Vielleicht
kann ja Holger Grund (so er mitliest) dafuer mal eine Erklaerung abgeben?
--
S
Andreas Heyer
"Martin Richter [MVP]" <martin....@mvps.org> schrieb:
> Aber was ich in der Doku lese hat nichts damit zu tun.
> Hier geht es ja eher um eine weitere Einschrï¿œnkung.
Doch, ich schï¿œtze, es hat genau damit zu tun. Das Integrity-Level kommt vor
der DACL.
Du gibst deiner Pipe zwar die richtige DACL, aber keine SACL. Damit erhï¿œlt
sie wohl den Standardeintrag "Mittlere Verbindlichkeitsstufe" (Medium
Integrity) mit der Policy "No Write Up". Damit kann man nicht schreibend mit
einer niedrigeren Integritï¿œtsstufe zugreifen, auch wenn die DACL das
erlaubt. Das alles ist meine Vermutung! Beim Dateibeispiel unten erhï¿œlt eine
Datei standardmￜￜig keine Integgrity-SACL verpasst, da aber bei mir auf dem
Rechner alle Pipes (pipelist.exe) mit Integrity-Level versehen sind, leite
ich das daraus ab.
Dein lokales Testprogramm wird bestimmt mit der Standard-Stufe Mittel
gestartet, erhï¿œlt also Schreibzugriff, das anonyme Logon ï¿œber das Netz wird
aber wohl ein Token mit Low Integrity erhalten (so wï¿œrde ich das zumindest
wï¿œhlen). Damit liegt es unter dem Pipe-Level und "No Write Up" kommt noch
vor der RW-ACE fï¿œr anonymen Zugriff zum Tragen. Du musst also noch eine
SACL mit Low Integrity setzen.
Im ï¿œbrigen ist das genau der Weg, wie UAC arbeitet: Das Admin-Token hat zwar
noch immer die passende DACL, um eigentlich ï¿œberall vollen Zugriff zu haben,
aber das Admin-Token erhï¿œlt ohne Elevation nur Medium Integrity. Damit wird
trotz DACL der schreibende Zugriff auf Systemeinstellungen verhindert, weil
diese mit einer SACL, die die hï¿œchste Verbindlichkeitsstufe erfordert,
versehen sind. Erst wenn die Stufe stimmt, wird die RWX-ACL bewertet, wenn
die SACL-Policy es erfordert.
Kann jeder selber testen:
1. Admin-Kommandozeile einmal normal, anderes Mal Elevated ï¿œffnen
2. In beiden "whoami /all" eingaben
3. dir > test.txt
4. dir > test2.txt
5. Normale Konsole: icacls test.txt /setintegritylevel M
6. Elevated Konsole: icacls test2.txt /setintegritylevel H
7. Normale Konsole: echo "Mehr Text" >> test.txt
8. Normale Konsole: echo "Mehr Text" >> test2.txt
9. Elevated Konsole: echo "Mehr Text" >> test.txt
Trotz passender ACL kann der Admin mit mittlerer Verbindlichkeitsstufe (non
elevated) nicht test2.txt schreiben.
MfG
Andreas
Martin Richter [MVP]
> Hallo Martin!
>
> "Martin Richter [MVP]" <martin....@mvps.org> schrieb:
>> Aber was ich in der Doku lese hat nichts damit zu tun.
>> Hier geht es ja eher um eine weitere Einschränkung.
>
> Doch, ich schätze, es hat genau damit zu tun. Das Integrity-Level kommt vor
> der DACL.
>
> Du gibst deiner Pipe zwar die richtige DACL, aber keine SACL. Damit erhält
> sie wohl den Standardeintrag "Mittlere Verbindlichkeitsstufe" (Medium
> Integrity) mit der Policy "No Write Up". Damit kann man nicht schreibend
> mit
> einer niedrigeren Integritätsstufe zugreifen, auch wenn die DACL das
> erlaubt. Das alles ist meine Vermutung! Beim Dateibeispiel unten erhält
> eine Datei standardmäßig keine Integgrity-SACL verpasst, da aber bei mir
> auf dem Rechner alle Pipes (pipelist.exe) mit Integrity-Level versehen
> sind, leite ich das daraus ab.
Du hast recht. Hier muss der Hase im Pfeffer liegen.
Das Programm läuft als Dienst, ist also sogar vom Level-High/System.
Nachdem Studium dieser Seiten wird mir auch einiges klarer:
Windows Integrity Mechanism Design
http://msdn.microsoft.com/en-us/library/bb625963.aspx
Windows Vista for Developers – Part 4
http://weblogs.asp.net/kennykerr/archive/2006/09/29/windows-vista-for-developers-_1320_-part-4-_1320_-user-account-control.aspx
Ich werde meinen Erfolg oder mein Versagen hier melden ;)
Martin Richter [MVP]
> Du hast recht. Hier muss der Hase im Pfeffer liegen.
> Das Programm läuft als Dienst, ist also sogar vom Level-High/System.
>
> Nachdem Studium dieser Seiten wird mir auch einiges klarer:
> Windows Integrity Mechanism Design
> http://msdn.microsoft.com/en-us/library/bb625963.aspx
> Windows Vista for Developers – Part 4
>
http://weblogs.asp.net/kennykerr/archive/2006/09/29/windows-vista-for-developers-_1320_-part-4-_1320_-user-account-control.aspx
>
> Ich werde meinen Erfolg oder mein Versagen hier melden ;)
Also (Teil-)Erfolg: (nach 2 Arbeitstagen)
Mein Fehler war die Ganze Zeit SECURITY_MANDATORY_LOW_RID zu verwenden.
Da Problem ist aber das Anonymer Zugriff im Integrity Level Untrusted liegt.
Ich arbeite mit SDDL String und dort war Low das niedrigste unter der
String den man auch im Netz und in der Seite
http://msdn.microsoft.com/en-us/library/bb625963.aspx findet. Dort steht
ziemlich weit unten ein Beispiel, um ein Objekt einem
"Low"-Integrity-Prozess zugänglich zu machen. Und es lautet:
#define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"
Aber wie gesagt. Anonymer Zugriff ist Integrity Level Untrusted.
Und nun wird es spaßig. Es gibt gar kein SDDL Sid für untrusted, es gibt
nur:
// Integrity Labels
#define SDDL_ML_LOW TEXT("LW")
#define SDDL_ML_MEDIUM TEXT("ME")
#define SDDL_ML_MEDIUM_PLUS TEXT("MP")
#define SDDL_ML_HIGH TEXT("HI")
#define SDDL_ML_SYSTEM TEXT("SI")
Also OK. Bauen wir uns einen eigenen Sid!
Und folglich geht es mit
_T("S:(ML;;NW;;;S-1-16-0)")
ABER!!!
Es bleibt ein Problem. Ich habe das Sample jetzt soweit angepasst, dass
es funktioniert. Ich kann jetzt den Server starten und dann den Client
von jeder beliebigen Maschine.
Aber sobald ein Rechner aus der Domäne sich mit dem Server verbindet ist
danach wieder kein anonymer Zugriff möglich.
Verbinde ich zuerst anonym so kann ich das x-mal wiederholen, bis die
erste Verbindung aus der Domäne da war. Dann habe ich das selbe Problem
wieder. Ich kann wieder nicht verbinden.
Was kann das jetzt sein?
Andreas Heyer
"Martin Richter [MVP]" <martin....@mvps.org> schrieb:
> Also (Teil-)Erfolg: (nach 2 Arbeitstagen)
Sag ich doch, alles viiiieeeel zu kompliziert. :-)
> Mein Fehler war die Ganze Zeit SECURITY_MANDATORY_LOW_RID zu verwenden.
> Da Problem ist aber das Anonymer Zugriff im Integrity Level Untrusted
> liegt.
Ähm ja, wieder mal lustig, dass sich dazu die Doku ausschweigt. Ich schätz
mal, dieses "unbekannte" Level haben die nach "Nicht vertrauenswürdige
Verbindlichkeitsstufe" übersetzt. Gefunden habe ich es so:
for /f "skip=7 tokens=1" %p in ('pipelist') do @accesschk -q -u "\pipe\%p"
Die LSASS-Pipe hat z.B. diesen Integrity-Level.
> Aber sobald ein Rechner aus der Domäne sich mit dem Server verbindet ist
> danach wieder kein anonymer Zugriff möglich.
Überhaupt keiner mehr, auch von Rechnern ausserhalb der Domäne? Und gelingt
der 1. Domänen-Zugriff auf deine Pipe auch nicht?
> Verbinde ich zuerst anonym so kann ich das x-mal wiederholen, bis die
> erste Verbindung aus der Domäne da war. Dann habe ich das selbe Problem
> wieder. Ich kann wieder nicht verbinden.
Da ich nicht verstanden habe, ob der 1. Domänenzugriff auch fehlschlägt,
weiß ich nicht, ob du evtl. nur das Domänen-Konto in deiner DACL vergessen
hast. Denn wenn aus der Domäne mal ein Zugriff (z.B. auf Share) mit
bekanntem Anmeldekonto stattfand, wird daraufhin wohl keine anonyme
Anmeldung vom selben Rechner mehr möglich sein (zumindest in einer Workgroup
funktioniert das so).
Hast du mal ein "net use \\PipeServer\IPC$ /delete" versucht, um die
erfolgte Anmeldung ungültig zu machen? Nur so kann man sich in einer
Workgroup mit zwei verschiedenen Accounts nacheinader an einem
Gruppenrechner anmelden. Vielleicht gilt das für die Domäne auch? Könnte ja
sein, dass sich die Domänenrechner nicht nur am DC anmelden, sondern auch
untereinader mit Domänenkonten, d.h. dass niemals anonymer Zugriff
stattfindet.
MfG
Andreas
PS: Tja, hättest du mal lieber einen Socket-Server gebaut oder gleich
.Net-WCF verwendet. ;-)
Martin Richter [MVP]
Zuallererst:
*Danke* für die Hilfreiche Diskussion mit Dir. Es hat mich in die
richtige Richtung gestupst.
> Sag ich doch, alles viiiieeeel zu kompliziert. :-)
10% ACK. Vor allem kriegt man irgendwann einen Knoten in die Birne bzgl.
SACL, DACL, Mandatory Label, Object Ingrity Level, Process Integrity
Level, Mandatory Integrity...
Scheußlich!
>> Mein Fehler war die Ganze Zeit SECURITY_MANDATORY_LOW_RID zu verwenden.
>> Da Problem ist aber das Anonymer Zugriff im Integrity Level Untrusted
>> liegt.
>
> Ähm ja, wieder mal lustig, dass sich dazu die Doku ausschweigt.
Ja! Es ist zum wütend werden.
Vor allem käme man ja evtl. noch drauf wenn es den SDDI String gäbe.
Dann hätte man zumindest eine Vorstellung der Möglichkeiten.
> Ich
> schätz mal, dieses "unbekannte" Level haben die nach "Nicht
> vertrauenswürdige Verbindlichkeitsstufe" übersetzt. Gefunden habe ich es
> so:
> for /f "skip=7 tokens=1" %p in ('pipelist') do @accesschk -q -u "\pipe\%p"
>
> Die LSASS-Pipe hat z.B. diesen Integrity-Level.
Logo. Auch klar, soweit ich die Sicherheit in diesen Systemen bisher
verstehe muss sie das haben.
>> Aber sobald ein Rechner aus der Domäne sich mit dem Server verbindet
>> ist danach wieder kein anonymer Zugriff möglich.
>
> Überhaupt keiner mehr, auch von Rechnern ausserhalb der Domäne? Und
> gelingt der 1. Domänen-Zugriff auf deine Pipe auch nicht?
Der Effekt *war*, dass ich weiterhin aus der Domäne verbinden konnte
aber eben nicht mehr anonym.
Aber vergessen wir das Ganze mal. Ich habe meinen Windows 7 Rechner neu
gebootet und aktuell geht alles wie gewünscht. Auch auf dem Server 2008
klappt alles.
Werde jetzt den Testcode in die Anwendung überragen...
Das Ganze endet wahrscheinlich in einem Blog-Artikel ;)
> PS: Tja, hättest du mal lieber einen Socket-Server gebaut oder gleich
> .Net-WCF verwendet. ;-)
Ja, ja. Wer den Schaden hat... usw..
Stefan Kuhr
Andreas Heyer wrote:
> <snip>
> PS: Tja, hättest du mal lieber einen Socket-Server gebaut oder gleich
> .Net-WCF verwendet. ;-)
>
Oder RPC. Meine RPC server laufen alle noch ohne irgendwelchen Probleme
unter Windows Vista/7/2008/2008R2 bis runter zu teilweise NT4 noch, im
Workgroup- und Domaenenumfeld, und benutzen dabei auch unter der Haube
named pipes. Die letzten groesseren Aenderungen, die ich da machen
musste, waren bei XPSP2 faellig, ansonsten ist das eine weitgehend
aenderungsresistente Technologie. Kein Wunder, das benutzt ja auch MS
selber als IPC-Technologie der Wahl - wenngleich zurzeit ein gewisser
Trend Richtung Webservices erfolgt - man denke nur an Exchange 2010 und
Entourage auf dem Mac.
--
S
Holger Grund [MSFT]
>
> Naja, vielleicht gibt's ja doch irgenwo oder irgendwann eine offizielle
> Erklaerung, was LocalAccountTokenfilterPolicy gleich 0 oder 1 nun
> wirklich bewirken. Und ich gebe Dir recht: Eine rein phaenomenologische
> Untersuchung der Sache ist nicht so wirklich befriedigend. Vielleicht
> kann ja Holger Grund (so er mitliest) dafuer mal eine Erklaerung abgeben?
>
Ab und an hab ich mal ein paar Minuten -- allerdings nicht genug um
hier alles nachzulesen. Was ist das Problem genau?
Soweit ich es verstehe bewirkt LocalAccountTokenfilterPolicy fuer lokale
Accounts und bei Remote Logins
= 0 => gefiltertes Token wird verwendet
= 1 => elevated Token wird verwendet
In beiden Faellen interestiert das Client Token nicht.
-hg
