Neuer Kerberos Stack: AD Authentifikation für Datenbank 12c

,

Wir haben in diesem Blog des öfteren die Empfehlung ausgesprochen, eine zentrale Benutzerverwaltung statt lokaler Benutzerkonten für den Zugang zu Oracle Datenbanken zu verwenden. Für Umgebungen mit bestehender Active Directory Infrastruktur bietet sich hierfür in erster Linie die AD-Anbindung über LDAP und Kerberos an.

Die Kerberos-Unterstützung ist bereits seit Version 7 der Oracle Datenbank vorhanden und gut dokumentiert. Für die Anbindung an Active Directory wird in der Regel ein Oracle LDAP-Server (OID oder OUD) verwendet, um die Oracle-spezifischen Einstellungen nicht im Active Directory Verzeichnis speichern zu müssen. Die Einrichtung dieser Komponenten mit der Datenbank 11gR2, dem Oracle Internet Directory als LDAP-Server und Microsoft Windows Server 2008 haben wir bereits in diesem Blog und in unserem Wiki beschrieben.

Für einen Kunden haben wir die zentrale Authentifikation mit Kerberos, AD, OUD und EUS gerade mit den aktuellen Software-Versionen (Datenbank 12.1, Windows Server 2012 und Java 8) aufgebaut und sind dabei auf eine Reihe von Besonderheiten gestossen, die bei der Einrichtung beachtet werden sollten. Ansonsten sieht man sich schnell mit einer Reihe von Inkompatibilitäten konfrontiert, die verhindern, das die Komponenten miteinander funktionieren. Die alten Anleitungen funktionieren nicht mehr. Das liegt vor allem daran, das Oracle den Kerberos Stack in der Datenbank 12c komplett überarbeitet oder sogar neu geschrieben hat.

Beachtet werden muß im Einzelnen:

Für Oracle Universal Directory (OUD):

  • Der Network Configuration Assistant funktioniert nicht mit Active Directory. Die LDAP-Konfiguration muss per Hand angelegt werden.
  • Das EUSM-Tool zum Einrichten der Zuordnung zwischen AD- und Datenbank-Benutzern (EUS Mappings) ist von mehreren Bugs betroffen und funktioniert nicht mehr. Abhilfe schafft:
    • Installation von Patch 20529805 im OUD (Hintergrund: Bug: 20529805 – SUPPORT FOR EUSM 12C AUTHENTICATION SCHEME IN OUD IS MISSING: Falsche DN-Syntax durch neue SASL-Implementation in  OUD)
    • Verwendung von AES-Hashes für OUD-Passwörter ist für EUS obligatorisch, um OUD aber nicht standardmässig aktiviert, daher muss das OUD „Default Passwort Storage Scheme“ verändert werden
  • Die Datenbank möchte unbedingt eine SSLv3-Verbindung zum LDAP-Server aufbauen, SSLv3 ist aber in Java 8 nach der Poodle Attacke abgeschaltet. Es gibt einen Oracle-Patch, der aber nicht öffentlich ist. Alternativ kann SSLv3 im Java des OUD-Servers wieder eingeschaltet werden

Für Kerberos:

  • Für die Datenbank 12c müssen Kerberos-Keytab-Dateien auf dem AD-Server Windows 2012 unter Umständen mit der Option „-crypto RC4-HMAC-NT“ erzeugt werden. In einigen Fällen erzeugt der AD Keytab-Dateien mit DES statt AES, wenn die RC4-HMAC-Option nicht explizit angefordert wurde. In diesen Fällen sollte die AD-Konfiguration überprüft werden. DES ist natürlich keine aktuelle Option mehr, aber RC4-HMAC eigentlich auch nicht.
  • In einigen Fällen ist es notwendig, Kerberos Pre-Authentication-Support in der SQL-Net Konfiguration einzuschalten, oder Pre-Authentication im AD auszuschalten.

