Hallo Welt da drau\u00dfen,<\/p>\n
heute bin ich mal wieder fast verzweifelt. Ein bisschen habe ich mich an meine Zeiten als Angestellter mit dem Projekt der Helaba erinnert gef\u00fchlt. Da war die Woche \u00fcber alles ruhig, bis dann Freitag Mittag irgendein Bug gemeldet wird und einem das ganze Wochenende versaut wird, weil der nat\u00fcrlich als h\u00f6chste Prio eingestuft und m\u00f6glichst superschnell gefixt werden muss.
\nSo ist das halt…<\/p>\n
Worum geht’s eigentlich?<\/p>\n
Vor etlichen Jahren hatte ich meinem langj\u00e4hrigsten 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\u00e4tzlichen Client-Rechnern. Einer der Server ist ein Windows Server 2012 R2 auf dem ein Active Directory l\u00e4uft, der andere ein Ubuntu-Server der als Email- und Fileserver dient. Soweit so chic. Warum auch immer habe ich damals das ganze als Dom\u00e4ne eingerichtet, obwohl im Endeffekt abzusehen war, dass das f\u00fcr die geringe Anzahl der Nutzer so ziemlich overkilled ist.<\/p>\n
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 \u00fcberlaufen. Heute w\u00fcrde ich es anders (mit VPN) machen, aber damals wusste ich es nicht besser.<\/p>\n
Der Linux-Server ist mit dem Windows-Server per Dom\u00e4ne verbunden, soweit ist das eigentlich ziemlich cool, da der Kunde dann im Windows einfach Nutzer hinzuf\u00fcgen kann und diese dann automatisch im Linux-Server erscheinen. Probleme hat das bisher eigentlich noch nie so wirklich gemacht, au\u00dfer, 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\u00e4ndert hat.
\nDas f\u00fchrt dann dazu, dass sich der Linux-Rechner nicht mehr verbinden kann, die Nutzer damit nicht mehr im Linux-System verf\u00fcgbar sind und der Rechner quasi aus der Dom\u00e4ne fliegt.<\/p>\n
Leider kommt das so selten vor, dass ich das immer vergessen, was ich da machen muss.<\/p>\n
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 \u00fcberein, aus irgendeinem (noch unerkl\u00e4rlichen Grund) wollten beide nicht mehr miteinander.
\nRichtig komisch war, dass die Nutzer, mit denen man sich sonst immer nicht anmelden konnte, trotzdem funktionierten, d.h. man konnte grunds\u00e4tzlich eine Shell starten, aber eben die Anmeldung beim IMap (Dovecot)-Server schlug fehl.<\/p>\n
Nach etlichem Fluchen und Suchen hier mal die Fehlerbehebung:<\/p>\n
Einloggen in den Rechner als Root oder als „lokaler“ Nutzer (der nicht in der Domain registriert ist).
\nDann habe ich geschaut, ob die Dienste (dovecot, winbind) Probleme machen:<\/p>\n
sudo systemctl status dovecot<\/pre>\nsudo systemctl status winbind<\/pre>\nBei winbind gab es dann folgendes Problem:<\/p>\n
Kinit for ***** to access cifs\/**.***.local@*****.LOCAL failed: Cannot contact any KDC for requested realm<\/pre>\nDovecot brachte so etwas in der Art:<\/p>\n
pam_krb5(dovecot:auth): (user xxxxx) credential verification failed: Cannot find key for host\/fileserver@*****.LOCAL kvno 444 in keytab<\/pre>\nund<\/p>\n
pam_winbind(dovecot:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_AUTH_ERR (7), NTSTATUS: NT_STATUS_LOGON_FAILURE<\/pre>\nWie schon geschrieben, habe ich das lange nicht mehr gemacht, also bin ich wieder auf die Suche nach der M\u00f6glichkeit gegangen, das ganze wieder zu verbinden.
\nLeider gab es da nicht mehr so viel, da noch ein Ubuntu 16.04 eingesetzt wird und die meisten Dinge dann f\u00fcr die neueren Versionen, bei denen das ganze etwas anders funktioniert, beschrieben ist.<\/p>\nAm Ende wurde ich dann aber wieder f\u00fcndig.<\/p>\n
Als erstes habe ich mal gepr\u00fcft, ob ich mich \u00fcberhaupt mit meinem Windows-Nutzer irgendwie verbinden konnte:<\/p>\n
ntlm_auth --username= --diagnostics<\/pre>\nHier kamen blo\u00df Fehler:<\/p>\n
Wrong Password (0xc000006a)<\/pre>\nund das etliche Male.
\nDann habe ich mal gepr\u00fcft, ob noch irgendetwas an Verbindung da ist:<\/p>\nsudo klist<\/pre>\nBrachte dann ein paar Daten, speziell wie lange die Kerberos-Schl\u00fcssel funktionieren.
\nMit:<\/p>\nsudo kinit -V<\/pre>\nkonnte ich pr\u00fcfen, dass eine Verbindung grunds\u00e4tzlich m\u00f6glich ist. Trotzdem f\u00fchrte das nicht zum Ergebnis.
\nUnd dann gab es ja noch:<\/p>\nsudo net ads join -k<\/pre>\nwas so auch nicht funktionierte und mit :<\/p>\n
ADS join did not work, falling back to RPC\r\ngss_init_sec_context failed with [ Miscellaneous failure (see text): unable to reach any KDC in realm *****.LOCAL]\r\nFailed to join domain: failed to lookup DC info for domain '*****' over rpc: An internal error occurred.\r\n<\/pre>\nquittiert wurde<\/p>\n
<\/p>\n
<\/p>\n
… weil ….<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
nat\u00fcrlich die Nutzerinformationen (der Admin-Nutzer fehlte), mit dem der Beitritt zur Dom\u00e4ne erlaubt ist.
\nMit:<\/p>\nsudo net ads join -k -U<\/pre>\nund Eingabe des Passworts konnte ich den Server endlich wieder mit dem PDC verbinden und Email und alles andere lief wieder.<\/p>\n","protected":false},"excerpt":{"rendered":"
Hallo Welt da drau\u00dfen, heute bin ich mal wieder fast verzweifelt. Ein bisschen habe ich mich an meine Zeiten als Angestellter mit dem Projekt der Helaba erinnert gef\u00fchlt. Da war die Woche \u00fcber alles ruhig, bis dann Freitag Mittag irgendein Bug gemeldet wird und einem das ganze Wochenende versaut wird, weil der nat\u00fcrlich als h\u00f6chste […]<\/p>\n","protected":false},"author":1,"featured_media":663,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[],"_links":{"self":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/662"}],"collection":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/comments?post=662"}],"version-history":[{"count":1,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/662\/revisions"}],"predecessor-version":[{"id":664,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/662\/revisions\/664"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/media\/663"}],"wp:attachment":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/media?parent=662"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/categories?post=662"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/tags?post=662"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}