Daim

Nur damit ich nicht falsch verstanden werden, ich behaupte nicht das die Gruppe DNSUpdateProxy überflüssig ist. Wie Ulf es in seinem Artikel erläutert gibt es durchaus Situationen in denen diese Gruppe ihre Verwendung findet. Aber sie sollte nicht in meinem geschilderten Fall (DHCP auf einem DC der DDNS durchführt) verwendet werden, was auch nicht notwendig ist. Siehe: DHCP, DNS and the DNSUpdateProxy-Group - Directory Services/Active Directory

Buenos tardes, trotzdem verharre ich weiter und bin anderer Meinung (wie Südländer eben so sind). ;-) Die MS-Artikel die du nennst sind mir samt allen anderen x Artikeln bezgl. der Gruppe DNSUpdateProxy bekannt. Überall steht gerade in Bezug auf DNSUpdateProxy das ganze eher verwirrend drin, wie ich finde. Rollen wir das ganze doch von vorne auf. Die Gruppe DNSUpdateProxy wurde zu Zeiten Windows 2000 eingeführt, da damals auch noch nicht die Möglichkeit bestand ein dediziertes Konto im DHCP zu hinterlegen, dass für das DDNS-Update verwendet werden konnte und man sich der Gefahr die sich daraus ergab nicht bewußt war. Das Problem stellt bezgl. des ADs das DNS dar, sei es, dass unsichere oder aber auch nur sichere DDNS Updates erlaubt werden. Fakt ist, dass DNS stellt einfach ein (sei es ein großes oder kleines) Sicherheitsrisiko dar. Sicherheitsfanatiker sehen es als vertretbar, lediglich das DNS zusätzlich auf einem DC zu installieren, nicht aber das DHCP. Denn umso weniger Dienste auf einem DC laufen, desto weniger bietet sich dem Angreifer eine Angriffsfläche dar. Das Problem das mit dem DHCP auf einem DC im Zusammenhang mit dem DDNS besteht wäre folgendes: Der DHCP-Server der auf einem DC installiert wurde, sollte eigentlich nur die Einträge verändern/entfernen können, die er verständlicherweise auch selbst angelegt hat. Auf einem DC kann der DHCP aber alle Einträge bearbeiten, weil die Privilegien von dem Konto LOCALSYSTEM es ihm erlauben. Wenn nun also ein Client mit dem Namen TEST vom DHCP-Server eine DHCP-Adresse anfordert und der DHCP-Server so konfiguriert ist, das DDNS-Update durchzuführen, überschreibt dieser ggf. den vorherigen Eintrag TEST. Das ist aber doof, wenn das DDNS-Update von einem Server durchgeführt werden soll - das Ergebnis einer DoS, ggf. auch einer Man-in-the-Middle Attacke ist. Dieser Artikel beschreibt das Problem mit dem DHCP auf einem DC: Installing Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) on a Domain Controller Fakt ist, dass DNS ist mit sicheren oder unsicheren DDNS-Updates so oder so nicht sicher. Worauf ich nun hinaus möchte; In den MS-Artikeln wird das Sicherheitsproblem mit der Gruppe DNSUpdateProxy überall beschrieben und das zusätzlich ein dediziertes Benutzerkonto hinzugefügt werden soll. Da kann ich nur sagen, dann nutze ich die Gruppe DNSUpdateProxy erst garnicht und füge trotzdem ein dediziertes Domänen-Benutzerkonto im DHCP hinzu, das für das DDNS im DHCP hinterlegt und genutzt werden kann. Somit geht mir der Eigentümer der DNS-Einträge bei einem DHCP-Server crash nicht verloren. Dieses dedizierte Konto kann ich dann auf weitere DHCP-Server in der Domäne hinterlegen. Das sind meine zwei türkische Lira dazu ;) .

Servus, natürlich nicht. Denn Namen sind in der IT "Schall und Rauch". Wenn du einen neuen Benutzer mit dem gleichen Benutzernamen einrichtest, erhält dieser trotz des gleichen Namen, eine neue SID und das ist das entscheidende. Somit bekommt das neue Benutzerkonto auch ein neues Profil. Das lässt sich aber wieder richten. Interessant wäre noch zu wissen, passiert das immer mit dem gleichen Benutzer auf dem gleichen Client? Finde heraus was passiert, wenn sich ein anderer Benutzer an dem Client anmeldet. Tritt dabei das Problem erneut auf? Teste weiter, der Benutzer bei dem es auftritt soll sich an einem anderen Client anmelden usw. usf. Was spricht das Eventlog auf dem Client? Versuche es einzugrenzen. Mein Schuss aus der Hüfte sagt Computerkonto.

