grizzly999

Anmerkung: funktioniert aber erst ab Windows XP. 2000 kann mit dieser GPO noch nichts anfangen .... ;) grizzly999

Das ist auch woanders ;) In einer AD-Richtlinie: Computereinstellungen\Windows Eisntellungen\Sicherheitseinstellungen\Richtlinien öffentlicher Schlüssel\Vertrauenswürdige Stammzertifizierungsstellen. Dort Das Zert der Root-CA hinzufügen grizzly999

Macht ihr Outlook über ein Modem? Ich habe bestimmt schon eine Menge Offices installiert, aber die Standortinformationen für DFÜ wollte noch keines von mir grizzly999

Das ist möglich, aber mit einer AD-integrierten CA bekommt man auf direktem Wege keine Certs für Nicht-AD-Rechner, nur über manuelle Umwege. Und wenn schon, dann auf einer Enterprise Edition installieren ;) grizzly999

Wenn das ein Forest ist, sind die Vertrauensstellungen transitiv, das kann man auch nicht ändern. Du kannst separate Forest einrcihten, dann kann mna manuelle Vertrauensstellungen beliebiger Art einrichten. Aber: Na und?! Anmelden können sie sich an einer anderen Domäne sowieso nicht. grizzly999

Was meinst du mit "Internetzertifikate"? Zertifikate von Root-CAs? grizzly999

Haben die denn die (oder der) Site-DC die DNS-Zonen überhaupt repliziert? Die DNS-Auflösung ist noch etwas unklar: Was forwardet der genau? Kannst du mit der jetzigen Einrichtung FQDNs und SRV-Records in der Domäne auf dem Problemserver auflösen? grizzly999

Jetzt verstehe ich das Anliegen, erneut von mir ein ABER: Ihr habt das alles durchdacht und geplant? Was ist anschließend (IPSec wäre jetzt entsprechend implementiert) mit Zugriff auf Netzwerkdruckern, was mit Zugriff auf andere Netzwerkgeräte wie managbare Switches, Printerboxen, um ein paar Beispiele zu nennen? Können alle Clients IPSec? Die von MS standardmäßigen Unterschiede in den DefaultExemptions-Levels für 2000/XP/2003 berücksichtigt? Wie bekommen die Nicht-AD-Clients Ihr Zertifikat, um dann anschließend IPSec damit zu machen? Das ist alles keine einfache Sache und bedarf eines großen Analyse und Planungsaufwandes, u.U. auch einen kräftigen Griff in die Portokasse, wegen neuer Hardware ...... grizzly999

Ich würde sagen, einfach den Artikel aufmerksam lesen, Betonung liegt dabei auf aufmerksam. Dort geht man in dem Beispiel von einer Migration von 2000 als Quell-Domäne auf 2003 als Zeildomäne aus. Aus Sicht der 2000 Domäne snid dann in dem Artikel die Begriffe trusting domain und trusted domain genau erklärt, auch welcher Adminaccount usw. Das ganze lässt sich natürlich auch auf zwei 2003 Domänen übertragen. Am besten machst du das in beiden Domänen in beide Richtungen, das Disablen der SID-Filterung, dann bist du garantiert richtig, und die Zugriffe klappen egal in welche Richtung ;) ACHTUNG: Wenn man netdom bei 2003 verwendet, heißt der Paramter hinten nicht /Filtersids:yes|no sondern /EnableSIDHistory:yes|no grizzly999

Solange du auf den Computer als Administrator drauf kommst, gibt es einen von Microsoft vorgeschlagenen Weg: How to Change the Recovery Console Administrator Password on a Domain Controller Fällt auch nicht unter die Boardregel 8, da du ja bereits Domänen-Admin-Zugriff haben musst ;) grizzly999

Ei jo, so wie dort mit dem netdom-befehl beschrieben ;) grizzly999

Out Of the Box: Einfach CD rein, installieren, dcpromo. Dann läuft die Domäne - auch 2003 - im 2000 gemisht Modus. Aber in dem Fall nciht. Aber dann ist das der "Standard-fehler" einer Migration mt dem verweigerten Zugriff: SID-Filterung nicht ausgeschaltet (Dieser Fehler hier: Error message when you try to access shared resources on a Windows 2000-based trusting domain from a Windows Server 2003-based trusted domain: "Access is denied") ;) Ausschalten der SID-Filterung auch im Artikel steht drin.... grizzly999

Das hat nichts zu sagen. Eine 2003 Domäne kann auch im 2000-gemischt DFL aufen, tut sie Out-of-The-Box auch. In diesem Domain Functional Level kann keine SID-Migration stattfinden ;) grizzly999

