Eine KEYTAB-Datei wird verwendet, um einen Principal auf einem Host für Kerberos zu authentifizieren, ohne dass Benutzer eingreifen müssen (SSO). Die Datei ist verschlüsselt, sollte aber gut gesichert sein, da jeder, der Zugriff auf die Datei hat, als dieser Principal fungieren kann.
Mit einer solchen Datei kann also zum Beispiel der Zugang zu einem Webdienst über AD-Konten gesteuert werden. Sind die Brwoser entsprechend konfiguriert, können AD-Benutzer Webdienste sogar ohne die Eingabe von Zugangsdaten über Single Sign On (SSO) nutzen.
Die Konfiguration besteht aus 3 Schritten:
- Erstellung Servicekonto im AD
- Erzeugen der Keytab
- Konfiguration der Browser
Dies sind die nötigen Schritte, um einem Webdienst eine Keytab zur Verfügung zu stellen und den Browsern das Anfordern eines Kerberos Tickets für den Webdienst zu erlauben (SSO). Das kerberos Ticket wird dabei über das AD ausgestellt.
Erstellung Servicekonto im AD
Wir erstellen zuerst einen neuen Benutzeraccount. Ich mache Serviceaccounts gerne als solche Sichtbar, indem ich dem Namen ein _svc_ voran stelle.
Bei der Erstellung des Accounts gibt es ein paar Dinge zu beachten.
- Der Benutzeranmeldename folgt einer bestimmten Konvention. Er muss lauten wie die Domäne, unter der der Webdienst zur Verfügung gestellt wird, mit einem vorangestellten „HTTP/“. Wäre unser Webdienst z.B. unter beispiel.de zu erreichen, würde der Benutzeranmeldename „HTTP/beispiel.de“ heißen. Die Domäne ist dabei egal, wir nehmen an es wäre domain.de.
- Der Benutzeranmeldename Prä-Windows 2000 enthält die Anmeldedaten, die je nach Konfiguration dem Webdienst übergeben werden müssen. Z.B. domain\_svc_kt_beispiel
- In den Kontooptionen müssen 2 Haken gesetzt werden für „Dieses Konto unterstützt Kerberos-AES-128-Bit-Verschlüsselung“ und „Dieses Konto unterstützt Kerberos-AES-256-Bit-Verschlüsselung“
Erzeugen der Keytab
Die Keytab muss auf einem Domaincontroller erzeugt werden. Dazu öffnen wir eine CMD als Domainadmin. Der Befehl wir dnach folgendem Muster eingegeben:
ktpass -princ [Benutzeranmeldename]@[Domäne groß geschrieben] -pass [pw] -mapuser [Benutzeranmeldename Prä-Windows 2000]@[Domäne Prä-Windows 2000 mit TLD Endung (.DE), alles groß geschrieben] -Ptype KRB5_NT_PRINCIPAL -out "keytab.tab"
Für unser Beispiel wäre das also folgendes Kommando:
ktpass -princ HTTP/beispiel.de@DOMAIN.DE -pass einSicheresPasswort -mapuser _svc_kt_beispiel@DOMAIN.DE -Ptype KRB5_NT_PRINCIPAL -out "keytab.tab"
Die Keytab liegt dann in dem Ordner, aus dem das Kommando ausgeführt wurde. Dieses weg sichern und dem Webdienst zur Verfügung stellen. Nicht nach extern geben!
Konfiguration der Browser für SSO
Im Wesentlichen muss man den Browsern mit auf den Weg geben, dass sie für eine bestimmte Domain Kerberos Tickets anfordern dürfen. Ich gehe hier natürlich nicht auf alle Browser ein, sondern nur auf die 3 wichtigsten, meiner Meinung nach. Nämlich
- Firefox
- Chrome
- Edge (aktuelle Version 2022)
Chrome und Edge
Die gute Nachricht ist, dass der Chrome und der Edge über Gruppenrichtlinien konfiguriert werden können. Die Einstellung kann als Computerrichtlinie oder Benutzerrichtlinie unter den Administrativen Vorlagen vorgenommen werden. Und zwar unter folgendem Pfad:
Windows-Komponenten/Internet Explorer/Internetsystemsteuerung/Sicherheitsseite/Liste der Site zu Zonenzuweisungen
Der 1. und der 3. Eintrag sind z.B. für das Office365 SSO (dafür braucht man aber keine Keytab, das läuft über den AzureAD Connector). Genau hier wird dann aber auch unsere Webanwendung eingetragen, Wert 1.
Man kann über den Internet Explorer prüfen, ob die GPO gegriffen hat (oder über RSOP). Explorer öffnen und dann
Interneteinstellungen->Tabe Sicherheit->Lokales Intranet->Erweitert
Man könnte die Seite hier natürlich auch direkt eintragen. Bei uns werden die Einstellungen aber zentral verwaltet und daher sind die Schaltflächen gesperrt.
So und nun ist das Ganze Clientseitig ordentlich konfiguriert.