TheUnholyOne

Danke Sunny61. Das hab ich die ganze Zeit übersehen. Habe am WE längere Zeit mit den GPOs experimentiert und mir nochmals die Dokus reingezogen. Nun funktioniert es so, wie es halt funktioniert und ich weiß, was ich zu tun habe, wenn ich was anders haben möchte. Besten Dank an alle Helfenden! TuO

Langsam wird's klarer ^^ das steht auch in den FAQ (und Du hast wohl auch ganz zu Anfang geschrieben. Aber ok. Besser spät, als nie. Aaaaalso: Bei gruppenrichtlinien.de (Nr.35) steht es ja auch so. Das Problem, welches ich jetzt habe (und vorher auch schon hatte): Ich finde die Option "Gruppenrichtlinien Übernehmen" nicht. Habe gerade die erweiterten Sicherheitseinstellungen für eine AD-Gruppe offen und suche nach "read policy" oder "read group policy". Zum einen ist es bei gpo.de auf W2K3 bezogen, zum anderen scheinbar nicht auf den Einsatz mit dem Gruppenrichtlinien-Editor. Hier wäre es doch die Sicherheitsfilterung auf dem Reiter "Bereich"? Es steht da ja auch, dass diese GPO nur auf die folgenden Gruppen, User und Computer zutrifft. Muss ich an anderer Stelle der Sicherheitsgruppe auch noch den Zugriff auf die GPO gestatten? Wenn ja, wo denn? Oder gilt das evtl. nur für DLS und nicht für GLS? Besten Danke nochmals TuO

Ja, ich denke auch. Werde mir jetzt mal die Grundlagen durcharbeiten. Aber vielleicht eine Frage noch vorher: HIER schrieb der Thread-Opener, dass er eine AD-Gruppe mit 2 Test-PCs hinzugefügt hat und es klappte (sein eigentliches Problem habe ich ja nicht, da ich die SW garnicht verteilt bekomme). Wo ich das verlinke ist doch wohl egal, solange die Computer diese GPO erhalten. Also direkt in der OU oder vererbt. Kann mir jemand sagen, woran es liegen könnte, dass es dort DOCH mit einer AD-Gruppe in der Sicherheitsfilterung geht und hier nicht? Das würde mich sicherlich schon weiterbringen (und natürlich das Lesen der Grundlagen). Danke und Gruß TuO

OK, das werde ich als nächstes ansehen und versuchen. Jetzt gerade habe ich versucht, das umzusetzen, was Norbert im ersten Beitrag geschrieben hat: GPOs gelten nicht für Gruppen. Das konnte ich gerade feststellen, indem ich mein Testszenario umgestrickt habe: neue OU "Computer-GPO", darin enthalten die Test-PCs und eine Sicherheitsgruppe "Alle_PCs" mit allen Test-PCs. Die GPO ist auf Computer-GPO verknüpft und gilt für "Alle_PCs". Es ist also richtig, dass das nicht funktioniert? Eine andere Test-GPO gilt für "Authenticated Users" und ist ebenfalls in Computer-GPO verlinkt. Hier wird die Software installiert. Nun steht HIER Heisst das dann, es müssten ALLE Computer manuell in die Liste "Security Filtering" eingefügt werden? @ Sunny61 Da wäre ich dann bei Deinem Hinweis, einzelne Computer auszuschließen. Wie würde ich das dann machen? Wenn ich auf der OU -> Delegation -> Add -> ComputerKto gehe, kann ich nur sagen, ob dieser PC auf den Container und untergeordnete Rechte hat und nur auf den aktuellen? Ich danke Euch für die Hilfe! TuO

Danke. Kann man dann umgekehrt: Computer von der GPO ausschließen?

