Linux-Domänenanmeldung bei Hostnamenswechsel

thoschi · 25. Oktober 2024 um 13:44

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:

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.
Fund: es fehlte die macct-Datei auf dem Server - macht Sinn, dann kann es nicht gehen. Aber warum?
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
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?!

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

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 · 25. Oktober 2024 um 14:01

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 · 25. Oktober 2024 um 20:37

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 · 25. Oktober 2024 um 20:40

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