Wir haben die gesamte Konfiguration in zwei Wiki-Artikeln zu jeweils EUS/OUD und Kerberos beispielhaft und mit allen Fehlerbehandlungen beschrieben.

/von

Oracle Wallets hacken

, , ,

Oracle Wallets werden benutzt, um SSL Zertifikate, die dazugehörigen Schlüssel, aber auch Klartext-Passwörter (Secure Enterprise Password Store) abzulegen. Sie werden normalerweise durch ein Wallet-Passwort geschützt, das bei jedem Öffnen oder Auslesen eingegeben werden muß.

Um auch automatisiert mit Wallets arbeiten zu können, gibt es die Auto-Login-Funktion. Wird diese aktiviert, wird eine zusätzliche Datei im Wallet erzeugt, die sogenannte Single Sign On Datei (.sso). Diese ist ebenfalls verschlüsselt, aber nicht mit einem benutzerdefinierten Passwort, sondern mit einem Standard-Passwort. Auto-Login-Wallets werden in der Regel verwendet, um eine automatisierte Anmeldung an der Datenbank durchführen zu können, ohne dass ein Passwort im Klartext in Skripten, Konfigurationsdateien oder Umgebungsvariablen abgelegt werden muss.

Damit es nicht möglich ist, ein Wallet einfach zu kopieren und von einem anderen Rechner aus zu verwenden, gibt es die Auto-Login-Local-Funktion. Wird diese für ein Wallet eingestellt, so kann das Auto Login Wallet nur auf dem Rechner verwendet werden, auf dem es erzeugt wurde.

Weiterlesen

/von

Enterprise Security mit LDAP und PKI – Varianten der zentralen Benutzerverwaltung für Oracle Datenbanken

, , ,

Einleitung

Direkte Benutzerkonten und Passwörter in der Datenbank sind eine Sicherheits-Schwachstelle, da in der Regel keine eindeutige Zuordnung von natürlichen Personen zu Benutzerkonten möglich ist, keine unternehmenseinheitliche Sicherheitsregel durchgesetzt werden kann und ausgeschiedene Mitarbeiter nicht sicher und sofort aus sämtlichen Systemen ausgeschlossen werden können.

In diesem Artikel werden die verschiedenen Möglichkeiten aufgezeigt, Enterprise Single Sign On und Public Key Infrastructure (PKI) zu nutzen, um Datenbankbenutzer zu authentifizieren. Anhand von Projekterfahrungen aus der Praxis wird die Integration der Oracle Datenbank mit LDAP-Verzeichnissen (OID, OUD) und Microsoft ActiveDirectory mit und ohne Oracle Virtual Directory (OVD) erklärt sowie die Einführung von SmartCard-basierter PKI als Alternative vorgestellt. Weiterlesen

/von

Oracle Database Standard Edition 2 nur noch mit 2 Sockets

Mit der Oracle Datenbank Version 12.1.0.2 wird es keine Standard Edition (SE) und Standard Edition One (SEO) Lizenzen mehr geben.

Stattdessen gibt es eine Standard Edition 2 (SE2), die auf Server mit zwei Sockets begrenzt ist. Bisher waren 4 Sockets in der Standard Edition möglich. Wie bisher ist auch in der SE2 die RAC Lizenz für zwei Konten enthalten. Die alten Lizenzen SE und SEO sind nur noch bis Version 12.1.0.1 nutzbar, werden aber noch 6 Monate nach 12.1.0.2 unterstützt.

Ein Standard Edition Linux RAC mit zwei Knoten und jeweils zwei Sockets war bisher die oft genutzte leistungsfähige Einstiegslizenz für eine Oracle RAC Datenbank.

Siehe auch:

Update:

/1 Kommentar/von

DMU 2.1 erschienen

,

Eine neue Version des Database Migration Assistant for Unicode (DMU) ist erschienen. In der Version 2.1 bietet das Tool nun Unterstützung bei der Unicode-Migration mit Hilfe von Golden Gate zur Minimierung der Ausfallzeit:

Oracle DMU 2.1, released in May 2015, supports a near-zero downtime migration model in conjunction with the Oracle GoldenGate replication technology. Using DMU 2.1 and GoldenGate 12.1.2.1.0 or later, you can set up a migration procedure that takes advantage of the DMU data preparation and in-place conversion capabilities while leveraging GoldenGate to replicate incremental data changes on the production system during the migration process, thereby effectively eliminating the downtime window requirement. Other new features in DMU 2.1 include migration profile support, problem data report, and transparent repository upgrade. 

Wir hatten über die Unicode-Migration und die Möglichkeit zur entkoppelten Migration auf einem parallel aufgebauten System bereits berichtet. Damals war noch das inzwischen eingestellte Streams das Mittel der Wahl für die Nachbefüllung der migrierten Datenbank.

Die Release Notes sind hier zu finden. Siehe auch Mike Dietrichs Upgrade Blog.

/von

Probleme mit dem Snapshop Management Utility

,

In einem Kundenprojekt werden Test- und Entwicklungs-Datenbanken vorbereitet, indem ein Backup der Produktion auf einem ZFS Appliance Cluster geklont wird. Auf diese Weise können schnell und ohne überflüssigen Platzverbrauch neue Datenbanken erzeugt werden.

Das Klonen eines ZFS Shares (datasets) selbst erfordert keine spezielle Vorbereitung und ist mit einem Klick in der Appliance GUI beziehungsweise einem CLI-Befehl erledigt. Soll allerdings eine ganze Datenbank geklont werden, ist etwas mehr Umsicht erforderlich, denn die Klone aller ZFS Shares, auf denen Datafiles der Datenbank liegen, müssen zusammenhängend ausgeführt werden, und es muss sichergestellt werden, das kein Share, auf dem Dateien der Datenbank liegen, vergessen wird. Außerdem müssen bei Online Backups die Archive Redo Files separat geklont werden. Und beim De-kommissionieren einer Datenbank muss geprüft werden, welche Klone aufgelöst werden können.

Um all dies zu berücksichtigen, ohne sich die Finger wund zu skripten, hat Oracle das Snapshop Management Utility (SMU) entwickelt. In der GUI lassen sich alle Datenbanken, die verwaltet werden sollen, sowie alle Storage Server, die verwendet werden, eintragen, und dann lässt sich jede Datenbank wahlweise online oder offline mit einem Befehl per Snapshot sichern und auch klonen. Es steht sowohl eine Web GUI als auch ein Command Line Interface (CLI) zur Verfügung.

Ein feine Sache, die viel eigenen Entwicklungsaufwand sparen kann, und ein Produkt mit Oracle Support. Unser Kunde plant, das SMU in das eigene Skript-Framework inkl. der lokalen Vor- und Nachbereitungen bei der Erstellung von Testumgebungen einzubauen und per CLI aufzurufen.

In der letzten SMU-Version 1.1 liefen die Tests vielversprechend, aber eine Sache fehlte noch: SMU konnte nur Datenbanken verwalten, deren Datafiles auf einem einzigen Kopf eines ZFS-Appliance-Clusters liegen. Hat man eine ZFS Cluster, wird man seine größeren Datenbanken aber selten nur auf einem Kopf belassen. Stattdessen wird man in der Regel versuchen, die Datafiles auf beide Köpfe zu verteilen, um die Bandbreite beider Köpfe zu nutzen und so die Gesamtperformance zu erhöhen.

Daher war die Freude groß, als es im README zur Version 1.2 hieß:

„Important: Previously, all of the database shares had to reside with one head of a clustered Oracle ZFS Storage system. With the Snap Management Utility 1.2 release, this is no longer a requirement. Shares can span both heads of a clustered appliance.“

Leider ist es aber nicht möglich, diese Funktionalität auch zu nutzen. Auch nur der Versuch, mit dem SMU 1.2 ein Offline-Backup einer Datenbank, deren Datendateien sich über beide Köpfe eines Clusters erstrecken, auszuführen, führt zum Fehler:

