olc

Hi Truman, entschuldige - ich habe mich wahrscheinlich ein wenig undeutlich ausgedrückt. :) Ich meinte damit, ob auch andere Einstellungen (weg von den Kennwortrichtlinien und auch weg von den Administrativen Vorlagen) nicht angezeigt werden oder nur diese konkreten Einstellungen nicht? Viele Grüße olc

Hi, 1030 / 1058 Fehler können tatsächlich viele Ursachen haben. Hat sich denn direkt vor dem Auftreten des Fehlers etwas an der Umgebung geändert? Zuerst würde ich wahrscheinlich die "üblichen Verdächtigen" überprüfen, also beispielsweise: Sind die DNS-Einstellungen auf den DCs korrekt? Ist das SYSVOL freigegeben bzw. läuft der NETLOGON Dienst? Können sich Clients problemlos anmelden bzw. bekommen diese die Group Policies? Sind die Netzwerkkartentreiber aktuell bzw. Teaming aktiv? Läuft der DFS Dienst auf den DCs? Kannst Du manuell auf die angemerkten Group Policies / gpt.ini zugreifen? Vom DC aus als Domänen-Admin als auch aus dem SYSTEM-Kontext? Viele Grüße olc

Hi, Es ist keine Sicherheitsfilterung oder WMI-Filterung auf den entsprechenden Policies aktiv? Wenn Du eine neue, leere Policy oberhalb der OU der gemischten Clients anlegst, wird diese nach einem "gpupdate /force" auf den Vista Clients über "gpresult /H Report.html" angezeigt? Nein, Vista kann im Normalfall alle die GPO-Einstellungen anwenden, in denen nicht explizit angegeben ist, daß sie nur für 2000, 2003, XP (und nicht höher) gelten. Das Policy Objekt würde jedoch so oder so über gpresult angezeigt, auch wenn nicht alle Einstellungen innerhalb der GPO übernommen werden könnten. Um das noch einmal etwas genauer zu sagen (weil ich denke, daß es mißverstanden werden kann): Nur die neuen Policies, die unter Vista hinzugekommen sind, setzen auf den ADMX-Dateien auf. Man kann auch weiterhin mit 2003 / XP Clients die alten Policies verwalten. Nur werden dann halt nicht die neuen Vista Einstellungen angezeigt bzw. wird ggf. nicht angezeigt, ob eine Policy auch für Vista greift (greifen kann). Daher muß man für die neuen Vista Policies einen Vista Client mit RSAT Tools oder 2008er Server verwenden. :) Hierbei geht es nur um die Group Policy Preferences, nicht um die normalen Policies. Die normalen Policies greifen ohne eine Installation des genannten Pakets. Das höre ich zum ersten Mal. Grundsätzlich sind die Updates zwar empfehlenswert, aber nicht unbedingt erforderlich. Zum Verständnis ist es (glaube ich) wichtig herauszustellen, daß die ADM und ADMX / ADML Dateien ausschließlich Templates für die Group Policy Einstellungen sind und nicht die Art und Weise der Anwendung auf dem Client bestimmen. Diese hat sich von 2003 / XP zu 2008 / Vista nicht geändert. Im SYSVOL der entsprechenden Policy liegen die gleichen Daten (in Bezug auf die *.pol oder *.ini Dateien). Viele Grüße olc

Hi, kannst Du den 2008er Memberserver einmal neu in die Domäne joinen? Falls ja, teste das einmal. Viele Grüße olc

Hi Michael, ich bin mir nicht sicher, wo das Problem liegen könnte. Ein ACL- / Rechteproblem in Bezug auf den Zugriff auf das Script scheint ausgeschlossen zu sein, da Du dieses als Benutzer angemeldet ausführen kannst. In Deinem Testforest läuft die Anmeldung inkl. Script korrekt durch. Eim entsprechendes Setting wäre mir ehrlich gesagt nicht bekannt. Das heißt aber nicht, daß es keines gibt. Vielleicht kannst Du mit dem ProcMon einmal (im Bootmodus) mitschneiden, was bei der Anmeldung passiert. Du filterst nach dem Scriptnamen und schaust, ob es aufgerufen wird und was die Rückgabe für den Zugriff ist. Findest Du etwas in den Event Logs (siehe Ereignisse und Protokollierung)? Viele Grüße olc

