Laufwerk c: dichtmachen?

[Neomis 10]

und bastele nicht auf diese Weise rum :

 

Was haben Windows-eigene Administrationsmittel bitte mit "basteln" zu tun!?

 

Für RUNAS wird auch ein berechtigtes Konto benötigt. Wenn der User solch ein Konto kennt, nützt keine NTFS-Berechtigung mehr irgendwas ...

 

Das Bezog sich auf mein "Ich-sitz-zuhause-nicht-in einem-Domänenumfeld-experiement". Da ich zu faul zum ab-und wieder anmelden bin, eignet sich runAs.

 

Also alle meine XPs aus der Tüte raus installiert haben diese Berechtigung auf c:\Windows nicht.

 

Naja, ich ha zuhause jedenfalls keine Domäne. Dazu kommt, wie ich schon erwähnt hab,

Bei 2003 weiss ich's nicht genau...

 

 

Bei Win2000 ist es z.B. so, dass man als normaler User im Domänenumfeld leicht per Batch-skript (falls nicht deaktiviert, meist aber wg. Netzlaufwerken aktiv) einen lokalen Benutzer anlegen, diesen in die Gruppe der Hauptbenutzer hinzufügen kann und ein VB-sripkt welches den IE per runAs starten kann. Und schon hab ich als "normaler User" massig Möglichkeiten. Sowas gar nicht erst möglich zu machen meinte ich mit meiner obigen "Bastelei"

[IThome 10]

Du musst aber doch, um höhere Privilegien zu erlangen, RUNAS mit einem Konto starten, welches höhere Privilegien als der derzeit angemeldete Benutzer hat. In einem Domänenumfeld z.B. kennt kein User, der eingeschränkt werden soll, solch ein Konto (sonst kann man sich die Einschränkerei sparen). Daher ist es für ihn nicht möglich, mittels RUNAS einen Prozess mit erhöhten Rechten auszuführen ...

Ein normaler User kann in einer 2000 Domänenumgebung ein Script starten und mit diesem Skript einen Benutzer zur Hauptbenutzergruppe zufügen ? :suspect:

[Neomis 10]

Wie gesagt, ich weis nicht genau wie sich das in nem 2003er Umfeld verhält, daher kann ich nur von ner Win200 Domäne sprechen.

 

ich versuch das jetzt mal detailliert zu schilder, falls ich dabei gegen geltende Boardregeln verstosse möge man es mir nachsehen ;) :

 

Situation:

User01@dom01 (normaler User ohne Sonderrechte) meldet sich an seinem APC Rechner01@dom01 an. Der Administrator der Dom01 hat das Ausführen von Skript-Dateien nicht unterbunden, da die benötigten Netzlaufwerke per Logon-skript eingebunden werden. User01 erstellt eine neue Textdatei in der er folgenden Code einfügt:

net user local local /add

net localgroup Hauptbenutzer local /add

cscript ie.vbs

das speichert er dann als ie.bat ab.

 

Als nächstes erstellt User01 erneut eine neue Textdatei und fügt diesen Code ein:

Option explicit

Dim oShell

set oShell= Wscript.CreateObject("WScript.Shell")

oShell.Run "runas /user:%computername%\local ""C:\programme\internet explorer\IEXPLORE.EXE"""

Wscript.Quit

Diese speichert er dann als ie.vbs.

 

Führt User01 jetzt die ie.bat aus, wird der IE als Benutzer local gestartet und der Zugriff auf Laufwerk C: ist uneingeschränkt möglich.

Das ist wie gesagt nur eine Möglichkeit ein simples "Ausblenden" zu umgehen.

[IThome 10]

Ob eine 2000 oder 2003 Domäne vorliegt, sollte egal sein, da die Konfiguration lokal erfolgt. Bei einer XP-Maschine als Client und einem Benutzer, der nur Mitglied der lokalen Gruppe Benutzer ist (er ist Domänenbenutzer), schlägt schon der erste Schritt (das Anlegen des Benutzers) fehl, was die weiteren Schritte überflüssig macht. Ich habe zwar keine 2000 Workstation zur Verfügung, denke aber nicht, dass sie sich anders verhält (probiere ich aber noch mal aus) ...

[Neomis 10]

