Dieser Blog ist Teil der Blogserie Kerberos und Hadoop und erklärt, was Kerberos ist und wie Sie einen Kerberos-Server einrichten können. Dies ist der erste Teil der Blogserie und er ist nur ein "Hilfs-Blog", der erklärt, was Kerberos ist und wie es installiert werden kann. Der Rest der Serie enthält:
- wie Sie realitätsübergreifendes Vertrauen zwischen einem Active Directory und dem KDC-Server einrichten, den Sie in diesem Blog eingerichtet haben (Einrichten von realitätsübergreifendem Vertrauen zwischen Active Directory und Kerberos-KDC)
- wie Sie Kerberos mit Cloudera Manager und Hadoop verwenden (Einrichten der Kerberos-Authentifizierung für Hadoop mit Cloudera Manager)
Hintergrund Kerberos
Kerberos ist ein Netzwerk-Authentifizierungsprotokoll und basiert auf der Annahme, dass Netzwerkverbindungen unzuverlässig sind. Kerberos verwendet Kryptographie mit geheimen Schlüsseln, um eine starke Authentifizierung zu ermöglichen, indem es eine Authentifizierung von Benutzer zu Server ermöglicht.
Kerberos hat seine eigene Terminologie, die wir kurz erklären müssen, bevor wir fortfahren.
- Ein Realm legt eine administrative Domäne für die Authentifizierung fest. Jeder Realm verfügt über eine eigene Kerberos-Datenbank, die die Benutzer und Dienste für diese spezielle administrative Domäne enthält.
- Principals sind die Einträge in der Kerberos-Datenbank. Jedem Benutzer, Host oder Dienst wird ein Principal zugewiesen.
- Tickets werden vom Authentifizierungsserver ausgestellt. Clients legen dem Anwendungsserver Tickets vor, um die Echtheit ihrer Identität nachzuweisen. Jedes Ticket hat ein Ablaufdatum und eine Erneuerungszeit. Der Kerberos-Server hat keine Kontrolle über die ausgestellten Tickets. Selbst wenn wir also verhindern, dass ein Benutzer ein Ticket erhält, kann er/sie, wenn er/sie bereits ein gültiges Ticket hat, dieses verwenden, um den Dienst zu kontaktieren (bis das Ticket abläuft).
- Keytabs speichert langfristige Schlüssel für einen oder mehrere Principals.
Um die Kerberos-Terminologie besser zu verstehen, können Sie die Seite Kerberos Authentication Protocol lesen.
Ein Kerberos-Server, in der Regel als Key Distribution Center (KDC) bezeichnet, befindet sich auf einem physischen Host, hat aber logischerweise mehrere Komponenten integriert:
- Datenbank - enthält die Benutzer- und Serviceeinträge (Benutzerprinzip, maximale Gültigkeit, maximale Verlängerungszeit, Ablauf des Passworts usw.)
- Authentifizierungsserver (AS) - antwortet auf die Authentifizierungsanfragen des Clients, wenn der noch nicht authentifizierte Benutzer ein Passwort eingeben muss. Der AS sendet ein Ticket Granting Ticket (TGT) zurück, das vom Benutzer weiter verwendet werden kann, ohne dass er sein Passwort erneut eingeben muss.
- Ticket Granting Server(TGS) - verteilt Service-Tickets basierend auf dem TGT
Um mit Kerberos auf einen Dienst zuzugreifen, muss ein Client Folgendes tun:
- Authentifizieren Sie sich beim Kerberos-Authentifizierungsserver und erhalten Sie ein Ticket Granting Ticket (TGT).
- Beantragen Sie ein Service-Ticket vom Ticket Granting Server
- Verwenden Sie das Service-Ticket, um sich bei dem Server zu authentifizieren, der den Dienst bereitstellt, den der Client nutzen möchte (in unserem Fall: HDFS, MapReduce, HBase, usw.)
Die folgende Abbildung zeigt die oben genannten Schritte.
Kerberos Key Distribution Center installieren
Der KDC-Server kann ein völlig separater Rechner sein oder zum Beispiel der Rechner, auf dem der Cloudera Manager läuft. Sie sollten bedenken, dass Sie Ihren Hadoop-Cluster nicht nutzen können, wenn der KDC nicht erreichbar ist. Zur Installation des KDC-Servers habe ich die auf der CentOS-Website beschriebenen Schritte befolgt: Konfigurieren Sie einen Kerberos 5-Server.
Kurze Zusammenfassung der notwendigen Schritte:
HINWEIS: Diese Befehle müssen auf dem Rechner ausgeführt werden, der als KDC fungieren soll. Alle diese Befehle müssen als root oder als Benutzer mit sudo-Rechten ausgeführt werden.
- Installieren Sie die Pakete krb5-libs, krb5-server und krb5-workstation.
$ yum install krb5-libs krb5-server krb5-workstation
- Legen Sie den Realm-Namen und die Zuordnung zwischen Domäne und Realm in den Dateien /etc/krb5.conf und /var/kerberos/krb5dc/kdc.conf fest. HINWEIS: Gemäß der Konvention werden alle Realm-Namen in Großbuchstaben und alle DNS-Hostnamen und Domänennamen in Kleinbuchstaben geschrieben.Unser KDC läuft auf host1.mydomain.nl und unser Realm ist GDD.NL. Hier ist der Inhalt der Datei /etc/krb5.conf:
$ cat /etc/krb5.conf
[Protokollierung]
Standard = DATEI:/var/log/krb5libs.log
kdc = DATEI:/var/log/krb5kdc.log
admin_server = DATEI:/var/log/kadmind.log
[libdefaults]
standard_realm = GDD.NL
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
weiterleitbar = true
[Reiche]
GDD.NL = {
kdc = host1.meinedomain.nl
admin_server = host1.meinedomain.nl
}
[domain_realm]
.beispiel.de = GDD.NL
beispiel.de = GDD.NL
Der Inhalt von /var/kerberos/krb5kdc/kdc.conf
$ cat /var/kerberos/krb5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 88
kdc_tcp_ports = 88
[Reiche]
GDD.NL = {
#master_key_type = aes256-cts
acl_file =
/var/kerberos/krb5kdc/kadm5.acl
dict_file =
/usr/share/dict/words
admin_keytab =
/var/kerberos/krb5kdc/kadm5.keytab
unterstützte_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal
max_life = 24h 0m 0s
max_renewable_life = 7d 0h 0m 0s
}
HINWEIS: Wir haben die Eigenschaften max_life und max_renewable_life hinzugefügt.
- Erstellen Sie die Datenbank, in der die Schlüssel für den Kerberos-Realm gespeichert werden. Mit -s erstellen wir die stash-Datei, in der wir das Master-Kennwort speichern. Ohne diese Datei wird der KDC den Benutzer bei jedem Start nach dem Master-Passwort fragen.
$ kdb5_util create -s Laden von Zufallsdaten Datenbank initialisieren '/var/kerberos/krb5kdc/principal'. für Reich 'GDD.NL', Hauptschlüsselname 'K/M@GDD.NL' Sie werden dazu aufgefordert für das Master-Kennwort der Datenbank. Es ist wichtig, dass Sie dieses Passwort NICHT VERGESSEN. Geben Sie den Hauptschlüssel der KDC-Datenbank ein: Geben Sie den Hauptschlüssel der KDC-Datenbank erneut ein, um ihn zu überprüfen:
- Bearbeiten Sie die Datei /var/kerberos/krb5kdc/kadm5.acl, um festzulegen, welche Principals administrativen Zugriff haben.
$ cat /var/kerberos/krb5kdc/kadm5.acl */admin@GDD.NL *
- Erstellen Sie Ihren ersten PrincipalHINWEIS: Zunächst sollten Sie einen Principal erstellen, der über Administratorrechte verfügt (der Principal muss dem Ausdruck entsprechen, den Sie in /var/kerberos/krb5kdc/kadm5.acl angegeben haben). Das Dienstprogramm kadmin kommuniziert über das Netzwerk mit dem kadmind-Server und verwendet Kerberos für die Authentifizierung. Der erste Principal muss bereits existieren, bevor Sie sich über das Netzwerk mit dem Server verbinden. Wir können diesen Principal mit kadmin.local erstellen.
$ kadmin.local -q "addprinc tunde/admin" Authentifizierung als Auftraggeber root/admin@GDD.NL mit Passwort. WARNUNG: keine Richtlinie angegeben für tunde/admin@GDD.NL; Standardmäßig keine Richtlinie Passwort eingeben für Hauptperson "tunde/admin@GDD.NL": Passwort erneut eingeben für Hauptperson "tunde/admin@GDD.NL": Hauptsächlich "tunde/admin@GDD.NL" erstellt.
- Starten Sie Kerberos und stellen Sie sicher, dass die Dienste nach dem Neustart gestartet werden
$ service krb5kdc start $ service kadmin start $ chkconfig krb5kdc ein $ chkconfig kadmin ein
- Verwenden Sie kadmin oder kadmin.local, um Principals hinzuzufügen. Aber welches können wir verwenden? Als root können Sie kadmin.local verwenden, aber kadmin können Sie nicht verwenden, weil wir keinen Principal hinzugefügt haben root/admin@GDD.NL. Das würde also folgendermaßen ablaufen:
# sich mit dem Prinzipal root/admin anmelden -- schlägt fehl, da wir diesen Prinzipal nicht hinzugefügt haben [Wurzel]$ kadmin Authentifizierung als Auftraggeber root/admin@GDD.NL mit Passwort. kadmin: Client nicht in Kerberos-Datenbank gefunden während Initialisierung der kadmin Schnittstelle # Melden Sie sich mit dem tunde/admin Prinzip an - funktioniert [Wurzel]$ kadmin -p tunde/admin Authentifizierung als principal tunde/admin mit Passwort. Passwort für tunde/admin@GDD.NL: kadmin: kadmin: Ausgang # mit kadmin.local als root anmelden -- funktioniert [Wurzel]$ kadmin.local Authentifizierung als Auftraggeber root/admin@GDD.NL mit Passwort. kadmin.local: kadmin.local: Ausgang
Lassen Sie uns also sehen, wie wir Prinzipale verwalten:
[Wurzel]$ kadmin -p tunde/admin Authentifizierung als principal tunde/admin mit Passwort. Passwort für tunde/admin@GDD.NL: #list principals -- sehen, welche Benutzer ein Kerberos-Ticket erhalten können kadmin: list_principals #einen neuen Direktor hinzufügen kadmin: addprinc benutzer1 WARNUNG: keine Richtlinie angegeben für user1@GDD.NL; Standardmäßig keine Richtlinie Passwort eingeben für Hauptperson "user1@GDD.NL": Passwort erneut eingeben für Hauptperson "user1@GDD.NL": Hauptsächlich "user1@GDD.NL" erstellt. #Direktor löschen kadmin: delprinc user1 Sind Sie sicher, dass Sie den Auftraggeber löschen möchten? "user1@GDD.NL"? (ja/nein): ja Hauptsächlich "user1@GDD.NL" gelöscht. Stellen Sie sicher, dass Sie diesen Principal aus allen ACLs entfernt haben, bevor Sie ihn wieder verwenden. #Wir fügen den Prinzipal user1 wieder ein kadmin: addprinc benutzer1 WARNUNG: keine Richtlinie angegeben für user1@GDD.NL; keine Politik zu machen Passwort eingeben für Hauptperson "user1@GDD.NL": Passwort erneut eingeben für Hauptperson "user1@GDD.NL": Hauptsächlich "user1@GDD.NL" erstellt. kadmin: Ausgang
HINWEIS: Sie können auch eine Abfrage angeben und dann die kadmin-Konsole verlassen.
[Wurzel]$ kadmin -p tunde/admin -q "list_principals" [Wurzel]$ kadmin -p tunde/admin -q "addprinc user2" [Wurzel]$ kadmin -p tunde/admin -q "delprinc user2"
Was Sie sonst noch mit dem kadmin-Befehl tun können, erfahren Sie in der MIT Kerberos Dokumentation - kadmin.
- Jetzt sollten wir testen, ob unser KDC die Tickets korrekt ausstellt.
[Wurzel]$ kinit user1 Passwort für user1@GDD.NL: # Lassen Sie uns das Ticket sehen und auch den Verschlüsselungstyp anzeigen [Wurzel]$ klist -e Ticket-Cache: DATEI:/tmp/krb5cc_0 Standardmäßiger Auftraggeber: user1@GDD.NL Gültig ab Expires Serviceprinzip 02/03/14 02:32:42 02/04/14 02:32:42 krbtgt/GDD.NL@GDD.NL erneuern bis 02/03/14 02:32:42, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Das bedeutet, dass wir ein Ticket für user1 erhalten haben, das 1 Tag lang gültig ist. Wäre ich als Benutzer "user1" eingeloggt gewesen, hätte ich kinit verwenden können, ohne anschließend "user1" anzugeben.
Wir können auch Tickets vernichten:
[Wurzel]$ kdestroy [Wurzel]$ klist klist: Kein Berechtigungsnachweis-Cache gefunden (Ticket-Zwischenspeicher FILE:/tmp/krb5cc_0)
HINWEIS: Der Hauptbenutzername und der Hauptbenutzername/Admin sind unterschiedlich. Wenn Sie einen Hauptbenutzernamen/Admin hinzugefügt haben, bedeutet das nicht, dass Sie ein Ticket für den Hauptbenutzernamen erhalten können. Lassen Sie uns sehen, wie das funktioniert. Ich habe einen tunde/admin-Hauptbenutzer hinzugefügt, aber ich habe keinen tunde-Hauptbenutzer erstellt.
[Wurzel]$ kinit tunde kinit: Client nicht in Kerberos-Datenbank gefunden während Erlangung der Zugangsberechtigung [Wurzel]$ kinit tunde/admin Passwort für tunde/admin@GDD.NL: [Wurzel]$ klist Ticket-Cache: DATEI:/tmp/krb5cc_0 Standardmäßiger Auftraggeber: tunde/admin@GDD.NL Gültig ab Expires Serviceprinzip 02/03/14 01:51:27 02/04/14 01:51:27 krbtgt/GDD.NL@GDD.NL erneuern bis 02/03/14 01:51:27
- Prüfen Sie, ob Sie die Kerberos-Tickets erneuern können (dies ist wichtig für Hue)Warum ist die TGT-Erneuerung wichtig? Weil einige seit langem laufende Aufträge von der Erneuerung des Tickets profitieren könnten, damit sie weiterlaufen können. Hue verfügt über eine Kerberos-Ticket-Erneuerungsinstanz. Wenn Sie die Ticketerneuerung nicht korrekt konfigurieren, können Sie Hue nicht in einer kerberisierten Umgebung verwenden. Wie können wir das also überprüfen?
$ kinit tunde/admin $ klist Ticket-Cache: DATEI:/tmp/krb5cc_0 Standardmäßiger Auftraggeber: tunde/admin@GDD.NL Gültig ab Expires Serviceprinzip 02/05/14 14:08:06 02/06/14 14:08:06 krbtgt/GDD.NL@GDD.NL erneuern bis 02/05/14 14:08:06 $ kinit -R kinit: Ticket abgelaufen während Legitimation erneuern
Wenn Sie diese Fehlermeldung nicht erhalten haben, können Sie den Rest des Blogs überspringen, da Ihr Kerberos-Server ordnungsgemäß funktioniert.
Wenn Sie diese Fehlermeldung erhalten, bedeutet dies, dass etwas mit der Kerberos-Konfiguration nicht stimmt. Wenn Sie sich dadurch besser fühlen, ist es wahrscheinlich nicht Ihre Schuld: Die Erneuerung von Tickets ist in den meisten Linux-Distributionen standardmäßig nicht erlaubt. Was ist also los?
Die erneuerbare Lebensdauer wird auf ein Minimum von festgelegt:
- die beantragte erneuerbare Lebensdauer
- die maximal verlängerbare Lebensdauer des Auftraggebers
- die maximale verlängerbare Lebensdauer des Dienstherrn
- die maximale erneuerbare Lebensdauer für das Reich (oder einen Tag, falls nicht festgelegt)
Die maximale erneuerbare Lebensdauer der Principals wird in den KDB-Einträgen mit kadmin festgelegt. Neue Principals erhalten standardmäßig eine maximale erneuerbare Lebensdauer von 0, wenn die maximale erneuerbare Lebensdauer für den Realm nicht in kdc.conf festgelegt ist. Das Dienstprogramm kdb5_util setzt die maximale erneuerbare Lebensdauer für den TGS auf die gleiche Weise.
Wenn Sie eine ähnliche Fehlermeldung wie oben erhalten, ist es wahrscheinlich, dass Ihr krbtgt/realm>@<realm eine maximale erneuerbare Lebensdauer von 0 hat. Schauen wir mal:
$ kadmin -p tunde/admin kadmin: getprinc tunde/admin Hauptartikel: tunde/admin@GDD.NL Verfallsdatum: [niemals] Letzte Passwortänderung: Mo Feb 03 01:15:15 PST 2014 Ablaufdatum des Passworts: [keine] Maximale Lebensdauer des Tickets: 1 Tag 00:00:00 Maximale erneuerbare Lebensdauer: 0 Tage 00:00:00 Zuletzt geändert: Mo Feb 03 01:15:15 PST 2014 (root/admin@GDD.NL) Letzte erfolgreiche Authentifizierung: [niemals] Letzte fehlgeschlagene Authentifizierung: [niemals] Fehlgeschlagene Passwortversuche: 0 Anzahl der Tasten: 6 Schlüssel: vno 1, aes256-cts-hmac-sha1-96, kein Salz Schlüssel: vno 1, aes128-cts-hmac-sha1-96, kein Salz Schlüssel: vno 1, des3-cbc-sha1, kein Salz Schlüssel: vno 1, arcfour-hmac, ohne Salz Schlüssel: vno 1, des-hmac-sha1, kein Salz Schlüssel: vno 1, des-cbc-md5, kein Salz MKey: vno 1 Attribute: Politik: [keine]
Wie Sie sehen können, beträgt die maximale erneuerbare Lebensdauer 0 Tage.
Wo werden diese erneuerbaren Lebensdauern festgelegt?
- In der Datei /var/kerberos/krb5kdc/kdc.conf sollten Sie max_life und max_renewable_life finden. Leider ist dies bei CentOS nicht standardmäßig eingestellt.
- In der /etc/krb5.conf haben Sie ticket_lifetime und renew_lifetime, aber leider reicht es nicht aus, nur diese zu konfigurieren
Leider reicht es nicht aus, die max_life und max_renewable_life in /var/kerberos/krb5kdc/kdc.conf zu setzen und die Dienste kadmin und krb5kdc neu zu starten, da der Wert bereits in der KDB gespeichert wurde. Die schnelle Lösung wäre also, die Lebensdauer für den bestehenden Benutzer und den krbtgt-Realm zu erneuern. Wenn Sie nicht zu viele Benutzer haben, können Sie die KDB auch mit "kdb5_util create -s" neu erstellen. Bevor Sie die Datenbank neu erstellen, müssen Sie die Datei principal* aus /var/kerberos/krb5kdc löschen.
Die schnelle Lösung besteht darin, die maximale Lebensdauer für (alle) Benutzer zu ändern und krbtgt/REALM principal kann mit eingestellt werden:
$ kadmin: modprinc -maxlife 1days -maxrenewlife 7days +allow_renewable krbtgt@REALM $ kadmin: modprinc -maxlife 1days -maxrenewlife 7days +allow_renewable user@REALM
Wir müssen den krbtgt-Principal für unseren Realm aktualisieren, da das KDC keine Tickets mit einer längeren Lebensdauer als der des krbtgt-Principals ausgeben kann. In unserem Fall wäre dies:
$ kadmin: modprinc -maxlife 1days -maxrenewlife 7days +allow_renewable krbtgt/GDD.NL $ kadmin: modprinc -maxlife 1Tage -maxrenewlife 7Tage +allow_renewable tunde/admin@GDD.NL Hauptsächlich "tunde/admin@GDD.NL" geändert. $ kadmin: getprinc tunde/admin Hauptartikel: tunde/admin@GDD.NL Verfallsdatum: [niemals] Letzte Passwortänderung: Mo Feb 03 01:15:15 PST 2014 Ablaufdatum des Passworts: [keine] Maximale Lebensdauer des Tickets: 1 Tag 00:00:00 Maximale erneuerbare Lebensdauer: 7 Tage 00:00:00 Zuletzt geändert: Mi Feb 05 14:32:52 PST 2014 (tunde/admin@GDD.NL) Letzte erfolgreiche Authentifizierung: [niemals] Letzte fehlgeschlagene Authentifizierung: [niemals] Fehlgeschlagene Passwortversuche: 0 Anzahl der Tasten: 6 Schlüssel: vno 1, aes256-cts-hmac-sha1-96, kein Salz Schlüssel: vno 1, aes128-cts-hmac-sha1-96, kein Salz Schlüssel: vno 1, des3-cbc-sha1, kein Salz Schlüssel: vno 1, arcfour-hmac, ohne Salz Schlüssel: vno 1, des-hmac-sha1, kein Salz Schlüssel: vno 1, des-cbc-md5, kein Salz MKey: vno 1 Attribute: Politik: [keine]
Und die maximale erneuerbare Lebensdauer wurde auf 7 Tage geändert.
Wir haben also einen funktionierenden KDC, der Tickets ausstellen und neue Principals erstellen kann.
Wir sehen uns das nächste Mal, wenn wir besprechen, wie Sie realmübergreifendes Vertrauen konfigurieren.
Unsere Ideen
Weitere Blogs
Contact