Keberos ADS Squid

Was ist Kerberos?

Kerberos ist ein Netzwerk-Authentifizierungsprotokoll, das Sicherheit in Computernetzwerken bietet. Es verwendet ein Ticket-basiertes System, um Benutzern und Diensten eine sichere Identität zuzuweisen. Kerberos wird häufig in Umgebungen wie Active Directory (AD) eingesetzt.

Funktionsweise von Kerberos

• KDC (Key Distribution Center): Das Herzstück von Kerberos ist der KDC, der aus zwei Komponenten besteht:
  • Authentication Server (AS): Stellt Benutzern ein Ticket Granting Ticket (TGT) aus.
  • Ticket Granting Server (TGS): Gewährt Benutzern Service Tickets für den Zugriff auf bestimmte Dienste.

• Tickets:
  • TGT (Ticket Granting Ticket): Ein Ticket, das es einem Benutzer ermöglicht, Service Tickets für andere Dienste anzufordern.
  • Service Ticket: Ein Ticket, das für den Zugriff auf spezifische Dienste, wie z.B. Squid, verwendet wird.

1. Erhalt des Ticket Granting Ticket (TGT)

• Bei der ersten Anmeldung des Benutzers wird ein TGT vom Kerberos Authentication Server (AS) ausgestellt.
• Das TGT ist ein einmaliges Ticket, das die Identität des Benutzers für eine bestimmte Zeit bestätigt.

2. Anfordern eines Service Tickets

• Wenn der Benutzer auf einen spezifischen Dienst (z.B. einen Proxy-Server wie Squid) zugreifen möchte, verwendet er das TGT, um ein Service Ticket vom Ticket Granting Server (TGS) anzufordern.

3. Erhalt des Service Tickets

• Der TGS überprüft das TGT und die Berechtigungen des Benutzers. Wenn alles in Ordnung ist, stellt der TGS ein Service Ticket für den Proxy-Server aus.
• Dieses Service Ticket wird an den Benutzer zurückgegeben.

4. Verwendung des Service Tickets

• Der Benutzer verwendet das Service Ticket, um sich beim Dienst (z.B. beim Proxy-Server) zu authentifizieren.
• Das Service Ticket enthält Informationen über den Benutzer und die Berechtigungen für den Dienst.

5. Ablauf und Erneuerung

• Service Tickets haben eine begrenzte Lebensdauer. Nach Ablauf muss der Benutzer ein neues Ticket anfordern.

Warum benötigt der Proxy ein Ticket?

• Der Proxy-Server benötigt ein Ticket, um sicherzustellen, dass nur autorisierte Benutzer auf die über den Proxy bereitgestellten Dienste zugreifen können.
• Ein gültiges Service Ticket bestätigt die Identität des Benutzers und zeigt, dass er authentifiziert ist.
• Durch die Verwendung von Kerberos-Tickets kann der Proxy-Server den Zugriff auf Ressourcen steuern und sicherstellen, dass nur berechtigte Benutzer die Dienste nutzen.

Kerberos in Active Directory (AD)

• AD verwendet Kerberos zur Authentifizierung von Benutzern und Computern im Netzwerk.
• Benutzer, die sich bei einem AD-Domänencontroller anmelden, erhalten ein TGT, das sie verwenden können, um Service Tickets für verschiedene Dienste in der Domäne zu erhalten.

Kerberos und Squid

• Squid ist ein Proxy-Server, der Kerberos für die Authentifizierung von Benutzern verwenden kann.
• Um Kerberos mit Squid zu integrieren, sind einige Konfigurationen erforderlich.

Wichtige Programme und Dateien

• kinit: Ein Kommandozeilenwerkzeug, das verwendet wird, um ein Kerberos-Ticket zu erhalten.
• klist: Ein Tool zur Anzeige von Kerberos-Tickets, die in einem Ticket-Cache gespeichert sind.
• kdestroy: Ein Tool zum Löschen von Kerberos-Tickets aus dem Cache.
• /etc/krb5.conf: Die Konfigurationsdatei für Kerberos, die die Realms und KDC-Informationen enthält.
• /etc/squid/squid.conf: Die Hauptkonfigurationsdatei für Squid, in der Kerberos- und Authentifizierungseinstellungen festgelegt werden.

Konfiguration von Kerberos und Squid

• In der Datei /etc/krb5.conf sollten die Realms und KDC-Server konfiguriert sein.
• In der Squid-Konfigurationsdatei /etc/squid/squid.conf müssen die Kerberos-Authentifizierungsmechanismen und die Keytab-Datei angegeben werden.

Fazit

Kerberos bietet eine sichere Möglichkeit zur Authentifizierung von Benutzern in Netzwerken, insbesondere in Kombination mit Active Directory und Proxy-Servern wie Squid. Durch die richtige Konfiguration dieser Komponenten kann ein sicheres Netzwerkumfeld geschaffen werden.