Da denkst du definitiv falsch.

Unter 2000 kannst du auch ganz bequem ím Arbeitsplatz nach lusrmgr.msc suchen und diese ausführen, solange das nicht vom Admin unterbunden wird. Bei 2003 wird es wohl genau anders herum sein.

Prominentestes Beispiel:

Erstellst du eine Freigabe unter 2000 vergibt Windows automatisch Vollzugriff für "jeder". Unter 2003 gibt's hier nur Lese-Zugriff .

Wie gesagt, ich hab das Spielchen zu Demonstrationszwecken schon in 2000er Domänen praktiziert.

Aber wahrscheinlich hat Microsoft in 2003 diese Lücke geschlossen.

[IThome 10]

LUSRMGR.MSC kann ich auch bei einer XP-Maschine in einer 2003 Domäne ausführen, anlegen kann ich deswegen noch lange keine Benutzer (mit Benutzerprivilegien). Entscheidend sind die lokalen Gegebenheiten, eventuell vorkonfiguriert durch Domänenrichtlinien (z.B. Eingeschränkte Gruppen) und nicht, ob es eine 2000 oder 2003 Domäne ist. Schliesslich soll der Benutzer in der lokalen Datenbank angelegt werden und nicht in der Domäne. Hat ein Benutzer also nur Benutzerrechte auf der lokalen Maschine (weil er als Domänenbenutzer alle Rechte der lokalen Gruppe Benutzer erbt), kann er keine lokalen Benutzer anlegen, geschweige denn die eigene Gruppenzugehörigkeit verändern und somit seine Privilegien selbst anzuheben. In diesem Fall wäre das gesamte Sicherheitssystem für die Katze.

Übrigens funktioniert es mit einem 2000 Client in einer 2000 Domäne auch nicht, so wie erwartet (hätte mich auch sehr gewundert). Mit anderen Worten muss der Benutzer, der einen Benutzer anlegen will, höhere Privilegien als Benutzerprivilegien haben , Punkt ...

[Neomis 10]

...so die Theorie, aber in der Praxis sieht das anders aus. Du setzt 2000 zu sehr mit 2003 gleich. Am besten überzeugst du dich selbst davon.

Aber wenn selbst Microsoft-Mitarbeiter nicht wissen, was Windows so alles fabriziert, woher soll ich das dann wissen oO -> Interessant

[IThome 10]

Ich habe mich gerade selbst davon überzeugt. Es funktioniert genau so wie dokumentiert, Benutzer dürfen keine Benutzer anlegen , weder auf 2000 Maschinen, noch auf XP-Maschinen, weder in 2000 Domänen, noch in 2003 Domänen. Wenn es bei Dir klappte, war der Benutzer nicht nur Benutzer ...

Im Übrigen setze ich 2000 nicht mit 2003 gleich, in diesem Fall ist es auch vollkommen unerheblich. Entscheidend ist, welche Privilegien der Benutzer, der andere Benutzer anzulegen versucht, auf der Maschine hat, auf der er sie anlegen will, woher auch immer die lokale Konfiguration der Gruppenzugehörigkeiten und Benutzerrechte kommt ...

[Neomis 10]

Also in der Domäne,in der ich hier gerade arbeite bin ich simpler User und es funktioniert.

Dazu kommt noch ein Zitat von Microsoft selbst:

"Benutzer

 

Die Gruppe "Benutzer" stellt die sicherste Umgebung zur Ausführung von Programmen dar. Bei einem mit NTFS formatierten Datenträger sind die Standardsicherheitseinstellungen eines neu eingerichteten (nicht aber eines aktualisierten) Systems so konzipiert, dass Mitglieder dieser Gruppe nicht negativ auf die Integrität des Betriebssystems und der installierten Anwendungen einwirken können. Die Benutzer können weder Einstellungen in der Registrierung noch Betriebssystem- oder Programmdateien bearbeiten. Ein Benutzer kann zwar eine Arbeitsstation herunterfahren, nicht jedoch einen Server. Benutzer können lokale Gruppen zwar erstellen, sind jedoch nur zur Verwaltung der lokalen Gruppen berechtigt, die von ihnen selbst erstellt wurden. Benutzer können zertifizierte Windows 2000-Programme ausführen, die von Administratoren installiert bzw. eingesetzt wurden. Sie haben die volle Kontrolle über alle eigenen Datendateien (%userprofile%) und ihren Teil in der Registrierung (HKEY_CURRENT_USER)."

 

