Anmeldung an Domäne wenn DC offline

[Moschi76 11]

Hallo,

 

kurze Frage. Ist eine Anmeldung in der Domäne, in welcher der Client hängt, mit einem DC welcher offline ist bzw. nicht erreicht werden kann zur Auth möglich?

 

Es geht darum, ein Techniker sagt, das würde gehen, ich kenne es aber anders, dass man die Meldung bekommt, das eine Anmeldung nicht möglich ist, da der DC nicht zur Verfügung steht, solange der PC im Netz der Domäne ist.

 

Grüße Martin

[Weingeist 159]

Das kommt ganz darauf an wie man es konfiguriert. Standardmässig geht das, wenn man das abgewöhnt, nicht. Was nun sinnvoller ist bzw. ob es ein effektiver Sicherheitsgewinn ist, wenn man dies verhindert, da scheiden sich die Geister äh Sicherheitsspezis.

[NorbertFe 2.027]

vor 29 Minuten schrieb Moschi76:

Es geht darum, ein Techniker sagt, das würde gehen, ich kenne es aber anders, dass man die Meldung bekommt, das eine Anmeldung nicht möglich ist, da der DC nicht zur Verfügung steht, solange der PC im Netz der Domäne ist.

 

Wie immer: Es kommt darauf an. ;) Steht ja schon oben. Beide Varianten lassen sich entsprechend konfigurieren, wobei die cached credentials für die letzten 10 lokal angemeldeten Domainuser standardmässig vorliegen. Dreht man die Zahl rauf (max 50 oder runter auf 0), dann kannst du dir vorstellen, was passiert. :)

[NilsK 2.930]

Moin,

 

um noch kurz zwei Dinge zu ergänzen:

1. die Anmeldung gelingt offline nur dann, wenn sie vorher mindestens einmal für den betreffenden Account erfolgreich war
2. nur einen DC zu haben, ist zu wenig, sobald es mehr als eine Handvoll User in der Domäne gibt

Gruß, Nils

 

[Weingeist 159]

vor 17 Stunden schrieb NilsK:

nur einen DC zu haben, ist zu wenig, sobald es mehr als eine Handvoll User in der Domäne gibt

Och das können doch durchaus auch mehr als eine handvoll User sein. Würde das eher an der Häufigkeit der Änderungen im AD festmachen (Exchange, ERP das die Kontakte nutzt etc.), wie Fehlertolerant der Rest der Umgebung gestaltet wird etc. Bei Passwort/Kerberos Rotierungen empfiehlt sich ja eh ein neues Backup.

 

1. Stirbt ein physischer Server, ist bei vielen kleineren/mittleren Umgebungen eh meist soviel down, das nicht ohne Unterbruch weitergearbeitet werden kann/soll
2. Backup/Restore Maschinen haben vorzugsweise eine eigene Rechtsstruktur, hilft also nicht für den Restore
3. Die ganzen potentiellen Replikationsprobleme fallen weg
4. Eine Wiederherstellung bei nur einem DC ist sehr fehlterolarant gegenüber den gängisten Fehlern punkto Sicherung/Wiederherstellung oder auch wenn Windows-Updates in die Hose gegangen sind.
5. Eine DC VM ist ca. 25GB gross. Auf moderner Hardware ist die innerhalb 30 sek bis 5 min wiederhergestellt. Jede Prüfung der Replikation und allfällige Behebung von Problemen dauert länger als die Wiederherstellung.
6. Lizenzkosten, Wartungskosten, Unterhaltskosten sind insgesamt tiefer
7. Update-Handling bei der aktuellen Qualität der MS Updates ist einfacher (DC runterfahren, Cold-Snapshot/Kopie, hochfahren, Updates einspielen, Neustart). Das runterfahren, ziehen des Snapshots, hochfahren dauert weniger lang als irgend ein Update einzuspielen. Der effektive Ursprungszustand ist ebenso schnell wiederhergestellt, im Gegensatz zu Updates deinstallieren, was mal geht und mal nicht. Rollbacks wird es niemals geben).
8. Aus sicherheitstechnischer Sicht ist eine Replikation immer eine potentielle Vergrösserung der Angrifssmöglichkeiten, auch wenn ich persönlich das eher schlecht  abschätzen kann sondern nur schon entsprechendes über DHCP, DNS, WINS etc. gelesen habe und etwas schockiert über die teilweise Einfacheit war.

