Jump to content

IThome

Members
  • Gesamte Inhalte

    17.751
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von IThome

  1. 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) ...
  2. Du kannst Gruppenrichtlinien auf Standort- , Domänen- und OU-Ebene definieren, Dein Vorhaben sollte also möglich sein (lokal natürlich auch). Die Priorität von niedrig bis hoch ist ... Lokal Standort Domäne OU Also je näher am Objekt, desto höher ist die Priorität ...
  3. Einfach die NTFS-Berechtigungen der CMD.EXE anpassen ...
  4. 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:
  5. Klick mal in Active Directory Benutzer und Computer mit rechts auf die Domäne z.B. und dann auf Objektverwaltung. Wenn Deine Benutzer alle in einer OU sind, dann mach es da und schau Dir diesen Assistenten an, da kannste sowas einstellen ...
  6. Was ist an dem ersten Link auszusetzen, das ist doch prinzipiell genau so, wie Du es beschreibst, nur dass die Berechtigungen in der Root restriktiver sind !? Die Berechtigungen machen genau das, was sie sollen. Ein Ordner wird unterhalb der Base-Freigabe angelegt, in der nur die Administratoren und der entsprechende Benutzer Berechtigungen haben. Weiterhin kann in der Root der Freigabe ein Benutzer keinen Ordner und keine Dateien anlegen. Wie in dem zweiten Artikel von Microsoft beschrieben, wird diese Berechtigungen des Basisrootordners nach unten vererbt, womit erreicht wird, das nur die Administratoren, eventuell noch das System (wenn es in der Root des Basisordners entsprechend berechtigt wird) und der entsprechende Benutzer auf den Basisordner berechtigt wird. Der Templateuser ist nur zum Kopieren gedacht, damit man nicht alles zu Fuss machen muss (ist in Deinem Fall nicht interessant, aber das ist ja auch nicht Dein Thread). Die Freigabeberechtigung kann auf Jeder - Vollzugriff gestellt werden. Bei den von Dir angegebenen Berechtigungen kann jeder Benutzer soviele Ordner und Dateien in der Basisfreigabe erstellen, wie er will bzw. bis die Kontingenteinschränkung greift. Weiterhin frage ich mich, warum in den Freigabeberechtigung die Authentifizierten Benutzer UND die Administratoren stehen. Wer der Besitzer dieses Ordners ist, ist für das Kontingent völlig unerheblich. Wenn der User Dateien oder Ordner in diesem Basisordner erstellt, wird er automatisch der Besitzer dieser Ordner und Dateien. Und das Besitztum ist die Berechnungsgrundlage des Kontingentes. Derjenige, der die Basisordner erstellt (und sie werden sofort erstellt, im Gegensatz zu Benutzerprofilen, die der Client anlegen kann und dann auch der Besitzer ist), wird der Besitzer dieses Ordners, aber nicht automatisch der Besitzer der Dateien, die dort erzeugt werden (von dem User, der den Ordner benutzt) ... Abe funktioniert ebenso mit diesen Berechtigungen ... Zur SIcherheit noch mal getestet auf einem 2003er ohne R2, mit Kontingentverwaltung und ABE, funktioniert exakt so, wie es soll .... Ich weiss auch nicht, welchen Artikel Du gelesen hast, in dem obigen steht jedenfalls nicht, dass beim Erzeugen des Basisordners der zukünftige Benutzer dieses Ordners der Besitzer wird. Und der Grund für das Fehlschlagen der Quotas ist das sehr wahrscheinlich auch nicht, wenn der Benutzer nicht der Besitzer ist ...
  7. Du kannst diese Berechtigung an Benutzer delegieren ...
  8. Meine auch nicht ... @Neomis Für RUNAS wird auch ein berechtigtes Konto benötigt. Wenn der User solch ein Konto kennt, nützt keine NTFS-Berechtigung mehr irgendwas ...
  9. In der Root kann er einen Ordner anlegen (das geht auch auf einem 2003 Standalone Server als normaler Benutzer). Im Windows-Ordner allerdings nicht, da dort die Vererbung unterbrochen wird und der Benutzer hier keine speziellen NTFS-Berechtigungen hat (Ordner erstellen/Daten anhängen für Diesen Ordner, Unterordner und Dateien erstellen/Daten schreiben für Nur Unterordner, also die Berechtigungen für Benutzer in der Root). Im Programme-Ordner gilt das auch. Falls die Default-Berechtigungen nicht vorhanden sind, kann man sie via SECEDIT mit dem Parameter /AREAS FILESTORE und der entsprechenden INF-Datei auf Standard setzen ...
  10. Pingen kannst Du, richtig ? Klappt eine Remotedesktopverbindung zu einem Rechner oder bekommst Du nur ein schwarzes Bild ?
  11. Eventuell hilft es auch, wenn die Leute sich mit dem UPN anmelden (user@domain) ...
  12. Eventuell liegt es an fehlenden Berechtigungen der CMD.EXE ...
  13. IThome

    Netzwerk

    Nochmal zur Klarstellung: Du rufst auf einem PC \\<Rechnername> auf, Du siehst die Freigaben des anderen Rechners und wenn Du dann auf eine klickst, wirst Du sofort verweigert ? Oder Du rufst \\<Rechnername> auf und siehst keine Freigaben und wirst sofort verweigert ? Wenn Du fsmgmt.msc ausführst (auf dem Rechner, auf dessen Freigabe zu rauf willst) , was steht dort unter Sitzungen ganz rechts unterhalb von "Gast" ? Und was hast Du alles eingestellt ? Eventuell ist auch ein Benutzerrecht nicht korrekt gesetzt ...
  14. Naja, ausgeführt wird im Sicherheitskontext des Benutzers, der sich anmeldet, egal ob das Script beim Benutzer oder in einem GPO eingestellt wird. Mach das mal sichtbar und poste die Fehlermeldung ...
  15. Dieser Parameter ist eher dafür, wenn z.B. Laufwerke beim Anmelden nicht verbunden werden, also um die Anmeldeoptimierungvon XP abzuschalten ... :)
  16. Mach das via Regkey ...
  17. Ich glaube, sowas hatten wir schon mal und es wurde mit NETSH INT IP RESET C:\RESETLOG.TXT NETSH WINSOCK RESET CATALOG bzw. WinSock XP Fix download and review - fix XP internet connectivity from SnapFiles gelöst ...
  18. Dann setze doch ein Userpassword, passe "DefaultPassword" an, anmelden, Passwort zurücksetzen, "DefaultPassword" anpassen und von neuem ... Wann hat Microsoft das geändert (ich benutze AutoAdminLogon nicht, habe immer gedacht, das mit dem Passwort gilt immer noch) ? edit: hm, bei XP steht auch, dass ein Passwort notwendig ist ... How to turn on automatic logon in Windows XP
  19. Mit RRAS und Paketfiltern oder IPSec sollte das klappen ... edit: hui, 2 Minuten und 2 Posts, zu laaaangsam :D
  20. Du kannst auf dem Server die Zeit einstellen, nachdem eine Sitzung automatisch getrennt wird (Default 15 Minuten) ... How Autodisconnect Works in Windows NT and Windows 2000 Es gibt auch Probleme, wenn die Bindungsreihenfolge der installierten Netzwerkkarten nicht stimmt, z.B. wenn eine ISDN-Karte eingebaut ist und eine virtuelle Karte installiert, die in der Reihenfolge vor der LAN-Karte ist ...
  21. Off-Topic: Nur Spass, weisst Du ja ... :)
  22. Dieses Problem ? Cmd.exe does not support UNC names as the current directory Ist das ein Anmeldescript des Benutzers oder eine Anmeldscript via GPO ? In beiden Fällen würde ich es einmal sichtbar ausführen. Im 1. Fall eine Pause einbauen, im zweiten Fall Benutzerkonfiguration - Administrative Vorlagen - System - Skripts - "Anmeldeskripts sichtbar ausführen" ...
  23. Off-Topic: Nix zweiter, dritter :D
  24. Soweit ich weiss, MUSS der User ein Passwort haben ... How To Enable Automatic Logon in Windows Zitat "Also, if no DefaultPassword string is specified, Windows automatically changes the value of the AutoAdminLogon key from 1 (true) to 0 (false), which disables the AutoAdminLogon feature." edit: knapp, aber doch zu spät :D
  25. Der SBS hat zwei Firewallrichtlinien, die aktiv sind. Eine, die die Internetverbindungsfirewall konfiguriert und eine, die die Windowsfirewall konfiguriert, im Domänen- wie im Standardprofil. Die Internetverbindungsfirewallrichtlinie hat einen WMI-Filter Pre SP2 und die Windowsfirewallrichtlinie einen WMI-Filter Post SP2. Selbst wenn keine WMI-Filter vorhanden wären, würde bei einer SP2 Maschine nur die Windowsfirewallrichtlinie wirken, wenn gleichzeitig Internetverbindungsfirewall und Windowsfirewall konfiguriert sind (steht auch so in der Beschreibung der Richtlinie) ...
×
×
  • Neu erstellen...