„The number of remote shares is greater than the number of shares to backup.“

Für dieses Problem haben wir im Dezember 2014 einen Oracle Service Request eröffnet, der mittlerweile zu einem Bug (20469398) geführt hat. Das bisherige Fazit ist aber leider: SMU ist für größere Installationen, die an Performance interessiert sind, nicht zu verwenden.

/von

Performance Probleme mit der Oracle ZFS Appliance

, , , , ,

Für das Data Warehouse eines unserer Projektkunden, eines großen Telekommunikationsversorgers, hat dieser eine Oracle ZFS Appliance angeschafft und per Infiniband direkt mit seinen Exadata-Produktionssystemen verbunden, um ein schnelles Datensicherungs-Medium zu gewinnen, mit dem auch unkompliziert neue Test- und Entwicklungs-Umgebungen erzeugt werden können.

Die ZFS Storage Appliance (ZA) kann, wie jedes moderne Storage-System, Snapshots erzeugen, ohne nennenswert Zeit mit dem Kopieren der Daten zu verbringen. Diese können als Klone auch zum Schreiben geöffnet werden und so als Grundlage für neue Datenbanken dienen. Waren die Entwicklungsdatenbanken bisher stark veraltet, da das Erstellen aus der Produktion viel Zeit und Speicherplatz brauchte, können diese nun spontan geklont und auch einmal auf Zuruf in den Ausgangsstand zurückgesetzt werden. Die dafür notwendigen Schritte auf der ZA werden durch ein Oracle Tool namens Snapshot Management Utility (SMU) erleichtert, der den kompletten Prozess des Klonens inklusive dem notwendigen Recovery der Datenbanken dirigiert. Die Datenbanken werden dann mittels RMAN BACKUP AS COPY als inkrementelles Backup auf den NFS-Share der ZA  gesichert, wo sie als Datafiles vorliegen und nach einem Recovery geöffnet werden können.

Zunächst wurden auf der ZFS Appliance die entsprechenden Projekte und Shares angelegt. Wir haben einen ZA Cluster verwendet, der aus zwei Köpfen besteht, die jeweils alle Platten sehen, aber nur die ihnen zugewiesenen verwenden. In jedem Kopf sind Solid State Disks (SSDs) als Schreib-Cache (ZIL) verbaut. Fällt ein Kopf aus, kann der jeweils andere seine Platten übernehmen. Dieser Vorgang dauert übrigens tatsächlich einige Zeit, hinzu kommt, dass die Caches, wie nach jedem Neustart eines Kopfes, neu gefüllt werden müssen.

Aus Performance-Gründen haben wir nur einen ZFS Pool pro Kopf eingerichtet und ihn als Mirror (und nicht als RAIDZ) konfiguriert. Laut den Vorgaben aus dem entsprechenden Oracle Whitepaper für den Datenbank-Betrieb auf der ZA wurden dann die Shares für Datafiles, Redo und Archivelog entsprechend mit den passenden Einstellungen für Logbias, Recordsize, Kompression und Primarycache konfiguriert:

Share

Logbias

Recordsize

Primarycache

Compression
DATAFILES

latency (oder throughput)

db_blocksize

all

LZJB
INDIZES

latency

db_blocksize

all

off
CONTROLFILES

latency

128k

all

LZJB

Von der in ZFS prinzipiell unterstützen Deduplikation ist übrigens für diesen Einsatzzweck stark abzuraten, da die erforderlichen Ordnungstabellen sehr viel Platz im RAM benötigen und dort mit dem Cache kollidieren.

Die SSDs für das ZIL wurden gestriped eingerichtet. Ein Fehler auf einer SSD kann nun zusammen mit einem Stromausfall und dem daraus folgenden Verlust des Hauptspeicher-Inhaltes zu Datenverlust führen, aber wählt man hier die Konfiguration als Mirror, wird im Latency-Modus die maximale Schreibrate durch den Cache durch die Bandbreite einer SSD begrenzt – zu langsam für uns.