Hi Norbert und Danke. So etwas habe ich bereits "befürchtet". Ich habe mir DIESE Anleitung durchgelesen. In Kurzform: 1. Neue OU erstellen 2. in der OU eine Gruppe (globale Sicherheitsgruppe) 3. neues GPO-Objekt an gewünschter Stelle erstellen/verknüpfen 4. Authentifizierte Benutzer aus Sicherheitsfilterung raus (wie auch bei gruppenrichtlinien.de empfohlen) 5. Gruppe aus 2. hier rein 6. GPO bearbeiten (Softwareinstallation) 7. Client, der das Softwarepaket erhalten soll, hinzufügen Vom Grundprinzip sollte die "Anleitung 2" bei gruppenrichtlinien.de auch so funktionieren. Änlich ist es hier beschrieben. Und auch wieder grundsätzlich einleuchtend: Für jede Software eine GPO und Sicherheitsgruppe, damit es übersichtlich bleibt. Das heisst also, ich kann dieses Vorhaben vergessen und mit den genannten Anleitungen ist etwas ganz anderes gemeint? Könntest Du -oder jemand anderes- mir bitte erklären, wie dann vorzugehen ist, wenn man mehreren Clients Software zuweisen möchte, die in unterschiedlichen OUs liegen? Und wie sieht es dann mit der Übersichtlichkeit aus? Ich kann mir vorstellen, dass bestimmt in der einen oder anderen Umgebung über 10 Programme ohne WSUS etc verteilt werden. Vielleicht kann mir jemand mit einem Beispiel aus der Praxis helfen. Mit besten Grüßen TuO

Hallo Community. Ich versuche gerade, rudimentäre Kenntnisse zu Gruppenrichtlinien zu vertiefen. Im speziellen versuche ich in einer Test-Umgebung eine übersichtliche Gliederung zu erhalten und habe dafür eine OU "Softwareverteilung" angelegt. In dieser OU gibt es eine Global Security Group (Software1), die die Test-PCs enthält. Eine Gruppenrichtlinie, die hier verbunden ist, soll diese Software1 auf den Computern installieren (Computer configuration -> Policies -> Software settings -> assigned applications; User Configuration: disabled), das Programm ist zugewiesen. Vorgehen wollte ich nach der 2. Möglichkeit hier. Die betroffenen Computer sind alle im Ordner "Computer", so dass man die GPO auch einfach hier verlinken könnte. wenn ich aber darunter oder extra weitere OUs für verschiedene Architekturen oder getrennt nach PC / Laptop erstellen, muss es ja nach der 2. Möglichkeit eingerichtet werden. Die Gruppenrichtlinie ist also verknüpft, der Scope beinhaltet nur die GLS "Software1". funktionieren tut es aber nicht. Nun suche ich unter W2k8 R2 (was ich noch nicht so gut kenne) in der Gruppenrichtlinienverwaltung die Option, mit der ich festlegen kann, dass die der OU zugewiesenen GPO-Settings auch für die beinhalteten Clients gilt. Ich dachte, das wären die Security Filtering-Optionen. Nur funktioniert dies nicht. GPO-Result zeigt am Client diese GPO nicht mal an (auch nicht als "nicht zutreffend" Wenn ich ein Computer-Konto in die OU verschiebe, geht's (wie erwartet). Kann mir jemand sagen, was ich da übersehen / falsch gemacht habe? Besten Dank vorab TuO

Das Backup ist vorhanden. Ja. Dem entnehme ich, dass es kein kleines Script oder DOS-Tool gibt, mit dem man sich die Rechte zurückholen kann?! Das ist dann doch etwas zuviel Sicherheit ^^ Aber in diesem Bereich werde ich mal ein wenig rumtessten. Z.B. ist es ja gut, dass Exchange 'normal' weiterläuft (man kann nur keine User anlegen), wenn Domain-Admins auf Deny all stehen. Wenn man es dann noch damit hinbekommen hat, dass auch ein Administrator keine Postfächer mehr einsehen kann / sich Rechte nehmen kann, wäre das 'ne interessante Möglichkeit, um sicherzustellen, dass kein unkontrollierter Zugriff auf die Postfächer besteht. (Das teste ich aber lieber in 'ner Testumgebung, War genug Spannung für mich *g*). Und über adminSDHolder muss ich auch noch einiges nachholen. Besten Dank noch einmal für die Hilfe @ Norbert. CU TuO

Hi Leute, habs gelöst: Ich hatte noch einen User für Archivierung, der über volle Rechte über den Exchange verfügt. Mit dem habe ich mich angemeldet und die Domain-Admins gerade gebogen. Alternativ würde es wohl auch mit einem Mitglied der Enterprise-Admins gehen. Was mich nur interessieren würde: Was, wenn ich diesen User / die Enterprise-Admins nicht habe? Gruß TuO