Moin, die Gruppe "DNSUpdateProxy" sollte unter Windows Server 2003 nicht genutzt werden. Diese wurde unter Windows 2000 eingeführt, da es dort nicht die Möglichkeit gab, ein dediziertes Benutzerkonto unter dem die DNS-Updates durchgeführt werden sollten anzugeben, wie es unter Windows Server 2003 möglich ist. Unter Windows Server 2003 sollte ein dediziertes Domänen-Benutzerkonto erstellt werden, der im DHCP eingetragen wird.

Servus, ja. Wie? Dann fang hier an ;) : Microsoft Corporation

Salut, genau so sieht es aus mein Bub. ;) Nun leg mal los und zwar "zz" (ziemlich zügig) :D

Moin, du weißt schon, auf was Norbert verwiesen hat (auch wenn dieser Fehler schon Meterhohen Staub drauf hat) ? Dies nennt man einen Hyperlink, auf den auch drauf geklickt werden kann. Anschließend öffnet sich eine Webseite mit weiterführenden Informationen. Nun gilt es die erschienen Informationen zu lesen, zu verarbeiten, zu kontrollieren und falls es zutreffen sollte, zu beseitigen.

Nein, nicht richtig. Die FSMO-Rollen haben mit der Benutzeranmeldung überhaupt nichts zu tun. DAs Netzwerk funktioniert OHNE die FSMO-Rollen weiterhin. Erst bei der Ausführung einer Tätigkeit die eine FSMO-Rolle benötigt, merkt man das fehlen der FSMO-Rollen. Wenn der PDC-Emulator fehlt, dann funktioniert z.B. dieses nicht mehr: - Zeitabgleich - Kein Zugriff bzw. bearbeiten der GPOs - Kennwort-Änderung der Benutzer wird zum Problem - Externe Trusts Wenn der RID-Master fehlt und die DCs ihre 500 RIDs aufgebraucht haben, können keine Objekte mehr erstellt werden. Wenn der Schema-Master fehlt, können keine Schemaänderungen durchgeführt werden usw. usf. Der Benutzer merkt in seiner Arbeit nicht im geringsten das fehlen der FSMO-Rollen.

Servus, ich will auch meinen Senf dazu geben ;) . Das AD befindet sich bereits dank der AD-Replikation auf den anderen beiden DCs. Daher brauchst du dir darüber keine Gedanken machen. Auf die FSMO-Rollen die du benötigst, haben die Kollegen bereits verwiesen. Wichtig wäre noch, dass auf den anderen beiden DCs ebenfalls der GC aktiviert werden sollte. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Abgesehen davon musst du natürlich noch die Dienste (WINS, DHCP etc.) die auf dem gecrashten DC liefen, auf die anderen DCs nun neu installieren. Wenn der DHCP auf diesem lief, musst du den noch aus der Liste der autorisierten DHCP-Server entfernen. Das kannst du aber so nicht ohne weiteres. Wie das geht, erfährst du erst, wenn meine These zutrifft.

Servus, ich vermute das hier der Hase im DNS begraben liegt... Kannst du in der Quell-Domäne einen Ping auf den Domänennamen erfolgreich absetzen? Wenn der FQDN der Domäne "intra.contoso.com lautet" funktioniert dann ein "Ping intra.contoso.com" ?

Servus, genau so ist es. Die Priorität ist von oben nach unten, also wird von unten nach oben abgearbeitet ;) .

Servus, Best Practice ist es, in jedemfall die Forward Lookup Zone (FLZ) AD-integriert zu speichern. Dies ist aber nur dann möglich, wenn das DNS auf einem DC installiert wird. Denn damit brauchst du dich nicht um die synchronisation bzw. Replikation der DNS-Informationen zu kümmern. Wenn die DNS-Daten im AD gespeichert werden, erledigt die AD-Replikation für dich den Rest. Zusätzlich kannst du dann von der Einstellung "Nur sichere" Updates profitieren. Somit läufst du keine Gefahr, dass fremde Clients deinen DNS-Server kompromitieren können (theoretisch). Dabei streiten sich auch die Geister, trotz der bestehenden Microsoft-Artikeln. ;) Die relevanten Informationen kannst du aus dem Artikel, den phoenixcp verlinkt hat entnehmen. Es gibt dabei auch Unterschiede zwischen Windows 2000 und Windows Server 2003. Was man auch oft in der Praxis sieht, ist die Überkreuz-Eeinstellung. Bedeutet, auf dem ersten DC trägst du den zweiten DC ans "Bevorzugten DNS-Server" und sich selbst als zweiten DNS-Server ein und auf dem zweiten DC, trägst du das in umgekehrter Reihenfolge ein. Ja, ist es. In den meisten Umgebungen sollten alle FSMO-Rollen auf EINEM DC liegen. Lediglich in großen Umgebungen, wo sehr viel AD-lastig gearbeitet wird, macht es unter Umständen Sinn die Rollen zu trennen. Aber auch wenn die Rollen getrennt werden sollten, gilt es einiges dazu zu beachten: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Anders herum, wenn es nicht funktionieren würde, würdest du es im Eventlog protokolliert bekommen. Ansonsten kannst du die Windows Support Tools DCDIAG, NetDIAG und das mächtige DNSLint ausführen. Du musst dich dann eben mit den Tools auseinandersetzen.