Auf der Exadata als Quellsystem und einer X4-2 Maschine, die als Datenbankserver für die Klon-Datenbankenvorgesehen ist, werden nun die Linux-Interfaces für Infiniband eingerichtet:

Enable LACP Link Aggregation
ifcfg-ibx MTU: 65520
Connected Mode

Dann werden die ZA-Shares per dNFS eingehängt. dNFS wickelt die wesentlichen Übertragungsprozesse direkt in den Oracle-Prozessen ab und führt für den Database Writer sowie für RMAN zu erheblichen Geschwindigkeitsvorteilen. Wir haben die folgenden Linux NFS- und Mount-Options verwendet:

rw, bg, hard, nointr, rsize=1048576, wsize=1048576, tcp, vers=3,timeo=600

Die Einstellungen in /etc/sysctl.conf waren:

net.ipv4.tcp_timestamps=0
net.ipv4.tcp_sack=0
net.core.netdev_max_backlog=250000
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.rmem_default=16777216
net.core.wmem_default=16777216
net.core.optmem_max=16777216
net.ipv4.tcp_mem="16777216 16777216 16777216"
net.ipv4.tcp_rmem="4096 87380 16777216"
net.ipv4.tcp_wmem="4096 65536 16777216"

dNFS in Kombination mit Remote Direct Memory Access (RDMA) erbrachte die besten Ergebnisse. Allerdings ist RDMA nicht in allen Konfigurationen von Oracle mit dNFS unterstützt.

Insgesamt blieben die Lese- und vor allem Schreibraten, die wir von den Linux-Servern gegen die ZA bekamen, weit hinter den Erwartungen zurück.

Mit dd, CTAS aus der Datenbank oder anderen Testwerkzeuge haben wir folgende Durchsätze gemessen:

Konfiguration / Test

Durchsatz lesend

Durchsatz schreibend
Initiale Konfig, RMAN/OS

 

260 MB/s
CTAS, INSERT APPEND 

 

100 MB/s
Kernel-NFS

400 MB/s

 
dNFS

1,9 GB/s

 
Adaptive Direct IO, NOLOG, throughput bias, rs=128k, IPoIB

1,6 GB/s

 
NFS over RDMA

3,5 GB/s

400 MB/s pro Pool
Bündel-Test, Latency Mode

5,5 GB/s mit beiden Köpfen

1 GB/s
ORION Test

 

600 MB/s (ein Kopf)
_adaptive_direct_read=TRUE

 

55 MB/s (DOP=10)
Mit Patch für Bug 19339320

 

115 MB/s
_direct_io_wslots=32, parallel_execution_message_size=65536

 

315 MB/s
Schreiben mit vielen parallelen Sessions

 

1,2 GB/s
Mit allen SSDs

 

1,7 GB/s
NFS/IPoIB Durchsatz X4-2 / ZA

1,25GB/s pro Interface

 
Ziel mit 2x 4G Wirespeed

7 GB/s

4 GB/s (sustained IO)
Oracle-Angabe

(27TB/h), 17,3GB/s on ZA

 

Viele der genannten Tests beruhen auf Vorschlägen durch den Oracle Support. Wegen dieser Performance sind seit einigen Monaten zwei Oracle-SRs und ist mittlerweile ein Bug offen. In den Griff bekommen haben wir die Probleme bisher trotz Überprüfung von allen denkbaren Komponenten bis hinunter zur Verkabelung und Einsatzes mehrere Oracle-Engineers vor Ort nicht. Eventuell ist hier ein Bug in den Mellanox-Treibern oder im Linux Kernel verantwortlich?

/3 Kommentare/von

Passwörter wiederherstellen in Oracle 11g

,