Für die Gruppenmigration ist hier ganz unten ein Screenshot, in dem das entsprechende Häkchen zu sehen ist: SolutionBase: Migrating Windows NT to Windows Server 2003 using the Active Directory Migration Tool Un hier eine bebilderete anleitung, wie man mit ldp.exe die SID-History eines Benutzers anschauen kann: Mark Wilson's Blog : How to migrate users between Active Directory forests using ADMT when the source and target domain names are similar grizzly999

Ups?! Zieldomäne läuft mindestens im "2000 Pur Functional Level"?

Würde mich auch wundern, wenn die Migration ohne SidHistory stattgefunden hätte. Was ist denn das Problem? Migrierter User der neuen Domäne bekommt auf Resourcen in der alten Domäne "Zugriff verweigert", wo er vorher zugreifen konnte? grizzly999

Hallo und willkommen im Board :) Hast du uns etwas mehr Informationen (gleich für die Zukunft merken ;) )? Eine Domäne, mehrere? Mehrere Sites (vermutlich, da BH)? Wieviele DCs an den Sites? Wo kommt/steht der Fehler (Eventlog,Replmon, Repadmin,etc)? Wie heißt die vollständige Meldung und Ereignis-ID (wenn im Ereignis-Log)? Auf welchem Server erscheint die Fehlermeldung? Weitere Fehlermeldungen? Auf anderen Servern auch Fehlermeldungen? usw. grizzly999

Wenn Benutzer und Gruppen mit ADMT und SidHistory migrifert wurden, und die SID-Filterung augeschaltet wurde, sollten Zugriffe auf die Resourcen - mit Ausahme des benutzerprofils - eigentlich kein Problem sein. Zumindest war das bei meinen Migrationen immer so. grizzly999

Um auf die Frage oben zu antworten: Das ist durchausmöglich, auch ohne Ca und Zertifikate, Stichwort "IPSec" schon gennant, ABER: Man sollte da wirlich sehr gutes KnowHow haben,man braucht manuell angepasste IPsec-Richtliniene, außer man nimmt die Standardrichtlinie "Server-Sicherheit anfordern". Dann kann es allerdings auch sein, dass unverschlüsselte Kommuniation stattfinden kann. Zudem sollte man sich bewußt sein, dass IPSec auf einem DC möglich ist, aber von Microsoft nicht supportet wird. Außerdem stellt sich die Frage, warum soll der ganze Verkehr zum DC verschlüsselt werden? Ist das wirklich nötig. Wenn man - vielleicht auch berechtigte -Angst vor "Informaton Disclosure", "Tampering" oder anderen Netzwerkangriffen hat, sind da andere Server im netz mit Sicherheit bessere und begehertere Ziele. Dazu kommt, dass solch' eine Maßnahme nur eine von ganz vioelen im Bereich Security sein kann, was meist dann nicht der Fall ist, bzw. um es deutlicher zu sagen, Ich verschlüssele hier den Verkehr, aber an anderen Stellen nicht, lasse schlampige Kennwörter zu, oder LM-Authentifizierungsverkehr, da kann ich mir den Aufwand punktuell an dieser Stelle sparen. Daher eben die Frage: Was will ich mit dieser Maßnahme erreichen? grizzly999

Wenn du eine Verweigern-Regel einrichtest, kannst nach Abschluß der Regeleinrichtung in den Regeleigenschaften unter "Aktion" eine alternative URL (z.B. zu einer internen Seite mit einer selberdefinierten Fehlermeldung) einrichten, wohin der Benutzer umgeleitet werden soll. Das sollte doch das sein,was du wolltest? grizzly999

Tja, da ht jemand (der TO) den Sinn einer Firewall nicht verstanden :rolleyes: grizzly999

Schon mal die Boardsuche benutzt? Z.B. hier: http://www.mcseboard.de/windows-forum-allgemein-28/man-pogrammpfad-aendern-104808.html u.a. grizzly999

Was du das siehst, ist der SOA-Eintrag der Zone ;) grizzly999

Einen 2003 Server als Member in einer 2000 Domäne ist gar kein Problem, aber kein SBS. Der ist DC und zwar muss es der erste DC sein und alle FSMO Roles halten. Es gibt Artikel, wie man einen SBS in eine vorhandene Domäne bringen kann und dann alles auf ihn umswitcht, aber nein, als Member :nene: Wenn man einen 2003 Member Server in einer 2000 Domain zum DC machen will, muss man zuerst das Schema auf einem 2000 DC auf 2003 updaten, bevor man das dcpromo durchführen kann: How to upgrade Windows 2000 domain controllers to Windows Server 2003 grizzly999

Ja, da gibt es einen "Code" für die Hersteller (nicht Hardware, sondern OS). Finde ich im Moment nicht, aber ^311 ist der Code für Microsoft. Die Regel lautet also übersetzt, wenn Betriebssytem=Microsoft grizzly999