Das denke ich aber nicht. Dann hast du leider nicht viel mitgenommen! Den technischen Sachverhalt den ich in diesem Thread, in der ausführlicheren Version geschrieben habe, wird exakt so nur mit anderen Worten, präzise auch in dem unten stehenden Artikel beschrieben. Man muss diesen evtl. mehrfach lesen, aber es steht das gleiche drin, wie ich es hier bereits wiedergegeben habe. Denn ich erinnere, es geht um das Szenario wann auf dem Infrastrukturmaster der GC aktiviert werden darf. Genau diese Antwort, erhälst du aus diesem Artikel (nur verstehen muss man ihn): Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben

Server, schau dir entweder den EventComb oder das mächtigere Log Parser an. Von seiner Vielfältigkeit her, wäre der Log Parser prätestiniert. Download details: Log Parser 2.2 ScriptCenter Tools: Log Parser 2.2 List of features available in the Event Comb tool

Was soll das jetzt schon wieder? Du hast das Umfeld erwähnt in dem du dich bewegst, dann darf ich das wohl doch auch. Abgesehen davon habe ich alles technische geschildert. Wenn du immer noch anderer Meinung bist, dann ist das legitim. Ob es richtig ist oder nicht, steht auf einem anderen Blatt.

Deine Meinung kannst du natürlich äussern, nur sollte sie Hand und Fuss haben. Jetzt trittst du erneut in die ... Tagtäglich. Doch, dass kann man sehr wohl. Denn die AD-Replikation kann sogar über eine 56Kb Leitung stattfinden, diese benötigt eben nur länger. Abgesehen davon, wird auf einem DC der GC aktiviert, so entsteht lediglich bei der Initialreplikation der GC Informationen etwas Replikationslast. Wenn ansonsten nicht AD-lastig gearbeitet wird, kann die GC-Replikation vernachlässigt werden. Was soll der Bridgehead-Server mit dem GC zu tun haben... Dieser ist lediglich zum einen für den standortübergreifenden Transport zuständig und zum anderen für das verteilen der AD-Daten innerhalb des Standorts. Genauso wenig wie ich es für nicht fair halte, wenn jemand ohne das er die Quelle kennt, sich noch nicht einmal die Mühe macht herauszufinden, wie vertrauenswürdig die Quelle denn ist. Übertreffe ich um längen. Ich brauche es 1.) nicht auszuprobieren, denn ich habe es Live vor mir und 2.) solltest du schon deine Hausaufgaben machen. Wenn in einer Domäne mit mehreren DCs der GC auf dem Infrastrukturmaster aktiviert ist, wird die Event-ID 1419 protokolliert. Diese wird dann alle x Minuten immer und immer wieder protokolliert, bis... du entweder den Infrastrtukrumaster auf einen anderen DC verschoben hast der KEIN GC ist oder du auf dem anderen DC ebenfalls den GC aktiviert hast. Du möchtest sicher einen Microsoft-Artikel dazu... bitte schön: Event ID 1419 Generated on a Domain Controller Ich bewege mich gerade in einem Multi-Domänen Forest in dem ALLE DCs der Gesamtstruktur (> 40) GC sind und was spricht das Eventlog? Rein garnichts. Hättest du diesen Satz nicht oder anders beschrieben: Ich halte diese Blog für nicht empfehlenswert! hätten die darauffolgenden Antworten anders geklungen. Ein Kollege von mir beschreibt das gleiche wie ich, mit diesen Worten: faq-o-matic.net » Globaler Katalog vs. Infrastruktur-Master Ich kann diesen Mhytos mit dem GC und dem Infrastrukturmaster bald nicht mehr lesen, geschweige denn dazu etwas schreiben.

