Thema: kerberos
-
Kerberos-Client-Grundlagen unter Linux: krb5.conf, kinit/klist/kdestroy und Keytabs
Ein Linux-Host nutzt Kerberos über /etc/krb5.conf, einen benutzer- oder dienstbezogenen Credential Cache, der mit kinit, klist und kdestroy verwaltet wird, sowie Keytabs für die unbeaufsichtigte Authentifizierung. Zeitabweichungen und die Gross-/Kleinschreibung von Realm-Namen verursachen die meisten Fehler, auf die ein Agent stösst.
-
Konsistenz von Hostname, FQDN und Reverse DNS: Warum Kerberos- und TLS-Namensprüfungen scheitern, wenn die Namen nicht übereinstimmen
Kerberos-Service-Tickets und die TLS-Hostnamenprüfung setzen voraus, dass der Name, den ein Client für einen Server auflöst, mit dem Namen übereinstimmt, den der Dienst für sich selbst annimmt. Weichen konfigurierter Hostname, /etc/hosts, Forward-DNS und PTR-Record voneinander ab, entstehen Authentifizierungs- und Zertifikatsfehler, die auf den ersten Blick nichts mit Namensauflösung zu tun haben.
-
Kerberos unter Windows: klist, klist purge und setspn -L/-Q bei SPN-Problemen
Windows stellt gecachte Kerberos-Tickets über klist und Service Principal Names über setspn zur Verfügung. Doppelte SPNs und Zeitabweichungen zwischen Client und Domänencontroller sind die zwei Fehlerursachen, die am häufigsten als unklare «Authentifizierung nicht möglich»-Meldungen statt als eindeutige Kerberos-Fehler auftreten.
-
NFS-Exports absichern: Netzwerkbeschränkung, Squash-Optionen und sec=krb5 statt AUTH_SYS
Die standardmässige NFS-Authentifizierung (AUTH_SYS) vertraut jeder UID, die ein Client angibt. Diese Methodik beschränkt Exports auf das kleinstmögliche Client-Netzwerk, begrenzt mit root_squash/all_squash, was eine behauptete UID darf, und wechselt zu sec=krb5, wo die Daten echte Authentifizierung rechtfertigen.
Maschinenlesbar: JSON