Linuxclients Anmeldungs-/Domänenproblem

Hallo Thomas!

Kann es sein, dass dann die Anmeldung unter Linux nach 7 Tagen nicht mehr geht, weil das Ticket 7 Tage läuft und kein neues gezogen werden kann?

Vielleicht ist die Frage unsinnig, dann liegt es daran dass mir der Gesamtzusammenhang mit Gerätepasswort, Domänenbeitritt, kerberos-Ticket und Legitimierung verschiedener Dienste nicht klar ist.
Kann mich jemand erleuchten?

Gruß - Rainer

Hallo Rainer!

Kann ich mir nicht vorstellen. Das Ticket wird ja nur für den global-admin für den Domänenbeitritt benötigt. Der Benutzer zieht sich bei jeder Anmeldung selbst ein neues Ticket.

VG, Thomas

Hallo,

Kann ich mir nicht vorstellen. Das Ticket wird ja nur für den
global-admin für den Domänenbeitritt benötigt. Der Benutzer zieht sich
bei jeder Anmeldung selbst ein neues Ticket.

ich glaub das auch nicht: sonst hätten ja meine virtuellen Umgebungen,
die ich seit Januar verwende, alle schon vor Monaten ablaufen müssen:
Fakt ist aber: die sind alle problemlos in ihrer Domäne gelieben: auch
nach Monaten…

Wichtiger Hinweis, und das hatte mich schon ein wenig beunruhigt, ist
dass man „verbrannte“ Clients durch auskomentieren in der devices.csv,
import und wieder rein, import reparieren kann.
Dass man so gleich die Dualbootfähigkeit zurück bekommt ist natürlich
schon ein Knaller.
Da heißt es jetzt wirklich: testen …

LG

Holger

Hallo Thomas!
Und für das Ticket genügt das richtige Passwort der Workstation und die Benutzerdaten des Ticketziehers?!
Interessanterweise funktioniert das auch an geclonten Ubuntu-Clients, die nicht in der Domäne sind - „#net ads testjoin“.
Aber auch nicht immer. Vielleicht wenn das Maschinenpasswort nicht stimmt? Aber dieses dann einfach (über die macct-Datei) auf den richtigen Wert zu setzen reicht auch nicht. Da muss es noch etwas anderes geben.
Ich habe unzählige Stunden damit verbracht, aber keine Logik gefunden. :frowning:
Gtuß - Rainer

Hallo Rainer,

wie sieht den bei dir die hosts Datei auf dem Client aus?

LG

Holger

Moin!

[roesslerrr] roesslerrr https://ask.linuxmuster.net/u/roesslerrr
Entwickler
7. September

Hallo Thomas!
Und für das Ticket genügt das richtige Passwort der Workstation und
die Benutzerdaten des Ticketziehers?!
Interessanterweise funktioniert das auch an geclonten Ubuntu-Clients,
die nicht in der Domäne sind - „#net ads testjoin“.
Aber auch nicht immer. Vielleicht wenn das Maschinenpasswort nicht
stimmt? Aber dieses dann einfach (über die macct-Datei) auf den
richtigen Wert zu setzen reicht auch nicht. Da muss es noch etwas
anderes geben.
Ich habe unzählige Stunden damit verbracht, aber keine Logik gefunden.
:frowning:

samba speichert das beim Domänenbeitritt mit dem Server ausgehandelte
Geheimnis lokal in seinem Schlüsselspeicher. Gleichzeitig landet das
Geheimnis auf dem Server im AD im Computeraccount. Da der
Samba-Schlüsselspeicher über das Linbo-Image an die anderen Clients
ausgerollt und beim BS-Start der Hashwert des Geheimnisses über die
macct-Datei in den jeweiligen Computeraccount gepumpt wird, bleibt das
konsistent. Wenn du jetzt aber auf einem Client nochmal der Domäne
beitrittst, stimmt das Ganze für diesen Client nicht mehr und der Server
lässt keine Domänenauthentifizierung mehr zu. Funktioniert eigentlich
wie bei Windows.

Versuch mal mit den Clients, die nicht mehr gehen den Workaround:

  • Computeraccount löschen
  • Computeraccount wieder anlegen
  • synchronisiert starten.

VG, Thomas

Hallo Thomas,

ich stecke ja vor dem gleichen Problem:
und denke dass die drei Schritte nicht reichen.
wir haben die verfügbaren ubuntu1804basis.cloop auf den Server geholt,
Eingetragen in die devices.csv; Aufbau einer start.conf usw.
linuxmuster-import-devices
per Linbo partitioniert und "new" verteilt.
linuxmuster-distupgrade
die IP Adresse in die „noProxy“ Alias Firewall Regel-Liste (davon schreibt hier keiner mehr was?)
linuxmuster-adsso
(als linuxadmin)
An dem Standort war zu keinem Zeitpunkt mit diesen Linux PCs ein Domänen-Logon möglich.
(zuvor unter LMLv6 lief hier jahrelang Linux Ubuntu drauf)