Ist schon klar. Schon wieder jemand der einem nur etwas glaubt, wenn es mit einem Artikel von Microsoft bestätigt wurde... Ist erstmal eine gesunde Einstellung, aber die Quellen solltest du kennen und vorallem wissen, wem du glauben kannst und wem nicht! Da gebe ich dir TEILWEISE recht. Microsoft hat das sehr oft in sehr vielen Artikeln falsch dargestellt. Das haben sie aber mittlerweile wieder korrigiert. Dann hättest du es besser wissen müssen... Genau, aber nur dann, wenn das wie in dem verlinkten Artikel von Stephan nicht so ist! Das kannst DU gerne tun und lassen wie du möchtest. Ich frage mich, ob DU dich richtig auf deine Schüler vorbereitest! Ach noch etwas, du wolltest einen Microsoft-Artikel... dann lies selbst: Quelle: FSMO placement and optimization on Active Directory domain controllers Noch irgendwelche Anmerkungen?

Servus, siehe Stephans brilliante Antwort. ;) Auf allen. Das ist in Ordnung, denn wenn es das nicht wäre, würdest du sofort im Verzeichnisdienstprotokoll eine entsprechende Fehlermeldung diesbezüglich erhalten. Was genau die "Spezialitäten" des GC und des Infrastrukturmasters sind, entnimmst du bitte aus dem Artikel, auf den Stephan verlinkt hat. Dort ist der entscheidende Absatz, in der zweiten Aufzählung Punkt 3.

Servus, stimmt. Bei einer bedingten Weiterleitung gibst du direkt vor, dass Anfragen zu einer bestimmten Domäne an die angegebene IP-Adressen weitergeleitet werden soll. Die bedingte Weiterleitung steht auch erst ab Windows Server 2003 zur Verfügung. Es ist immer empfohlen, eine Weiterleitung einzurichten (in den Eigenschaften des DNS-Server, die Einstellung "Alle anderen DNS-Domänen"), nämlich idealerweise auf die IP des Routers. Es wird auch oft empfohlen das eine Weiterleitung auf die IP-Adresse des DNS-Servers vom ISP eingetragen werden sollte. Das hat aber den kleinen Nachteil (bei SoHo), dass wenn der ISP die IP-Adresse ändern sollte, du davon nichts mitbekommst. Ja, denn genau genommen, brauchst du keine Weiterleitung zu konfigurieren. Die Stammhinweise, dem Volksmund auch als Root-Server bekannt, reichen aus. Nur konfiguriert man trotzdem eine Weiterleitung, da die Stammhinweise nicht so schnell antworten als z.B. der DNS-Server vom ISP. Aber technisch würde es auch nur mit den Stammhinweisen funktionieren. Das bedeutet also, hast du eine bedingte Weiterleitung an die Domäne "Contoso.com" konfiguriert und der DNS-Server erhält eine Anfrage vom Client, die die Domäne Contoso.com betrifft, so leitet der DNS-Server direkt die Anfrage an den autorisierenden DNS-Server der Domäne Contoso.com weiter. Dieser beantwortet dann die Anfrage. Wenn der Client eine Anfrage stellt die z.B. ins Internet geht, so schaut der DNS-Serevr zuerst nach ob eine Weiterleitung konfiguriert wurde und verweist dann auf diesen. Falls keine Weiterleitung konfiguriert ist, schickt der DNS-Server die Anfrage an die Stammhinweise.

