Hallo Welt da draußen,
heute bin ich mal wieder fast verzweifelt. Ein bisschen habe ich mich an meine Zeiten als Angestellter mit dem Projekt der Helaba erinnert gefühlt. Da war die Woche über alles ruhig, bis dann Freitag Mittag irgendein Bug gemeldet wird und einem das ganze Wochenende versaut wird, weil der natürlich als höchste Prio eingestuft und möglichst superschnell gefixt werden muss.
So ist das halt…
Worum geht’s eigentlich?
Vor etlichen Jahren hatte ich meinem langjährigsten und besten Kunden (und Kumpel) eine Mini-Server-Architektur eingerichtet, mit denen er sein “Business” durchziehen kann. Im Endeffekt besteht das Teil eigentlich nur aus 2 Servern und ein paar zusätzlichen Client-Rechnern. Einer der Server ist ein Windows Server 2012 R2 auf dem ein Active Directory läuft, der andere ein Ubuntu-Server der als Email- und Fileserver dient. Soweit so chic. Warum auch immer habe ich damals das ganze als Domäne eingerichtet, obwohl im Endeffekt abzusehen war, dass das für die geringe Anzahl der Nutzer so ziemlich overkilled ist.
Bis auf wenige Ausnahmen lief das immer ganz gut – naja, abgesehen vom Remote Desktop, der von Remote aus zugreifbar sein soll und daher eigentlich immer unter Dauerfeuer steht und beim dem (obwohl eigentlich niemand angemeldet ist), die Connections immer überlaufen. Heute würde ich es anders (mit VPN) machen, aber damals wusste ich es nicht besser.
Der Linux-Server ist mit dem Windows-Server per Domäne verbunden, soweit ist das eigentlich ziemlich cool, da der Kunde dann im Windows einfach Nutzer hinzufügen kann und diese dann automatisch im Linux-Server erscheinen. Probleme hat das bisher eigentlich noch nie so wirklich gemacht, außer, die Serverzeit wich zu stark voneinander ab. I.d.R. sollte das nicht vorkommen, wenn sich beide mit einem ntp-Server verbinden, aber es gab auch mal Zeiten, wo das nicht funktioniert hat oder ein Nutzer einfach mal die Serverzeit geändert hat.
Das führt dann dazu, dass sich der Linux-Rechner nicht mehr verbinden kann, die Nutzer damit nicht mehr im Linux-System verfügbar sind und der Rechner quasi aus der Domäne fliegt.
Leider kommt das so selten vor, dass ich das immer vergessen, was ich da machen muss.
Heute war es dann mal wieder soweit, die Email ging nicht mehr – am Imap-Konto konnte man sich nicht mehr anmelden. Prinzipiell stimmten aber die Uhren beider Server überein, aus irgendeinem (noch unerklärlichen Grund) wollten beide nicht mehr miteinander.
Richtig komisch war, dass die Nutzer, mit denen man sich sonst immer nicht anmelden konnte, trotzdem funktionierten, d.h. man konnte grundsätzlich eine Shell starten, aber eben die Anmeldung beim IMap (Dovecot)-Server schlug fehl.
Nach etlichem Fluchen und Suchen hier mal die Fehlerbehebung:
Einloggen in den Rechner als Root oder als “lokaler” Nutzer (der nicht in der Domain registriert ist).
Dann habe ich geschaut, ob die Dienste (dovecot, winbind) Probleme machen:
sudo systemctl status dovecot
sudo systemctl status winbind
Bei winbind gab es dann folgendes Problem:
Kinit for ***** to access cifs/**.***.local@*****.LOCAL failed: Cannot contact any KDC for requested realm
Dovecot brachte so etwas in der Art:
pam_krb5(dovecot:auth): (user xxxxx) credential verification failed: Cannot find key for host/fileserver@*****.LOCAL kvno 444 in keytab
und
pam_winbind(dovecot:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_AUTH_ERR (7), NTSTATUS: NT_STATUS_LOGON_FAILURE
Wie schon geschrieben, habe ich das lange nicht mehr gemacht, also bin ich wieder auf die Suche nach der Möglichkeit gegangen, das ganze wieder zu verbinden.
Leider gab es da nicht mehr so viel, da noch ein Ubuntu 16.04 eingesetzt wird und die meisten Dinge dann für die neueren Versionen, bei denen das ganze etwas anders funktioniert, beschrieben ist.
Am Ende wurde ich dann aber wieder fündig.
Als erstes habe ich mal geprüft, ob ich mich überhaupt mit meinem Windows-Nutzer irgendwie verbinden konnte:
ntlm_auth --username= --diagnostics
Hier kamen bloß Fehler:
Wrong Password (0xc000006a)
und das etliche Male.
Dann habe ich mal geprüft, ob noch irgendetwas an Verbindung da ist:
sudo klist
Brachte dann ein paar Daten, speziell wie lange die Kerberos-Schlüssel funktionieren.
Mit:
sudo kinit -V
konnte ich prüfen, dass eine Verbindung grundsätzlich möglich ist. Trotzdem führte das nicht zum Ergebnis.
Und dann gab es ja noch:
sudo net ads join -k
was so auch nicht funktionierte und mit :
ADS join did not work, falling back to RPC gss_init_sec_context failed with [ Miscellaneous failure (see text): unable to reach any KDC in realm *****.LOCAL] Failed to join domain: failed to lookup DC info for domain '*****' over rpc: An internal error occurred.
quittiert wurde
… weil ….
natürlich die Nutzerinformationen (der Admin-Nutzer fehlte), mit dem der Beitritt zur Domäne erlaubt ist.
Mit:
sudo net ads join -k -U
und Eingabe des Passworts konnte ich den Server endlich wieder mit dem PDC verbinden und Email und alles andere lief wieder.