Wie wird /etc/krb5.keytab beim Verteilen der Images angepasst?

Cosmicos · 27. August 2020 um 07:28

Ich habe aktuell das Problem, dass auf meinen 16 Linux-Clients die krb5.keytab nicht mehr zu stimmen scheint.

Konkret haben alle 16 Rechner nach dem Sync eine identische Keytab mit dem Hostnamen des Image-Masters. Der PC10 hat also z.B. nicht PC10 sondern PC12 in den Schlüsseln stehen (auf PC12 wurde das cloop erstellt und hochgeladen).

Bevor ich nun eine neue Sync-Runde bei 16 Rechnern starte möchte ich wegen des Zeitaufwandes gerne sicherstellen, dass die krb5.keytab danach korrekt ist.

Wo könnte der Fehler liegen? Durch welchen Mechanismus wird die krb5.keytab angepasst?
Ich habe schon ins postsync-script geschaut, dort aber nichts gefunden…

Danke vorab und Grüße
Ralf

Cosmicos · 27. August 2020 um 10:21

Okay… um irgendwie mal weiter zu kommen habe ich mich entschlossen, dass bionic-cloop mit den client-servertools komplett neu zu installieren.

Heruntergeladen habe ich lmn-bionic-200507. Nun wollte ich nach der aktuellen Anleitung weiter vorgehen: https://docs.linuxmuster.net/de/v7/getting-started/linuxclient.html

Leider ist das nicht ohne weiteres möglich, da die Anleitung nicht mehr aktuell ist und auf v7 nicht funktioniert

Die Syntax von linuxmuster-client hat sich verändert. Eine man-page existiert nicht, so dass ich es wie folgt versucht habe:

root@server:~# linuxmuster-client setpassword -c bionic-200507 (alte Syntax - klappt nicht!!!)

ersetzt durch:

root@server:~# linuxmuster-client -p xxxxxx -l lmn-bionic-200507 setpw
INFO: Setze Passwort auf Kommandozeilenwert

Ist das korrekt???

Nächster Schritt (klappt auch nicht wegen Syntaxänderung:)

root@server:~# linuxmuster-client configure

geändert in:
root@server:~# linuxmuster-client -f -r lmn-bionic-200507 configure

+++ Konfiguration +++
Überprüfe bereits vorhandene Dateien: Die Datei /srv/linbo/start.conf.lmn-bionic-200507  existiert bereits. (Wird mit -f überschrieben)
Die Datei /srv/linbo/lmn-bionic-200507.cloop  existiert bereits. (Wird mit -f überschrieben)
Die Datei /srv/linbo/lmn-bionic-200507.cloop.desc  existiert bereits. (Wird mit -f überschrieben)
Die Datei /srv/linbo/lmn-bionic-200507.cloop.info  existiert bereits. (Wird mit -f überschrieben)
Die Datei /srv/linbo/linuxmuster-client/lmn-bionic-200507/  existiert bereits. (Wird mit -f überschrieben)
Success.
HW-Klasse: lmn-bionic-200507
INFO: Patchklasse ist lmn-bionic-200507
INFO: Sichere /srv/linbo/start.conf.lmn-bionic-200507 nach /srv/linbo/start.conf.lmn-bionic-200507.20200827-095206.autobackup
INFO: Sichere das vorhandene Patchklassenverzeichnis
      /srv/linbo/linuxmuster-client/lmn-bionic-200507  nach
      /srv/linbo/linuxmuster-client/lmn-bionic-200507.20200827-095206.autobackup
