Jump to content

Daim

Members
  • Gesamte Inhalte

    4.534
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Daim

  1. Wo hat denn ein Client den Logon Server eingetragen? Logon-Server ist jeder DC, auf dem der KDC läuft. Entscheidend ist das DNS. Deshalb sollte jeder Client zwei DNS-Server kennen. Wenn sich ein Client morgens authentifiziert, bekommt dieser ein Kerberos-Ticket das für 10 Stunden gültig ist. Der Client während seiner Arbeit kein Problem, SOLANGE er einen verfügbaren DNS-Server erreichen kann. Ja, in deiner überschaubaren Umgebung würde ich auf jedem DC den GC aktivieren.
  2. Buenos dias, dabei sollte die Forward Lookup Zone idealerweise AD-integriert gespeichert sein. Dann deklariere doch beide DCs zum GC. Wenn einer von beiden crashen sollte und den Clients beide Server als DNS-Server bekannt sind, merken die Clients erstmal nichts von dem Crash. Es sei denn, es läuft ein Dienst oder eine Applikation auf dem gecrashten DC, dann würden es die clients schnell merken. Auch läuft die Domäne normal weiter, wenn der Träger der FSMO-Rollen crashen sollte. Erst wenn eine Aufgabe durchgeführt werden soll, in der einer der FSMO-Rollen benötigt wird, erhält man eine Fehlermeldung. Oder wenn der RID-Pool des DCs verbraucht wurde, versucht der DC den RID-Master zu erreichen. Falls der DC keinen neuen RID-Pool anfordern kann, kann der DC keine weiteren Objekte mehr einrichten (wie z.B. einen neuen Benutzer). Wenn der einzigste GC crashen sollte, stehen keine Forestweiten AD-Informationen zur Verfügung. Wie bereits erwähnt, dann läuft die Domäne normal weiter. Du musst die FSMO-Rollen dann mit Gewalt auf einen anderen DC verschieben (seizen). Anschließend entfernst du händisch mit NTDSUTIL oder ADSIEdit die Leiche aus dem AD. Wenn du die FSMO-Rollen extra vom GC getrennt hast wegen der "Problematik" zwischen dem Infrastrukturmaster und dem GC, beachte in diesem Artikel in der zweiten Aufzählung den Punkt 3: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben How to remove data in Active Directory after an unsuccessful domain controller demotion Auch hier wie breits beschrieben, stehen dann die Gesamtstrukturweiten Informationen nicht zur Verfügung. Wenn der einzigste GC crashen sollte, bekommst du z.B. beim erstellen eines neuen Benutzers jedesmal eine Warnmeldung im Snap-In "Active Directory-Benutzer und -Computer". Die Benutzer in der Domäne können sich aber weiterhin - auch ohne GC - anmelden, wenn es sich um einen Single-Domänen Forest handelt. Also es existiert nur eine Domäne in der Gesamtstruktur. Existieren hingegen mehrere Domänen in der Gesamtstruktur und der GC crasht, so kann sich der Benutzer nicht anmelden. Daher, aktiviere auf beiden DCs den GC. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Sehr gut. Gehe dazu diesem Artikel nach: Event ID 53258 is logged in Event Viewer after you install or remove Active Directory in Windows Server 2003 Du betreibst hoffentlich einen WSUS. Wenn nicht, dann solltest du das. Ich würde NICHT die Update automatisch installieren lassen auf den Servern, sondern von Hand installieren (wenn möglich-je nach Größe der Umgebung). Aktiviere auf beiden DCs den GC und beobachte das weiter. Falls das Verhalten nur bei einem Neustart auftauchen sollte, würde ich das vernachlässigen.
  3. Servus, oftmals ist es in verteilten Umgebungen so, dass vor Ort an einem Standort ein EDV-Beauftragter existiert, der sich z.B. um die Datensicherung auch "wenige/leichte" Administrationsaufgaben vor Ort kümmert. Der EDV-Beauftragte benötigt aber im Prinzip lediglich die Rechte auf die LOKALE Maschine und nicht auf die Domäne. Mit dem RODC kann er nun die lokale Maschine, aber nicht die Domäne, administrieren. Wird die Maschine geklaut, besteht ebenfalls keine Gefahr für die Domäne, denn das AD sowie DNS ist auf dem RODC "Read-Only". Oder die Fertigstellung der RODC-Installation kann nun vor Ort, von dem EDV-Beauftragten fertiggestellt werden, der KEINE Domänen-Admin Rechte besitzt. Yusuf`s Directory - Blog - Die Installation eines RODC Ja, sofern die Benutzer- sowie Computerkontokennwörter nicht auf den RODC repliziert wurden, was man aber tuen würde. Denn wenn mal der WAN-Link unterbrochen ist und sich die Kennwörter nicht vor Ort auf dem RODC befinden, kann sich solange der WAN-Link down ist, keiner an dem RODC authentifizieren. Du kannst von bestimmten Benutzern sowie Computerkonten die Kennwörter auf den RODC replizieren lassen. Weiterhin kannst du dir bei einem Diebstahl anzeigen lassen (in den Eigenschaften des RODC-Computerkontos), welche Kennwörter auf den RODC repliziert waren. Somit bekommst du nun die Möglichkeit, die "geklauten" Kennwörter zu resetten. Wenn sich nun ein Benutzer gegenüber einem RODC authentifizieren möchte, überprüft der RODC ob er das Kennwort des Benutzerkontos vorliegen hat. Falls das nicht der Fall ist, leitet er diese Anmelde-Anfrage an einen beschreibbaren DC weiter erhält von diesem dann ein Kerberos-Ticket. Danach stellt der RODC dem Benutzer ein eigenes Kerberos-Ticket aus. Zeitgleich stellt der RODC eine Replikationsanforderung nach dem Kennwort des Benutzers an einen beschreibbaren DC. Der beschreibbare DC überprüft dann, ob der RODC dazu die Berechtigung hat und repliziert ggf. das Passwort-Hash zum RODC. Yusuf`s Directory - Blog - Read-Only Domain Controller (RODC) Ja, der RODC kann auch GC sein. Es ist eine primäre Zone, worauf der RODC keine Rechte bekommt. DNS-Updates leitet der RODC auf einen beschreibbaren DC weiter und der RODC repliziert sich die Informationen dann. Jeder DC hat noch eine lokale SAM. Denn was denkst du, wo das Konto für den DSRM gespeichert wird ;) . Aber das Verhalten bezgl. des RODCs ist ein anderes. Siehe oben meinen ersten Link.
  4. Servus, warum nicht gleich auf Windows Server 2008? Du kannst den Windows 2000 DC per Inplace-Upgrade auf Windows Server 2003 aktualisieren, dass ist möglich. Jedoch würde ich diese Variante nicht unbedingt durchführen, sondern die Migration durch neue Hardware erledigen. Per Inplace-Upgrade funktioniert das ganze so: Yusuf`s Directory - Blog - Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update) Nein, wozu? Das ist nicht notwendig. Idealerweise würde ich wie bereits erwähnt die Migration durch zusätzliche Hardware durchführen. Dabei würde ich folgendermaßen vorgehen: Zu allererst sollte ein /aktuelles/ sowie natürlich funktionierendes Backup vom System State existieren. Du musst im ersten Schritt das Active Directory-Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Du führst das ADPREP mit dem Parameter /FORESTPREP auf deinem 2000er Schema-Master aus. Anschließend führst du ADPREP mit den Parametern "/DOMAINPREP /GPPREP" auf dem Infrastruktur-Master in der Domäne aus, in der du den neuen Server hinzufügen möchtest. Danach füge den neuen Server als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Deine Forward Lookup Zone (FLZ) im DNS sollte auf deinem 2000er DC idealerweise AD-integriert gespeichert sein und "Nur sichere" Updates zulassen". Wenn die FLZ im AD gespeichert ist, erleichtert dir die Replikation das Leben ein wenig. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du die DNS-Server Einstellung verändern. Siehe: Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ? Somit hast Du das AD und DNS auf Deinen neuen DC "gesichert". Dann solltest Du die 5 FSMO-Rollen auf den neuen DC noch verschieben: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Zusätzlich solltest Du den neuen DC zum GC deklarieren. Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Was sonst noch alles zu beachten ist und wie du die einzelnen Dienste übernehmen kannst, erfährst du aus diesem Artikel: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen Zum Schluss noch eine Empfehlung: Wenn möglich, sollten in jeder Domäne zwei DCs existieren.
  5. Servus, genau so ist es. Ganz nach dem Motto: Wer zuerst kommt, malt zuerst. Bei der Authentifizierung ist das DNS und das Desgin im Snap-In "Active Directory-Standorte und -Dienste" entscheidend. Es kann/sollte für jeden physikalischen Standort, ein Standort im AD mit samt dem Subnetz erstellt werden, wobei sich jeder DC an dem seinem AD-Standort befinden sollte. Denn der Client fragt im DNS nach, welche DCs es gibt. Er erhält eine Liste aus der DNS-Antwort und geht diese durch, um einen DC zu finden der online ist und auch funktioniert. Dabei nimmt er bevorzugt einen DC aus seinem Standort. Die DNS-Abfrage die der Client in diesem Moment stellt, wäre: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.<TLD>. Erst wenn er bei dieser Anfrage keine Antwort erhält, fragt er nach einem DC diesmal aus seiner DOMÄNE nach. Die Abfrage lautet: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>. Die Clients sollten natürlich ihren DNS-Server vor Ort in den TCP/IP-Einstellungen eingetragen haben, sei es statisch oder per DHCP. Daher muss auch sichergestellt werden, dass im DNS sich die DCs mit ihren SRV-Records für ihren Standort eingetragen haben. Dabei ist ein Blick in "_tcp.Standort.DC._MSDCS.Domäne.TLD" zu werfen. Siehe auch: Yusuf`s Directory - Blog - Domänencontroller am Standort Man kann zwar auch noch im DNS an der Priorität und Gewichtung eines DCs drehen damit ein DC bevorzugt authentifiziert, davon rate ich aber ab.
  6. Na sowas aber auch... Dann wurde ADPREP noch garnicht angetriggert. So muss das sein.
  7. Servus, das steht aber so nicht in dem Artikel. Wenn, dann solltest du das Verzeichnis <DVD-Laufwerk>\Sources\"Adprep" auf den Server kopieren. Es ist nicht notwendig das Verzeichnis in SYSTEM32 zu kopieren. Nach bestätigen des ersten Befehls ADPREP /FORESTPREP bekommst du in jedemfall eine Anzeige in der dich der Assistent bittet, mit "C" fortzufahren. Du führst das ADPREP auch auf deinem bestehenden Windows 2000/2003 Schemamaster und NICHT auf dem Windows Server 2008 aus? Des Weiteren wird im Verzeichnis %Systemroot%\Debug\Adprep\Logs ein Ordner erstellt, dass als Namen das aktuelle Datum sowie die Uhrzeit erhält. Darin befindet sich das Adprep-Protokoll mit dem Namen ADPrep.log. Werfe auch einen Blick dort hinein. Der DC ist auf dem aktuellen Patch/SP-Stand? Das DVD-Laufwerk ist soweit auch in Ordnung?
  8. Daim

    net group Befehl

    Moin, siehe: Yusuf`s Directory - Blog - Active Directory - Abfrage
  9. Daim

    GPO einstellungen

    Servus, kurz und schmerzlos: Vergiss es. Die ganzen Lösungen (einen falschen Proxy eintragen usw.) sind Pfusch und viel zu leicht zu umgehen. Die bessere Lösung wäre: Einen Proxy Server mit Benutzerauthentifizierung zu betreiben. Dabei muss es nicht gleich der ISA sein, Squid tut es auch. Schau dir den IPCop mit dem "Advancerd Proxy" Addon an. Damit kann man eine Benutzerauthentifizierung realisieren.
  10. Moin, die Replikation des GCs findet mit einer niedrigeren Priorität statt, als die standmäßige (normale) AD-Replikation. Wie bereits blub schrieb, hängt die Replikation von eurer Replikationstopologie oder von der Anzahl an Objekten ab. Wenn du dennoch die Replikation forcieren möchtest, setze dich mit REPADMIN auseinander.
  11. Im Nirwana ;) . Und nein, ich meine nicht die Musik-Gruppe. Nur durch Dritt-Anbieter. Suche mit der Suchmaschine deines Vertrauen nach "Server Undelete". Da wirst du nur so erschlagen mit Ergebnissen.
  12. Wie? Auf einmal? Auf welchem DC bekommst du diese Meldung und seit wann?
  13. Eieieii... du solltest die "Default Domain Policy" öffnen...
  14. Du bist der englischen Sprache mächtig? Dann stellt das ebenfalls kein Problem dar.
  15. Willst du mich veräppeln oder was?! Muss man alles vorkauen?
  16. Dann solltest du das EFS-Zertifikat sichern. Wie das funktioniert, steht in diesem bereits geposteten Artikel: faq-o-matic.net » Was muss ich tun, um den ersten DC zu deinstallieren?
  17. Nicht zwingend, aber ich kann es in einer überschaubaren Größe der Umgebung nur empfehlen. Dabei kannst du dir nicht sicher sein. Woher willst du denn sicherstellen, dass nicht ein Benutzer "ausversehen" den Haken gesetzt hat? Wie gesagt, wichtig für das EFS wäre, ob dieser DC der allererste DC war.
  18. Du darfst ruhig die Links die man dir postet, samt den Weiterverlinkungen durchlesen. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) faq-o-matic.net » Was muss ich tun, um den ersten DC zu deinstallieren?
  19. Wenn du meine erste Antwort beachtet hast, ja.
  20. Dann führe es erneut mit NTDSUTIL aus und gib diesmal "Transfer Domain Naming Master" ein.
  21. Wie hast du denn das verschieben der Rolle versucht, über die GUI oder NTDSUTIL? Ansonsten, gehe auf den Ziel-DC, also der DC, der die Rolle bekommen soll und registriere - wenn noch nicht geschehen - auf diesem die Schema-Management DLL. Dazu gehst du auf START - AUSFÜHREN und gibst dort folgendes ein: regsvr32 schmmgmt.dll. Anschließend öffnest du unter START - AUSFÜHREN eine MMC und fügst unter DATEI - Snap-In... die AD-Schema MMC hinzu. Wenn sich die MMC mit dem Ursprungsrollenträger verbunden haben sollte (was es standardmäßig tut), mache einen Rechtsklick auf auf "AD-Schema" udn wähle die Option "Domänencontroller ändern...". Anschließend trägst du den Namen des "neuen" Schemarolleninhaber ein. Nun kannst du mit einem erneuten Rechtsklick auf "AD-Schema" die Option "Betriebsmaster..." auswählen und klickst dort auf "Ändern". Funktioniert es nun?
  22. Ist denn der Ursprungsrolleninhaber der Schemamaster-Rolle denn auch erreichbar? Oder ist dieser Offline? Wenn offline, dann musst du die Rolle mit Gewalt verschieben, also "seizen". Dann kannst du ebenfalls über die GUI oder mit NTDSUTIL durchführen.
  23. Hola, die FSMO-Rollen werden sofort übertragen und der GC benötigt je nach Umgebung seine gewisse Zeit, bis er alle Informationen repliziert bekommen hat. Bis die Replikation des GC abgeschlossen wurde, hängt hauptsächlich von der Umgebung, Replikationstopologie und Bandbreite ab. Das hat aber mit dem DC den du herunterstufen möchtest nichts zu tun. Diesen kannst du direkt herunterstufen. Allerdings muss natürlich sichergestellt sein, dass der neue DC bereits das DNS repliziert bekommen hat. Du kannst auch eine Abfrage im RootDSE durchführen und schauen, ob dieser Eintrag existiert: isGlobalCatalogReady. isGlobalCatalogReady Erst dann gibt sich der DC im AD als GC bekannt. Oder du überprüfst das Eventlog und suchst nach der EventID 1119. Auch dann ist der GC ready.
  24. Dann delegiere demjenigen im AD das Recht, Benutzer zu verwalten. Anschließend installierst du auf dem Client das Adminpak, denn somit kann derjenige schön einen Benutzer mit der GUI einrichten. Gruppenrichtlinien - Übersicht, FAQ und Tutorials Oder eben wie es Norbert erwähnt hat, mit DSADD.
  25. Off-Topic:Wie so oft, er möchte fertige Lösungen, keine Hinweise ;) .
×
×
  • Neu erstellen...