Erklärung der Kerberos-Befehle und Ausgaben

Befehl: kinit

• kinit administrator:
  • Dieser Befehl wird verwendet, um ein Kerberos-Ticket für den Principal administrator@LAB34.LINUGGS.DE zu erhalten.
  • Der Benutzer wird zur Eingabe des Passworts aufgefordert. Nach erfolgreicher Eingabe wird ein Ticket Granting Ticket (TGT) für den Benutzer erstellt.

Befehl: klist

• klist:
  • Dieser Befehl zeigt die im Kerberos-Ticket-Cache gespeicherten Tickets an.
  • Er zeigt, welche Tickets aktuell für den Benutzer gültig sind und deren Ablaufdaten.

Ausgabe von klist

• Ticket cache: FILE:/tmp/krb5cc_0:
  • Dies gibt an, wo der Ticket-Cache gespeichert ist. In diesem Fall ist es die Datei /tmp/krb5cc_0.

• Default principal: administrator@LAB34.LINUGGS.DE:
  • Dies zeigt den Standard-Prinzipal an, für den das Ticket erstellt wurde.

• Valid starting / Expires / Service principal:
  • Diese Spalten zeigen die folgenden Informationen an:
    • Valid starting - Das Datum und die Uhrzeit, zu der das Ticket gültig wurde.
    • Expires - Das Datum und die Uhrzeit, zu der das Ticket abläuft.
    • Service principal - Der Service, für den das Ticket gilt, in diesem Fall krbtgt/LAB34.LINUGGS.DE@LAB34.LINUGGS.DE, das für den Kerberos Ticket Granting Ticket Service (TGS) steht.

• renew until:
  • Dies gibt an, bis wann das Ticket erneuert werden kann. In diesem Fall kann das Ticket bis zum 10/03/2024 19:50:54 erneuert werden.

Zusammenfassung

• Durch die Verwendung von kinit erhält der Benutzer ein Kerberos-Ticket.
• klist ermöglicht die Überprüfung des Ticket-Status und der Gültigkeitszeiträume.
• Diese Befehle sind entscheidend für die Verwaltung von Kerberos-Authentifizierungsprozessen.

Erklärung des Befehls und der Ausgabe

Befehl: klist -k

• klist -k /etc/squid/PROXY.keytab:
  • Dieser Befehl wird verwendet, um den Inhalt einer Keytab-Datei anzuzeigen.
  • Eine Keytab-Datei speichert Kerberos-Schlüssel für verschiedene Principals und wird häufig verwendet, um die Authentifizierung von Diensten zu ermöglichen, ohne dass Passwörter gespeichert werden müssen.

Ausgabe von klist -k

• Keytab name: FILE:/etc/squid/PROXY.keytab:
  • Dies zeigt den Pfad zur Keytab-Datei an, die untersucht wird.

• KVNO Principal:
  • Diese Spalten geben an, dass die folgende Tabelle die Key Version Number (KVNO) und die zugehörigen Principals zeigt.

• KVNO (Key Version Number):
  • Die Zahl zeigt die Version des Schlüssels an, die für den Principal verwendet wird.
  • Ein höherer KVNO bedeutet in der Regel, dass der Schlüssel aktualisiert wurde.

• Principal:
  • Ein Principal ist der Name eines Benutzers oder Dienstes, der in der Kerberos-Datenbank registriert ist.
  • Es gibt verschiedene Principals in der Ausgabe, einschließlich:
    • PROXYSRV-HTTP$@LAB34.LINUGGS.DE: Ein Principal für einen HTTP-Dienst, wahrscheinlich für interne Proxy-Dienste.
    • HTTP/proxy.lab34.linuggs.de@LAB34.LINUGGS.DE: Ein Principal für den Proxy-Server, der Kerberos-Authentifizierung verwendet.
    • host/proxy.lab34.linuggs.de@LAB34.LINUGGS.DE: Ein Principal für den Hostnamen des Proxy-Servers.
    • PROXY$@LAB34.LINUGGS.DE: Ein weiterer Principal, möglicherweise für einen bestimmten Dienst oder Benutzer.

• Die Anzahl der Einträge zeigt, wie oft jeder Principal in der Keytab-Datei vorhanden ist.

Zusammenfassung

Der Befehl klist -k wird verwendet, um die Kerberos-Principal-Einträge in einer Keytab-Datei anzuzeigen, die für die Authentifizierung von Diensten wie Squid verwendet werden. Die Ausgabe bietet Informationen über die Principals, ihre Versionen und deren Verwendung innerhalb des Kerberos-Systems.

GSSAPI und Kerberos

Was ist GSSAPI?