Für mich vereinfacht es das Handling massivst, habe weniger Ärger (je älter ich werde, desto weniger Ärger-Tolerant bin ich) und ich muss weniger Stunden verrechnen.

Aber eben, das ist nur meine Meinung und natürlich Immer in Bezug auf Grösse/Änderungen/Abhängigkeiten von AD

[NorbertFe 2.027]

vor 22 Minuten schrieb Weingeist:

Für mich vereinfacht es das Handling massivst, habe weniger Ärger (je älter ich werde, desto weniger Ärger-Tolerant bin ich) und ich muss weniger Stunden verrechnen.

TOTAL OT: Du tust so, als wären Probleme bei Verwendung von 2 DCs der Standard. Sind sie meiner Erfahrung nach aber nicht. Und selbst wenn sind die meist ohne massiven (geschweige denn "massivsten") Aufwand zu beheben, wenn man es denn will. Ja in bestimmten Umgebungen und wenn der Rest dazu passt, tuts auch ein Fire and Forget DC. Da ist allerdings meiner Erfahrung nach meist noch viel mehr zu berücksichtigen. Aber jeder wie er mag, und wir müssen diese Diskussion ja auch nicht jedes Mal führen. :)

 

Bye

Norbert

 

PS: Dein letzter Satz relativiert die vorher aufgezählten 8 Punkte auf genau das: Abhängig vom System und rein subjektive Empfindung. ;)

[daabm 1.348]

@Weingeist Ich hab sogar privat 3 DCs am laufen - und das sind nur 3 natürliche Benutzer... Die fressen kein Heu, laufen mit 2 GB RAM als VM "irgendwo" mit. Und ich hab keinerlei Streß damit.

 

In Prod skalieren wir 1 DC pro 10k Benutzer. Unsere größten Domains haben wegen Geo- und lokaler Redundanz >30 Domain Controller (1/3 davon muß die gesamte Anmeldelast abkönnen), und auch da haben wir keine Probleme mit irgendwelchen Replikationen. Deine Argumente oben passen für mich auch fachlich nicht zu dem, was ich von Dir in anderen Threads schon in hoher Qualität gelesen habe.

[Gulp 252]

So verschwenderisch wie daabm bin ich nicht, ich hab nur 2 DC's für 5 Benutzer ...... aber ich gebe Norbert absolut recht, das macht nicht mehr Aufwand, vereinfacht aber Einiges und sei es auch nur für einen Staged Reboot nach Windows Updates ...

 

Grüsse

 

Gulp

[daabm 1.348]

vor 6 Stunden schrieb Gulp:

So verschwenderisch wie daabm bin ich nicht, ich hab nur 2 DC's für 5 Benutzer

 

Hatte ich auch erst, aber dann kam ein eigenartiges Problem mit WLAN und virtuellen DCs auf Synology-VMs. Daher ein dritter

[NorbertFe 2.027]

Also immer noch nicht gelöst? ;) vielleicht Zuviele dcs :p

[daabm 1.348]

[OT] Ne, nicht zu viele DCs. Auf den Synologys laufen 2 virtuelle DCs in QEmu (glaub ich jedenfalls ). Zentraler "Switch" ist eine 7530ax. Und - ich hab hier schon mal nen Thread dazu aufgemact - seit einem Zeitpunkt X bekommen Computer über WLAN in der Konfiguration keine Kerberos-Tickets mehr. "Irgendwann" funktioniert es dann zufällig mal. Kerberos Packet Size steht auf 1 (TCP erzwungen), UDP out of order scheidet also aus. Mi tMTU hab ich auch schon experimentiert, ohne Ergebnis. Also nen 3. DC dazugestellt als VM auf einem sparsamen Arbeitsrechner. [/OT]

[Weingeist 159]

Sorry wurde etwas später. Eure Argumentation verstehe ich durchaus und habe es auch jahrelang so gehandhabt. Und in grösseren Umgebungen ist das ja auch kein Thema. Da ist aber auch der Rest der Umgebung fehlertolerant ausgelegt. Und ja, sie fressen fast kein Heu, insbesondere als VM nicht. Aber der Unterhalt ist eben doch da und die Lizenzkosten auch. Bei physischen Maschinen war das auch noch was anderes da nicht in Sekundenschnelle der alte wiederhergestellt werden konnte.

 