In der Datenbank Version 11gR1 hat Oracle bekanntlich case-sensitive Passwörter und einen neuen Passwort-Algorithmus eingeführt. In der Datenbank werden nicht die Klartext-Passwörter, sondern nur deren Hashes abgelegt, und der Algorithmus, mit dem diese Hashes berechnet werden, war bei 10g 3DES, und ist seit 11g SHA1. Im 10g-Hashverfahren fliesst der Username als Salt in den Hash mit ein, während ab 11g ein zufälliges Salt verwendet wird. Ab 11g können die Hashes also zwischen verschiedenen Benutzern geteilt werden.

Will man das Passwort eines Benutzers sichern, um es beispielsweise in einer anderen Datenbank wieder einzuspielen, kann man sich den Hash im Data Dictionary suchen (der 10g Hash steht in SYS.USER$.PASSWORD, der 11g Hash in SYS.USER$.SPARE4), und dessen Wert mit Hilfe der „BY VALUES“ Klausel beim Anlegen eines neuen Users angeben:

CREATE USER AKIRA IDENTIFIED BY VALUES ‚DA3A39221404DD55‘; –10g hash

ALTER USER AKIRA IDENTIFIED BY VALUES ‚S:3CAFD1F43D6958FD4F67C2EDD91B3FF54913344723750F6AE48C802D37E4‘ –11g hash

Oracle erkennt hier selbstständig aus dem verwendeten Wert, ob es sich im einen 10g oder um einen 11g Hash handelt. Wird ein 11g Hash angegeben, löscht die Datenbank allerdings den 10g Hash aus dem Dictionary – und umgekehrt. Normalerweise kann man mit dieser Syntax also nur entweder einen alten oder einen neuen Hash setzen, aber nicht beide, wie man es zur vollständigen Wiederherstellung eines bisherigen Zustandes in einigen Fällen bräuchte.

In der MOS Note (Doc ID 1051962.101) hat Oracle beschrieben, wie man beide Hashes mit der „BY VALUES“ Syntax eintragen kann:

alter user TEST identified by values
‚7A0F2B316C212D67;S:F3F4BA77C0E960A5973095AF787988CBE52410CB2EA53F6AF008AD99179B‘;

Indem man beide Hashes mit einem Semikolon getrennt zusammen angibt.

Bei der Authentifikation ab 11g existiert eine erschreckende Sicherheitslücke im O5LOGON Protokoll, das es einem Angreifer ermöglicht, den Session Key und das Salt auszulesen, ohne Spuren zu hinterlassen. Um sie zu schließen, haben einige Datenbankadminstratoren die 11g-Authentifizierung ganz ausgeschaltet, indem sie den Parameter „SEC_CASE_SENSITIVE_LOGON=FALSE“ gesetzt oder alle 11g-Hashes aus dem Dictionary gelöscht haben.

In dieser Kombination kann es zu dem Effekt kommen, dass Passwörter zum Beispiel beim Aufbau einer Testumgebung mittels der BY VALUE Methode mit einem gespeicherten 11g-Hash zurückgesetzt werden, sich aber danach kein Anwender anmelden kann, weil in der Quell-Datenbank noch der 10g-Hash verwendet wurde, dieser aber durch das Neu-Setzen des 11g-Hashes überschrieben wurde, und die Anmeldung nur mit einem 11g-Hash nicht funktioniert. Hier hilft dann die oben beschriebene Methode, beide Hashes anzugeben, so man sie denn gesichert hatte.

Siehe auch zum Thema:
  • Marcels Blog Post zum Thema Hashes in 11g. Hier wird auch der verwendete Algorithmus vollständig beschrieben.
  • „Cryptographic flaws in Oracle Database authentication protocol“, Esteban Martínez Fayó
/von

Infrastructure Repository Databases

Eine RMAN-Catalog-Datenbank zum Speichern der Metadaten von RMAN-Sicherungen muss ab Version 12.1.0.2 auf einer Enterprise-Edition (EE) – Datenbank betrieben werden, weil sie nun Partitionierung verwendet.

Ansonsten erhält man beim Aktualisieren (upgrade) des Katalogs folgenden Fehler:

RMAN> upgrade catalog;error creating create_deleted_object_seq
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-00439: feature not enabled: Partitioning

Was zunächst wirkt wie eine enorme Lizenz-Verteuerung durch die Hintertür, relativiert sich durch die neu geschaffene Möglichkeit, eine sogenannte „Infrastructure Repository Database“ zu verwenden. Eine solche Datenbank, immer als Enterprise Edition zu installieren, erfordert keine zusätzliche Lizensierung, wenn sie nur mittels Oracle-Tools verwendet wird:

A separate single instance Oracle Database can be installed and used as an infrastructure repository for RMAN, Oracle Enterprise Manager Cloud Control, Automatic Workload Repository (AWR) Warehouse, Global Data Services Catalog, and Grid Infrastructure Management Repository without additional license requirements, provided that all the targets are correctly licensed.

Siehe: RMAN Catalog requires Enterprise Edition (EE) since Oracle Database 12.1.0.2

/von

DB Link Passwörter Metadaten in 11.2.0.4

, ,

Seit der Datenbank Version 11.2.0.4 funktioniert das Auslesen der Beschreibungen für Datenbank-Links über DBMS_METADATA.GET_DDL nicht mehr. Statt des Passwort Hashes wird nun eine Bind Variable angezeigt.

Die Passwörter von Datenbank-Links wurden früher in der PASSWORD-Spalte der Tabelle SYS.LINK$ im Klartext abgelegt und waren einfach lesbar. In Version 10gR1 wurde der Zugriff auf diese Tabelle aus der Rolle SELECT ANY DICTIONARY entfernt, mit 10gR2 wurde die Spalte PASSWORDX eingeführt, die nun nur noch den Hash speichert.  Mit der Sicherheit dieses Hashes steht es allerdings auch nicht zum Besten.

Während es in älteren Versionen möglich war, die komplette Link-Beschreibung inklusive der Passwort-Hashes in einer „BY VALUES“-Klausel auszulesen, sieht das Ergebnis in 11.2.0.4 so aus:

SQL> SELECT OWNER, DB_LINK, DBMS_METADATA.GET_DDL('DB_LINK',DB_LINK,OWNER) as DDL FROM DBA_DB_LINKS;
OWNER          DB_LINK      DDL
-------------- ------------ ----------------------------------------------------------
SYS            TEST_LINK    CREATE DATABASE LINK "TEST_LINK"
                            CONNECT TO "DBLINK_ACCOUNT" IDENTIFIED BY VALUES ':1'
                            USING 'TNSALIAS'

Der für den Link notwendige Hash steht allerdings immer noch in der PASSWORDX-Spalte der SYS.LINK$-Tabelle, und kann mit Hilfe von DBMS_CRYPTO recht einfach ausgelesen werden:

SQL> select 
 name, 
 userid, 
 utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)), 
  4353, (substr(passwordx,3,16)))) 
from sys.link$;

NAME       USERID         UTL_RAW.CAST_TO_VARCHAR2(DBMS_CRYPTO.DECRYPT
                          ((SUBSTR(PASSWORDX,19)),4353,(SUBSTR(PASSWORDX,3,16))))
---------- ---------      -------------------------------------------------------
TEST_LINK  DBLINK_ACCOUNT GEHEIMESPASSWORT

Oft wird eine solche Möglichkeit benötigt, um Skripte zu erstellen, die Objekte wie Links zusammensuchen, um sie zu paketieren und für Deployment bereitzustellen.

Dieser Bug in der Datenbank Version 11.2.0.4 ist bei Oracle klassifiziert unter: Bug 18461318. Der Status dieses Bus steht allerdings auf „44 – Not Feasible to fix, to Filer„, was nicht sehr vielversprechend klingt.

Update 23.11.2017: Es findet eine Verschlüsselung, keine Hash-Wert-Berechnung, des Link-Passwortes statt, und diese lässt sich brechen.

/3 Kommentare/von