Kopiere start.conf.lmn-bionic-200507 nach /srv/linbo/start.conf.lmn-bionic-200507: Success.
Kopiere lmn-bionic-200507.cloop nach /srv/linbo/lmn-bionic-200507.cloop: Success.
Kopiere lmn-bionic-200507.cloop.desc nach /srv/linbo/lmn-bionic-200507.cloop.desc: Success.
Kopiere lmn-bionic-200507.cloop.info nach /srv/linbo/lmn-bionic-200507.cloop.info: Success.
Kopiere linuxmuster-client/lmn-bionic-200507/ nach /srv/linbo/linuxmuster-client/lmn-bionic-200507/: Success.
INFO: Cloop-Datei ist /srv/linbo/lmn-bionic-200507.cloop
INFO: Creating and sourcing /etc/linuxmuster-client/server.network.settings in the clients filesystem
INFO: Sichere /srv/linbo/start.conf.lmn-bionic-200507 nach /srv/linbo/start.conf.lmn-bionic-200507.20200827-095206.autobackup
INFO: Passe /srv/linbo/start.conf.lmn-bionic-200507 an
INFO: Erstelle postsync aus Vorlage mit korrekter Patchklasse
WARNING: Sichere /srv/linbo/lmn-bionic-200507.cloop.postsync nach /srv/linbo/lmn-bionic-200507.cloop.postsync.20200827-095206.autobackup
INFO: Kopiere generische postsync.d-Dateien und passe sie an
 Copying /usr/lib/linuxmuster-client-servertools/postsync.data.d/etc_fstab from template
 Copying /usr/lib/linuxmuster-client-servertools/postsync.data.d/etc_hosts from template
 Copying /usr/lib/linuxmuster-client-servertools/postsync.data.d/etc_ssh_sshd_config from template
 Copying /usr/lib/linuxmuster-client-servertools/postsync.data.d/etc_systemd_timesyncd.conf from template
INFO: Setze Passwort für linuxadmin & co.
INFO: Setze Passwort auf Konfigurationswert
INFO: Kopiere root-public-keys in den postsync-Baum nach /root/.ssh/authorized_keys
cat: '/root/.ssh/id_*.pub': No such file or directory
INFO: Eigenes postsync.d-file nach linuxmuster-client/PATCHCLASS/common/postsync.d kopieren, z.B. folgendermaßen:
cp /usr/share/linuxmuster-client-servertools/examples//10-local-example-fix-permissions /srv/linbo/linuxmuster-client/lmn-bionic-200507/common/postsync.d
Success

Korrekt?

Nächster Schritt: Masterclient in die HW-Gruppe aufnehmen. Check!

Nächster Schritt: Masterclient syncronisieren!
Erster Versuch per ssh. Klappt nicht

root@server:~# linbo-ssh PC12
root@pc12: Permission denied (publickey).

Warum klappt das nicht? (UPDATE: klappt jetzt. Ich hatte bei irgendeinem Versuch mal die ssh-keys verschoben, daher wurden sie nicht gefunden) - ist korrigiert!

… also an den Rechner gesetzt und syncronisiert. Funktioniert!

Nächster Schritt: Masterclient aufnehmen - Bionic erstmalig gebootet

Login nicht möglich, da /etc/fstab nicht korrekt gepacht wurde

Also /etc/fstab von Hand gepatcht (Partitionen korrekt eingetragen) und erneut gesynct.
Nun bekomme ich endlich einen Anmeldebildschirm.

Nächster Schritt - Anmelden als linuxadmin:
Auch das funktioniert NICHT! Es wird kein Passwort für den User „linuxadmin“ angenommen. Weder „Muster!“, noch das PW, welches ich also Kommandozeilenparameter übergeben habe.

Nun habe ich für heute keinen Bock mehr

Fehler über Fehler gepaart mit falschen Anleitungen. Das macht so wirklich keinen Spaß

Oder liegt es an mir? Mache ich blöde Fehler???

Fakt ist, dass ich im Moment „betriebsblind“ bin. Ich habe das Ganze jetzt schon sooo oft durchgeorgelt, dass ich vielleicht tatsächlich Fehler mache oder Dinge nicht mehr sehe!

Daher mein HILFERUF!

Was mache ich falsch??? Wer sieht etwas???

zefanja · 27. August 2020 um 11:02

Log dich doch vom Server mit root ein (wenn du den ssh key von root per postsync auf den Rechner legst) und setzte da einfach das Passwort des linuxadmin neu.

vG Stephan

