net user /domain abfrage deaktivieren

[MStuhldreier112 10]

Hallo Leute,

 

in unserem Netzwerk sollen die User nicht in der CMD den befehl: net user /domain ausführen können. Gibt es für diese Unterbindung ne GPO???

 

Das Netzwerk besitzt nen W2k3 Server mit AD, die Clients haben alle XP installiert.

[phoenixcp 10]

Hallo

 

Um mal ne Vorstellung von deinem Vorhaben zu gewinnen: Was versuchst du denn zu bezwecken?

Du könntest sehr wahrscheinlich die Nutzung der CMD blockieren indem du die notwendigen Rechte nimmst, du könntest ebenso die Rechte auf die net.exe einschränken, aber nur einen Parameterbestandteil einer EXE wirst du keinen Einfluss nehmen können.

 

Gruß

Carsten

[NilsK 2.918]

Moin,

 

Carstens Frage nach dem Ziel ist korrekt.

 

Rein technisch betrachtet, würde dich dein Ansatz nicht weiterbringen. Es gibt zahlreiche Wege, sich die Userkonten der Domäne aufzulisten. Da die User Leserechte auf AD haben (und auch benötigen), wirst du wohl keine Komplettlösung finden.

 

Also: Was bezweckst du?

 

Gruß, Nils

[MStuhldreier112 10]

Also wir haben das Auführen von net.exe über eine GPO unterbunden. Wenn jedoch nun ein affiner User hergeht und die net.exe aus dem windows\system32 verzeichnis wieder woandershin kopiert, dann werden die net user /domain befehle wieder ausführbar sein :/

 

 

also ist diese lösung nur ein teil meiner komplettlösung....

 

es geht mir hier einzig und allein um den datenschutz....!!!

[robotto7831a 10]

Und wer verhindert, dass der Benutzer sich PHP als Zipdatei runterlädt und in der Kommandozeile ein Skript laufen läst um sich alle Benutzer der Domäne anzuzeigen.

 

Du wirst es nie ganz verhindern können, dass keiner an die Informatioen kommt.

 

Und vor allem welche Informationen aus net user /domain sind so sensibel?

 

Frank

[MStuhldreier112 10]

ein kunde von uns möchte, dass dieser befehl aus datenschutzgründen bei clients nicht ausgeführt werden kann...! wenn ein user "x" im AD existiert, kann man über net user /domain x jede menge informationen herausfinden.

 

aus datenschutzrechtlichen gründen möchte ich das unterbinden auf wunsch des kunden...

[robotto7831a 10]

Ich habe im Hinterkopf, dass man Dateien über den Hashwert sperren kann. Dann ist es egal wo der Benutzer die Datei hinkopiert. Ich kann es aber im Moment nicht überprüfen.

 

Frank

[olc 18]

Hi,

 

neben dem Sperren von Dateien über den Hash könntest Du auch generell den Zugriff auf die CMD per GPO verweigern. Jedoch kommt man dann auch schnell als Admin in Probleme, wenn man "mal schnell" ein Troubleshooting mit Benutzerrechten machen möchte.

 

Die Hash-Wert sind jedoch auch nicht unbedingt "sicher", da unterschiedliche Programmversionen unterschiedliche Hashes haben.

 

Wie schon die Vorredner sagten: Auch ohne net.exe bekommst Du problemlos die Informationen, die Du auch über das Tool bekommen würdest. Gerade wenn die Benutzer offensichtlich genügend Kenntnis zu den Mechanismen von Gruppenrichtlinien und des Programms haben, wird solch eine simple Sperre sie wohl kaum aufhalten. Dafür gibt es genügend andere Möglichkeiten.

 

Auch wenn ich zugeben muß, daß jede Information für einen Angreifer eine wichtige Information ist: Ein Arbeitsgeber, der seinen Mitarbeitern derart mißtraut, hat etwas falsch gemacht oder sollte sich alternativ nach anderen Mitarbeitern umsehen.

 

Viele Grüße

olc

[IThome 10]

