hansdampf06
Goto Top

NT-STATUS-IO-TIMEOUT bei Samba-AD-DC am zweiten Standort

Hallochen Gemeinde!

Gegeben ist ein Windows-AD, das ausschließlich von vier Samba-AD-DC's verwaltet wird. Windows-DC's gibt es nicht (mehr). Von den vier Samba-AD-DC's basieren zwei auf Ubuntu 20.04 und waren schon länger als Tandem vorhanden. Einer dieser beiden DC's hat alle FSMO-Rollen. Die anderen beiden beruhen auf Debian 12 und sind in den letzten zwei Monaten hinzugekommen. Das Netzwerk hat zwei (physische) Standorte, wobei die beiden Ubuntu-DC's und einer der Debian-DC am (Haupt)Standort 1 werkeln und der andere Debian-DC am Standort 2 agiert. Beide Standorte haben eigene/abweichende private 24er IPv4- / 64er IPv6-Netzwerkbereiche und sind durch eine site-to-site-Verbindung (sowohl IPv4- als auch IPv6-Tunnel) permanent verbunden. Die Tunnel haben keine Regelbeschränkungen seitens der Firewalls. Die Netzwerkbereiche sind als Subnets im AD eingetragen. Weil beide (physischen) Standorte zum selben Domainbereich gehören, gibt es auch nur einen (logischen) AD-Standort. Das ist auch deshalb wichtig, weil es mehrere Clients gibt, die sich an beiden (physischen) Standorten einloggen.

Die beiden Debian-DC's sind identisch konfiguriert und unterscheiden sich lediglich im Hostname und den zugewiesenen IP-Adressen.

Mit dem Befehl samba-tool visualize [ntdsconn | reps | uptodateness] -r kann der Replikationsstatus abgerufen werden. Bei den drei DC's am Standort 1 läuft dieser Befehl sauber durch. Alle Replikationsverbindungen (source <-> destination / DC <-> out-of-date-ness) zwischen den vier DC's werden angezeigt und es gibt keine Fehlermeldungen. Der DC des Standorts 2 hingegen meldet für sich selbst:

Failed to connect to ldap URL 'ldap://DC4.domain.tld' - LDAP client internal error: NT_STATUS_IO_TIMEOUT  
Failed to connect to 'ldap://DC4.domain.tld' with backend 'ldap': LDAP client internal error: NT_STATUS_IO_TIMEOUT  
Could not contact ldap://DC4.domain.tld ((1, 'LDAP client internal error: NT_STATUS_IO_TIMEOUT')) 

Ebenso läuft der Befehl samba-tool drs showrepl [--summary] auf den drei DC's des Standorts 1 ohne Fehlermeldungen durch, während der DC des Standorts 2 meldet:

ERROR(<class 'samba.drs_utils.drsException'>): DRS connection to DC4.domain.tld failed - drsException: DRS connection to DC4.domain.tld failed: (3221225653, '{Device Timeout} The specified I/O operation on %hs was not completed before the time-out period expired.')  

Wird der Befehl samba-tool drs replicate Ziel-DC Quell-DC [--full-sync --sync-all] für den DC des Standorts 2 in beiden Richtungen für die jeweilige AD-Partition auf ihm selbst ausgeführt, funktioniert alles fehlerfrei. Ebenso klappt es fehlerfrei, wenn dieser Befehl in seinen Varianten auf einem anderen DC ausgeführt wird.

Folgelich kann konstatiert werden, dass die Replikation als solche nicht nur zwischen den drei DC's des Standorts 1, sondern genauso in beiden Richtungen mit dem DC des Standorts 2 funktioniert. Das ist beispielsweise über die RSAT-Tools für die Replikation der DNS-Einträge nachvollziehbar, wenn sich am Standort 2 ein Client anmeldet und eine IP zugewiesen bekommt, ist nicht nur ein entsprechender DNS-Eintrag beim DC des Standorts 2 vorhanden, sondern wenige Augenblicke später auch bei den drei anderen DC' am Standort 1. Das Ganze gilt auch umgekehrt. Insgesamt funktioniert die Namensauflösung an beiden Standorten einschränkungslos und erwartungsgemäß.

Soweit ich bei meiner Recherche bisher herausgefunden habe, kann der time-out-Fehler an den abweichenden IP-Bereichen für den Standort 2 liegen. Ich habe sogar eine gepostete Frage gefunden, die genau meine Fehlerkonstellation beschreibt. Aber darauf gab es leider keine Antworten. Bisher konnte ich mir nicht erschließen, was der Grund für dieses time-out-Problem ist und wie es abgestellt werden könnte.

Wer hat einen Tipp für mich oder weiß sonstigen Rat?

Vielen Dank im Voraus für Euren Input und viele Grüße
HansDampf06

Content-Key: 93324665550

Url: https://administrator.de/contentid/93324665550

Printed on: March 1, 2024 at 01:03 o'clock

Member: commodity
commodity Nov 14, 2023 at 21:13:15 (UTC)
Goto Top
Hallöle,
bin in dem Feld leider noch recht frisch.
Das hier haste nach dem Join gemacht?
If you are joining a new DC the 'nameserver' you set in '/etc/resolv.conf' must be another AD DC, otherwise the join will not be work. Once the new join has succeeded, you need to change the 'nameserver' to the new DCs ipaddress, do not use '127.0.0.1' or any other IP.  
https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Activ ...

Viele Grüße, commodity
Member: LordGurke
Solution LordGurke Nov 14, 2023 at 22:01:52 (UTC)
Goto Top
Hast du da Firewallregeln, die LDAP nur für bestimmte IP-Adressen freigeben? So, dass nur die Replikation funktioniert?
Oder wird eventuell nur LDAPS (das ist ein anderer Port) bedient?

