Ade, AD und DNS! Oder etwa doch nicht?

Wenn es nach der gestrigen intensiven Google-Suche meinerseits geht, ist das gestern aufgetretene (berufliche) Problem bei einem Kunden mehr als selten. Informationen hierzu waren spärlich, wenn nicht sogar armseelig. Anscheinend taucht es niemals auf – obwohl es das tut. Was war passiert? Ich versuch es so ausf?hrlich wie möglich, aber bedenkt – ich mach es aus dem Kopf, da ich die Fehlermeldungen nicht mehr vorliegen habe.

Die genauen Hintergr?nde sind mir selbst verborgen. Anfangs lag der Verdacht auf ein fehlerhaftes Update eines Antiviren-Programmes, welches ich aber nach erster Recherche beim Kunden vor Ort ausschließen konnte. Nach Start des Servers (hier ein MS 2003 Server Standard), war eine Anmeldung nicht möglich, da ein Fehler im Verzeichnisdienst (Active Directory) aufgetreten ist. Um es mit einfachen Worten zu sagen, die Active Directory Informationen waren im Anus.

Im Verzeichnisdienstwiederherstellungsmodus war es mir nicht möglich die ntds.dit-Datei (welche die AD-Informationen beinhaltet) mit den ?blichen Tools, wie ntdsutil oder esentutl zu reparieren. Ich hatte an dieser Stelle fast aufgegeben, da eine aktuelle Sicherung nicht vorhanden war. Der Server pfiff eh schon auf dem letzten Loch und die Datensicherung war genauso zuverlässig und glaubw?rdig, wie Backsteine in der Luft schweben können.

Die Betonung lag hier auf „aktuelle“ Sicherung. Ich hatte noch Zugriff auf eine Sicherung von 2006. Also relativ zeitnah möchte ich anmerken. Aus dieser holte ich im Modus Verzeichnisdienstwiederherstellung die ntds.dit und ?berschrieb die Originale (nach händischer Sicherung) im Ordner C:\WINDOWS\NTDS. Die Pr?fungsmechanismen mittels ntdsutil verliefen fehlerfrei und ich startete den Server durch. Ich konnte mich daraufhin anmelden aber das nächste Problem folgte – der DNS Server. Es handelte sich um eine AD mit integriertem DNS und die r?ckgesicherte ntds.dit war einfach viel zu alt, sodass der DNS Server dies nicht akzeptierte. Ich konnte den DNS Server nicht konfigurieren oder eine neue Zone erstellen – beides wurde mit einer Meldung in der Art „konnte nicht in Active Directory (null) schreiben“. Ebenso war es mir nicht möglich, mit den mir verständlichen Mitteln den DNS Server zu deinstallieren und blanko zu installieren. Es schlug jeder Eingriff fehl.

Somit konnten auch die Clients keine Namensauflösung mehr machen, geschweige denn sich an der Domäne anmelden. Intern, wie auch extern war der Zugriff auf DNS-Namen nicht möglich. Ein Gl?ck, dass der Kunde mittels HTTP-Proxy surfte. Zumindest war der Server via \\IP-Adresse erreichbar. Eine Konstellation, die dem Kunden „erst einmal ausreichte“. Ich versprach mich darum zu k?mmern, denn völlig mich einer Neuinstallation hingeben lag mir fern. Ich recherchierte gestern ?ber 5 Stunden zu Hause und stieß auf den f?r mich letzten besaglichen Strohhalm.

Heute beim Kunden angekommen, habe ich das auch gleich umgesetzt, Daumen gedr?ckt, weggesehen und … es lief! Einzig allein die wenigen Arbeitsstationen musste ich aus der „alten“ Domäne austreten und in die „neue“ Domäne eintreten lassen und alles funktionierte, wie es sollte. Und f?r alle die, die ungeduldig warten, was ich getan habe, hier eine „Kurzanleitung“ am Hauptserver (DC+DNS).

  1. Deinstallation des DNS-Servers (Systemsteuerung->Software->Windowskomponenten hinzuf?gen/entfernen)
  2. Löschen (vorher sicherheitshalber sichern) der Dateien netlogon.dns und netlogon.dnb (hier unter C:\WINDOWS\SYSTEM32\CONFIG)
  3. Löschen (vorher sichern) des kompletten Ordners DNS (unter C:\WINDOWS\SYSTEM32)
  4. wenn noch nicht vorhanden, die Support Tools von M$ installieren
  5. CMD starten und folgenden Befehl eingeben (vom Support Tools Installationspfad aus): netdom resetpwd /server:SERVERNAME /userd:SERVERNAME\Administrator /passwordd:*
  6. es wird nun nach dem Kennwort gefragt: hier kann einfach das alte Administratorkennwort eingegeben werden
  7. DNS Server installieren (Systemsteuerung->Software->Windowskomponenten hinzuf?gen/entfernen)
  8. Sicherstellen, dass die oben entfernten Dateien und Ordner wieder erzeugt wurden
  9. CMD starten und netdiag /fix ausf?hren
  • Restarbeiten (Aus- & Eintritt der Client-PCs in die Domäne)
  • Feierabend machen

Mindestens durch die alte ntds.dit Datei, wenn nicht durch einen Fehler in der DNS Konfiguration oder anderen Ursachen, wurde das Kerberos-Passwort des Administrators zur?ckgesetzt. Mittels netdom wird dieses „aufgefrischt“ und dann sollten in dieser Hinsicht diese Probleme beseitigt sein.

Hoffe es hilft Einem – dem Kunden f?r sein Geschäft und mir f?r das „Wissen“ auf jeden Fall.