Herzlichen Dank für die Hilfe, Norbert Leider habe ich gerade einen mittelprächtigen Fehler begangen: Ich habe also die Berechtigungen für Domain-Admins gelöscht. Die Usergroup selber ist aber nicht verschwunden, weil wieder etwas vererbt wurde. Da dachte ich mir, ich teste das mal über verweigern und habe mal flugs der Gruppe Domain-Admins alle Rechte verweigert (statt nur Lesen, was ich eigentlich wollte). "Kein Thema", dachte ich, " über das System (cmd -> at) kommste ran". Die Exchange-MMC bekomme ich auch geöffnet, habe auch den Reiter Sicherheit unter System bekommen, kann aber das Desaster nicht rückgängig machen. Wenn ich den Haken bei Verweigern rausnehme, kommt "Zugriff verweigert, ID-Nr. 80070005". Hmmm, kommt davon, wenn man schnell ins Wochenende verschwinden möchte :( Das ist erstmal verschoben. Ich bin da für jeden Tipp dankbar, wie ich erstmal wieder den selbst angerichteten Quatsch rückgängig machen kann. Achso: Das ursprüngliche Ziel ist damit aber erreicht, der Preis ist mir so nur etwas zu hoch^^ Grüße TuO

Danke für die schnelle Unterstützung! Also im "Mailbox Store" ist sowohl für den Administrator als auch für die Gruppe Domain-Admins "Receive As" und "Send As" zugelassen/verweigert (vererbt). Auf der Ebene "First Storage Group" hat der Administrator ebenfalls geerbte Rechte, die Gruppe der Domain-Admins ist hier neu eingetragen. HMmm, ist das normal? Da bin ich mir überhaupt nicht sicher. Eher ein wenig verwirrt gerade. Nochmal zum adminSDHolder: Hmm, ok. Ich bin immer davon ausgegangen, dass der auch die Rechte auf dem Exchange (halt alle Rechte für eine Gruppe oder einen Benutzer) zurücksetzt und man darum auch z.B. Extra-Backupuser anlegen soll (was ja auch sonst sinnig ist). *klatsch* logo ^^ Aber wenn ich mich da nicht grob verhaue, ist das auch i.O. so wie anfangs geschrieben, denn dort ist nichts geändert, wird alles vererbt?! Vielen Dank und Gruß TuO

Hi Norbert. Die Domain-Admins und der Admin selbst bekommen "Recieve As" und "Send As" verweigert von der obersten Ebene. Das ist so wohl auch richtig/standard. Trotzdem kann z.B. der Administrator alle Postfächer öffnen. Normalerweise sorgt der adminSDHolder doch auch dafür, dass die Admins keinen Zugriff haben. Das tut er aber nicht. Was meinst Du mit "auf Organisationsebene wurde dieser Haken entfernt"? Ist es nicht so, dass -wenn diese Haken gesetzt sind- der Zugriff nicht möglich ist und Einschränkungen vor Befugnissen gehen? Danke und Gruß TuO

Hallo Leute, ich habe gerade festgestellt, dass die Berechtigungen auf dem Ex2k3 (Enterprise Vault + BESAdmin konfiguriert) nicht mehr i.O. sind: Der Administrator + Mitglieder der Gruppen Domain-Admins können alle Postfächer öffnen. Das soll natürlich NICHT so sein. Ich habe einen Sicherungs-User, der den Zugriff hat. Habe dabei auch m.E. den adminSDHolder berücksichtigt, was die Gruppenmitgliedschaft des Sicherungs-Users angeht. Beim letzten Test (Test-user angelegt und mit Admin versucht zu öffnen) war alles, wie es sein sollte. Heute nun nicht mehr. Ich vermute mal, dass ich da irgendwo Mist gemacht habe (alle anderen Vermutungen möchte ich lieber nicht verfolgen). In der Technet habe ich mir die Standard-Sicherheitseinstellungen für alle Konten / Gruppen im adminSDHolder angesehen und bin der Meinung, dass alles i.O. ist. Nun weiß ich nicht, wo ich da noch schauen soll und hoffe, dass mir jemand auf die Sprünge helfen kann. Gruß TuO

Danke für die Hinweise und Anregungen !! @ carlito: Hier der Link: Account Management for Windows Server 2003: User and Location Management Architecture Guide Der Punkt, dass, wenn jemand im Netz ist, die Namen egal sind... Hmmm, klingt schon irgendwie sinnig :-) Das würde also bedeuten, dass man sich einfach 'ne schlüssige Namenskonvention überlegt, mit der man arbeiten kann / will ?! Also muss ein Sicherheitskonzept viel früher ansetzen und die Namen sind, zumindest was die Sicherheit angeht, egal ?! So würde ich das jetzt zusammenfassen. Ich werde mal bei demjenigen nachfragen, der mich erst auf diese Gedanken gebracht hat. Danke @ all Greetinx TuO