Cosmicos · 27. August 2020 um 11:05

Ja, das hatte ich auch vor. Ich habe ja inzwischen den ssh-Fehler gefunden und werde mich nach dem nächsten Versuch per ssh anmelden können.
Dann sehen wir weiter…
Danke!

ChristianWd · 27. August 2020 um 12:41

Hallo Ralf,

ich bin noch relativ unbedarft, was die LMN7 angeht. Heute habe ich mich auch an den Linuxclient gemacht und hatte ähnliche Probleme.

Du hast das Passwort das linuxadmin zwar neu gesetzt, es wird aber evtl. mit der Zeile
linuxmuster-client -f -r lmn-bionic-200507 configure
wieder überschrieben. Leider weiß ich nicht mehr, wo die Standarddaten für den Linuxclient auf dem Server hinterlegt sind, aber dort stand bei mir als Passwort „muster2016“ (ohne Anführungszeichen).
Die Festplattenzuordnung hat bei mir auch nicht gestimmt. Das Mint-Image konnte ich nicht mal starten, da es auf Partition 1 mit einer bestimmten UUID die Festplatte erwartet. Ich würde testweise einen Client im noproxy-Bereich nur für die Imagebearbeitung anlegen. Denn der Domänenbeitritt muss mit linuxmuster-cloop-turnkey auch noch gemacht werden. Erst dann kannst du das eigentliche für deine Domäne passende Image erstellen. Ich weiß zwar nicht wie, aber vielleicht lässt sich das Startproblem bzw. die falsche /etc/fstab gleich noch beheben.

Das ist das, was mir dazu einfällt.

Schöne Grüße

Christian

Cosmicos · 27. August 2020 um 12:41

So, ich habe den bionic-client nun komplett neu eingespielt. Alles exakt nach Anleitung.
Angepasst, upgedated, in die Domaine aufgenommen, Image-erstellt, Image verteilt.

In Bezug auf die /etc/krb5.keytab hat sich leider nichts geändert. Die Dateien sind schon wieder auf dem Master und den Clients identisch

Konkret: Überall stehen nur keys für PC12 drin!

Ich weiß nun echt nicht weiter! Hilfe!!!

Cosmicos · 27. August 2020 um 14:10

Hi Christian,
vielen Dank für Deine Tipps. Das Problem mit den Passwörtern könnte ich dank @zefanja lösen. Es ist zwar rätselhaft, dass der Befehl nichts bewirkte (er meldete ja explizit, dass das PW des Kommonazeilenparameters gesetzt wurde) aber per SSH Login war das zu fixen.

Das Problem mit der nicht gepatchten fstab war mir bekannt, nur im Moment der Installation nicht mehr präsent Wenn man es kennt, dann ist das ja kein Problem. Wenn man neu mit dem System arbeitet, dann ist es aber nervig und zeitraubend

Es gibt auch noch ein paar andere unsaubere Stellen, die erst nach dem Start von lmncc offenbar werden. So geistet z.B. die 10.16.1.1 noch in Configfiles rum (doof wenn man wie ich das 172.16.1.0/24 Netz verwendet) und als Domänenname ist in cups noch lmn.net zu finden. Das muss man alles erst einmal finden und von Hand zurecht biegen. Wenn man es weiß alles kein Problem. Wenn nicht, dann hängt man stundenlang am Rechner

Schwerwiegend ist jedoch das krb5.keytab Problem, da das die Domänenanmeldung nach erfolgreichem Join verhindert!

Ich fürchte allerdings, dass ich mir das krb5.keytab Problem selber geschaffen habe. Das hat nämlich Anfangs mal funktioniert, soweit ich mich erinnere. Zumindest hatte mein Test-PC 2 (PC09) mal eine korrekte keytab. Kann allerdings auch sein, dass ich PC09 manuell gejoint habe. Ich erinnere mich leider nicht, da das 8 Wochen her ist.
Ein manueller Domänenjoin auf JEDEM Linux-Client kann ja auch nicht Sinn der Sache sein, da das ein automatisches Syncen in der Nacht ad absurdum führen würde.