Das könnte Dich auch interessieren...

4 Antworten

  1. pixel sagt:

    wow .. das is echt mal nen tricky problem …
    konntest du dich weder als domänenuser noch als lokaler admin anmelden ?

  2. FireFox sagt:

    Es ging nichts mehr. Die Anmeldungen an den Client-PCs liefen nur noch, da diese mit den zwischengecached-ten Kennwörtern arbeiteten. Ein Neustart der Clients war vorher ohne Erfolg, da sie ja ohne AD und DNS den Domain Controller (DC) nicht fanden – ergo somit auch keine Authentifizierung möglich war. Lokal konnte man sich an den Clients anmelden, aber ein Netzwerkzugriff war erst nach Wiederherstellung der AD mittels der alten ntds.dit Datei und ntdsutil möglich – ABER nur via IP, nicht via Servernamen. Dies ging erst als DNS wieder lief.
    Am Server selbst (der DC) ist eh eine lokale Anmeldung nicht möglich – es sei denn im Verzeichnisdienstwiederherstellungsmodus. Bis auf letzteres war eine Anmeldung nicht möglich, da vor der Möglichkeit des Logins das Fehlermeldungsfenster aufkam, indem von einem Fehler im Verzeichnisdienst gesprochen wurde. Ich glaube der Fehlercode hierzu war 0xc00000221 – bin mir aber nicht sicher ob der Code stimmt. Mein Suchprotokoll ist leider schon weg und mein Schmierzettel vom Kunden auch, wo der Fehlercode drauf war.
    Sobald dieses Meldungsfenster bestätigt wurde (ging nur OK), dann startete der Server neu – also blieb nur der Wiederherstellungsmodus.
    Ich hatte vorgestern 3 Stunden beim Kunden verbracht, kam aber nur bis zum Punkt Anmeldung ging lokal an den Clients, Zugriff auf Server nur via IP. Das war gestern der Stand, wo ich den Kunden leider verlassen musste, da ich ja in Elternzeit bin und unsere Kleine aus der Kita abholen musste. Dieser Stand reichte ihm aber als „Notmaßnahme“.
    Heute habe ich binnen 10 Minuten diesen Workaround bearbeitet – die restliche Zeit von 1 1/2 Stunden ging für die Client PCs drauf (Aus- Eintritt). Der Kunde zufrieden, ich zufrieden wegen der Lösungsfindung, Firma zufrieden, weil Dienstleistung erbracht und vielleicht die Welt zufrieden, da diese mögliche Lösung jetzt auch noch einmal in Deutsch anderen zur Verfügung steht und Google & Co hier auf die Seite leiten.
    Mal schaun, ob es etwas bringt 🙂

    PS: Ich hatte heute noch mit einigen Anderen einen „Erfahrungsaustausch“ deswegen. Die bzw. deren Firmen hätten schon längst die „einfachere“ Variante gewählt – alles mach neu! Ich für meinen Teil rätsle gern – hängt natürlich von der Dringlichkeit ab bzw. bedarf ein ausgewogenes Händchen hier und da. Bei anderen Dienstleistern hätte der Kunde bereits auf dem alten Server ein neues System und mit all den damit verbundenen zeiraubenden Ärgerlichkeiten.

  3. pixel sagt:

    hui … interessante lösung ! ich bin/war früher auch lieber der tüftler … das prob dabei ist aber, dass man meist nicht die zeit hat „ewig“ zu tüfteln … irgendwann ist halt der kosten/nutzen faktor so krass das man sagt .. kiste neu, problem gelöst 😉
    in der elternzeit bin ich auch grad *g* und seit gestern ist unser exchangecluster etwas „kaputt“. . . dort hats nen kompletten store zerlegt .. BoD auf nem Exchange ist voll BlöDe … die ersten kollegen sind gestern nacht noch ins rz nach ffm geflogen :-/

  4. FireFox sagt:

    Ja – „noch“ kann ich tüfteln und ich denke, sofern keine weiteren anderen Argumente fehlen, sollte man es tun. Sicherlich hätte ich anders reagiert, wenn ich ein sauberes junges Backup des Servers gehabt hätte. Hier, wie bereits gesagt, lag aber halt ein anderer Fall vor und für meinen Teil brachte das Vorgehen den eigentlich guten Weg hervor – seitens der Kosten und dem Aufwand. Dass ich nun außerhalb meiner Arbeitszeit damit beschäftigt war, lag an meinem Ehrgeiz und an meinem Hobby. Wie sagt man so schön – mein Berufung ist mein Beruf .. oder so ähnlich.
    Mit Clustern selbst hatte ich noch nicht zu tun – das schwebt doch eine Ebene über mir bisher – zumindest von den Erfahrungen und vom Einsatzfeld her. Was aber nicht heißen mag, dass diese Erfahrung nicht kommen wird 😉
    Ich drücke deinen Kollegen zumindest die Daumen, damit sie diesem Problem schnell Herr werden.
    Letztendlich zeigt es: wenn ein System wichtiger Natur abschmiert – aus welchen Gründen auch immer – dann hängt eine Menge davon ab. Die Situation selbst muss zeigen, welches Mittel – ob schnell und „brachial (Backup zurück und gut) oder „tüftelnd“ – das Richtige in der jeweiligen Situation ist.
    Also nochmal: ich drück die Daumen für ein Wiederbeleben ohne Datenverlust und das in einem akzeptablen Zeitrahmen – auf dass das Problem nicht allzu schwerwiegend ist 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.