Oder ne Pfadregel und dort die NET.EXE eintragen. Die kann man dann auch hinkopieren, wohin man will. Wenn man sie umbenennt, kann man sie allerdings ausführen.

Naja, ich schliesse mich dann auch noch mal der Meinung der Kollegen an, das ist nichts Halbes und nichts Ganzes ...

[NilsK 2.918]

Moin,

 

wenn die Anforderung des AG tatsächlich umgesetzt werden soll, bringt das ganze net.exe-Verbieten rein gar nichts. Du müsstest auch noch csvde.exe, ldifde.exe, die ds*-Tools und einiges andere verbieten. Und immer noch könnte sich jemand z.B. Carmen oder José herunterladen oder sich selbst ein Skript schreiben. Oder aus Excel per ADO zugreifen. Oder eine Datei erzeugen und dort den Berechtigungsdialog aufrufen. Oder oder oder.

 

Der einzig gangbare Weg wäre, das über Berechtigungen im AD zu steuern. Aber Vorsicht, das ist erstens in der Form hochkomplex und geht zweitens ganz schnell nach hinten los: Wenn etwa Exchange im Einsatz ist und die User keine Leserechte auf andere Userobjekte haben, dürfte ihnen die Nutzung des Adressbuchs auch schwerfallen.

 

Wenn der AG tatsächlich meint, dass die Informationen im AD zu "heikel" sind, dann soll er dort nur die technisch unbedingt nötigen Daten ablegen und als Anmeldenamen keine realen Namensdaten verwenden, sondern z.B. Nummern. (Wobei das allerdings den Sinn des AD verfehlt und z.B. Exchange so auch nicht sinnvoll zu betreiben ist.)

 

Gruß, Nils

[phoenixcp 10]

Wenn der AG tatsächlich meint, dass die Informationen im AD zu "heikel" sind, dann soll er dort nur die technisch unbedingt nötigen Daten ablegen und als Anmeldenamen keine realen Namensdaten verwenden, sondern z.B. Nummern. (Wobei das allerdings den Sinn des AD verfehlt und z.B. Exchange so auch nicht sinnvoll zu betreiben ist.)

Naja, man könnte ja alle Nutzern das Flag HideFromAdressbook setzen, was dann denn Sinn des OAB ad absurdum führt. Aber ich finde die Anforderung ansich völlig überzogen. Worum hat der betroffene AG denn Angst? Welche Daten sind ihm denn so schützenswert, das er das begrenzt haben will? Ansich soll man ja eine solche Datenschutzeinstellung bei einem AG positiv hervorheben, die Frage ist nur, ab wann man anfängt mit Kanonen auf Spatzen zu schießen.

[robotto7831a 10]

Als Schützenswert sehe ich eventuell das letzte Anmeldedatum, obwohl das auch nicht immer stimmt, und die Gruppenmitgliedschaften an.

 

Frank

[NilsK 2.918]

Moin,

 

es bring wenig, wenn wir hier diskutieren, wer eventuell was für schützenswert halten könnte. Die Anforderungen werden da in der Praxis sehr unterschiedlich sein. Und letztlich ergibt es nur Sinn, Lösungen für Praxisprobleme zu entwickeln.

 

Also, wenn überhaupt, sollte der TO preisgeben, welches Schutzerfordernis tatsächlich besteht. Vielleicht wird man dies sogar mit einem relativ einfachen OU-basierten Berechtigungskonzept abbilden können. Dafür sollte sich bei Microsoft sogar ein Überblick finden lassen; ich erinnere mich an ein Whitepaper, das solche Lösungen für Exchange-Hosting skizziert.

 

Gruß, Nils

[blub 115]

Hallo,

 

download.microsoft.com/download/win2000srv/spdep/101/NT5XP/EN-US/SP_AD_Deployment.doc

 

damit, bzw. noch dem Vorgängerpapier haben wir unsere AD-Umgebung mandantenfähig aufgebaut. Allerdings war dafür schon einiger Testaufwand von Nöten

 

 

cu

blub