Daher wäre es sehr wichtig für mich zu wissen wie der Mechanismus dahinter funktioniert. An welcher Stelle wird während eines syncs die krb5.keytab angepasst?

Entwickler???

Michael · 27. August 2020 um 16:44

Hi.
Es ist zwar keine große Hilfe aber ich habe einfach mal das github-Repository linuxmuster-linbo heruntergeladen und darin herum gestöbert:

Darin kann man immerhin nach .macct suchen und wird auch fündig. Genauer kann ich aber nicht sagen, ob da alles passt … wenn man nach krb5.keytab sucht, findet man dort leider nichts … daher müssten dann doch die Entwickler nochmal sagen, wie der Mechanismus abläuft …

VG,
Michael

rettich · 27. August 2020 um 16:44

Hallo Ralf,
ich glaube das mit den keytab-Einträgen stimmt so.
Auf meinen Rechnern steht auch überall das gleiche. Und ich kann mich auf allen Rechnern anmelden.
Bisher ist auf allen Rechnern nur Linux drauf. Und am liebsten würde ich auch kein Windows installieren. Aber leider bekomme ich Cassy unter Linux nicht zum laufen. Und dann befürchte ich, werde ich die gleichen Probleme mit der Anmeldung, wie du haben.

Gruß,
Mathias

rettich · 27. August 2020 um 18:07

… ich bins nochmal…
Meine Vermutung ist ja, dass bei mir und auch bei Ralf etwas mit der Systemzeit nicht stimmt. Das würde erklären, dass sobald ein Windows-Client auf den AD zugreift (also wenn sich jemand anmeldet) bei den Linux-Clients nichts mehr geht.

Ich könnte mir vorstellen, dass die Windows-Clients bei der Anmeldung den AD oder Kerberos dazu veranlassen, die Zertifikate in einer anderen Zeitzone zu checken. Linux macht das wohl nicht.
Im Augenblick arbeiten opnSense und der Server mit UTC-Zeit.

@baumhof @thomas
Wie sehen die Zeiteinstellungen bei euch aus?

Ich werde jetzt von meinem System einen Snapshot machen und morgen auf einem Client Windows 10 prof installieren. Bei diesem Client werde ich RTC=UTC einstellen (wie bei den Linux-Clients auch). Und ich werde ihn dann erst in die Domäne aufnehmen. Mal sehn…

Ich würde mich freuen, wenn mir jemand, bei dem Dualboot funktioniert sagen könnte, auf welcher Zeit seine Maschinen laufen. Dann könnte ich mir eventuell etwas Arbeit ersparen.

Gruß,
Mathias

Cosmicos · 27. August 2020 um 18:39

Ich bin gerade dabei mich ein wenig in die Kerberos-Thematik einzulesen.
Mein bisheriger Kenntnisstand ist, dass jeder Host einen Host-Pricipal auf dem Kerberos-Server haben muss. Für jeden Principal gibt es dann einen Host-Key in der keytab.
Von der Logik her würde ich sagen sauber wäre, wenn jeder Host seinen eigenen Principal und Key hätte. Vielleicht funktioniert das aber auch mit einem einzigen Host-Principal (sozusagen dem Erzeuger), mit dessen Daten sich alle Hosts anmelden. Soweit bin ich aber noch nicht. Ob das clean oder dirty ist vermag ich ebenfalls noch nicht zu beurteilen…

Das Ganze erschließt sich mir noch nicht so ganz und die Systemkonfiguration scheint auch nicht frei von Altlasten zu sein. Wenn ich mir z.B. auf dem Server ein TGT holen möchte dann werde ich nach einem Passwort für einen mir unbekannten Menschen gefragt, der sich irgendwo noch im System versteckt…

Der Benutzer heißt „wuestelo@LINUXMUSTER.LAN“
Vielleicht weiß der ja was korrekt ist

rettich · 27. August 2020 um 18:49