Hallo Lyrius und willkommen, ist es korrekt, daß Du von virtuellen Maschinen sprichst? Falls ja, um welches Produkt handelt es sich (VMWare, Hyper-V, Parallels etc.)? Vielleicht kannst Du das Szenario ein wenig genauer beschreiben? BTW: Dein Ausbilder hat sich sicherlich etwas dabei gedacht, Dir diese Aufgabe zu übertragen. ;) Sinn ist es eher nicht, daß Du die Lösung aufbereitet bekommst, sondern Dir erarbeitest. Das ist im Normalfall die Grundlage einer Ausbildung. :) Viele Grüße olc

Hallo Michael und willkommen im Board, was genau tut das "logon.cmd" Script? Sollte es Netzlaufwerke mappen und der angemeldete Benutzer Administrator sein, kann es hier Probleme geben, siehe http://support.microsoft.com/kb/937624/en-US . Viele Grüße olc

Hi Truman, werden alle anderen Einstellungen im RSOP korrekt angezeigt oder betrifft es alle Einstellungen? Viele Grüße olc

Hallo pep, leider sind keine Abbildungen der ACLs vorhanden. Vielleicht kannst Du diese als XCACLS Export + Freigabeberechtigungen als CODE oder aber als Textdatei über ImageShack® - Image Hosting o.ä. posten? Heißt der Namespace "testsystem.intra" oder "testsystem"? Wenn Du die Freigaben einzeln aufrufen kannst und diese leer sind, haben die Benutzer ganz offensichtlich das Recht, in die Freigaben zu "browsen". Also würde ich nochmals vermuten, daß hier die Freigabe oder NTFS ACLs auf Freigabeebene nicht korrekt sind. Die Daten unterhalb "C:\DFSRoots\datenserver" sind die Verknüpfungen zu den Namespaces. Dies ist auf den Namespaceservern erforderlich und korrekt. Hier solltest Du nach Möglichkeit nicht direkt an den ACLs etwas ändern. Viele Grüße olc

Hi, wenn der Benutzer in den Ordner wechseln kann, dann jedoch den Inhalt nicht angezeigt bekommt, würde ich vermuten, daß vielleicht doch an den Rechten etwas nicht stimmt. Gerade die Rechte auf den Ordnern, in die der Benutzer noch wechseln kann, wären hierbei interessant. Überprüfe doch noch einmal wie die Berechtigungen auf Freigabeebene als auch NTFS Ebene vergeben sind. Unter Umständen liegt hier ein Fehler und daher wird die obere Ebene noch angezeigt. Viele Grüße olc

Hi Norbert, ok - es ist also wie bereits vermutet: Standardmäßig ist der Account auch bei einem Remote-Zugriff nicht zu sperren, sondern dieses Verhalten muß "nachgerüstet" werden. "Passprop.exe" war also der Name des Programmes - an diesen konnte ich mich nicht mehr erinnern. Meiner Meinung nach ist das aber eher nicht zu empfehlen, da man sich damit vollkommen aussperren kann. Wahrscheinlich ist diese Einstellung daher auch nicht Standardeinstellung. Aber ein interessanter Satz zu dem Programm steht hier: Viele Grüße olc

Hi, wie oben geschrieben wäre ein "ipconfig /all" hinlfreich. ;) Schau einmal in den folgenden Link (unterer Bereich) - vielleicht sind "Konflikte" angegeben? Routing name suffixes across forests: Active Directory Viele Grüße olc

