Jump to content

net user /domain abfrage deaktivieren


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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....!!!

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar
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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...