Hallo zusammen! Ich mache mir gerade Gedanken über die Servernamen im Netzwerk. Vor mir liegt ein Artikel von Microsoft, in dem steht, man solle den Namen von Servern aus Kürzeln zusammensetzen, die den Ort, die Domäne und die Funktion des Servers erkennen lassen (als Empfehlung) So hätte ich es bis vor Kurzem auch gemacht. Nun denke ich aber darüber nach, was aus sicherheitstechnischer Sicht am Besten wäre, da ein Eindringling ja schon eine Menge Daten erhält, wenn man die Namensgebung nach dieser Konvention vornimmt. Darum würde mich mal interessieren, wie andere hier darüber denken, oder ob es Argumente gibt, die die eine oder andere Variante recht sicher ausschließen können. Besten Dank Greetinx TuO

Hallo zusammen und Danke für die Hilfe! Es funktioniert nun so, wie es sollte. Zum einen habe ich jetzt von "/delete /yes" auf "/delete /y" geändert. Damit werden die Laufwerke nun richtig getrennt. Und nachdem ich die aktuelle Version vom ifmember.exe genommen hatte (Aus dem 2003 ResKit), funktionierten auch endlich alle Zuweisungen. Schöner wäre es ja, wenn MS die Möglichkeit böte, in den Eigenschaften einer Sicherheits- oder Verteilergruppe ein Laufwerk für diese Gruppe festzulegen. Dann könnt man sich diese Skripte sparen. Thx nochmal und Gruß TuO

*uups* RIchtige Befehle sollt man schon nutzen :-) Aber damit funzt es leider auch nicht. kA, woher, aber ich bekomme LW T: immer wieder. Is das mit dem IFMEMBER denn so richtig? Ich habe das ganze noch einmal mit einem Testuser durchgespielt. Habe aber auch da das gleiche Ergebnis :-(

Hi Hirgelzwift Ich habe jetzt unter extras-Netzlaufwerke trennen nachgesehen. Dort stehen alle Verbindungen drin. Ich habe dann nochmal über cmd->net use geschaut: Da steht nichts. Eine Verbindung habe ich über Extras->Netzlaufwerke Trennen getrennt. Auf dem Arbeitsplatz is das Mapping dann auch verschwunden. Das Mapping ist das, welches über IFMEMBER.EXE verbunden wurde. Ich bin nicht Mitglied der Gruppe, habe das Mapping nach dem Neustart aber wieder. Hier mal das logon.bat (SRV-Namen sind geändert) REM *** alles säubern *** net use * /delete /yes REM *** allgemeine mappings *** net use I: \\srv-dus01\gruppe1 /persist:no net use J: \\srv-dus01\abt1 /persist:no REM *** Bestimmte Anwendungen erfordern root-gemappte Laufwerke *** REM *** Das betrifft aber nur einige Anwender *** %logonserver%\netlogon\ifmember.exe _sondergruppe1 if errorlevel 1 goto sondergruppe1 goto ENDE :sondergruppe1 net use T: \\srv-rat01\Sonder /persist:no :ENDE Greetinx TuO

Hallo zusammen. Ich habe in einer 2003-er Domäne (XP-Clients) ein Logon-Script, welches die Laufwerksmappings vornimmt. Bis gerade dachte ich auch, dass alles richtig funktioniert. Nun habe ich mit Hilfe von ifmember.exe ein weiteres Mapping erstellt und getestestet. Ergebnis: Als ich NICHT Mitglied der Gruppe war, habe ich das Laufwerk NICHT bekommen. OK Als ich Mitglied der Gruppe war, habe ich das Laufwerk bekommen. Auch OK. Als ich mich anschliessend wieder aus der Gruppe rausgenommen habe, war das Laufwerk aber immer noch da. im Script steht ganz oben aber die Zeile: net use * /delete /yes Die Mappings waren bisher ganz "normal" ohne Persist: Y/N. Das habe ich jetzt auf N voreingestellt. Gerade habe ich einen Beitrag gelesen und dann gedacht, dass das persist:no schon helfen würde, die Netzlaufwerke loszuwerden. Ist aber nicht so. Gerade habe ich mir die bestehenden Verbindungen anzeigen lassen und bin jetzt noch verwirrter: C:\>net use Neue Verbindungen werden gespeichert. Es sind keine Einträge in der Liste. Beim Versuch, alle Verbindungen zu löschen bekommen ich die Meldung: C:\>net use * /delete /yes Es sind keine Einträge in der Liste. Der Arbeitsplatz hat aber alle Verbindungen, die auch aktiv sind. Vor kurzem habe ich per GPO die Eingabeaufforderung und den Aufruf von Netz-Ressourcen über "Netzwerklaufwerk verbinden..." unterbunden. Habe dabei aber angegeben, dass batch-Scripte immer noch ausgeführt werden dürfen. Kann mir jemand sagen, was ich machen muss, damit jeder PC im Netz beim Starten alle Netzlaufwerke neu holt und evtl. veraltete löscht? Besten dank und Gruß TuO

Sorry, etwas mehr Input macht schon Sinn :-) Ich hab hier schonmal angefragt: http://mcseboard.de/showthread.php?t=67864 Mit dem "falsch" meinte ich folgendes: im Netzwerk gibt es 2 Router. Einer zum Zugriff auf's Internet (192.168.2.1) und einen für eine Terminal-Verbindung zu einer anderen Firma (192.168.1.1). Alle local Clients haben die 192.168.1.1 als Gateway, weil sonst die Terminal-Verbindung nicht funktioniert. Wählt man sich über VPN (ISA) ein, so hat man ja die Möglichkeit, bei den Einstellungen der VPN-Verbindung "Standardgateway des Remotenetzwerkes benutzen" zu aktivieren. Da aber ja der ISA die Anfrage entgegennimmt und nur den Router (192.168.2.1) auf einer NIC als GW hat, laufen Anfragen für die eine Terminal-Application ins Leere. Der ISA ist so konfiguriert, dass er sich IP-Adressen für die VPN-Clients von einem DHCP-Server im netz holt. Hier ist auch das "richtige" Gateway eingetragen. Entferne ich den Haken "Standardgateway...." so zeigt mir ipconfig/all an, dass ich KEIN Gateway mehr habe. Also weder das Gateway vom ISA, noch das, welches im DHCP eingetragen ist. Und genau da liegt mein Problem. Ich weiß nicht, wie ich es hinbekommen kann, dass ich über VPN diese Anwendung nutzen kann. (Über ISDN oder analog RAS geht es). Gruß TuO