• GSSAPI (Generic Security Services Application Program Interface):
  • GSSAPI ist eine API, die es Anwendungen ermöglicht, sicherheitsbezogene Dienste wie Authentifizierung, Verschlüsselung und Integritätsschutz zu nutzen, ohne sich um die Details des zugrunde liegenden Sicherheitsmechanismus kümmern zu müssen.
  • GSSAPI unterstützt verschiedene Sicherheitsprotokolle, darunter Kerberos.

Verbindung zwischen GSSAPI und Kerberos

• GSSAPI wird häufig in Kombination mit Kerberos verwendet, um eine sichere Authentifizierung in Netzwerken zu ermöglichen.
• Wenn eine Anwendung GSSAPI verwendet, um sich bei einem Dienst anzumelden, wird Kerberos oft als Sicherheitsmechanismus genutzt, um die Identität des Benutzers zu überprüfen und ein Kerberos-Ticket zu generieren.
• GSSAPI abstrahiert die Komplexität der Kerberos-Interaktion und ermöglicht es Anwendungen, Kerberos für die Authentifizierung zu nutzen, ohne die Details der Ticketverwaltung selbst implementieren zu müssen.

Fehleranalyse

• Befehl: ldapsearch -LLL -Y GSSAPI -H ldap://win2022.lab34.linuggs.de -b dc=lab34,dc=linuggs,dc=de cn=thomas sAMAccountName:
  • Dieser Befehl versucht, eine LDAP-Abfrage unter Verwendung der GSSAPI-Authentifizierung durchzuführen, um die Identität des Benutzers zu bestätigen.

• Fehlermeldung: ldap_sasl_interactive_bind: Local error (-2):
  • Diese Meldung zeigt an, dass es ein Problem bei der lokalen Authentifizierung gab.
  • Der Fehlercode -2 deutet auf ein Problem mit der SASL-Authentifizierung hin.

• Zusätzliche Info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database):
  • Diese Meldung weist darauf hin, dass ein spezifisches Problem mit der GSSAPI-Authentifizierung aufgetreten ist.
  • Die Angabe "Server not found in Kerberos database" deutet darauf hin, dass der Kerberos-Server den Principal für den LDAP-Dienst (in diesem Fall wahrscheinlich `ldap/win2022.lab34.linuggs.de`) nicht finden kann.

Mögliche Ursachen

• **Principal fehlt in der Kerberos-Datenbank**: Der Principal, der für die GSSAPI-Authentifizierung benötigt wird, könnte nicht in der Kerberos-Datenbank vorhanden sein.
• **Falsche Kerberos-Konfiguration**: Die Kerberos-Konfigurationsdatei (`/etc/krb5.conf`) könnte falsch konfiguriert sein oder der KDC ist nicht erreichbar.
• **DNS-Probleme**: Der FQDN des LDAP-Servers könnte nicht korrekt aufgelöst werden, was dazu führt, dass der Principal nicht gefunden wird.

Ergebnis der LDAP-Abfrage

• Befehl:
  • ldapsearch -LLL -Y GSSAPI -H ldap://win2022.lab34.linuggs.de -b dc=lab34,dc=linuggs,dc=de cn=thomas sAMAccountName

• Ausgabe:
  • SASL/GSSAPI authentication started
  • SASL username: administrator@LAB34.LINUGGS.DE
  • SASL SSF: 256
  • SASL data security layer installed.

• • dn: CN=thomas,CN=Users,DC=lab34,DC=linuggs,DC=de
    • Dies zeigt den Distinguished Name (DN) des gesuchten Benutzers (in diesem Fall `thomas`) an.

• • sAMAccountName: thomas
    • Dies ist der Benutzername (sAMAccountName) des Benutzers `thomas`.

• • Referrals:
    • # refldap://ForestDnsZones.lab34.linuggs.de/DC=ForestDnsZones,DC=lab34,DC=linuggs,DC=de
    • # refldap://DomainDnsZones.lab34.linuggs.de/DC=DomainDnsZones,DC=lab34,DC=linuggs,DC=de
    • # refldap://lab34.linuggs.de/CN=Configuration,DC=lab34,DC=linuggs,DC=de

Bedeutung

• Die erfolgreiche Authentifizierung zeigt, dass die Konfiguration der Kerberos- und LDAP-Dienste nun korrekt funktioniert.
• Der korrekte Principal und die Reverse-DNS-Konfiguration sind entscheidend für die erfolgreiche GSSAPI-Authentifizierung.
• Die Ausgabe enthält den DN des Benutzers und seinen sAMAccountName, was zeigt, dass die LDAP-Abfrage erfolgreich war.

Fazit

• Die Lösung des Problems durch die Korrektur der Reverse-DNS-Auflösung ermöglicht nun die erfolgreiche Authentifizierung beim LDAP-Server.
• Dies ist ein wichtiger Schritt für die Integrität der Kerberos- und LDAP-Integration in deiner Umgebung.