In der host Datei gibt es neben den IPv6 Einträgen, folgende beiden Zeile:
127.0.0.1 localhost
127.0.1.1 template
was ist damit zu tun?
hostname -f: r207-pc05.bw-wiz.llan
der Stimmt.
Die Fragen sind also:
„Computeraccount löschen“ meint aus der devices.csv löschen und linuxmuster-import-devices
„Computeraccount wieder anlegen“ mit selben namen? dann wieder linuxmuster-import-devices
Muss die /etc/hosts Datei angepasst werden?
Was ist mit der macct-Datei ?
Was ist jetzt mit dem Befehl: linuxmuster-adsso

Das war es ?

Grüße,
gerd

@Holger:
Habt ihr den universellen postsync eingerichtet?
Gibt es ein Verzeichnis
/srv/linbo/linuxmuster-client bei euch?

nein und nein…
Wir sprechen von LMLv7?
Ich habe dazu was gefunden:
Anpassungen mit Postsync-Scripten
Aber wie (und wofür) das Grundeingerichtet wird fand ich bisher noch nicht.

Ich gehe den Artikel mal durch…

Grüße,
gerd

Hallo Gerd,

[gpeter] gpeter https://ask.linuxmuster.net/u/gpeter
9. September

thomas:

Versuch mal mit den Clients, die nicht mehr gehen den Workaround:

  * Computeraccount löschen
  * Computeraccount wieder anlegen
  * synchronisiert starten.

VG, Thomas

Hallo Thomas,

ich stecke ja vor dem gleichen Problem:
und denke dass die drei Schritte nicht reichen.
wir haben die verfügbaren ubuntu1804basis.cloop auf den Server geholt,

linuxmuster-import-devices|
per Linbo partitioniert und „new“| verteilt.
linuxmuster-distupgrade|
die IP Adresse in die „noProxy“ Alias Firewall Regel-Liste (davon
schreibt hier keiner mehr was?)
linuxmuster-adsso|
(als linuxadmin)
An dem Standort war zu keinem Zeitpunkt mit diesen Linux PCs ein
Domänen-Logon möglich.
(zuvor unter LMLv6 lief hier jahrelang Linux Ubuntu drauf)

In der host Datei gibt es die Zeile:

127.0.1.1 template|
was ist damit zu tun?

Das müssen die beantworten, die das cloop gebastelt haben.

hostname -f: r207-pc05.bw-wiz.llan|
der Stimmt.
Die Fragen sind also:
„Computeraccount löschen“ meint aus der devices.csv löschen und
linuxmuster-import-devices
„Computeraccount wieder anlegen“ mit selben namen? dann wieder
linuxmuster-import-devices

das ist nur für den Fall, dass man auf dem selben Rechner mit
verschiedenen Systemen der Domäne beigetreten ist. Dann ist nämlich u.U.
der Computeraccount nicht mehr konform.

Was ist jetzt mit dem Befehl: |linuxmuster-adsso|

linuxmuster-client-adsso-setup braucht man, um den Master initial
einzurichten und um der Domäne beizutreten. Danach erstellt man gleich
ein Image, damit man eine konforme macct-Datei hat.

Wichtig ist, dass man vor dem Domänenbeitritt die macct-Datei löscht,
die evtl. mit dem cloop mitgeliefert wird. Denn sonst wird beim ersten
Neustart des Systems nach dem Setup auf dem Server ein falsches
Computeraccountpasswort gepatcht.

Hallo Gerd,

@Holger <https://ask.linuxmuster.net/u/holger>:
Habt ihr den universellen postsync eingerichtet?
Gibt es ein Verzeichnis
/srv/linbo/linuxmuster-client bei euch?

nein und nein…
Wir sprechen von LMLv7?

ich weiß: ich spreche auch von der lmn7

Du brauchst das Verzeichnis für den linuxclient, um die Anpassungen an
der /etc/hosts des Clients durch linbo machen zu lassen.
Schau in meinem Post zum defaultcloop von Samstag, hol dir das .zip und
lad das Verzeichnis auf den Server: dann hast du den universellen
postsync (mit der .postsync Datei).

LG

Holger

Hallo Thomas,

Wichtig ist, dass man /vor dem Domänenbeitritt die macct-Datei löscht/,
die evtl. mit dem cloop mitgeliefert wird.

ich habe pinibel darauf geachtet, dass bei meinem .cloop keine .macct
Datei dabei ist.

LG

Holger

Hallo Holger!

/etc/hosts:
"127.0.0.1 localhost

::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters"

Gruß - Rainer

Hallo Rainer,

da fehlt der Rechnername.

Nimm mein .zip, hol den postsync raus: dann wird die Datei bei dir
gepatched.
Ich denke: dann klappt es auch mit der Domäne.