Hallo Ralf,
wenn wir zu den Wenigen zählen, bei denen Dualboot nicht geht, muss es etwas geben, was bei uns anders ist.

Hast du den mal eingeführt oder war der schon im System?
Gruß,
Mathias

Cosmicos · 27. August 2020 um 18:56

Der war schon im System. Die Person ist mir nicht bekannt und hier im Forum gibt es „nur“ einen Anton Wuest. Der ist es aber sicher nicht…

Ich glaube, die Mehrheit der Nutzer verwendet Dualboot nicht. Das hatte ich irgendwo gelesen.
Man könnte auch sagen, dass wir etwas gemeinsam haben in unseren Setups was u.U. die Probleme verursacht. Daher finde ich den Zeit-Ansatz ebenfalls interessant. Ich habe Windows 10 ja ebenfalls auf RTC = UTC umgestellt…

hoeferwolf · 9. September 2020 um 10:46

Hi,

auch wenn etwas verspätet …

die krb5 ist überall identisch und das ist ein fettes Problem. Ich hatte (gibt es irgendwo nen post hier) den Image-Master-Rechner nach dem Aufsetzen des Systems "vom Netz genommen, umbenannt, wo anders hin gestellt … und NICHTS ging mehr, da der Image-Master-Rechner nach dem nächsten Import der Workstations dann für die V7 nicht
mehr existiert. Mit anderen Worten gibt es für den Kerberos quasi nur einen Rechner - wenn man das so sagen kann …

Das mit dem Dualboot ist auch so ein Problem, das geht bei uns auch nicht - also Booten schon, aber anmelden nicht. Das liegt ganz einfach daran, dass der letzte Sync „gewinnt“. Synce ich in der Reihenfolge „Linux - Windows“ kann sich Windows anmelden, Synce ich „Windows-Linux“, dann geht es von Linux aus. Ich kann im laufenden Betrieb aber nicht vor jedem Boot das gewünschte System syncen, damit es korrekt im AD registriert ist …

Aktuell hab ich aber wieder das Problem, dass ich auf einigen Rechnern
von Linux aus ins Internet komme, andere aber gegen die Proxy-Auth knallen … War vor den Ferien nicht. Ist also irgendwas mit „zu lange inaktiv“ oder so? klist -l zeigt für mich auf dem Rechner allerdings ein abgelaufenes Kerby-Ticket an … wann wird das neu ausgestellt?

VG
Wolfgang

baumhof · 10. September 2020 um 18:17

Hallo Wolfgang,

Das mit dem Dualboot ist auch so ein Problem, das geht bei uns auch
nicht - also Booten schon, aber anmelden nicht. Das liegt ganz einfach
daran, dass der letzte Sync „gewinnt“. Synce ich in der Reihenfolge
„Linux - Windows“ kann sich Windows anmelden, Synce ich „Windows-Linux“,
dann geht es von Linux aus. Ich kann im laufenden Betrieb aber nicht vor
jedem Boot das gewünschte System syncen, damit es korrekt im AD
registriert ist …

… das ist bekannt: das geht so nicht.
Erst beim sync wird das Workstationpasswort in den AD geschrieben (die
macct Datei auf dem Server) und da das unterschiedlich ist zwischen
Windows uns Linux muß dieser Prozess beim umbooten ausgelößt werden: was
bisher nur beim sync der Fall ist.
Dass das früher ging lag nur daran, dass das ubuntu nie in der Domäne war.

Aktuell hab ich aber wieder das Problem, dass ich auf einigen Rechnern
von Linux aus ins Internet komme, andere aber gegen die Proxy-Auth
knallen … War vor den Ferien nicht. Ist also irgendwas mit „zu lange
inaktiv“ oder so? klist -l zeigt für mich auf dem Rechner allerdings ein
abgelaufenes Kerby-Ticket an … wann wird das neu ausgestellt?

das war bei mir auch eine Weile so: das ging erst weg nachdem ich den
Zeitsync auf den Clients ordentlich eingestellt hatte (also den
timedatectl auf ubuntu gesagt hatte: frag den server nach der Zeit).
LKäuft die Zeit mehr als ca. 3 Minuten auseinander, dann schmollt der
Proxy und motzt wegen des Kerberoszertifikats.