Quelle

 

Bleibt doch die Frage im Raum stehen: Wenn normale Benutzer Gruppen alegen können, liegt dich die Vermutung nahe, dass es auch mit Benutzern geht.

 

Wo ist deine Dokumentation?

[IThome 10]

Sag mal, was redest Du denn da ? Da steht , dass sie Gruppen erzeugen können und keine Benutzer (im Übrigen kann ich auch auf einer 2000 Maschine in einer aktuellen Standardinstallation noch nicht mal eine Gruppe erzeugen). Wir reden die ganze Zeit von Benutzer anlegen Gruppen werden auch nicht via NET USER sondern NET LOCALGROUP angelegt. Es ist doch vollkommen egal, ob sie Gruppen erzeugen können oder nicht. Diese Gruppen haben keinerlei Privilegien, also bekommt kein Mitglied dieser Gruppe Extra-Privilegien.

edit: doch noch was gefunden , erst Hauptbenutzer können Benutzerkonten erstellen, können aber Gruppenmitgliedschaften oder andere, schon existierende Konten nicht nach Belieben konfigurieren ...

Übersicht über Gruppen

Noch ein Nachtrag: Unter NT 4 Workstation konnte ein Benutzer eine lokale Gruppe anlegen, unter Windows 2000 klappt das schon nicht mehr ...

[porschinho 10]

Bei Win2000 funktioniert das definitiv. Bei 2003 weiss ich's nicht genau, aber er hat ja auch kein Sys genannt.

Ich weiss das, weil ich die Lücke letzt erst selbst unserem Admin vorgeführt hab !!

Rechtsklick -> Neu -> Verknüpfung -> C: -> oO

 

Dann hat dein Admin aber irgendwo einen Fehler eingebaut...

 

Ich habe das vor 2 Minuten auf einem Windows 2000 und einem XP Client getestet. --> Zugriff verweigert!

(Der Zugriff wurde aufgrund von Einschränkungen ...)

 

 

gruß

 

porschinho

[IThome 10]

Was hast Du probiert, das Anlegen eines Benutzers oder das Erzeugen einer Datei in der Root von C: ? Das erste scheitert, das zweite nicht ...

[grizzly999 11]

@Neomis: Also langsam reichts mir irgendwie hier.

 

Du hast keine standardmäßig eingerichteten Maschine/Domäne und was auch immer. Deine Berechtigungen z.B. auf XP's %windir% sind alles andere Default, du kannst angeblich Sachen machen, die ein normaler User seit NT 4.0 (!!) Zeiten nicht kann (lokale User anlegen), und seither auch nie konnte, und wer weiß, was du noch alles aus dem Hut zauberst, und nimmst diese verquerten Maschinen dann als Masstab deiner Sicherheitsratschläge :rolleyes: :rolleyes: :rolleyes:

 

Und statt uns dann den Tipp zu geben, das doch mal bei 2000 oder XP oder sonst was auszuprobieren oder nachzuschauen, jetzt ein guter Tipp von mir:

Gehe her, setze einen sauberen Rechner auf, von mir aus 2000 um deine tolle "Ich kann als DAU-User andere User anlegen"-Geschichte zu testen, setze von mir aus ein XP auf, mit oder ohne SP2 und schau die die Berechtigungen alle an, und DANN poste hier weiter, und tausche dich mit Leuten aus, die fit sind und Erfahrung haben. :wink2:

 

 

Vielen Dank

 

grizzly999

[IThome 10]

Vielleicht glaubt er Dir ja ...

[porschinho 10]

Was hast Du probiert, das Anlegen eines Benutzers oder das Erzeugen einer Datei in der Root von C: ? Das erste scheitert, das zweite nicht ...

 

Wenn du mich meintest: Ausblenden von Laufwerk c: mittels GPO und dann per Verknüpfung doch drauf zugreifen, sprich im Explorer öffnen. Das geht mit sicherheit nicht!!! Da kann er erzählen was er will. Zumindest nicht in einem sauber aufgesetzten System.