Kannst du von Linux aus mit Traceroutes testen:

# Schauen wo LDAP versandet
traceroute -T -p ldap ip.des.servers

# Gegenproben mit LDAPS und ICMP
traceroute -T -p ldaps ip.des.servers
traceroute -I ip.des.servers
Member: HansDampf06
HansDampf06 Nov 14, 2023 at 23:04:36 (UTC)
Goto Top
Zitat von @commodity:
Das hier haste nach dem Join gemacht?

Nach meinem Verständnis des Kontextes des von Dir benannten Links und nach meiner Erfahrung ist die DNS-Server-Benennung vor dem Join "nur" dann relevant, wenn der Join-Befehl ohne Angabe eines vorhandenen DC's ausgeführt oder bei dessen Benennung der FQDN verwendet wird. Wird der DC hingegen mit seiner IP-Adresse benannt, ist eine DNS-Auflösung für einen erfolgreichen Join nicht unbedingt zwingend. Daher kann ein künftiger Samba-AD-DC bis auf den Join-Befehl sogar vollständig vorkonfiguriert werden, so dass der künftige DC bereits in der resolv.conf nachrangig benannt sein kann.

Zudem verstehe ich den Link nicht dahingehend, dass nach dem Join der neue DC in seiner eigenen resolv.conf an erster Stelle oder gar ganz allein benannt werden müsste. Vielmehr dürfte für Samba dasselbe gelten, was für Windows-DC's schon immer galt - meiner Erinnerung nach ist das eine Best-Practice-Empfehlung von Microsoft: Der erste DNS-Server-Eintrag auf einem DC verweist immer auf einen anderen DC. Weil Linux nur die ersten drei Benennungen in der resolv.conf effektiv berücksichtigt, wird bei mir der jeweilige DC in seiner eigenen resolv.conf immer an dritter Stelle benannt. Davor stehen zwei andere DC's. Jedenfalls bin ich mit diesem Ansatz bisher immer bestens gefahren und habe eine schnelle und störungsfreie DNS-Auflösung im gesamten Netzwerk.

Ein tcpdump -i für die LAN-Schnittstelle hat gleichfalls für mich nicht wahrnehmbar werden lassen, dass die DNS-Auflösung scheitern würde. Ebenso ist den relevanten log-Dateien nichts zu entnehmen.


Zitat von @LordGurke:

Hast du da Firewallregeln, die LDAP nur für bestimmte IP-Adressen freigeben? So, dass nur die Replikation funktioniert?
Oder wird eventuell nur LDAPS (das ist ein anderer Port) bedient?

Nein, an den Standardports ist nichts verändert. Die Ports sind auch nicht durch Firewall-Regeln eingeschränkt.

Kannst du von Linux aus mit Traceroutes testen:

Der traceroute-Befehl mit beiden IP-Adressen oder dem FQDN ist erfolgreich und erwartungsgemäß.

Die Ursache für mein Phänomen muss mithin woanders liegen.

Viele Grüße
HansDampf06
Member: Pjordorf
Pjordorf Nov 15, 2023 at 00:12:29 (UTC)
Goto Top
Hallo,

Zitat von @HansDampf06:
Ein tcpdump -i für die LAN-Schnittstelle hat gleichfalls für mich nicht wahrnehmbar werden lassen, dass die DNS-Auflösung scheitern würde. Ebenso ist den relevanten log-Dateien nichts zu entnehmen.
Würde/Könnte/Dürfte ist alles Glückskecks lesen. Ein Wireshark hilft dir mehr. https://wiki.ubuntuusers.de/Wireshark/
https://www.wireshark.org/faq.html#_can_wireshark_read_capture_files_fro ...
https://www.wireshark.org/

Gruß,
Peter
Member: HansDampf06
Solution HansDampf06 Nov 15, 2023 at 17:54:14 (UTC)
Goto Top
Zitat von @Pjordorf:
Ein Wireshark hilft dir mehr.

So ähnlich. @LordGurke hatte mich mit seinem Kommentar daran erinnert, dass ich eigentlich noch den Befehl samba-tool drs showrepl in einem erhöhten Debugmodus (z.B. -d3) ausführen wollte, wovon ich aber irgendwie abgekommen war. Das nachgeholt und sofort wurde sichtbar, wo der Fehler liegt.

Letztlich war es ein unbemerkter Schreibfehler in der hosts-Datei bei der IP-Adresse. Augenscheinlich greift samba-tool zuerst auf diese hosts-Datei zu, während der reguläre Replikationsvorgang die angegebenen DNS-Server nutzt. Jedenfalls würde das erklären, warum die Replikation zwischen den vier DC's anstandslos funktioniert, während samba-tool scheiterte. Auch die ganzen anderen Testbefehle, die naheliegenderweise gerne benutzt werden, scheinen vorrangig die DNS-Server und nicht die hosts-Datei zu benutzen. Daher wurde die Fehlerursache in gewisser Weise verschleiert und es gab auch keine brauchbaren Logs etc.

Ärgerlich, wenn eine kleine Unachtsamkeit unnötig Zeit und Aufwand kostet.

Nach der Korrektur des Schreibfehlers laufen die im Eingangspost genannten Befehle auch auf dem DC des Standorts 2 anstandslos durch. Sehr schön!

Vielen Dank für Euren Input und viele Grüße
HansDampf06
Member: commodity
commodity Nov 15, 2023 at 18:51:49 (UTC)
Goto Top
Super! Danke für's Feedback.

Viele Grüße, commodity
Member: HansDampf06
HansDampf06 Nov 16, 2023 at 11:07:15 (UTC)
Goto Top
Super! Danke für's Feedback.

Sehr gern!

Viele Grüße
HansDampf06