Seit ich das gerichtet habe ist Ruhe …

In deinem Dualboot setting ist es extrem wichtig windows bei zu bringen
ins BIOS nicht die Localtime zu schreiben, sondern UTC (wie alle anderen
BS auch …).

LG

Holger

jrichter · 11. September 2020 um 02:17

Hallo Holger,

Wäre es dann nicht sinnvoll, dass das Passwort auch beim unsynchronisierten Start gesetzt wird? Oder ein neuer Knopf: „Patch und Start“? Es gab ja schon mal den Wunsch, nur das Postsync-Skript auszuführen (also ohne vorher zu syncen).

Beste Grüße

Jörg

Cosmicos · 11. September 2020 um 05:13

Seltsam, bei uns geht das! Ich habe in der Nacht von Mi. auf Do. alle Win10-Clients neu bespielt, da ich einen neuen Drucker ins cloop gebaut hatte (nur sync geht ja wg. NTFS nicht) und konnte gestern sowohl Linux als auch Windows starten und auf beiden Domänenanmeldungen machen.

EDIT: Von gestern auf heute habe ich außerdem alle Linux-clients neu aufgespielt (Software nachinstalliert). Heute habe ich dann das Gesamtsystem mit den SuS ausgiebig getestst.
Sowohl die Domänenanmeldung unter Windows 10 als auch unter Linux funktioniert.
Ein Windows-Rechner von 16 hatte die Vertauensstellung verloren - das muss ich noch checken (evtl. Uhrzeit?) ansonsten klappt aber alles perfekt.
„Der letzte gewinnt“ trifft hier eindeutig nicht zu.

@hoeferwolf Hast du die „Master-Images“ (Win/Lin) auf dem selben Rechner erzeugt oder auf getrennten Rechnern bzw. in VMs?

Ich hatte lange Probleme weil ich sowohl Windows als auch Linux auf dem selben Rechner mit dem selben Hostnamen (PC12) erzeugt hatte. Seit ich das getrennt habe, funktioniert im Prinzip alles.
Das Linux-Image muss isoliert installiert und hochgeladen werden. Auf diesem Rechner darf kein Windows installiert sein.

LG
Ralf

hoeferwolf · 11. September 2020 um 11:38

Hi,

interessanter Aspekt und durchaus nicht unplausibel. Gehen wir mal davon aus, dass das Clonen bei Windows den geleichen „Fehler“ macht, wie bei Linux (in Bezug auf die krb5-Datei).
Mach ich das Linux-image von einem Rechner, ist dieser im AD drinnen.
Alle anderen Clients mit diesem Image erscheinen dem AD dann „gleich“. Wenn ich Windows auf einem anderen Rechner erstelle und dieser dann quasi auch nur „Einmal“ im AD auf diese Weise registriert haben, dann kennt der AD auf dieser Ebene - welche auch immer das sein mag - genau 2 verschiedene Rechner und diese können sich anmelden. Ob das dann Kopien oder das Original ist, kümmert ihn nicht …
Ok - gewagte Theorie, ist mir auch klar und dass zig Mechanismen dabei nicht berücksichtigt sind ebenfalls — würde das Verhalten aber erklären …

VG
Wolfgang

rettich · 11. September 2020 um 19:06

Hallo zusammen,
ich habe festgestellt, dass nicht nurf beim sync das Workstationpassword auf den AD geschrieben wird, sondern beim bloßen Start. Allerdings muss der Client am Netzwerk hängen. Also nicht offline gestartet werden. Und genau das ist das Problem bei Laptops. Die werden nämlich im allgemeinnen offline gestartet und da wird auf dem AD kein Workstationpasswort geschrieben.
Eine Lösung könnte sein, dass das Workstationpasswort für Linux und Windows gleich ist. Nur wie man das macht, weiß ich leider auch nicht
Gruß,
Mathias