Client auf Basis von Debian 13?

[Buster]

Hi,

ich kenne die Details der Implementation der beiden Linux-Clients (net ads und realm) und -Servers (samba) für das AD nicht, daher ist das mal ein Schuss ins Blaue: Microsoft hat seine Implementation in Windows Client und Server dahingehend geändert, dass der Nutzer, der im Active Directory das Computerobjekt erstellt identisch sein muss mit dem Nutzer, der den Client in die Domäne aufnimmt. Da die Vertrauensstellung, die bei Aufnahme des Rechners hergestellt wird, aber auch nur eine Kombination von Zugangsdaten (Passwort und Benutzername in Form von Computername$) ist, die auf beiden Seiten (Client/Server) gleichermaßen hinterlegt sein muss, kann es auch sein, dass das hier keine Rolle spielt.

VG
Buster

[Arnaud]

Hi,

@rettich : es fehlen noch die Argumente für ldapsearch, so kann es nicht funktionieren …

Etwas wie:

ldapsearch -x -H ldaps://server.linuxmuster.lan:636 -LLL "sAMAccountName=EINUSER" -b 'DC=linuxmuster,DC=lan' -D 'CN=EINLEHRER,OU=Teachers,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan' -W cn

Gruß

Arnaud

[rettich]

@Arnaud : Vielen Dank …

[Blair]

Hallo,
auch ein Schuss ins Blaue.
Sind net ads und realm nicht zwei verschiedene Sachen?
Nutz realm nicht sssd und realm kommt von Samba und braucht eine eigene Konfiguration? Da decken sich weite Teile, aber identisch ist das nicht.

root@multi-1:~# net ads info
LDAP server: 10.0.0.1
LDAP server name: server.linuxmuster.lan
Workgroup: LINUXMUSTER
Realm: LINUXMUSTER.LAN
Bind Path: dc=LINUXMUSTER,dc=LAN
LDAP port: 389
Server time: Mo, 13 Okt 2025 20:10:05 CEST
KDC server: 10.0.0.1
Server time offset: 0
Last machine account password change: Do, 01 Jan 1970 01:00:00 CET

Also net ads hat das Maschinenpasswort nie erhalten und daher auch kein Kerberos Ticket.
Vergleicht doch mal
/etc/krb5.conf
/etc/samba/smb.conf
in Ubuntu und Debian nach Durchlauf des linuxmuster-linuxclient7 Skripts.

Viele Grüße
Christian

[thomas]

Moin!

net ads benötigt einen user und die workgroup. Wenn der realm Eintrag in smb.conf gemacht wurde, klappt die Authentifizierung gegen das samba ad:

root@multi-1:~# net -U zell%'*****' -W LINUXMUSTER ads status
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
userAccountControl: 4096
objectSid: S-1-5-21-221477971-3326973540-1634130914-1219
sAMAccountName: MULTI-1$
servicePrincipalName: HOST/MULTI-1.linuxmuster.lan
servicePrincipalName: RestrictedKrbHost/MULTI-1.linuxmuster.lan
servicePrincipalName: HOST/MULTI-1
servicePrincipalName: RestrictedKrbHost/MULTI-1
dNSHostName: multi-1.linuxmuster.lan
msDS-SupportedEncryptionTypes: 28
msDS-KeyVersionNumber: 5

Anmeldung lokal gegen pam schlägt aber fehl:

root@multi-1:~# pamtester gdm zell authenticate
Password: 
pamtester: Authentication failure

Das Problem steckt also in dem ganzen pam-sss-Geraffel, das wohl in Trixie irgendwie anders konfiguriert werden muss. At least one step further …

VG, Thomas

[thomas]

Moin!

Es fehlt das pam-Modul für kerberos, also fix libpam-krb5 installiert, dann gehts mit Trixie!

VG, Thomas

[rettich]

Hallo Thomas,

@thomas

Es fehlt das pam-Modul für kerberos, also fix libpam-krb5 installiert, dann gehts mit Trixie!

Super!!! Vielen Dank
Mathias

[thomas]

Hallo Mathias,

zu früh gefreut. Funktioniert bisher leider nur mit dem Client, mit dem das Image gemacht wurde.
Auf dem gesyncten Client in /var/log/auth.log:

2025-10-15T10:33:52.576252+02:00 multi-2 pamtester: pam_krb5(gdm3:auth): (user zell) credential verification failed: Cannot find key for host/multi-2.linuxmuster.lan@LINUXMUSTER.LAN kvno 6 in keytab

Also weiterforschen.

VG, Thomas

[thomas]

Moin!

~# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   9 MULTI-2$@LINUXMUSTER.LAN
   9 MULTI-2$@LINUXMUSTER.LAN
   9 MULTI-2$@LINUXMUSTER.LAN
   9 host/MULTI-2@LINUXMUSTER.LAN
   9 host/MULTI-2@LINUXMUSTER.LAN
   9 host/MULTI-2@LINUXMUSTER.LAN
   9 host/multi-2.linuxmuster.lan@LINUXMUSTER.LAN
   9 host/multi-2.linuxmuster.lan@LINUXMUSTER.LAN
   9 host/multi-2.linuxmuster.lan@LINUXMUSTER.LAN
   9 RestrictedKrbHost/MULTI-2@LINUXMUSTER.LAN
   9 RestrictedKrbHost/MULTI-2@LINUXMUSTER.LAN
   9 RestrictedKrbHost/MULTI-2@LINUXMUSTER.LAN
   9 RestrictedKrbHost/multi-2.linuxmuster.lan@LINUXMUSTER.LAN
   9 RestrictedKrbHost/multi-2.linuxmuster.lan@LINUXMUSTER.LAN
   9 RestrictedKrbHost/multi-2.linuxmuster.lan@LINUXMUSTER.LAN

pam_krb5 sucht den hostkey mit kvno 6, während es im keytab den hostkey mit kvno 9 gibt.

VG, Thomas

[Arnaud]

Hi @thomas

• krb5_validate is set to False. This is necessary because the KVNO in /etc/krb5.keytab might not match the msDS-KeyVersionNumber in the AD which will lead to SSSD errors when krb5_validate is set to True

Domain join

Ist es der Fall in sssd.conf ?

Gruß

Arnaud

[thomas]

Hallo Arnaud,

denke nicht, krb5_validate ist ja auf False gesetzt, Wechsel auf True ändert nichts.

VG, Thomas

[thomas]

Moin!

So langsam kommt Licht ins dunkel. Auf dem gesyncten Client muss die krb5.keytab geflusht werden. Bitte mal so nachvollziehen:

1. Auf Masterclient libpam-krb5 installieren.
2. In /usr/share/linuxmuster-linuxclient7/templates/smb.conf
   die Zeile
   realm = @@realm@@
   ergänzen.
3. Domänenbeitritt: linuxmuster-linuxclient7 setup
4. pam updaten: pam-auth-update, Konfiguration mit OK bestätigen.
5. Image erstellen.
6. Masterclient syncen und Login testen.
7. Zweiten Client syncen.
8. Vor dem User-Login als root auf der Konsole
   net ads keytab flush
   ausführen.
9. User-Login auf dem zweiten Client testen.

VG, Thomas

[thomas]

Ergänzung:
Falls weitere Logins auf dem zweiten Client fehlschlagen, muss bei Schritt 8 noch ein
net ads keytab create
hinterhergeschickt werden.

[rettich]

Hallo Thomas,
ich hab’s ausprobiert. Mit net ads keytab flush läuft die Anmeldung. net ads keytab create war nicht nötig.
Allerdings muss man das nach dem Syncen immer machen. Naja, dafür gibt’s ja /etc/linuxmuster-linuxclient7/onBoot.d/test.sh… Was leider so nicht geklappt hat (Weder mit net ads keytab create noch ohne net ads keytab create)?!?
Gruß
Mathias

[baumhof]

Hallo Mathias,
hast du, wenn du den Eintrag in der onBoot.d hast, mal 3 Minuten nach dem Hochfahren gewartet? Vielleicht ist der onBoot Auftrag einfach ein wenig später.

Ansonsten: kannst du dein script, wie es im Verzeichnis onBoot.d liegt, mal posten?

Steht was in den logs bezüglich des scripts? Vielleicht steht da warum das nicht geht …

LG
Holger

[rettich]

Hallo zusammen,

@baumhof

hast du, wenn du den Eintrag in der onBoot.d hast, mal 3 Minuten nach dem Hochfahren gewartet? Vielleicht ist der onBoot Auftrag einfach ein wenig später.

#!/bin/bash
/usr/bin/net ads keytab flush

Gruß
Mathias

[thomas]

Moin!

Sieht so aus, dass man flush und create nach jedem Sync machen muss. Die onBoot-Skripte werden vor dem Start des sssd-Dienstes ausgeführt. Evtl. ist das ein Problem.
Mann, das ist echt ein sch…

VG, Thomas

[rettich]

Hallo Thomas,

@thomas

Sieht so aus, dass man flush und create nach jedem Sync machen muss. Die onBoot-Skripte werden vor dem Start des sssd-Dienstes ausgeführt. Evtl. ist das ein Problem.

Ich befürchte, das ist es nicht.
Ich hab mich als root auf dem Client angemeldet und net ads keytab flush und net ads keytab create ausgeführt. Bei Clients, bei denen einmal die Anmeldung fehlschlug kann sich danach immernochniemnad anmelden. Auch nicht nach einem Neustart
Gruß
Mathias

[thomas]

Ja, das funktioniert so nur nach einem Sync. Also weiterforschen (sic!).

[rettich]

Hallo zusammen,
ich hab in /etc/linuxmuster-linuxclient7/onBoot.d das Script 20_VorAnmeldung.sh mit folgendem Inhalt abgelegt:

#!/bin/bash
/usr/bin/net ads keytab flush
/usr/bin/sleep 10

Damit läuft’s bisher…
Ich geb’s zu, es ist nicht schön…
Gruß
Mathias