Linux-Domänenanmeldung bei Hostnamenswechsel

[thoschi]

Hallo zusammen,

wir hatten schon öfter (auch hier geschildert) das Problem, dass man sich mit einem Linux-Image, das erfolgreich der Domäne beigetreten ist, auf anderen Rechnern nicht anmelden konnte. Das Image war vorher sauber, es wurde sich also noch nicht angemeldet, etc.

Ich bin dem nun mal nachgegangen, weil das bei uns zunehmend zu einem Problem wird:

1. Fund: nach dem Synchronisieren an einem anderen Rechner keine Anmeldung möglich („das hat leider nicht funktioniert“. In den Logs gab es einen SSSD-Fehler.

2. Fund: es fehlte die macct-Datei auf dem Server - macht Sinn, dann kann es nicht gehen. Aber warum?

3. Funde: Linbo erstellt keine macct-Datei - also in die /var/log/linuxmuster/linbo/rsync-post-upload.log geschaut. Auffällig gleich zu Beginn:

    HOSTNAME: UNKNOWN.corvi.linuxmuster.lan
    IP: 10.0.102.101
   

   Warum unknown - steht in der Devices und ist auch auf dem Musterclient als hostname sichtbar. Testen wir mal den Hostnamen hier und da

4. Fund: nslookup 10.0.102.101 liefert:

   101.102.0.10.in-addr.arpa	name = admin-tarox.
   101.102.0.10.in-addr.arpa	name = alephnvme-ubnvm.corvi.linuxmuster.lan.
   

   DAS sollte nicht so sein. admin-tarox hieß mal ein Rechner unter dieser Adresse, aber das ist lange her. Es gibt ihn schon sehr lange nicht mehr in der devices.csv. Auf dem Musterclient ist es noch seltsamer, da liefert der obige nslookup:

   nslookup 10.0.102.101
   Server:    10.0.0.1
   Address 1: 10.0.0.1 server.corvi.linuxmuster.lan
   
   Name:      10.0.102.101
   Address 1: 10.0.102.101 admin-tarox
   

   Also NUR den alten Hostnamen ohne Domäne. Ich durchsuche also mit samba-tools das AD: samba-tool dns query localhost corvi.linuxmuster.lan @ ALL | grep admin-tarox liefert aber kein Ergebnis. Woher kommt dann der alte Rechnername?!

5. Fund: auf gut Glück greppe ich mal die AD-Datenbank auf dem Server: grep -r admin-tarox * ergibt tatsächlich:

   grep: private/sam.ldb.d/DC=CORVI,DC=LINUXMUSTER,DC=LAN.ldb: binary file matches
   grep: private/sam.ldb.d/DC=DOMAINDNSZONES,DC=CORVI,DC=LINUXMUSTER,DC=LAN.ldb: binary file matches
   

6. Fund: der einzige Grund, warum Linbo die macct-Datei nicht erstellt, scheint mir hier zu liegen:

   unicodepwd="$("$LDBSEARCH" "$url" "(&(sAMAccountName=$compname$))" unicodePwd | grep ^unicodePwd:: | awk '{ print $2 }')"
   [...]
   if [ -n "$unicodepwd" ]; then
   

   Ich habe das händisch getestet und mit dem korrekten Hostnamen kommt auch das entsprechende Passwort. Aber da $compname$ sich von RSYNC_HOST_NAME ableitet, bleibt die Variable hier leer.

Im Moment vermute ich, dass der Upload der aktuellen macct-Datei fehlschlägt, weil eine Prüfung des Hostnames im DNS schief läuft. Das würde aber bedeuten, dass man wirklich NIE irgendwelche IP-Adressen wiederverwenden darf. Oder dass - warum auch immer - hier irgendwelche Reste im DNS liegen, die dort nicht sein dürften. Und das ist bisher schon öfter passiert, wenn wir IPs neu vergeben haben (gibt’s auch hier im Forum etwas zu).

Ich werde da weiter suchen - aber hat jemand eine Idee, wie man diesem Problem näher kommen könnte? Und @thomas hast Du eine Idee, wie man RSYNC_HOST_NAME debuggen könnte? Wie wird diese Variable erstellt? Kann man die Erstellung der macct-Datei evtl. (vorläufig) nachträglich erzwingen?

Ich bin mir nicht sicher, ob das ursächlich ein sophomorix-Problem oder ein Samba-Bug ist (es gibt da z.B. ein altes Ticket von Univention) und/oder ob man das über Linbo anders abfangen könnte (und will - ich denke eher, man müsste das DNS-Problem lösen).

In jedem Fall bin ich jeden Hinweis dankbar.

Viele Grüße
Thomas

[baumhof]

Hallo Thomas,

mega Untersuchung: Spitze!
Das ist ein so verdecktes Problem und du hast da jetzt mal richtig Licht ins Dunkel gelassen. Eine große Hilfe.

LG
Holger

[thoschi]

Hallo zusammen,

wieder etwas weiter: host -t PTR 10.0.102.101 liefert:

101.102.0.10.in-addr.arpa domain name pointer admin-tarox.
101.102.0.10.in-addr.arpa domain name pointer alephnvme-ubnvm.corvi.linuxmuster.lan.

Und samba-tool dns query localhost 102.0.10.in-addr.arpa @ ALL zeigt tatsächlich:

Name=, Records=2, Children=0  SOA: serial=161, refresh=900, retry=600, expire=86400, minttl=3600, ns=server.corvi.linuxmuster.lan., email=hostmaster.corvi.linuxmuster.lan. (flags=600000f0, serial=161, ttl=3600)
NS: server.corvi.linuxmuster.lan. (flags=600000f0, serial=1, ttl=3600)
Name=101, Records=2, Children=0
PTR: admin-tarox (flags=f0, serial=110, ttl=3600)
PTR: alephnvme-ubnvm.corvi.linuxmuster.lan (flags=f0, serial=145, ttl=900)
Name=102, Records=1, Children=0
[...]

Und das kann man „beheben“ mit:

samba-tool dns delete localhost 102.0.10.in-addr.arpa 101 PTR admin-tarox

Hurra - danach nur noch ein Eintrag und Linbo erzeugt die macct-Datei!! Also scheint das das Problem zumindest mal zu fixen.

In den Samba-Binaries wird der String admin-tarox zwar immer noch gefunden - aber die DNS-Zone scheint sauber. Und vor allem kann es bei uns weiter gehen!

Ich hoffe, das hilft vielleicht hier und da bei ähnlichen Problemen als zusätzliches Werkzeug für die Suche. Und evtl. gibt es ja auch tatsächlich ein Problem z.B. bei sophomorix, das man fixen kann.

Viele Grüße
Thomas

[thoschi]

Und NOCH etwas - ein weiteres Problem auf Client-Seite:

• bevor ich das mit der macct-Datei herausgefunden habe, habe ich gedacht, es sind vielleicht noch Reste im AD
• also den Eintrag aus der devices.csv entfernt und importiert. Danach gab es den Eintrag immer noch im DNS.
• was immer das verursacht hat: sssd meldete beim Versuch der Anmeldung, dass es den Client (hier LEHR04$) nicht gäbe - obwohl sophomorix ihn angelegt hat
• das Einzige, was hier half (und das ist vielleicht ein weiteres „Werkzeug“ bei Problemen) war, den KOMPLETTEN Raum in der devices.csv zu löschen. Erst dann verschwanden auch die entsprechenden DNS-Zonen mit den alten Einträgen
• nachdem dann alle Clients wieder hinzugefügt wurden funktionierte endlich die Anmeldung (yey!!)

Ich fasse für mich zusammen (korrigiert mich gerne):

• es gibt beim Wechseln von IP-Adressen und/oder Hostnamen offenbar noch ein paar Unklarheiten, die zu Problemen führen, die nicht ohne weiteres erkenn- oder lösbar sind. Sophomorix meldet hier keine Fehler, obwohl zumindest eventuell Reste im DNS des AD verbleiben können bzw. Reste dort offenbar zu Problemen bei der Rechnererstellung führen können.
• diese Fehler führen derzeit nicht zu einem Abbruch von sophomorix und werden davon auch nicht behoben
• Tests der DNS-Namensauflösung und untersuchen des AD-Baums sind mühsam (sorry, man wird mich schwerlich davon überzeugen, dass dieses Microsoftsche AD-Chaos in der Form wirklich ne tolle Sache ist), aber führen mit etwas Glück/Fleiß zu Erkenntnissen.

Abschließend:

• das Löschen von ganzen Räumen in der devices.csv löst ein Problem von verwaisten DNS-Zonen
• verwaiste doppelte PTR-Einträge führen zu fehlenen/nicht aktuellen macct-Dateien und lassen sich mit samba-tool entfernen (wobei das Löschen der Räume das Problem evtl. ebenfalls löst)

Das ist es jetzt hoffentlich erst einmal. Ich hoffe, es hilft (und dass sich vielleicht @jeffbeck (?) dieser Einblicke noch einmal annimmt.

Und jetzt gute Nacht
Thomas

[Michael]

Hi.
Gibt es hier eigentlich neue Erkenntnisse bzw wurde das Problem in der Zwischenzeit gefixt?
Wir haben auch des öfteren den Fall, dass Rechner andere / neue IP-Adressen oder Räume erhalten.

Daher wüsste ich gerne, ob das noch aktuell ist oder kein Problem mehr darstellt?
Viele Grüße,
Michael

[Arnaud]

Hallo Thomas,

Danke für alle deine Tests und Berichte.
Ich möchte gerne das Thema vertiefen und probieren herauszufinden, warum die DNS Einträge nicht gelöscht sind.
Ich schaffe aber nicht, das Problem zu reproduzieren (bis jetzt habe ich nur Einträge aus devices.csv enfernt, und linuxmuster-import-devices aufgerufen).

Weiß evtl jemand, wie man das Problem reproduzieren könnte ?

Danke und viele Grüße

Arnaud

[thoschi]

Hallo Arnaud,

das Problem trat auf, wenn ich

• einen Linuxclient in die Domäne aufgenommen habe
• dann ein Image geschrieben habe (gemäß Anleitung)
• andere Clients in der Hardwareklasse synchronisiert - Domänenbeitrag klappt (alles ist gut)
• dann war es nötig, die IP oder den Hostnamen des Musterclients zu ändern
  Ab dann misslang der Domänenbeitritt. Selbst, wenn der Client wieder manuell der Domäne hinzugefügt und ein neues Image erstellt wurde, war bei anderen synchronisierten Clients kein Domänenbeitritt mehr möglich, da offenbar DNS-Reste (PTR) im AD verbleiben.

Ich hoffe, das hilft weiter.

Workarund derzeit: Raum komplett leeren (oder eben einen neuen Raum erzeugen) und Device Import machen. Alternativ die PTR manuell entfernen.

Aber natürlich wäre es schöner, das Problem zu lösen.

Danke und viele Grüße
Thomas

[Arnaud]

Hallo Thomas,

Ok, danke für die ausführliche Antwort.

@thoschi

einen Linuxclient in die Domäne aufgenommen habe

Mit linuxmuster-linuxclient, oder jedes mal manuell ?

@thoschi

dann war es nötig, die IP oder den Hostnamen des Musterclients zu ändern

Nur wegen Schulbetrieb, oder gab es hier einen bestimmten Grund ? So eine Änderung ist bei Samba nicht ganz trivial, ich kann mich erinnern, dass wir damit DNS und Kerberos Probleme hatten. Ich sollte wieder testen.

Gruß

Arnaud

[thoschi]

Hallo Arnaud,

Mit linuxmuster-linuxclient, oder jedes mal manuell ?

Immer über die devices.csv und anschließendem linuxmuster-import-devices.

Nur wegen Schulbetrieb, oder gab es hier einen bestimmten Grund ?

In der Regel, um zu vereinheitlichen oder Ordnung zu schaffen. Wir haben z.B. virtuelle Clients (VMs, über die wir die Images betreuen und die sollten halt einheitlich so wie die Images heißen). Dabei ist es dann aufgefallen, dass plötzliche die Domänenanmeldung nicht mehr lief.

Man kann das ja vermeiden - aber das war ja ein Hinweis, dass sich da irgendwo Altlasten ansammelten. Vor allem, weil diese alten Namen dann dauerhaft nicht mehr verwendbar waren.

Und wie ich schrieb ist es ja tatsächlich der DNS, der da noch Reste enthält.

Viele Grüße
Thomas

PS: Das ist ja so ähnlich wie Nutzernamen, die man nicht wiederverwenden kann, wenn Sophomorix sie in den Log-Dateien findet. Ab und an ist das halt gewünscht oder notwendig - und wenn die Benutzer schon länger gelöscht sind, wäre es schon gut, wenn das irgendwie geht.

[Arnaud]

Hallo Thomas,

@thoschi

Immer über die devices.csv und anschließendem linuxmuster-import-devices.

Ha ok ! Ich hatte „Domän aufgenommen“ als ein join manuell auf dem Linuxclient ausgeführt verstanden. Damit haben die andere Fragen, die ich gestellt habe, auch kein Sinn: Ordnung in die Daten bringen sollte für uns alle natürlich sein

Ich teste immer noch weiter die PTR Einträge, aber kann immer noch nicht reproduzieren.

Wegen ehemalige Benutzernamen: das hat schon einen Sinn, da ein User, selbst wenn er nicht mehr in LMN existiert, könnte immer noch Daten bei einem externen Ldap Dienst haben. Da fehlt eine Interaktion in der Form: „ein User mit diesem Login war schon vorhanden. Dieses Login kann man nur verwenden indem LMN das alte endgültig vergisst. Soll LMN das alte endgültig vergessen und den neuen User mit dem Login LOGIN erstellen ?“
Das ist schlecht formuliert, aber du hast bestimmt verstanden, was ich meine.
Die Schwierigkeit hier ist diese Fehlermeldung zu fangen.

Gruß

Arnaud

[baumhof]

Hallo,

ich hatte das schon: dass ein neuer Nutzer überraschend die Daten des alten in der nextcloud „fand“ (sie wurden ihm netterweise automatisch auf den Rechner gesynct, nachdem er den Nextcloud Client eingerichtet hatte …).
Seit dem verstehe ich, warum sophomorix das jetzt so „per Default“ macht.
Aber ich muss gestehen, dass ich mir notiert habe, aus welchen Logdateien sophomorix die Info über „vergangene“ Nutzer bezieht: und wenn ich doch mal einen erneut verwenden will, dann weiß ich, wo ich den Eintrag löschen muss, damit der Nutzernamen wieder frei wird.

LG
Holger

[thoschi]

Hallo zusammen,

zur Domäne: ja, nur nach Anleitung mit den Linuxmuster-Befehlen. Arnaud - was hast Du versucht? Bei erfolgreichem Client in der devices.csv den Hostname des Image-Rehners geändert, ein neues Image erstellt und damit einen zweiten Rechner synchronisiert? Bei uns kommt dieser dann nicht mehr in die Domäne (und kein Rechner, den man synchronisiert). Das Problem erkennt man schon an der MACCT-Datei, die dann nicht mehr neu geschrieben wird, weil in den Linbo-Skripten eine DNS-Abfrage steht, die falsch beantwortet ist - falls das nicht inzwischen gefixt wurde.

Zum Nutzernamen: ich meinte auch nicht, dass das komplett sinnlos ist Aber wie Arnaud schrieb - die Option auf Rückfrage wäre gut.

Wir pflegen haben inzwischen einen SSO-Dienst und pflegen ohnehin unsere Daten nebenher per REST ein. Da haben wir also deutlich mehr Kontrolle (und so ein Fall mit alten Datenresten darf eh nicht sein. Und da wäre es eben gut, wenn man die Option hätte.
Letztlich kann ich damit leben, den Nutzer händisch aus den Logs zu löschen - aber Log-Dateien verändern mache ich auch nicht gerne - wer weiß, ob man nicht doch mal wissen will, wann dieser Nutzer verschwunden ist…
Ich war damals vor allem überrascht, dass das passiert - das Logdaten für den Nutzerabgleich ausgewertet werden - ist halt schon kreativ
Eine Abfrage in diesem Fall (gerne auch mit Default „nicht verwenden“ wäre vermutlich eine perfekte Lösung.

Viele Grüße
Thomas

PS: Insgesamt stellt sich mir eh die Frage (unabhängig von Linuxmuster), wie das mit Logins weiter geht. Viele Dienste bieten ja Unterstützung von LDAP/AD, aber Dinge wie OIDC sind eben doch sehr komfortabel und da bleibt immer mehr die lokale Arbeitsstation als letzte Bastion für einen AD. Ich kann da ja Föderieren, aber viele Infos (z.B. kaskadierende Gruppen) packe ich doch eher per REST in unseren Keycloak als sie im AD abzubilden und dann die Infos wieder abzubilden. Da bin ich gespannt, wohin die Reise so geht…

[Arnaud]

Hallo Thomas,

@thoschi

Arnaud - was hast Du versucht?

Ich werde es in meinen eigenen Worten sagen:

• Client in devices.csv aufgenommen + linuxmuster-import-devices,
• Auf diesen Client neues Image erstellt + auf dem Server hochgeladen (ich sehe hier aber nicht warum es einen Zusammenhang mit PTR Records haben sollte),
• andere Client aus der gleichen Gruppe mit neuem Image synchronisiert,
• in devices.csv Client IP (10.0.0.100 → 10.0.0.104) und/oder Hostname geändert + linuxmuster-import-devices,
• samba-tool dns query 10.0.0.1 0.0.10.in-addr.arpa @ ALL -U global-admin zeigt den richtigen PTR Name (104) + neuer Hostname.

Usermanagement ist eine andere Diskussion, vielleicht sollten wir es in einem anderen Thread weiter diskutieren, aber ich glaube auch, dass Tools wie Keycloak eine gute Lösung sind.

Gruß

Arnaud