Anmeldung an Domäne wenn DC offline

[daabm 1.185]

Am 9.2.2023 um 11:40 schrieb Weingeist:

wenn es zu einem Ausfall kam, noch nie AD an sich der Verursacher des Problems war

 

Noch nie "Secure Channel lost" bei nem DC gehabt? Wenn dir das beim "einzigen" passiert, hast gelitten...

 

[Weingeist 157]

Mal wieder eure Antworten verpennt... Sorry.

 

Am 9.2.2023 um 12:00 schrieb NorbertFe:

Naja, das würde ich grundsätzlich anzweifeln, es sei denn, dass bei dir ein Restore automatisch bei fast jeglicher Fehlerauswirkung ein Reflex ist. ;) Ich hab auch schon fehlerhafte Single DCs gesehen, da hätte ein Restore auch nur vor x Monaten geholfen, und man musste das Problem dann trotzdem lösen.

 

Natürlich nicht, möchte ja grundsätzlich herausfinden worans happert. Aber wens zu lange dauert oder eben die Leute nicht arbeiten können aber sollten, wird mit dem Hämmerchen der Reflex provoziert. Aber klar, wäre auch der Moment wo ich einen Spezi holen würde wenn es länger nicht bemerkt wurde und ich mit dem Vergleich einer funktionierenden Umgebung sowie der Netzhilfe nicht weiter komme. Aber das läuft ja wohl auch noch, macht einfach stellenweise Probleme, sonst hätte es nicht monatelang unbemerkt bleiben können.

 

Aber mal ehrlich, wann musstest Du den letzten DC wegen vermurkstem AD wiederherstellen? Ich sicher über 15 Jahre nicht mehr. AD ist doch recht statisch, also wozu der ganze Aufwand und das Risiko (Snapshots, versehentliche Restores usw. ) bei vermutlich keiner Ausfall-Situation wo ein zweiter DC tatsächlich dazu geführt hätte, dass die Mitarbeiter ohne Intervention des Admins hätten weiterarbeiten können? Auch Fehler werden repliziert. Und wenn die Leute nicht arbeiten können, was jucken dann 5min Restore-Time für einen DC? Sonst spricht man auch immer vom Aufwand/Ertrag. Ich verstehe es nicht, würde es aber gerne verstehen. Zugriff auf Backup zählt nicht, die sollten ja optimalerweise eine eigene, unabhängige Struktur haben.

Wie immer für die Situation: keine Fremdprogramme wie Exchange die in der DB rumschreiben, relativ statisches AD, Wartungsfenster vorhanden von normal 5-15min pro Monat für Updates wo keine Anmeldungen am DC möglich sind (Zeit für ColdCopy + Reboot). Wer bringt das schlagende Argument? Ich konnte noch keines erkennen. Ich weiss man macht es nicht, aber das ist kein Argument oder? Wenn ich blind und ignorant bin, schiebe ichs einfach aufs fortschreitende Alter, aber interessieren würds mich trotzdem =)

 

HostCrash hat normal nichtmal Auwirkungen auf ein statisches AD. Restores gabs bei mir nur bei Update-Runden.

--> Beispiel: Defekter ComponentStore aus verschiedenen Gründen/Ursachen (Festplattenplatz, Updatereihenfolge usw), verbocktes Update von MS oder selber ne Timeline verbockt (  NTLM etc). Der Aufwand für das Beheben eines Store-Defekts - sofern er möglich ist - steht selten im Verhältnis zu einem Restore, selbst ein Neuaufsetzen wäre vermutlich schneller. Aber vielleicht bin ich auch einfach zu langsam/ungeschickt. Oder niemand prüft den Store nach den Updates auf Beschädigungen

 

 

Am 10.2.2023 um 23:51 schrieb daabm:

Noch nie "Secure Channel lost" bei nem DC gehabt? Wenn dir das beim "einzigen" passiert, hast gelitten...

Kann leider nicht folgen. Wie kann das auf nem einzelnen DC passieren bzw. Auswirkungen haben? Er hat doch immer auf sich selber Zugriff und kennt sein aktuelles Maschinen-PW.

Oder meinst was ganz anderes? Falls ja, was genau und wie kann ich es provozieren zur Test-Behebung? Wenn er der einzige ist, was hindert mich am Image-Restore/CopyPaste des DC vom Stand Tag davor.

[NorbertFe 1.805]

vor 15 Minuten schrieb Weingeist:

Aber mal ehrlich, wann musstest Du den letzten DC wegen vermurkstem AD wiederherstellen?

Sehr lange her, weil ich mehr als einen habe. ;) unabhängig deiner Beschreibung liegt’s vielleicht auch daran, dass bei meinen Kunden bisher fast überall auch ein exchange läuft. Der wäre pauschal kein Hinderungsgrund, aber da überlegt man eher länger ob man mal eben zurückrollt bzw. Bei mehr als einem dc ist es eben nicht notwendig.

[daabm 1.185]

vor 23 Stunden schrieb Weingeist:

Am 10.2.2023 um 23:51 schrieb daabm:

Noch nie "Secure Channel lost" bei nem DC gehabt? Wenn dir das beim "einzigen" passiert, hast gelitten...

Kann leider nicht folgen. Wie kann das auf nem einzelnen DC passieren bzw. Auswirkungen haben? Er hat doch immer auf sich selber Zugriff und kennt sein aktuelles Maschinen-PW.

Oder meinst was ganz anderes? Falls ja, was genau und wie kann ich es provozieren zur Test-Behebung? Wenn er der einzige ist, was hindert mich am Image-Restore/CopyPaste des DC vom Stand Tag davor.

 

Ein DC verhält sich da genau wie ein Client - er kennt lokal (Registry) sein Kennwort, und es steht auch im Computerkonto im AD. Paßt das nicht mehr, hast das gleiche wie bei nem Member - entweder rejoin (also de-/promote) oder nltest /screset. Zweiteres geht aber nicht gegen ihn selber, sondern muß auf ihm selbst gegen einen anderen ausgeführt werden - hast Du nur einen, ist hier Ende. Und rejoin aus offensichtlichen Gründen das gleichen Problem.

[Weingeist 157]

@NorbertFe Jo mit Exchange sieht die Sache defintiv anders aus. Da bin ich gleicher Meinung.

 

@daabm Hmm und wie kommt das tatsächlich zustande? Kann mir das Szenario irgendwie nur schwer vorstellen. Kam mir auch noch nie unter.

 

Wenn der DC nicht mehr vertrauenswürdig ist, geht ja in der Domäne eh nix mehr, also von extern das Maschinenpasswort zurücksetzen wird dann wohl auch essig sein. Dann müsste eben das Backup her. Aber eben, ich kenne aktuell noch nicht mal die Sympthome die das hervorrufen wird. ;)

 

Auf alle Fälle würde ich die Risiken durch ungewollten Wiederherstellungen z.Bsp. durch Snapshots deutlich höher gewichten. Totalschaden und Rückgriff auf Backup gibts dann wohl bei beiden Fällen. Ausser man nimmt sich unter Umständen viel Zeit. Gab ja grad wieder einen Fall hier im Forum von ungewollter Wiederherstellung. Bei einem wäre das nicht passiert. ;)

 

Werde sobald ich mal etwas Spieltrieb habe, das Szenario mal austesten ob man wirklich nicht an die DB rankommt und das PW ersetzen kann oder die gängigen Powershell-Funktionen mangels Authentifizierung nicht funktinieren (was zu hoffen ist).

[daabm 1.185]

vor 3 Stunden schrieb Weingeist:

wie kommt das tatsächlich zustande?

 

Wir haben ein paar mehr Domains als gemeinhin üblich - bei uns einige Male pro Jahr.

[cj_berlin 1.137]

Das war aber eine Antwort auf "wie oft", nicht auf "wie" - Letzteres würde mich tatsächlich interessieren 😀

[Weingeist 157]

Am 26.4.2023 um 19:39 schrieb cj_berlin:

Das war aber eine Antwort auf "wie oft", nicht auf "wie" - Letzteres würde mich tatsächlich interessieren 😀

Genau, mich auch. So ohne den Rest Deiner Aussagen hätte ich glatt auf Replikations-Probleme bei mehr als einem DC getippt, allenfalls in Verbindung mit aktivem, manuellem Eingriff in die Aktualisierungs-Politik der Maschinenkennwörter. *hust*

[daabm 1.185]

Wir konnten es nie exakt eingrenzen, aber es gab Hinweise auf Timeouts im Storage. Wenn ein Member Computer sein PW ändert, macht er das erst im AD, und wenn das geklappt hat, lokal. Ein DC macht es AFAIK andersrum, und wenn das AD-Update dann schiefgeht, war's das.