Servus, ändere zuerst die IP-Adresse des DCs und bereinige anschließend die Dienste DNS sowie WINS. Yusuf`s Directory - Blog - Die IP - Adresse eines Domänencontrollers ändern

Dann denke daran, die Leiche noch mit NTDSUTIL oder ADSIEdit aus dem AD zu entfernen. Befolge dabei diesen Artikel: How to remove data in Active Directory after an unsuccessful domain controller demotion

Servus, setze dich mit dem Tool SUBINACL auseinander. faq-o-matic.net » Wie halte ich die ACLs auf meinem Fileserver sauber?

Hello, also, bevor du im AD rumschraubst, muss natürlich das Routing stehen und der Standort IP-technisch von der Zentrale aus erreichbar sein (du errinnerst dich an das OSI-Layer Modell?) ;) . Wenn IP-mäßig alles in Ordnung ist, deklariere den Memberserver zum zusätzlichen Domänencontroller der bereits bestehenden Domäne (DCPROMO ausführen und die Option "zusätzlichen DC..." wählen). Was es zu beachten gilt, wenn ein weiterer DC installiert werden soll, erfährst du aus deisem Artikel: Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen Das wichtigste ist, die Forward Lookup Zone im DNS sollte AD-integriert gespeichert sein. Dann erledigt die AD-Replikation den Rest für dich. Du musst dich nach dem Heraufstufen des DCs lediglich gedulden bis die Replikation stattgefunden hat. Anschlie0end stehen dir die AD- samt DNS-Informationen auf dem neuen DC zur Verfügung. Richte dann im Snap-In "Active Directory-Standorte und -Dienste" einen Standort samt Subnetz ein und verschiebe den DC an seinen Standort. Aktualisiere danach die Standortverknüpfung. Vorallem musst du beim verschieben eines DCs an einen anderen Standort, unbedingt danach das DNS bereinigen. Ansonsten kann es zu langen Anmeldezeiten an den Clients führen. Yusuf`s Directory - Blog - Domänencontroller am Standort Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben Aber wenn vor Ort der DC nicht physikalisch sicher steht, dann solltet ihr evtl. vor Ort keinen DC aufstellen und sich die Benutzer an dem DC in der Zentrale authentifizieren lassen. Natürlich hängt das davon ab, welche Leitung zur Verfügung steht (Bandbreite und Stabilität) und was alles über die Leitung geht. Der Nachteil an dieser Variante ist, wenn die WAN-Leitung unterbrochen wäre, könnten sich die Benutzer nicht am dem DC authentifizieren. Lediglich das anmelden mit ihren zwischengespeicherten Benutzerinformationen wäre möglich. Diese Variante solltet ihr evtl. genauer prüfen. Oder wenn ihr zu Windows Server 2008 migrieren solltet, ist genau für dein Szenario, der Windows Server 2008 RODC gedacht. Yusuf`s Directory - Blog - Read-Only Domain Controller (RODC)

Eieieii... warum den mit Gewalt, also "seize"? Ich hatte doch extra geschrieben: Statt "seize" hättest du "transfer" verwenden sollen. Natürlich funktioniet TRANSFER nur, wenn der Ursprungsträger noch online ist. Denn gerade der RID-Master darf nie und nimmer zweimal in der Domäne existieren. Oder existiert der Ursprungsträger der FSMO-Rollen garnicht mehr in der Domäne? Dann wäre das ok. Falls er doch existiert, überprüfe auf dem anderen DC, wer nun in der GUI als RID-Master angezeigt wird. Ahh ok, anhand dieser Info wird bestätigt, dass der Ursprungsträger nicht mehr zu erreichen ist. Dann geht das mit "seize" in Ordnung. Exakto Mundo. Denn trotz der Angabe von "seize" wird trotzdem versucht die Rolle online zu verschieben, was eben fehlschlägt wenn der Ursprungsträger nicht mehr zu erreichen ist. Daher kommt das die irritierende Fehlermeldung wobai dann aber am Ende die Rolle trotzdem verschoben wird. Das hätte Microsoft besser geschickter lösen sollen, denn die Meldung irrtiert viele, gerade wenn man das nicht jeden Tag ausführt. Der Test beim Systemlog prüft, ob es Fehlermeldungen in den letzten 60 Minuten im Ereignisprotokoll gab. Was den KCCEVENT Test betrifft, ist auch alles im Snap-In "Standorte und Dienste" alles sauber konfiguriert (jeder DC steht an seinem Standort, Subnetze sind erstellt und mit den entsprechenden Standorten verknüpft, richtige Zuordnung der Standorte in den Standortverknüpfungen) Aber nun nochmals zum mitschreiben: Wurde der Ursprungsträger der FSMO-Rollen sauber mit DCPROMO aus der Domäne entfernt oder ist dieser gecrasht?

Bei diesem Test wird geprüft, ob sich der Domänencontroller zu allen fünf FSMO-Rollen im Active Directory, verbinden konnte, die sich entweder auf ihm selbst oder auf einem anderen Domänencontroller befinden. Es leuchtet unmittelbar ein, dass dieser Test selbstverständlich mit einem "passed" beendet werden muss. Dieser Test stellt sicher, dass der Knowledge Consistency Checker auf dem Domänencontroller auf dem er läuft, alle weiteren Domänencontroller finden kann, um Replikationsverbindungen aufzubauen. Nein, die KnowOfRoleHolder sind alle fünf FSMO-Rollen, nicht nur einer. Stelle erst einmal sicher, dass die beiden fehlenden Rollen ordnungsgemäß angezeigt werden. Führe dazu das durch, was ich in meiner vorherigen Antwort geschrieben hatte und lies dir auch den Artikel durch, den ich gepostet habe. Das du behebbare Probleme hast, die beide zusammenhängen. ;)