LG

Holger

Okay und danke für die Info.
Den Post konnte ich jetzt noch nicht finden…
Ich bin auch noch mal alle Infos der Linux-Image-Datei durchgegangen und konnte nichts zum Notwendigen postsync finden:

Wenn das Skript nur die hosts Zeile baut?:
welcher Eintrag wird gesetzt? der mit der 127er Adresse oder mit der tatsächlichen IP?
oben schreibt ja andreas72 dass er sogar den 127.0.1.1 auskommentiert hat, folglich könnte ja nur so was wie folgendes funktionieren:
10.16.114.11 r122-pc11.bs-muster.llan r122-pc11
richtig?

Darüber hinaus stellt sich mir die Frage, ob es nicht doch einfacher für mich ist noch mal mit einer Standard Ubuntu Installation zu beginnen…

Hallo Gerd,

Den Post konnte ich jetzt noch nicht finden…

Wenn das Skript nur die hosts Zeile baut?:

nein, das macht viel mehr.

welcher Eintrag wird gesetzt? der mit der 127er Adresse oder mit der
tatsächlichen IP?
oben schreibt ja andreas72 dass er sogar den 127.0.1.1 auskommentiert
hat, folglich könnte ja nur so was wie folgendes funktionieren:

10.16.114.11 r122-pc11.bs-muster.llan r122-pc11|
richtig?

schau mal in die Datei /linuxmuster-client/bionic/common/etc/hosts
nachdem du das .zip ausgepakt hast.

LG

Holger

Hallo Holger,
Alles klar,
ich versuche das mit diesem bionic cloop für v7
Danke dir für den Link und das zip

Grüße,
gerd

Ein Beitrag wurde in ein neues Thema verschoben: Linux-Clients waren 2 Wochen offline - nun kein Login mehr möglich

Hi zusammen, @ironiemix vor allem,

Cheat Domänenbeitritt

Ich habe einen Weg gefunden, wie ich ohne neues Image zu erstellen auskomme:

  1. linuxmuster-client-adsso-setup - neu der Domäne beitreten
  2. gewisse Daten von diesem client auf den Server in common/ kopieren (+chmod uog+r)
  3. macct datei auf dem server erstellen (ohne neues Image)
  4. postsync-Daten müssen fix-permission unterlaufen, damit sie auf dem Zielsystem wieder 600 haben
  5. syncronisierter Start egal welchen Rechners der Gruppe: login möglich

Das muss/kann noch optimiert werden, aber damit ist ein unnötiger Schritt weg: ich muss kein neues Image machen. Und man kann die Domänenanmeldungsdaten auch bei einem Upgrade des Cloops retten.

Für das erste Ausrollen könnte man den ganzen Prozess auf dem Server anstoßen:

linuxmuster-client configure:
  linbo-remote -p sync+start
  wait for finish
  login via ssh and start linuxmuster-client-adsso-setup (interactively)
  ssh-copy relevant data to common/... fix permissions
  create macct file on server
  reboot client with sync, postsync fixes permissions back

die „relevant data“ ist noch nicht ganz klar, evtl. nur ein subset von diesen vier:

/var/lib/samba/private/secrets.tdb
/var/lib/samba/private/netlogon_creds_cli.tdb
/var/lib/samba/private/tls/lmn.lan.pem
/etc/krb5.keytab

mein „recreate_macct.sh“ Skript ist ein schamloser Auszug aus Thomas’ skript. Das paste ich jetzt nicht hier. Sind nur ein paar Zeilen.

Dualboot

Ich habe keinen Dualboot, so dass ich nicht weiß, ob meine Erkenntnisse irgendetwas hier beitragen können.

Noch eine mögliche Ursache…

Ich habe auch noch eine zweite Seltsamkeit einmal gesehen: Ich habe einmal den client auf dem die Domänenbeitritt geschah in der devices.csv umbenannt, danach konnte ich mich nicht mehr anmelden, weil die Logs geschrieen haben, dass HOSTNAME.LMN.LAN nicht gefunden werden könne. Das steckt ja in der krb5.keytab drin (und ist auf jedem Client ja identisch). Evtl. sollte man den Masterclient nicht aus devices.csv rausnehmen, damit er wenigstens per DNS aufgelöst werden kann.

VG, Tobias

1 „Gefällt mir“

Hallo Tobias, wie erstellst du die macct Datei von Hand?

Gruß,
Andreas

Hi @Till,

ich habe die relevanten Teile aus Thomas SKript zur Erstellung der macct Datei rausgeklaut.
Leider hab ich das hemdsärmelig und nicht in einem sauberen Skript gemacht, denn jetzt könnte ich den kram wieder brauchen.
Ich weiß nicht mal wo ich das skript habe. Scheint nicht mehr auf meinem Server in der Schule zu liegen. Evtl. noch auf dem Testrechner…

VG, Tobias