Wir haben einen TS809U, den wir der Domäne hinzugefügt haben. Freigaben und Zugriffsrechte funktionieren mit den Domänenbenutzern wie gewünscht und alles ist so, wie es sein soll. Aber nach ein paar Wochen/einem Monat verschwinden die Domänenbenutzer und -gruppen vom TS809 und ich muss der Domäne erneut manuell beitreten. Nach dem erneuten Beitritt zur Domäne wiederholt sich der Vorgang innerhalb desselben Zeitraums und ich muss der Domäne erneut beitreten.
In den Protokollen der Weboberfläche sind keine Fehler enthalten und es wird angezeigt, dass das NAS der Domäne erfolgreich beigetreten ist. Ich habe das TS809U auf die neueste Firmware 4.0.3 (von 3.x) aktualisiert, in der Hoffnung, dass dies das Problem lösen würde, aber das Problem besteht weiterhin.
Ist das schon einmal jemandem passiert und weiß, was das Problem sein könnte oder wie man es weiter beheben kann?
Die einzige Meldung, die ich in der Ereignisanzeige finden konnte und die auf das NAS verweist, ist eine 5722, die auf den folgenden Kommentar hinweisen könnte:
Die Authentifizierung des Sitzungsaufbaus vom Computer
NASC473CD
ist fehlgeschlagen. Der/die Name(n) des/der in der Sicherheitsdatenbank referenzierten Kontos/Konten ist/sindNASC473CD$
.
Der folgende Fehler ist aufgetreten:
Zugriff verweigert.
Die Zeitspanne zwischen dem Verschwinden und dem erneuten Auftauchen der Einträge beträgt offenbar 14 Tage. Unsere Domäne basiert (noch) auf Windows Server 2003.
Aktualisieren
Update: Das Problem ist erneut aufgetreten, aber die Protokolle haben nichts wirklich Interessantes gezeigt.wbinfo -t
(Testen des Vertrauensgeheimnisses)hat nicht funktioniert und (wenig überraschend) auch nichtwbinfo -c
(Ändern des Vertrauensgeheimnisses). Ich habe festgestellt, dass der aktuelle Kerberos5-Ticketspeicher nicht aktualisiert wurde und die Gültigkeit der Kerberos-Tickets abgelaufen ist, was damit zusammenhängen könnte. Ich habe es jetzt /sbin/update_krb5_ticket
zur Crontab hinzugefügt, um zu sehen, ob das hilft (und es wird jetzt jede Stunde aktualisiert).
Aktualisierung 25.02.2014
Immer noch kein Erfolg. log.wb-DOMAINNAME
zeigt an, dass uns anscheinend der Zugriff verweigert wird, wahrscheinlich aufgrund abgelaufener Anmeldeinformationen oder ungültiger Geheimnisse. Ich bin nicht sicher, wie ich weitermachen soll, da die Kerberos-Ticketliste ( klist
) ein gültiges Ticket angezeigt hat, als es auftrat.
log.wb-DOMAINNAME
zeigt an:
[2014/02/25 03:05:20.545176, 3] winbindd/winbindd_pam.c:1902(winbindd_dual_pam_auth_crap)
could not open handle to NETLOGON pipe (error: NT_STATUS_ACCESS_DENIED)
[2014/02/25 03:05:20.545198, 2] winbindd/winbindd_pam.c:2003(winbindd_dual_pam_auth_crap)
NTLM CRAP authentication for user [DOMAINNAME]\[MACHINE$] returned NT_STATUS_ACCESS_DENIED (PAM: 4)
[2014/02/25 03:05:20.548424, 3] winbindd/winbindd_pam.c:1841(winbindd_dual_pam_auth_crap)
[20497]: pam auth crap domain: DOMAINNAME user: MACHINE$
(dieselben Fehlermeldungen treten auf, wenn auf Benutzer verwiesen wird). Soweit ich weiß, scheint das Problem zumindest darin zu liegen, dass der Server antwortet, ACCESS_DENIED
wenn Samba versucht, die Ressource zu verwenden NETLOGON
. Ich habe jedoch festgestellt, dass einer der DNS-Server auf dem TS809 auf einen externen Server eingestellt war – und nicht auf einen Server in der Domäne. Ich habe die DNS-Server aktualisiert, sodass beide auf unsere AD DC-s zeigen, um zu sehen, ob das der Grund sein könnte (wenn es auf den externen Server umfällt, wird „Host nicht gefunden“ angezeigt, anstatt Timeouts für interne, domänenbasierte Hosts).
Update 04.03.2015. Als Workaround wurde ein automatisches Rejoin-Skript bereitgestellt.
Wir sind noch immer nicht näher an einer dauerhaften Lösung, aber wir sehen derzeit jede Woche Timeouts. Dies scheint dieselbe Zeit wie ein gültiges Kerberos-Ticket zu sein, aber ich konnte keine Einstellung finden, die dies ändert.
Ich habe jedoch ein kleines Skript erstellt, das überprüft, ob wir die Benutzerliste aus der Domäne verloren haben, und sich bei Bedarf wieder mit dem Server verbindet. (Mit Sambanet rpc join
Befehl.) „Benutzername“ ist ein Benutzer in der Domäne, der Zugriff auf das Hinzufügen von Computern zur Domäne hat (wir haben nur zu diesem Zweck einen Benutzer für QNAP erstellt):
COUNT=`wbinfo -g | grep DOMAINNAME | wc -l`
if [ "$COUNT" -lt "1" ]
then
/usr/local/samba/bin/net rpc join -Uusername%password
fi
Dieses Skript wird auf dem Qnap mit Cron ausgeführt (suchen Sie bei Google nach „Qnap Cron“, um zu erfahren, wie man Cron richtig einrichtet). Das hat in den letzten Monaten gut funktioniert.
Antwort1
Scheint mir ein Problem mit dem Passwort des Computerkontos zu sein. In einer 2k3-Domäne wird der Reset konzeptgemäß alle 30 Tage durchgeführt, aber der Reset des Passworts des Computerkontos kann jederzeit vom Client ausgelöst werden.
Im Normalfall erstellt das Member zunächst das neue Passwort und zieht dieses anschließend zum DC.
Aus irgendeinem Grund scheint es so, als ob Ihr QNAP nach zwei Wochen ein neues Passwort generiert, es dann aber aufgrund eines defekten sicheren Kanals nicht an den DC übertragen kann.
Ich kenne die von QNAP angebotenen Funktionen nicht. Könnten Sie sich über SSH anmelden? Ich glaube, es ist ein Unix-basiertes System?! Vielleicht gibt es eine Option zum Deaktivieren des Computerkontokennworts. Das Vertrauen wird nach diesen 30 Tagen nicht aufhören zu funktionieren.
Vielleicht interessant: Linksammlung:
- http://support.microsoft.com/kb/810977, Ereignis-ID 5722 wird auf Ihrem Windows Server-basierten Domänencontroller protokolliert
- http://blogs.technet.com/b/asiasupp/archive/2007/01/18/typical-symptoms-when-secure-channel-is-broken.aspx
- http://www.dekart.com/howto/howto_logon/howto_logon_samba/trust_accounts/