Deine domain-beigetretene Windows-Maschine loggt sich still in interne Webanwendungen ein. Kerberos-Ticket, SPNEGO-Handshake, fertig — du siehst nie ein Login-Formular. Die Frage war, ob eine Linux-Maschine, von der AD noch nie gehört hat, denselben Trick schafft.

Sie schafft es. Ein Domain-Beitritt ist für Maschinen-Konten da. Ein Benutzer-Ticket braucht drei Dinge: einen Kerberos-Client, fünf Zeilen Konfiguration und dein Passwort. Hier ist die ganze Reise, samt der zwei Stellen, an denen ich auf die Nase fiel.

Die Einrichtung

sudo apt install krb5-user

Dann /etc/krb5.conf:

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_kdc = true
    dns_lookup_realm = true
    rdns = false

Das war’s. Keine fest codierten KDC-Adressen — AD veröffentlicht seine Domänencontroller im DNS, und der Client findet sie von selbst:

dig +short SRV _kerberos._tcp.example.com
# 0 100 88 dc01.example.com.
# 0 100 88 dc02.example.com.

(Nur internes DNS. Öffentliche Resolver wissen nichts. Im VPN erst resolvectl status prüfen, bevor du Kerberos die Schuld gibst.)

AD-Bonusfakt: Jeder DC ist gleichzeitig KDC, Passwort-Server und Admin-/LDAP-Endpunkt. Die MIT-Kerberos-Unterscheidung zwischen kdc und admin_server? Fällt weg. Jeder DC macht alles.

Ein Ticket bekommen — und Bauchlandung Nr. 1

Erster Versuch:

kinit myuser@example.com

Ergebnis: eine leere Zeile. Kein Prompt, kein Fehler, nichts. Nur ein Cursor, der zurückstarrt. Enter drücken erzeugte eine weitere leere Zeile. Großartige Software.

Das Problem: Alles nach @ ist ein Kerberos-Realm, und Realms werden GROSSGESCHRIEBEN. example.com sieht aus wie die Domain — sieht sogar aus wie meine E-Mail-Adresse —, aber für Kerberos ist es ein unbekannter Realm, und statt das zu sagen, hat es einfach nur … geschmollt.

Die Lösung ist fast schon eine Beleidigung:

kinit myuser
Password:

Lass den Realm ganz weg, und default_realm aus krb5.conf springt ein. Plötzlich gibt es einen echten, sichtbaren Password:-Prompt — so weißt du, dass du mit dem richtigen Realm sprichst. Passwort eingeben (Eingabe verborgen, wie bei sudo), Enter, und:

klist
# Default principal: myuser@EXAMPLE.COM
# krbtgt/EXAMPLE.COM@EXAMPLE.COM   valid ~10h

Ein krbtgt-Eintrag bedeutet, dass du ein TGT besitzt. Du bist jetzt, kryptografisch gesprochen, in der Domain eingeloggt.

Wenn kinit sich noch einmal danebenbenimmt, zeigt das hier genau, was es tut — DNS-Abfragen, welchen DC es kontaktiert, wo es stirbt:

KRB5_TRACE=/dev/stdout kinit myuser

Bauchlandung Nr. 2: „Unable to locate package nc“

Wollte prüfen, ob Port 88 überhaupt erreichbar ist. apt install nc — kein solches Paket. Unter Debian/Ubuntu heißt es netcat-openbsd. Oder die Installation ganz überspringen, bash hat Netzwerk eingebaut:

timeout 3 bash -c 'cat < /dev/null > /dev/tcp/dc01.example.com/88' && echo OPEN || echo CLOSED

Dem Browser Manieren beibringen

Windows-Browser handhaben die Aushandlung automatisch, weil sie der Intranet-Zone vertrauen. Linux-Browser vertrauen niemandem, bis man es ihnen sagt:

Firefox — about:config → network.negotiate-auth.trusted-uris → .example.com

Chrome/Chromium — /etc/opt/chrome/policies/managed/kerberos.json:

{ "AuthServerAllowlist": "*.example.com" }

curl — weil curl das natürlich auch kann:

curl --negotiate -u : https://internal-app.example.com/

Eine interne Seite öffnen. Sie loggt dich ein. Lautlos. Auf einer Maschine, die nicht in der Domain ist.

Das Kleingedruckte

• Uhren: Kerberos erlaubt ~5 Minuten Abweichung. NTP am Laufen halten, sonst funktioniert nichts und die Fehler sagen dir nicht, warum.
• FQDNs verwenden: der Hostname muss zum SPN des Dienstes passen. IPs und beliebige Aliase fallen auf NTLM zurück oder schlagen fehl.
• Tickets laufen ab (~10 Std.). Täglich neu kinit machen oder mit k5start, einem Keytab oder sssd + KCM automatisieren.