Hi Norbert, Da hast Du Recht. Jedoch leisten sich meist nur größere Unternehmen diesen "Luxus". :wink2: Off-Topic:Streift zwar den anderen Thread - aber mir wäre das wie gesagt neu. Wenn Du zu dem "Remote-Zugriff kann ersten Administrator Account sperren"-Thema noch etwas finden würdest, würde mich das sehr interessieren. Ich konnte jedenfalls nichts dazu finden und habe es daher gerade noch einmal getestet: Zumindest standardmäßig wird der Account nicht gesperrt. Wie gesagt gab es unter Windows 2000 dafür ein Programm, welches diese Sperre aufhob. Aber ich habe später nie wieder etwas davon gehört. Viele Grüße olc

Hi eXOs, schau einmal in den folgenden Thread - dort wird das entsprechende bcdedit Kommando genannt, welches jedoch scheinbar nicht korrekt funktioniert. Es geht zwar um Vista, aber Windows Server 2008 sollte sich da aufgrund der gleichen Codebasis nicht stark unterscheiden. KB932596 problem x64 - TechNet Forums Ich würde mir jedoch überlegen, ob ich dieses Feature tatsächlich deaktiviere oder ob es vielleicht sinnvoller ist, ein anderes Virtualisierungsprodukt (mit signiertem Treiber) zu verwenden. :) Viele Grüße olc

Hi fredy, schau einmal in den folgenden KB-Artikel, er zeigt einige mögliche Lösungsansätze: "The Local Security Authority Cannot Be Contacted" (Error 0x80090304) When You Try to Connect to a Remote Access Server Viele Grüße olc

Hi, welche DNS Server sind auf beiden Seiten eingetragen? Sind dort unter Umständen DNS-Server des ISPs oder ein Router eingetragen (als 1. DNS Server)? Ggf. bitte einmal "ipconfig /all" posten. Gibt es Fehler in den Ereignisprotokollen? Falls ja bitte ebenfalls posten. :) Viele Grüße olc

Hi, ergänzend sei noch erwähnt, daß Du zum "Dampf machen" und zum Anlegen von Benutzer, Gruppen, OUs etc. auch ADTest verwenden kannst. Download details: Active Directory Performance Testing Tool (ADTest.exe) Windows Server How-To Guides: Active Directory Stresstest mit „ADTest“ - ServerHowTo.de Viele Grüße olc

Hi Michi, Was genau meinst Du mit "Information aktiviert"? Viele Grüße olc

Hi, Da hast Du Recht, das habe ich nicht in meine Überlegungen mit aufgenommen. Vielen Dank für den Hinweis. Grundsätzlich lassen sich Änderungen in den Gruppenmitgliedschaften jedoch loggen, so daß man hier zumindest einen Alarm generieren kann, wenn sich jemand als Mitglied der Enterprise-Admin Gruppe definiert. Weiterhin haben viele größere Unternehmen genau aus diesem Grund als Root-Domäne nur Resourcen-Domänen, in denen ausschließlich die administrativen Accounts liegen. Aber Du hast Recht, sicherlich gibt viele Wege diese zusätzliche Sicherheit zu umgehen. Zumindest kann man ihn beispielsweise nicht so einfach Sperren (Stichwort: Account Lockout). Die Sache mit den Mitgliedern der Schema- und Enterprise-Admins wird immer wieder unterschiedlich diskutiert. Ich für meinen Teil habe bisher noch keine (endgültige, eindeutige und schlüssige) Empfehlung dazu finden können - weder von Microsoft, noch von anderen Sicherheitsunternehmen. Ich denke, das ist eine "Glaubensfrage". Viele Grüße olc

