Hallo Andreas,
Ich würde an deiner Stelle noch ein Passwort dazu packen, ansonstens kann jeder sich grafisch verbinden.
Gruß
Arnaud
@Arnaud: Korrekt, mache ich.
@Dorian: Habe ich gerade gemacht, bringt leider nix.
Wir verwenden Kubuntu, haben den Login-Manager aber durch lightdm ersetzt, weil kdm nicht geht.
Standard-Ubuntu verwendet natürlich gdm.
Könnte es sein, dass lightdm jetzt nicht mehr unterstützt wird?
Ich habe jetzt noch festgestellt, dass timesyncd nicht lief. Das sollte allerdings nicht das Problem sein, da linbo die Zeit ja schon synchronisiert, dennoch habe ich das auf den Schulserver eingestellt.
Ich bin jetzt völlig Ratlos. Ein Client, an den unsere Schüler + Kollegen gewöhnt sind und der seit 1,5 Jahren lief, läuft jetzt nicht mehr. Sehr viel Feinarbeit steckte da drin.
Wenn irgend jemand eine Idee hat, wie ich das debuggen kann (wo sind die logs für Kerberos? Wie kann ich feststellen, an welcher Stelle der login-prozess fehlschlägt), wäre ich extrem zu Dank verpflichtet.
Gruß,
Andreas
Noch eine letzte verzweifelte Frage: Muss ich nach dem Domain-Join (mit turnkey oder setup) dann direkt das Image schreiben, oder sollte ich nach Neustart in der Lage sein, mich an der neu gejointen Maschine anzumelden? Passiert da noch irgend eine Magie beim Image erstellen?
CIFS: Attempting to mount //ohg-netz.llan/sysvol
[ 335.309633] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3)
, from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) spe
cify vers=1.0 on mount.
[ 335.338278] CIFS VFS: Verify user has a krb5 ticket and keyutils is installed
[ 335.338286] CIFS VFS: \\ohg-netz.llan Send error in SessSetup = -126
[ 335.338309] CIFS VFS: cifs_mount failed w/return code = -2
Das hier berichtete mir dmesg.
Hallo Andreas,
Ich bin kein Profi mit KDC, ich versuche trotzdem einige Punkte zu listen, die evtl helfen das Problem zu begrenzen :
- Ist es ein Dualboot mit Win ?
- Geht eine SSH-Verbindung für ein Lehrer von Server aus ? Ich meine, wenn man auf 10.0.0.1 ist, dann
ssh lehrer@LINUXCLIENT. - Melde dich auf dem Linuxclient an als linuxadmin. Was ergibt :
sudo kinit global-admin # Passwort Eingeben
sudo klist
sudo net ads info
- Wenn Punkt 3. erfolgreich ist, funktioniert das folgende ?
sudo mount -o sec=krb5,user=global-admin //ohg-netz.llan/sysvol /var/lib/samba/sysvol
- Wenn 4. erfolgreich ist, sind beide Zetifikat gleich ?
sudo diff /var/lib/samba/sysvol/ohg-netz.llan/tls/cacert.pem /var/lib/samba/private/tls/ohg-netz.llan.pem
Gruß
Arnaud
Hallo Arnaud,
vielen Dank für die Antwort.
- Nein, nur Linux
- Nur für meinen eigenen Lehreraccount, der im Cache auf dem Client ist.
linuxadmin@m772:~$ sudo kinit global-admin
[sudo] Passwort für linuxadmin:
(pam_mount.c:365): pam_mount 2.16: entering auth stage
kinit: für Realm »OHG-NETZ.LLAN« kann nicht KDC kontaktiert werden bei Anfängliche Anmeldedaten werden geholt.
(pam_mount.c:133): clean system authtok=0x555f7ef122d0 (1073741824)
linuxadmin@m772:~$ sudo klist
klist: No credentials cache found (filename: /tmp/krb5cc_0)
linuxadmin@m772:~$ sudo net ads info
LDAP server: 10.0.0.1
LDAP server name: server.ohg-netz.llan
Realm: OHG-NETZ.LLAN
Bind Path: dc=OHG-NETZ,dc=LLAN
LDAP port: 389
Server time: So, 14 Feb 2021 15:30:04 CET
KDC server: 10.0.0.1
Server time offset: 0
Last machine account password change: So, 14 Feb 2021 11:15:03 CET
linuxadmin@m772:~$
Kann nicht KDC kontaktiert werden ist auch der Fehler, den ich öfters bei linuxmuster-cloop-turnkey bekomme (aber nicht immer).
Edit: Ich verwende einen Code-Tag, sieht trotzdem mist aus, was ist der richtige Tag?
Hallo Andreas,
Ich habe deine Nachricht editiert, damit kannst du sehen, wie man Code schreiben kann.
Ich schlage vor, den Log zu aktivieren, um zu verstehen warum den KDC nicht erreichbar ist, und dafür macht man auf dem Linuxclient :
sudo KRB5_TRACE=/dev/stdout kinit global-admin
Sind die DNS auf dem Linuxclient ok ?
dig server.ohg-netz.llan
Gruß
Arnaud
linuxadmin@m772:/var/lib/samba/sysvol$ sudo KRB5_TRACE=/dev/stdout kinit global-admin
[1713] 1613314768.25362: Getting initial credentials for global-admin@OHG-NETZ.LLAN
[1713] 1613314768.25364: Sending unauthenticated request
[1713] 1613314768.25365: Sending request (201 bytes) to OHG-NETZ.LLAN
[1713] 1613314768.25366: Sending initial UDP request to dgram 192.168.148.101:88
[1713] 1613314769.27290: Initiating TCP connection to stream 192.168.148.101:88
[1713] 1613314772.30415: Sending retry UDP request to dgram 192.168.148.101:88
[1713] 1613314777.35520: Sending retry UDP request to dgram 192.168.148.101:88
[1713] 1613314786.44649: Terminating TCP connection to stream 192.168.148.101:88
kinit: für Realm »OHG-NETZ.LLAN« kann nicht KDC kontaktiert werden bei Anfängliche Anmeldedaten werden geholt.
linuxadmin@m772:/var/lib/samba/sysvol$
linuxadmin@m772:/var/lib/samba/sysvol$ dig server.ohg-netz.llan
; <<>> DiG 9.11.3-1ubuntu1.10-Ubuntu <<>> server.ohg-netz.llan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30491
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;server.ohg-netz.llan. IN A
;; ANSWER SECTION:
server.ohg-netz.llan. 390 IN A 192.168.148.101
server.ohg-netz.llan. 390 IN A 10.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Feb 14 16:00:08 CET 2021
;; MSG SIZE rcvd: 81
linuxadmin@m772:/var/lib/samba/sysvol$
Das sieht mir ganz und gar nicht richtig aus, wir haben ja kein 192er Netz.
Kurz nach einem Neustart des Clients klappte es aber mit dem kinit:
linuxadmin@m772:~$ sudo kinit global-admin
[sudo] Passwort für linuxadmin:
(pam_mount.c:365): pam_mount 2.16: entering auth stage
Passwort für global-admin@OHG-NETZ.LLAN:
(pam_mount.c:133): clean system authtok=0x55c85a6692d0 (1073741824)
linuxadmin@m772:~$ sudo klist
Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
Standard-Principal: global-admin@OHG-NETZ.LLAN
Valid starting Expires Service principal
14.02.2021 15:53:01 15.02.2021 01:53:01 krbtgt/OHG-NETZ.LLAN@OHG-NETZ.LLAN
erneuern bis 21.02.2021 15:52:53
linuxadmin@m772:~$ sudo net ads info
LDAP server: 10.0.0.1
LDAP server name: server.ohg-netz.llan
Realm: OHG-NETZ.LLAN
Bind Path: dc=OHG-NETZ,dc=LLAN
LDAP port: 389
Server time: So, 14 Feb 2021 15:53:45 CET
KDC server: 10.0.0.1
Server time offset: 0
Last machine account password change: So, 14 Feb 2021 11:15:03 CET
linuxadmin@m772:~$ sudo mount -o sec=krb5,user=global-admin //ohg-netz.llan/sysvol /var/lib/samba/sysvol
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Keine Ahnung, was mir das sagen soll.
Ok, die DNS waren falsch, das ist schon mal eine Erklärung.
Klappt jetzt die Anmeldung in Lightdm ?
Gruß
Arnaud
Aber sind sie denn nicht immer noch falsch? Ich habe ja nichts geändert? Wo müsste ich das ändern?
Du könntest ein Ticket für global-admin auf dem Server holen, die Verbindung mit dem KDC auf 10.0.0.1 hat damit geklappt.
Um zu überprüfen, ob die DNS immer noch falsch sind : dig server.ohg-netz.llan
Was hast du in deinem resolv.conf ?
grep -v "^#" /etc/resolv.conf
Gruß
Arnaud
kinit global-admin geht ja nur manchmal, gerade wieder nicht
resolv.conf:
linuxadmin@m772:/etc$ grep -v „^#“ /etc/resolv.conf
nameserver 127.0.0.53
options edns0
search ohg-netz.llan
Also, in der resolv.conf steht offenbar ein falscher Nameserver.
Wenn ich diesen durch die IP unseres Servers ersetze, geht kinit global-admin sofort.
Die Anmeldung geht aber immer noch nicht
Wenn ich dann linuxmuster-cloop-turnkey aufrufe, wird die resolv.conf wieder durch eine mit falschem Nameserver ersetzt, sodass es wieder nicht geht.
Woher nimmt also linuxmuster-cloop-turnkey die IP des Nameservers?
Die resolv.conf ist ein Link, der auf resolv.conf.stub verwies. Ich habe das korrigiert, sodass da jetzt unser Server drin steht.
Jetzt bekomme ich:
linuxadmin@m772:~$ sudo KRB5_TRACE=/dev/stdout kinit global-admin
[sudo] Passwort für linuxadmin:
(pam_mount.c:365): pam_mount 2.16: entering auth stage
[2791] 1613321541.984020: Getting initial credentials for global-admin@OHG-NETZ.LLAN
[2791] 1613321541.984022: Sending unauthenticated request
[2791] 1613321541.984023: Sending request (201 bytes) to OHG-NETZ.LLAN
[2791] 1613321541.984024: Sending DNS URI query for _kerberos.OHG-NETZ.LLAN.
[2791] 1613321541.984025: No URI records found
[2791] 1613321541.984026: Sending DNS SRV query for _kerberos._udp.OHG-NETZ.LLAN.
[2791] 1613321541.984027: SRV answer: 0 100 88 "server.ohg-netz.llan."
[2791] 1613321541.984028: Sending DNS SRV query for _kerberos._tcp.OHG-NETZ.LLAN.
[2791] 1613321541.984029: SRV answer: 0 100 88 "server.ohg-netz.llan."
[2791] 1613321541.984030: Resolving hostname server.ohg-netz.llan.
[2791] 1613321541.984031: Sending initial UDP request to dgram 10.0.0.1:88
[2791] 1613321541.984032: Received answer (287 bytes) from dgram 10.0.0.1:88
[2791] 1613321541.984033: Sending DNS URI query for _kerberos.OHG-NETZ.LLAN.
[2791] 1613321541.984034: No URI records found
[2791] 1613321541.984035: Sending DNS SRV query for _kerberos-master._udp.OHG-NETZ.LLAN.
[2791] 1613321541.984036: No SRV records found
[2791] 1613321541.984037: Response was not from master KDC
[2791] 1613321541.984038: Received error from KDC: -1765328359/zusätzlich Vorauthentifizierung erforderlich
[2791] 1613321541.984041: Preauthenticating using KDC method data
[2791] 1613321541.984042: Processing preauth types: 16, 15, 2, 19
[2791] 1613321541.984043: Selected etype info: etype aes256-cts, salt "OHG-NETZ.LLANglobal-admin", params "\x00\x00\x10\x00"
Passwort für global-admin@OHG-NETZ.LLAN:
[2791] 1613321548.941687: AS key obtained for encrypted timestamp: aes256-cts/7283
[2791] 1613321548.941689: Encrypted timestamp (for 1613321548.948145): plain 301AA011180F32303231303231343136353232385AA10502030E77B1, encrypted 4223265417C5A1AECD9F7AF202B41DF2E19229656B640953AF48D9C7A1FF88B1DA4AA6107345EC26695B0D1040B4113B632C7588235ABB9B
[2791] 1613321548.941690: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
[2791] 1613321548.941691: Produced preauth for next request: 2
[2791] 1613321548.941692: Sending request (281 bytes) to OHG-NETZ.LLAN
[2791] 1613321548.941693: Sending DNS URI query for _kerberos.OHG-NETZ.LLAN.
[2791] 1613321548.941694: No URI records found
[2791] 1613321548.941695: Sending DNS SRV query for _kerberos._udp.OHG-NETZ.LLAN.
[2791] 1613321548.941696: SRV answer: 0 100 88 "server.ohg-netz.llan."
[2791] 1613321548.941697: Sending DNS SRV query for _kerberos._tcp.OHG-NETZ.LLAN.
[2791] 1613321548.941698: SRV answer: 0 100 88 "server.ohg-netz.llan."
[2791] 1613321548.941699: Resolving hostname server.ohg-netz.llan.
[2791] 1613321548.941700: Sending initial UDP request to dgram 10.0.0.1:88
[2791] 1613321549.187603: Received answer (170 bytes) from dgram 10.0.0.1:88
[2791] 1613321549.187604: Sending DNS URI query for _kerberos.OHG-NETZ.LLAN.
[2791] 1613321549.187605: No URI records found
[2791] 1613321549.187606: Sending DNS SRV query for _kerberos-master._udp.OHG-NETZ.LLAN.
[2791] 1613321549.187607: No SRV records found
[2791] 1613321549.187608: Response was not from master KDC
[2791] 1613321549.187609: Received error from KDC: -1765328332/Antwort für UDP zu groß, erneuter Versuch mit TCP
[2791] 1613321549.187610: Request or response is too big for UDP; retrying with TCP
[2791] 1613321549.187611: Sending request (281 bytes) to OHG-NETZ.LLAN (tcp only)
[2791] 1613321549.187612: Sending DNS URI query for _kerberos.OHG-NETZ.LLAN.
[2791] 1613321549.187613: No URI records found
[2791] 1613321549.187614: Sending DNS SRV query for _kerberos._tcp.OHG-NETZ.LLAN.
[2791] 1613321549.187615: SRV answer: 0 100 88 "server.ohg-netz.llan."
[2791] 1613321549.187616: Resolving hostname server.ohg-netz.llan.
[2791] 1613321549.187617: Initiating TCP connection to stream 10.0.0.1:88
[2791] 1613321549.187618: Sending TCP request to stream 10.0.0.1:88
[2791] 1613321549.187619: Received answer (1684 bytes) from stream 10.0.0.1:88
[2791] 1613321549.187620: Terminating TCP connection to stream 10.0.0.1:88
[2791] 1613321549.187621: Sending DNS URI query for _kerberos.OHG-NETZ.LLAN.
[2791] 1613321549.187622: No URI records found
[2791] 1613321549.187623: Sending DNS SRV query for _kerberos-master._tcp.OHG-NETZ.LLAN.
[2791] 1613321549.187624: No SRV records found
[2791] 1613321549.187625: Response was not from master KDC
[2791] 1613321549.187626: Processing preauth types: 3
[2791] 1613321549.187627: Received salt "OHG-NETZ.LLANglobal-admin" via padata type 3
[2791] 1613321549.187628: Produced preauth for next request: (empty)
[2791] 1613321549.187629: AS key determined by preauth: aes256-cts/7283
[2791] 1613321549.187630: Decrypted AS reply; session key is: aes256-cts/FA36
[2791] 1613321549.187631: FAST negotiation: unavailable
[2791] 1613321549.187632: Initializing FILE:/tmp/krb5cc_0 with default princ global-admin@OHG-NETZ.LLAN
[2791] 1613321549.187633: Storing global-admin@OHG-NETZ.LLAN -> krbtgt/OHG-NETZ.LLAN@OHG-NETZ.LLAN in FILE:/tmp/krb5cc_0
[2791] 1613321549.187634: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/OHG-NETZ.LLAN@OHG-NETZ.LLAN: pa_type: 2
[2791] 1613321549.187635: Storing global-admin@OHG-NETZ.LLAN -> krb5_ccache_conf_data/pa_type/krbtgt\/OHG-NETZ.LLAN\@OHG-NETZ.LLAN@X-CACHECONF: in FILE:/tmp/krb5cc_0
(pam_mount.c:133): clean system authtok=0x5557f17943f0 (1073741824)
linuxadmin@m772:~$
und zwar zuverlässig, was schon mal ein großer Fortschritt ist. Anmeldung geht aber immer noch nicht.
Ich mache auf dem Client, den ich da am Wickel habe, jetzt noch ein Update, danach bin ich erst mal wieder ratlos.
Andreas
Hier nochmal etwas strukturierter:
die Datei /etc/resolv.conf ist ein Link, der auf
/run/systemd/resolve/stub-resolv.conf
verweist.
In dieser stub-Datei steht ein falscher Nameserver drin (127.0.0.53).
In dem gleichen Verzeichnis ist aber auch eine Datei resolv.conf
Diese enthält unseren Schulserver als Nameserver.
Das habe ich jetzt von einem Client, an dem ich noch nicht rumgefummelt habe, das war also ein Client, der vor 2 Wochen noch funtkioniert hatte.
Irgendwo muss der nameservereintrag ja herkommen, das muss irgend ein Linuxmuster-Skript machen, und irgendetwas sorgt dafür, dass es jetzt nicht mehr geht.
Nein, diese Konfiguration ist für mich vollkommen richtig.
Ich würde mit den DNS unter Ubuntu spielen, es ist nicht mehr so einfach wie /etc/resolv.conf editieren. Insbesondere ist es explizit geschrieben, dass die Datei von systemd verwaltet ist.
Ich habe den gleichen Eintrag bei mir, und die Anmeldung funktioniert problemlos. Einzige Unterschied zwischen uns beide ist folgende :
options edns0 trust-ad
Ich weiß ehrlich nicht, ob es wichtig für den KDC ist.
Ich glaube lieber, dass das Update auf Ubuntu den DNS neu konfiguriert hat, und damit hast du deine eigene Konfiguration verloren.
Geht ein kinit als Lehrer der nicht im Cache ist ?
Gruß
Arnaud
Das Problem tritt auch an clients auf, an denen ich das Update noch nicht eingespielt habe.
Wie „spiele“ ich denn mit dem DNS? Ich habe jetzt erst mal den resolv-conf-systemd-service abgeschaltet, anschließend modifizierte mir networkmanager die resolv.conf, das habe ich jetzt auch noch abegeschaltet, jetzt muss ich schauen.
OK, client ist neu gestartet:
- resolv.conf manuell gesetzt
- kinit für Lehrer der nicht im cache ist GEHT jetzt sofort
- login geht trotzdem NICHT
Hallo Andreas.
Ich denke weiterhin, dass du ein änliches Problem hast wie ich hier … kannst du mal als User das Anmeldescript manuell ausführen?
Also cd /etc/linuxmuster-client/scripts und dort dann:
login.sh
Wird da etwas gemeldet? Vor allem etwas in Sachen CIFS?