Nur musste ich über die Jahre feststellen, dass wenn es zu einem Ausfall kam, noch nie AD an sich der Verursacher des Problems war, aber doch schon ab und wann Kopfzerbrechen verursacht hat nach einem Problem wo z.Bsp. die Hardware, der Mensch oder ein Update schuld war. Die Reparatur nahm immer einiges an Stunden und teilweise Nerven in Anspruch. Die Erfahrung fehlt ja dann etwas wenn man nicht täglich solche Probleme hat. Gleichzeitig hatte ich nie Probleme in Kleinstumgebungen mit einem Server, auch wenn die Putzfrau versehentlich den Stecker gezogen hat oder die USV über den Jordan ging. Einschalten und lief einfach wieder. Völlig schmerzfrei. Da habe ich dann irgendwann angefangen nur noch auf einen DC zu setzen wo es möglich war. Im Endeffekt muss so oder so der PDC - auch wenn es nur noch eine Rolle ist - online sein bei den Dingen die wirklich Ärger verursachen können (DFS-Ziele umlegen z.Bsp.). Klar ist ein Designfehler wenn PDC-Emulator-Rolle auf dem gleichen physischen Server liegt wie das aktive PDC-Ziel. Ist aber schnell passiert und ein Design-Fehler der sehr oft vorkommt, auch weil den Leuten Jahrelang eingetrichter wurde, dass es den PDC nicht mehr gibt. Komplett vergessen ging bei den ganzen Belehrungen jeweils, dass die Abhängigkeiten von seinen Funktionen aber durchaus immer noch vorhanden sind. Auch heute noch. Sprich am Fakt das er da sein muss hat sich wenig geändert, trotz aller Begriffs-befindlichkeiten auf die man aus diesem Grund besser verzichtet hätte. Die Wahrscheinlichkeit das bei einem Hardwareausfall also der PDC bzw. der DC mit der PDC-Emulator-Rolle betroffen ist, liegt im KMU-Bereich in der Regel bei 50%. Also bringt mir diese Fehlertoleranz wenig bis nix. Jede Rollenübertragung und korekte Überprüfung und Neuanlegunge eines DC's brauchen länger als ein Restore. ;)

 

Ich sage nicht, dass es der Weisheit letzter Schluss ist und die Meinung muss auch nicht jeder teilen und wenn jemand mit einem schlagenden Gegenargument kommt, bin ich nie abgeneigt meine Meinung zu ändern, aber ich persönlich sehe heute im Gegensatz zu früher keine effektiven Vorteile in mehreren DC's in Kleinumgebungen mehr. (Edit: Wenn dann für die Infrastruktur --> Ticket-High-Jack Problematiken). Einfach weil ein Restore eine Sache von Sekunden/Minuten und nicht mehr von Stunden ist, weil der DC heute ein File und keine physische Maschine mehr ist. Möchte aber nochmals betonen, das gilt ausschliesslich solange man nicht Daten im AD ablegt, welche für die tägliche Arbeit benötigt werden und permanent im AD rumgeschrieben wird. Ich persönlich habe diese Zöpfe mittlerweile fast alle aus Sicherheits- oder Komplexitätsgründen abgeschnitten. Ich versuche heute alles möglichst einfach zu halten und die Komplexität auf den Unterbau zu schieben.

bearbeitet 9. Februar 2023 von Weingeist

[NorbertFe 2.027]

vor 20 Minuten schrieb Weingeist:

Jede Rollenübertragung und korekte Überprüfung und Neuanlegunge eines DC's brauchen länger als ein Restore. ;)

 

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.

bearbeitet 9. Februar 2023 von NorbertFe

[zahni 550]

Kleiner Hinweis: Gecachte Logons sind ein Sicherheitsrisiko, wenn die Client-HDD nicht verschlüsselt ist. Ansonsten lassen sich die Domain-Kennwörter mit geeigneten Tools auslesen.

Also: wenn man es nicht braucht (z.B. bei Notebooks), dann abschalten.

[NorbertFe 2.027]

vor 41 Minuten schrieb zahni:

Gecachte Logons sind ein Sicherheitsrisiko

Hmmm, naja...

Also wenn die Platte nicht verschlüsselt ist, ist jeder Offline Angriff ein Risiko. Da sind die cached credentials auch egal. Siehe:

https://cqureacademy.com/blog/hacks/cached-credentials-important-facts