Hallo, Wenn alle Administratoren der Root-Domäne bzw. HQ-Domäne z.B. in einer Globalen Gruppe Mitglied sind, kannst Du diese Gruppe beispielsweise zum Mitglied der lokalen Administratoren der Zieldomänen machen. Dies ist standardmäßig zwangsweise der Fall, da die Gruppe "Domain Admins" eine Globale Gruppe ist. Hierzu eignen sich beispielsweise "Eingeschränkte Gruppen" (siehe Windows Server How-To Guides: Lokale Gruppenmitgliedschaften in der Domäne (Restricted Groups) - ServerHowTo.de oder Restricted Groups Policy Settings: Security Policy) oder einfache Computer Startup Scripts mit dem Aufruf von "net localgroup". Die Frage ist, ob das Sicherheitstechnisch wirklich gewünscht ist. Das müßt Ihr intern entscheiden. In einigen Umgebungen ist das explizit nicht gewünscht - nur können sich die "Enterprise Admins" immer jedes Recht verschaffen. Von daher ist es also eine Frage der Abwägung. Je nach Aufgabenbereich, der von den lokalen Administratoren übernommen wird, könntet Ihr Euch hier noch eine Einschränkung der Rechte überlegen: Sollte es tatsächlich "nur" um Serververwaltung geben, reichen meist "Server Operatoren" oder "Backup Operatoren" Rechte. Wenn dann zusätzlich noch AD-administrative Aufgaben durchgeführt werden sollen, reicht vielleicht eine Delegierung der Rechte aus und erfordert nicht die Zuweisung von Domänen-Admin Rechten. Aber auch hier gilt es abzuwägen und die Voraussetzungen zu prüfen. Viele Grüße olc

Hi Norbert, mh, das wäre mir in diesem Szenario neu. Aber natürlich kann auch ich mich irren. ;) Im Normalfall sollte dieser spezielle Administrator immer geschützt werden. Ich denke, daß sonst auch Netzwerkanmeldungen im Allgemeinen einen Lockout verursachen könnten - und das wird definitiv auch verhindert. Obwohl es da unter Windows 2000 noch so ein Tool gab, welches das aufheben konnte. Ich weiß nicht, ob es das auch für Windows Server 2003 / XP auch noch gibt. BTW: Mit dem Safe Mode hatte ich einen Denkfehler. Wenn man keinen Account mehr hat, um Systemdateien zu bearbeiten, muß man einen Menschen Vor-Ort haben. Viele Grüße olc

Hi, der erste Administrator der Root-Domäne ist standardmäßig auch gleichzeitig Enterprise-Admin. Dies kannst Du über die Gruppenmitgliedschaften gegenprüfen. Eine Alternative wäre beispielsweise in der Root-Domäne einen weiteren administrativen Account anzulegen, der Domänen-Admin Rechte zugewiesen bekommt. Dieser kann dann standardmäßig nicht mehr die Sub-Domänen administrieren. Der erste Administrator des Forests wird dann von Dir durch ein im Safe verwahrtes Kennwort gesichert und nur genutzt, sollten dies notwendig sein. Schau einmal hier hinein: http://www.microsoft.com/technet/solutionaccelerators/wssra/raguide/directoryservices/igdrbp_2.mspx Dort findest Du einige Hinweise zu Forest-Design Fragen. Viele Grüße olc

Hi Gulp, hi LukasB, auch von mir herzlichen Glückwunsch. :) Viele Grüße olc

Hi, der (lokale) Administrator sollte im Normalfall überhaupt nicht gesperrt werden, wenn es der erste Administrator-Account des Systems war. Heißt der Account tatsächlich "Administrator" oder reden wir hier von einem nachträglich eingerichteten Admin-Account? Falls letzteres der Fall wäre, könntest Du Dich ggf. über den ersten Administrator am System anmelden. Was meinst Du genau mit In den Safe Mode kommst Du im Normalfall ohne eine weitere Person vor dem Rechner. Viele Grüße olc

Hi Thomas, schau einmal hier hinein, es werden dort einige mögliche Ursachen genannt: "Directory Services cannot start" error message when you start your Windows-based or SBS-based domain controller Ist es möglich das Stripeset einmal aufzulösen, das Betriebssystem auf einer HDD danach neu zu installieren und es dann noch einmal zu probieren? Viele Grüße olc