LDAP LDAP Client (Synology NAS) verliert regelmäßig die Verbindung

[MichiL]

Hallo,

ich habe seit fast einem Jahr folgende Konstallation am Laufen:
- RS2423+ als LDAP-Server (DSM 7.2.1-69057 Update 3)
- DS414j als LDAP-Client (DSM 6.2.4-25556 Update 7)

Seit ca. 3 Wochen kann ich mich regelmäßig nicht mit den LDAP-Usern an der DS414j anmelden, wenn ich mit einem lokalen User drauf gehe, sehe ich folgende Meldung in den Einstellungen zu LDAP:

Die beiden Geräte hängen an einem gemeinsamen Switch ohne komplizierte Netzwerktopologie die Fehler haben könnte.

1) Kann ich LDAP wieder verbinden ohne die DS neu zu starten, oder den LDAP-Client zu deaktivieren was die erneute Konfiguration erfordert? SSH ist kein Problem, wenns einen Befehl gibt.
2) Ich hab keine Logs (Protokollcenter,... , dmesg) gefunden wo irgend was zu dieser Unterbrechung steht, wie kann ich dem Problem näher kommen, wo kann ich evtl. etwas finden?

Vielen Dank für die Hilfe.

Michael

 

[Synchrotron]

Kann es sein, dass die CMOS-Batterie der 414j leer ist ?

 

[MichiL]

Puh, keine Ahnung, woran kann ich das erkennen?
Und inwiefern kann eine leere CMOS-Batterie im Betrieb zu diesem Effekt führen?

Heute ist was neues passiert, er hatte selbst, ohne Neustart die Verbindung zum LDAP-Server wieder aufgebaut.
In der Vergangenheit hatte er das nach nach Tagen nicht gemacht.
Einträge in Protokollen und dmesg habe ich keine gefunden.

Für die akute Unterstützung wäre es auch ein erster Schritt wenn man den Verbindungsversuch manuell z.B. über ssh triggern könnte.

 

[maxblank]

Wenn die Zeit auf dem Client-NAS mehr als 5 Minuten abweicht, kann dies eine Trennung verursachen. Die Abweichung kann durchaus durch eine leere Batterie verursacht werden.

 

[MichiL]

Und die Zeit kann auch, wenn das Gerät in Betrieb ist durch die leere Batterie davon laufen?

Ich habe vorhin, als der Fehler wieder aufgetaucht ist, die Uhrzeit per date Befehl geprüft und diese war bis auf 2s gleich der Zeit des PCs.

Ich kann natürlich nicht ausschließen, dass in der Zwischenzeit synchronisiert wurde.
Wie kann ich den letzten Synchronisierungszeitpunkt aus der DSM ermitteln?


Da die Zeit aktuell korrekt ist, würde ich den LDAP-Client dazu bringen den Server wieder zu kontaktieren, das ist zumindest die letzen 2 Stunden nicht automatisch passiert.
Kann ich das irgendwie manuell anstoßen?

 

[MichiL]

Mittlerweile habe ich den Nachweis, an der Uhrzeit liegts nicht.
Ich hab die Synchronisation deaktiviert und nach dem Verlust der Verbindung waren die Uhren immer noch auf die Sekunde exakt und synchron.

Hat jemand eine Idee an welcher Stelle ich Logs finden kann, die mit dem ldap-Server zusammen hängen?

 

[Benares]

Und die Zeit kann auch, wenn das Gerät in Betrieb ist durch die leere Batterie davon laufen?

Eigentlich nicht. Die Batterie puffert lediglich die Zeit bei einem Reboot. Bei leerer Batterie kommt die DS erstmal mit 1970 hoch, bevor sie die korrekte Zeit wieder per NTP erhält - Voraussetzung, das ist richtig konfiguriert.
Schau mal in die Logs, ob da nach einem Reboot irgendwelche komischen Zeitstempel auftauchen. Wenn ja, dann bitte die Batterie erneuern.

 

[MichiL]

Mein Problem ist NICHT die Batterie, sondern LDAP.

Ich verliere mitten im Betrieb immer wieder die Verbindung zum LDAP-Server, es tritt alle 12 h bis 72 h auf und es kommt folgende Meldung:


Meine Fragen:
1) Kann ich LDAP wieder verbinden ohne die DS neu zu starten, oder den LDAP-Client zu deaktivieren was die erneute Konfiguration erfordert? SSH ist kein Problem, wenns einen Befehl gibt.
2) Ich hab keine Logs (Protokollcenter,... , dmesg) gefunden wo irgend was zu dieser Unterbrechung steht, wie kann ich dem Problem näher kommen, wo kann ich evtl. etwas finden? Gibts andere/spezielle Logs, .... ?

 

[NSFH]

Mal 2 Stellschrauben ausprobieren die unter AD Fehler/Probleme erzeugen:
1. unter SMB das Server signing deaktivieren
2. Nur SMB2 als Protokoll zulassen, kein SMB3

 

[MichiL]

Meinst du mit "Server signing" die Einstellung "Verschlüsselungsübertragungsmodus"?

Eine andere Option habe ich nicht gefunden und diese ist ohne SMB3 ohnehin nicht verfügbar.

Ist dann "SMB2 mit large MTU" ok, oder sollte ich nur "SMB2" wählen?

Und wird wirklich SMB für die Verbindung zwischen LDAP-Client und LDAP-Server verwendet, oder wie sollte das sonst Einfluss auf mein Problem haben?

 

[NSFH]

Deine Fehlermeldung spricht nicht explizit an wo das Problem liegt, nur allgemein Netzwerkeinstellungen. SMB gehört auch zu den Netzwerkeinstellungen.
Die Firewall wirst du ja wahrscheinlich für SMB und LDAP (2 Ports) freigegeben haben, oder?

 

[MichiL]

Bei mir sieht der Dialog so aus:


Ja, mehr Meldung habe ich leider nicht, ich habe die Protokolle der Oberfläche durchsucht und dmesg in der Konsole.
Leider habe ich keine Idee wo noch was stehen kann.
Wenn mir jemand sagen könnte ob und wo der Ldap Client (DS414) oder der Ldap Server (RS2423) evtl. noch logging Informationen hinterlassen oder ob ich den per Parameter zu mehr Ausgaben überreden kann, dann wäre das mit Sicherheit extrem hilfreich.

Zwischen den beiden Geräten gibts keine Firewall, die hängen beide an einem Switch.
Und da es über ein 3/4 Jahr problemlos lief und jetzt ohne eine Konfigurationsänderung plötzlich alle 0,5 bis 3 Tage zur Unterbrechung kommt, kann es eigentlich auch keine falsche Portkonfiguration sein.

 

[Benares]

Wozu noch SMB1 als Min-SMB ?

 

[NSFH]

Deine Fehlermeldung spricht von einem Netzwerkfehler, nicht von einem Kommunikationsproblem auf den beiden LDAP Ports!
Da kann ein simpler Wackelkontakt bei einem Nw-Kabel die Ursache sein.
Mein Screenshot der Einstellungen für den SMB Dienst gibt nur wieder, was sich als problemfreieste Einstellung für den Betrieb eines AD heraus gestellt hat. Warum du nun deine Einstellungen postest verstehe ich nicht, hilft nicht weiter, noch dazu wo bei dir auch noch das kompromittierte SMB1 werkelt.

Der LDAP Server müsste eigentlich auch eine Protokollebene haben, genau so wie das AD, welches man im Umfang was protokolliert werden soll konfigurieren muss.