Kerberos wurde als Authentisierungssystem vom MIT Ende der 1970ziger Jahre entwickelt und erst mit der Version 4 (Ende der 1980ziger) außerhalb der MIT genutzt. Heute ist Kerberos in der Version 5 als sicherer Authentisierungsstandard weit verbreitet. Der Kerberos-Authentisierungsdienst beteiligt drei Komponenten, den Client, der einen Server anfragt, den Server selber und den Kerberos Server. Hierbei authentisieren sich alle Komponenten gegenseitig, um so Man-in-the-Middle-Attacken zu verhindern. Darüberhinaus werden durch Kerberos auch insbesondere Angriffe durch passives Sniffing, Spoofing, Wörterbuch- und Replay-Attacken erschwert bzw. unterbunden. Bei dem Authentisierungsprozess werden sogenannte „Tickets (Ticket Granting Ticket TGT)“ genutzt. Bei einem Windows-Login an eine Windows-Domain wird das Kerberos Ticket sofort nach der Anmeldung erzeugt. Mit diesem Ticket kann der Client dann Berechtigungen für weitere Dienste beim Kerberos Server anfordern, ohne sich erneut anmelden zu müssen. Kerberos überträgt keine Kennwörter und ermöglichtüber den Ticketaustausch das bereits angesprochene Single-Sign-on. Während der Authentisierung nutzt Kerberos schnelle symmetrische Schlüssel (DES, 3DES, AES 256, etc.). Typische Anwendungen von Kerberos sind Benutzerauthentisierungen z.B. unter Windows 2000/2003/2008, SSH, Routern u.a..
Abbildung 1: Kommunikationsmodell der Kerberos Authentisierung
Um das sichere Authentisierungsverfahren Kerberos nutzen zu können, müssen Dienste, wie ein Datenbankdienst, mit den Kerberos-Tickets umgehen können. Die Oracle Datenbank beinhaltet bereits seit der Version 7 einen Kerberos Authentication Adapter, der in der damaligen Advanced Networking Option ausgeliefert wurde. Heute ist der Keberos Authentication Adapter Bestandteil der Advanced Security Option. Natürlich findet Kerberos auch in anderen Oracle Lösungen Anwendung wie Oracle Identity Manager, Oracle WebLogic, Oracle HTTP Server u.a..
Vorbereitung der Oracle Datenbank zur Kerberos Nutzung
Folgende
Komponenten kommen zum Einsatz: Eine Oracle Datenbank Enterprise Edition 10g R2
mit Advanced Security Option auf einem Linux Rechner und ein Microsoft Windows
Server 2003 mit Active Directory als Kerberos Server.
Abbildung 2: Demo-Aufbau
Eine Datenbank für eine Kerberos-Authentisierung vorzubereiten, ist sehr einfach. Es sind zwei wesentliche Schritte auszuführen. Als erstes muß die Datenbank dem Kerberos Server (also dem Active Directory lt. Abbildung 2) bekannt gemacht werden. Im zweiten Schritt muss die Datenbank so konfiguriert werden, dass diese die Kerberos Authentisierung mit dem Kerberos Server verwendet.
1.Datenbank dem Kerberos Server bekannt machen
Damit der
Kerberos Server die Datenbank authentisieren kann, muss die Datenbank einen Benutzer-Account
(kein Computer-Account) im Active Directory besitzen. In der Abbildung 3 wird
ein Beispiel für den Server „asterix“ dargestellt, auf dem die Oracle Datenbank
läuft:
Abbildung 3: Datenbank-Eintrag im Active Directory
Als nächstes wird auf dem Active Directory Server eine Datenbank Kerberos Keytab Datei mit einem eindeutigen Service Principal Name SPN (gemapped auf den so eben erstellten Benutzer Account) erstellt, die dann vom Datenbankserver für die Authentisierung verwendet wird. Der SPN wird für die Client-Dienst-Anfrage verwendet. Fragt der Client ein Service Ticket für einen Dienst beim Kerberos Server an, so muss der Client angeben für welchen Service Principal Name er dieses Ticket haben will. Für die Erstellung der Keytab Datei wird das Windows Support Tool KTPASS (auf der MS Windows Server CD zu finden) verwendet.
Abbildung 4: Erstellung der Keytab mit KTPASS
Entsprechend Abbildung 4 lautet der SPN „ORACLE“. Der verwendete Verschlüsselungsalgorithmus ist „DES-CBC-CRC“ und die Keytab Datei ist „asterix.keytab“. Besonders wichtig bei der Ausführung dieses KTPASS Befehls ist die Klein/Grossschreibung, bitte achten Sie darauf.
2. Datenbank für die Kerberos
Authentisierung konfigurieren
Die erstellte
Keytab Datei „asterix.keytab“ wird auf den Datenbank Server, typischerweise
unter dem Pfad \etc\asterix.keytab, kopiert. Nun muss der Datenbank-Server so
eingestellt werden, damit er weiß, wie er den Kerberosserver anzufragen hat.
Hierfür müssen die Parameter in den Konfigurtationsdateien krb5.conf und
krb5.realms eingestellt werden.
Abbildung 5: Beispiel krb5.conf Einstellungen
Abbildung 6: Beispiel krb.realms Einstellungen
Bitte achten Sie auch darauf, dass die Namensauflösung (DNS) funktioniert. Nehmen Sie hierfür den Kerberos-Server mit Hostnamen und IP in die HOSTS Datei auf.
Damit der Datenbank Server die eingestellten Kerberos Parameter verwendet, muss zu allerletzt die sqlnet.ora angepaßt werden. Man kann diese Datei direkt verändern oder die Veränderungen mit dem Oracle Net Manager durchführen.
Abbildung 7: Kerberos Authentisierung mit dem Net Manager einstellen (Methode)
Abbildung 8: Kerberos Authentisierung mit dem Net Manager einstellen (Parameter)
Abbildung 9: Einstellungen in der sqlnet.ora
Somit ist die Datenbank für die Kommunikation mit dem Kerberosserver vorbereitet.
Kerberos Authentisierung mit der Oracle Datenbank testen
Für den ersten
Test auf Funktionstüchtigkeit wird ein neuer Benutzer im Active Directory und in
der Oracle Datenbank erstellt. Die Benutzernamen müssen identisch sein. Der
Datenbankbenutzer wird als externally angelegt, da wir eine externe
Authentisierung nutzen möchten. Zusätzlich bekommt der DB-Benutzer noch einige
DB-Berechtigungen:
CREATE USER “SAHOVIC@DE.ORACLE.COM” IDENTIFIED EXTERNALLY;
GRANT CREATE SESSION, RESOURCE TO “SAHOVIC@DE.ORACLE.COM”;
Dieser neue AD-Benutzer meldet sich an die Windows-Domäne an, bezieht ein Kerberos TGT Ticket und authentisiert sich damit (ohne erneute Anmeldung) an die Datenbank.
Für den ersten Test braucht man keinen Windows Login durchführen, sondern kann das TGT Ticket manuell beziehen. Mit dem Oracle Tool okinit wird ein TGT Ticket für den Benutzer SAHOVIC vom Kerberos Server abgeholt. Das Kommando wird auf dem Datenbank Server ausgeführt.
Abbildung 10: TGT Ticket mit okinit beziehen
Das TGT Ticket entspricht der Funktion eines SSO Cookies, das als Grundlage für die Erstellung von Session Tickets dient. Das TGT Ticket wird in der Credential Cache Datei abgelegt. Den Inhalt der Credential Cache Datei kann mit dem Tool„oklist“ ausgelesen werden. Das Kerberos TGT Ticket ist vorhanden und nun kann eine externe Authentisierung zur Datenbank durchgeführt werden. Der DB-Benutzer wird bei einem Datenbank-Login an den Kerberos Server weitergeleitet, der dann das Session Ticket für die Datenbank zurückliefert. Das bereits erstellte TGT Ticket dient als Benutzerinformation beim Kerberos Server für die Session Ticket Erstellung.
Die Anmeldung an die Datenbank erfolgt ohne Username/Password, da wir alle Informationen bereits über die Kerberos Tickets bezogen haben.
Abbildung 11: Kerberos Authentisierung an die Datenbank
In der Abbildung 11 sieht man eine erfolgreiche Kerberos Authentisierung gegen die Datenbank und trotz nicht angegebener Benutzerinformation weiß die Datenbank, dass der Benutzer SAHOVIC@DE.ORACLE.COM angemeldet ist. Selbstverständlich ist dieser erste Test keine charmante und transparente Lösung für den Endbenutzer.
Kerberos im Zusammenspiel zwischen Oracle Datenbank, MS Windows Server mit Active Directory und einem MS Windows XP Client
Ein typischer Arbeitstag eines Endbenutzers beginnt in der Regel mit dem Starten seines Rechners und der Anmeldung an eine Windows Domäne. Bei diesem Anmeldeprozess kommt bereits eine Kerberos Authentisierung zum Einsatz. Nach der erfolgreichen Anmeldung des Benutzers speichert der Windows-Client-Rechner sein eben erlangtes Kerberos TGT Ticket in verschlüsselter Form in dem Windows Credential Cache. Dieses TGT Ticket kann man wie bereits erwähnt für die Anmeldung an die Oracle Datenbank nutzen und einen Kerberos-basierten single-Sign-on realisieren.
Windows XP konfigurieren für die Kerberos Anmeldung an die Oracle Datenbank
Der Windows Client (hier XP oder Win2000 Workstation, Vista, Windows7) muss eine Oracle Client Installation aufweisen. Als Minimum ist der Oracle InstantClient zu installieren. In der Oracle Client Installation befindet sich eine sqlnet.ora Datei ($ORACLE_HOME/network/admin), die entsprechend für eine Kerberos-Nutzung anzupassen ist:
Abbildung 12: Client sqlnet.ora anpassen
Die Client-seitige sqlnet.ora unterscheidet sich nur minimal von sqlnet.ora auf dem Datenbank-Server. Der Parameter SQLNET.KERBEROS5_CC_NAME mit dem Wert des Credential Cache „OSMSFT://“ besagt, hole die Credential Informationen aus dem Windows Credential Cache. Zusätzlich muss die krb5.conf Datei vom Datenbank-Server auf den Windows Client kopiert und in krb5.ini Datei umbenannt werden. Zu guter Letzt wird die Client-seitige tnsnames.ora Datei mit den Angaben des Datenbank-Servers angepaßt.
Funktionsweise zwischen dem Kerberos Server, der Oracle Datenbank und dem Windows Client überprüfen
Es wurden alle notwendigen Einstellungen am Client vorgenommen, so dass eine Kerberos-Anmeldung an die Datenbank durchgeführt werden kann. Hierzu wird Oracle SQL*Plus verwendet.
Abbildung 13: Login mit SQL*Plus
Die Kerberos Anmeldung ohne Kennwort Eingabe funktioniert. Sicherlich arbeiten nicht alle mit SQL*Plus, sondern verwenden auch andere DB Applikationen wie z.B. Oracle SQL Developer.
Kerberos Datenbank Anmeldung mit Oracle SQL Developer
Der
Oracle SQL Developer unterstützt die Kerberos Authentisierung seit der Version
1.5.3. Eine Kerberos Authentisierung muss auch am SQL Developer eingestellt
werden. Hierfür muss bei entsprechenden DB Connection das Häkchen für Kerberos
gesetzt werden:
Abbildung 14: DB Connection Einstellung beim SQL Developer
Zu erwähnen ist noch, dass der SQL Developer eine OCI Connection nutzen muss. Diese stellt man in den Preferences ein.
Abbildung 15: OCI im SQL Developer einstellen
Thin und Thick JDBC
Oracle SQL Developer unterstützt auch eine Kerberos-Authentisierung über JDBC Thin Connection. Dies wird jedoch erst ab einer Datenbank Version 11gR1 unterstützt. In der Abbildung 15 sind für die Thin Konfiguration zwei Eingabefelder (im Bereich Kerberos Thin Config) vorgesehen. Hier wird hinterlegt, wo sich das Kerberos TGT Ticket und der Kerberos Server befinden. Die DB Connection Details wiederum bleiben wie bei einer Kerberos OCI Connection absolut gleich. Um die Funktionstüchtigkeit einer Kerberos DB Anmeldung über eine JDBC Thin Connection zu überprüfen, müsste man vorher manuell ein Kerberos TGT Ticket mit okinit Tool beziehen. Das TGT Ticket ist dann per default 10 Stunden gültig. Das heißt, einmal beziehen und genießen.
Kerberos Datenbank Anmeldung mit Client/Server Java Applikationen
Die
Befähigung von Client/Server Java Applikationen, eine Kerberos Authentisierung
zu verwenden, ist wiederum abhängig vom benutzten JDBC Treiber. Kann der JDBC Thick
Treiber verwendet werden, also eine OCI Connection zur Datenbank aufgebaut
werden, dann sieht der Connect String wie folgt aus (ohne Benutzer
Informationen):
jdbc:oracle:oci:@10gee92
Bei einer JDBC Thin Connection hingegen müssen die vier Kerberosparameter der sqlnet.ora Einstellung (siehe Abbildung 12) programmtechnisch übergeben werden. Die Parameter haben folgende Bedeutung:
Ort Kerberos Konfigurationsdatei (krb5.ini)
Authentisierungsart
Gegenseitige Authentisierung aktivieren
Pfad der Credential Cache Datei
Der Code für das Setzen der Parameter in Java würde wie folgt aussehen:
Abbildung 16: Einstellung für JDBC Thin im Java Code
Hiermit erfolgt die Kerberos Anmeldung ebenso erfolgreich wie mit einer OCI Connection.
Zusammengefasst
ergibt sich eine erhöhte Sicherheit bei der Nutzung von Kerberos und eine
vereinfachte Administration. Der Nachteil der immer noch bestehenden redundanten
Benutzer (im Active Directory und Datenbank) kann man mit dem Datenbank Feature
Enterprise User Security (alle Benutzer bleiben im Active Directory) umgehen.
D.h. ein sichere und hoch-vereinfachte Benutzerverwaltung inklusive starker
Authentisierung kann mit Kerberos und Enterprise User Security umgesetzt
werden.
Abschliessend sind drei wichtige Benefits zu nennen:
- Kerberos Authentisierung gehört in den Bereich der starken Authentisierungen. Demzufolge erreicht man eine höhere Sicherheit im Betrieb der Datenbanken und Datenbank Applikationen.
- Zentrale Kennwort Verwaltung für alle Datenbankbenutzer durch den Kerberos Server und sein Benutzerrepository. Durch die zentrale Kennwort Verwaltung definiert man an einer zentralen Stelle die Kennwort-Policies, die für alle beteiligten Datenbanken gültig sind.
- Basierend auf dem Kerberos Single-Sign-On Prinzip, entfallen erneute Anmeldungen an den „Kerberos-enabled“ Datenbanken/Datenbank-Applikationen. Es ist kein neues Single-Sign-On Konstrukt, sondern man nutzt das vorhandene Single-Sign-On Konstrukt (für Windows typischerweise auf MS Active Directory basierend) und lässt die Datanbanken an diesem (Kerberos) Single-Sign-On Konstrukt als Dienst/Service partizipieren.