Kann mir da denn niemand 'nen Tipp geben?? :-(

Hallo zusammen! Ich habe hier ein Problem mit einer VPN-Verbindung über ISA-2004. Die Einwahl funktioniert, das Netzwerk ist verfügbar, aber das "Standardgateway des Remotenetzwerkes" ist falsch, bzw. nicht das, welches es sein sollte. Kann man das Gateway bei VPN-Clients irgendwie ändern? Danke und Gruß TuO

Hallo zusammen! Ich habe hier ein Problem beim VPN-Zugriff auf das LAN über den ISA 2004. Wenn ich den ISA-Server benutzer, um die VPN-Zugriffe entgegenzunehmen, komme ich zwar ins LAN, habe aber auf den VPN-Clients ein falsches Default Gateway. Es ist erforderlich, dass die VPN-Clients ein bestimmtes Gateway bekommen, da sie sonst bestimmte Anwendungen nicht benutzen können. Der Aufbau des Netzes sieht grob so aus: (WAN-IP)-DSL-Router-(192.168.2.1)----------(192.168.2.2)-ISA-SRV-(192.168.1.100) Im LAN gibt es einen weiteren Router, der Anfragen für bestimmte Anwendungen entgegen nehmen soll. Er hat die 192.168.1.1. Wählt man sich über ISDN in das Netzwerk ein (Karte steckt in einem Server hinter ISA), so bekommen die RAS-Clients das richtige Gateway (da der RAS-Server dieses als Default eingetragen hat). Wie kann ich es hinbekommen, dass die VPN-Clients sich ebenfalls am RAS-Server im LAN anmelden und damit auch das richtige Def-GW bekommen? Ist es irgendwie möglich, dass der ISA die VPN-Anfragen nicht selber entgegennimmt, sondern an den vorhandenen RAS-Server weiterleitet? Oder kann man irgendwie den VPN-Clients ein fixes Gateway zuweisen? Ich hoffe, da kann mir jemand helfen. Beste Grüße TuO

Generell würd ich sagen: 'ne Art Vermittlungsstelle zwischen Netzwerken. Alle Anfragen, die in einem Netzwerk nicht beantwortet können (IPs ned aufgelöst werden können), werden an das Gateway weitergeleitet, das widerrum versucht, damit was anzufangen. Greetinx TuO Etwas spät geantwortet :-)