1. Enterprise User Security
von der Business Rolle bis in die Datenbank
Marcel Pils
ACT IT-Consulting & Services AG
Niederkassel
Andre Lünsmann
Barmenia Versicherungen
Wuppertal
Schlüsselworte
Identity & Access Management , Enterprise User Security, Oracle Unified Directory, Microsoft Active
Directory, Oracle Identity Analytics, Oracle Virtual Directory, Oracle Internet Directory, Business
Rolle, Oracle Datenbank, Authentifizierung, Autorisierung Enterprise Manager Plug-in for OUD
Einleitung
Der Vortag bezieht sich auf ein Identity und Access Management Projekt zur Implementierung einer
zentralisierten Benutzerverwaltung für Oracle Datenbanken. Es werden die fachlichen Anforderungen
erläutert, die betrachteten Lösungsvarianten dargestellt und auf besonderer Erfahrungen während des
Proof of Concepts, der Definition der Business Rollen und der Produktivstellung eingegangen. Dieses
Manuskript bietet einen exemplarischen Einblick in die Votragsinhalte.
Identity & Access Management (IAM)
Im Kontext eines Unternehmens existieren verschiedene Personengruppen, die mit unterschiedlichen
Bedürfnissen zur Erfüllung Ihrer Aufgaben oder Anliegen mit den IT-Systemen des Unternehmens
interagieren. Zu diesem Zweck werden ihnen für einen begrenzten Zeitraum als Benutzer bestimmter
Anwendungen, Daten und IT-Ressourcen die benötigten Berechtigungen gewährt.
Die Verwaltung dieser technischen Identitäten unterliegt in Bezug auf die reale Identität einer Person
einem natürlichen Lebenszyklus. Berechtigungen werden beantragt, geplant, überprüft, genehmigt,
vergeben bzw. entzogen und in regelmäßigen Intervallen vom Management (Führungskräfte, Data
Owner) überprüft und bewertet.
In der Verantwortung des Unternehmens liegt es, die dafür benötigten Prozesse in Übereinstimmung
mit bestehenden Gesetzen und Regularien konsistent, verfügbar, verlässlich und nachvollziehbar zu
gestalten. Es wird somit eine Identity & Access Management Lösung benötigt, die zu den Geschäfts-
anforderungen des Unternehmens passt und den richtigen Personen zum richtigen Zeitpunkt hinrei-
chende Zugriffsrechte auf die erforderlichen Ressourcen erteilt.

2. Ein umfassendes Identity und Access Management sollte unter Anderem folgende Anforderungen
erfüllen:
• Alle Identitäten werden zentral verwaltet
• Keine Rechtevergabe außerhalb der zentralen Verwaltungsstelle
• Alle technischen Berechtigungen sind in Geschäftsregeln (Business Rollen) zusammengefasst
• Möglichkeit der bitemporalen Verwaltung von Identitäten, Rechte und Rollen
• Automatisierte Umsetzung (De-/Provisioning) von Berechtigungen und Identitäten
• Gewährleistung konsistenter Pflege der Identitäten, Rechte und Rollen
• Regelmäßiger Soll-Ist-Abgleich (Reconcilation) und Reporting
• Inkonsistenzen werden erkannt und behoben bzw. verhindert
• IDM Prozesse sind standardisiert, automatisiert und dokumentiert
• User Self Service zur Verwaltung von Identitäten und Berechtigungen
• Workflows zur Verwaltung der IAM relevanten Informationen (Genehmigung,
Wiedervorlage, Implementierung, De-/Aktivierung, Rückmeldung an den Antragsteller)
• Revisionssicherheit in Bezug auf Bestand, Historie und Verarbeitung der IAM Informationen
• Nachweis zur Einhaltung von Compliance Anforderungen
• Nutzung von Single Sign On Mechanismen
Es gibt - leider - nicht das eine, richtige IAM. Jedes Unternehmen hat spezifische Prozesse, seine
eigenen Historie und eine dementsprechend mehr oder weniger komplexe IT-Landschaft.
Anspruchsvolle IAM Lösungen bestehen deshalb aus unterschiedlichen Komponenten, die je nach
Bedarf eingesetzt, miteinander verzahnt und inhaltlich mit Leben gefüllt werden müssen.
Zur Realisierung einer zentralen IAM Verwaltung reicht es nicht aus, alle Identitäten in ein zentrales
LDAP Verzeichnis zu migrieren. In gewachsenen Umgebungen müssen heterogene ID-Quellsysteme
integriert und Regeln definiert werden, welche die vorhandenen technischen Identitäten auf ihre reale
Identität der bezogenen Person mappen. Für eine bitemporale Abbildung von Identitäten und
Berechtigungen werden Workflows benötigt, die nach erfolgter Genehmigung eines Antrages den
IAM Datensatz für einen gegebenen Zeitraum speichern und die darin enthaltenen Berechtigungen für
den definierten Gültigkeitszeitraum automatisiert aktivieren oder deaktivieren.
Je weiter man im Katalog der IAM Anforderungen voranschreitet, desto umfassender und komplexer
werden die damit in Verbindung stehenden Herausforderungen und Implementierungsprojekte. Mit
dem Umfang eines Projektes steigt aber auch die Gefahr, dass das angestrebte Ziel nicht erreicht wird.
Die Herausforderung bei der Durchführung von IAM Projekten liegt darin, sie in geeignete
Teilprojekte zu untergliedern und mit dem Blick auf das endgültige Ziel mit überschaubaren
Ressourcen und Aufwänden Quick Win’s zu generieren und damit Schritt für Schritt den nächsten
Reifegrad einer umfassenden IAM Lösung zu erreichen.

3. Projektanforderungen
Der Umfang des im nachfolgenden betrachteten IAM Projektes wurde bewusst begrenzt auf die
Anbindung der im Unternehmen vorhandenen Oracle Datenbanken an das als zentrale Identitätsquelle
definierte Active Directory und Auslagerung der Authentifizierung und Autorisierung personalisierter
Datenbankbenutzer in das LDAP Verzeichnis. Die technischen Datenbankbenutzer, die für den Zugriff
der Applikationen oder Schnittstellen benötigt werden, wurden außer Acht gelassen, da sich deren Zu-
griffsrechte selten verändern und das Passwort nur im Ausnahmefall geändert wird. Sie können ggf.
nachgelagert in das AD eingebunden werden, wenn mit der umgesetzten Lösung ausreichend Erfah-
rungen bestehen. Als kleinster gemeinsamer Nenner aller Benutzerwerkzeuge sollte eine passwort-
basierte Authentifizierung unterstützt werden. Zudem sollte die gewählte Lösung bei der Konsolidie-
rung bestehenden Berechtigungsstrukturen sowie der Bildung von Geschäftsregeln (Business Rollen)
unterstützen und Reports für Compliance relevante Audits generieren. Andere gewünschte IAM
Merkmale wie einem Single Sign On, einem automatischen Provisioning und Reconcilation der
Identitäten oder der Integration weitere Identitätsquellen wurden als zweitrangig bedeutsam bewertet
und damit aus dem Projekt Scope herausgenommen mit dem Auftrag auf einer nachträgliche
Erweiterung der gewählten Lösung zu achten.
Lösungsportfolio
Zur Realisierung der Projektanforderungen wurden in dem von Oracle angebotenen umfangreichen
IAM Portfolio folgende Produkte identifiziert. Einschränkend muss man dabei allerdings die
notwendigen Lizenzierungen beachten.
Abbildung 1: Zentralisiertes User-Management per EUS oder der OIM Lösung CUA4DB
Enterprise User Security ist ein Feature der Oracle Datenbank Enterprise Edition, das es der
Datenbank ermöglicht, die zur Authentifizierung und Autorisierung benötigten Informationen anstelle
des eigenen DB-Dictionary aus einem spezifischen LDAP Verzeichnis abzufragen. Zur

4. Implementierung dieses Verzeichnisdienstes bietet Oracle aufgrund der verschiedenen Zukäufe der
letzten Jahre unterschiedliche Produkte an, die alle für sich bestimmte Vor- und Nachteile aufweisen
und entweder als eigenständiges LDAP Verzeichnis oder auch als Proxy zu einem im Unternehmen
bereits bestehenden LDAP Dienst eingesetzt werden können.
Bei der Centralized User Administration for Databases handelt es sich um eine von Oracle auf Basis
des Oracle Identity Managers (OIM) erstellten Lösung. Als Krake in der Mitte führt sie auf Basis
hinterlegter Policies proaktiv Änderungen an den in den angeschlossenen Datenbanken oder Applika-
tionen hinterlegten Benutzer- und Berechtigungsinformationen durch. Die zur Authentifizierung und
Authorisierung erforderlichen Informationen verbleiben in den angeschlossenen Systemen. Der OIM
dient also als zentrale Verwaltungsinstanz, der seine Informationen mit den angeschlossenen Syste-
men (Datenbanken, Anwendungen, LDAP Verzeichnisse) entsprechend abgleicht. Dieses mächtige
Produkt bietet neben der Policy basierten Provisionierung und Reconcilation von Informationen auch
einen User Self Service, Workflows, Reports und andere Features.
Abbildung 2: Oracle Identity Analytics (OIA)
Das Oracle Identity Analytics ist ein Produkt zur Unterstützung bei der Konsolidierung und Rezertifi-
zierung bestehender Berechtigungsstrukturen. Auf Basis der importierten IAM Informationen fungiert
dieses Produkt im Sinne eines Identity Warehouses. Es verfügt über Funktionalitäten für das Mining
im Datenbestand, erstellt Vorschläge zur Bündelung von Zugriffsrechten und bietet Dashboards und
Reports für ein Auditing der vergebenen Berechtigungen.
Nach erfolgter Bewertung dieser Lösungen anhand der gegebenen Projektziele fiel die Entscheidung
auf die Durchführung von Proof of Concepts für den Einsatz der Enterprise User Security in Kombi-
nation mit Oracle Identity Analytics.
Systemarchitektur für Enterprise User Security
Zur Umsetzung der Enterprise User Security können von Oracle verschiedene Produkte verwendet
werden. Eines davon ist das Oracle Internet Directory, ursprünglich Oracle’s einziges LDAP
Verzeichnis. Das OID benötigt zur Speicherung seiner Daten eine externe Oracle Datenbank und kann
neben dem anzubindenden Active Directory auch keine weitere Identitätenquelle integrieren. Aus
diesem Grund wurde im Projekt auf den Einsatz des Oracle Virtual Directories (OVD) gesetzt. Eine

5. schlanke Lösung, die im Sinne eines Proxies Informationen aus unterschiedlichen Quellen in einen
eigenen virtuellen Verzeichnisbaum integriert.
Da das OVD aber ausschließlich externe Informationen mappt und nicht durch eigenständig
verwaltete Daten anreichern kann, müssen alle zur Bereitstellung der EUS Funktionalität benötigten
Informationen als sogenannter Oracle Context (siehe CTX in der Grafik) im Active Directory abgelegt
werden. Da die Oracle Datenbank zur Ausführung der Benutzerauthentifizierung den Oracle Passwort-
Hash mit dem im AD hinterlegten Passwort vergleicht, muss das im AD hinterlegt Benutzerpasswort
in der Oracle Hash Variante verschlüsselt hinterlegt werden und bei jedem Passwortwechsel
entsprechend aktualisiert werden.
Für die Umsetzung der EUS wurden also im Rahmen des POC folgende drei Änderungen am Active
Directory angefragt:
• Schemaerweiterung für die Oracle Context Informationen
• Schemaerweiterung für ein zusätzlichen Passwort Attribut am Benutzerdatensatz
• Installation einer Passwortfilter DLL auf jedem AD Controller
Dies hat aufgrund der Bedeutung eines unternehmenszentralen Verzeichnisdienstes und den von der
AD Administration geäußerten Bedenken für eine erhebliche Projektverzögerung geführt. Die Liste
der Vorbehalte reichte von Support Problemen mangels Zertifizierung von Schemaerweiterung und
Passwortfilter über Befürchtungen der Kollision mit anderen Schemaerweiterungen bis hin zu
Betriebsfragen der Integration in den Windows Dateischutz und DLL Versionskontrolle.
Abbildung 3: EUS Architekturvarianten

6. Die einzige Alternative, die umfangreiche Schemaerweiterung für den Oracle Context aus dem AD
auszulagern, war zu diesem Zeitpunkt der Aufbau einer eigenen OID Instanz ausschließlich für diesen
Zweck. Ein Variante, die die zu betreibende Infrastruktur insbesondere unter Berücksichtigung von
High Availability Anforderungen erheblich vergrößern würde.
Als dann jedoch in das OUD mit der Version 11.1.2.1 die EUS Unterstützung implementiert wurde,
stand eine neue und schlanke Variante zur Verfügung, die Proxy- und Directory Server Funktionalitä-
ten in einem kombiniert und aufgrund der Speicherung lokaler DataStores in Berkeley DB Files keine
externe Datenbank benötigt. Mit dieser Architektur konnte der größte Schmerz der AD Administration
beseitigt und ein neuer POC erfolgreich durchgeführt werden.
Abbildung von Business Rollen
Sollen die Benutzerrechte in Eigenverantwortung der Fachbereiche durch die jeweilige Führungskraft
oder den Data Owner gepflegt werden, müssen für alle Nutzungsfälle die benötigten technischen
Rechte (Resource Rolle) in verständliche, fachlich abstrahierte Business Rollen gekapselt werde. Folgt
man dabei einer intuitiven Vorgehensweise, sind folgende Merkmale denkbar:
• Verschachtelungen und Verzweigungen
• Mehrfachzuordnungen
• Zuweisung von einzelnen Benutzern oder Organisationeinheiten
Die Definition dieser Mappings sollte zusammen mit den Resource Rollen zentral an einer Stelle
erfolgen. Das Active Directory ist dafür bestens geeignet, da es alle aufgezählten Merkmale
unterstützt.
Abbildung 4: Intuitive Abbildung von Business Rollen
Die Herausforderung besteht jedoch darin, dass eine Vererbung von Benutzerzuweisungen über
mehrere AD-Gruppen von der Enterprise User Security nicht unterstützt wird und ein Enhancement
der Funktionalitäten aktuell nicht geplant ist. Der jeweilige AD-User muss entweder direkt im OUD
der jeweiligen Enterprise Role zugeordnet werden oder direkt Mitglied der AD-Gruppe sein, die im
OUD der jeweiligen Enterprise Role zugeordnet wird.

7. Man muss also die Vor- und Nachteile abwägen und entscheiden, wo man das Mapping von Business
Rollen auf technische Datenbankrechte/Rollen durchführt.
• Vorgelagert zum AD durch Abbildung im User Self Service was jedoch zu Konflikten bei
Mehrfachzuordnungen führen kann.
• Nachgelagert im OUD beim Mapping auf entsprechende Globale Datenbank Rollen oder
• am Ende der Kette durch Zuweisung der Global Roles auf die Local Roles der Datenbank.
Im Projekt hat man sich für die letzte Variante entschieden also dem 1 zu 1 Durchschleifen der
definierten Business Rollen bis auf die Globalen Datenbankrollen. Hauptgrund ist, dass man den
Nutzern des User Self Services eine einfache, möglichst globale Rechtevergabe ermöglichen möchte.
Das erfordert zwangsläufig, dass die Differenzierung erst später auf dem Weg zum AD stattfindet.
Monitoring der Infrastruktur
Für das Monitoring des Oracle Unified Directories bietet Oracle ein eigenes Plugin für den Enterprise
Manager Cloud Control an, dessen kostenpflichtige Nutzung mit der Lizenzierung des „Management
Pack Plus for Identity Management“ abgedeckt wird. Die Installation des Plug-in erfolgt über ein einf-
aches Download und Deployment im Plug-ins Dialog des Enterprise Managers 12c. Beim Deployment
für das OUD Server Montoring Target wird ausgewählt, ob es sich dabei um einen Proxy Server,
einen Directory Server oder ein Replication Gateway handelt. Da der OUD in unserem Fall als Proxy
Instanz aufgesetzt ist, wählt man hier den Proxy Server aus. Nach der Verteilung des Agenten auf den
OUD Host sollte man einige Minuten warten bevor man mit dem Discovery der OUD Instanz
fortfährt. Auf diese Weise wird gewährleistet, dass alle Metriken beim Agenten ankommen, bevor
dieser genutzt wird. Wer das berücksichtigt, hat innerhalb von 15 Minuten eine funktionierende OUD
Proxy Überwachung im Enterprise Manager implementiert.
Abbildung 5: Enterprise Manager Plug-in for Oracle Unified Directory

8. Mit 572 Metriken in 33 Gruppen bietet das OUD Proxy Plug-in eine Menge Informationen bezüglich
Health State, Ressourcenverbrauch und Performance der Instanz wie auch der angebundenen Remote
Verzeichnisdienste (in diesem Fall 3 AD Controller). Bei genauer Betrachtung fällt jedoch auf, dass
lokale OUD LDAP Stores wie der für den Oracle Context vom Proxy Plug-in nicht überwacht werden.
Ein naheliegender Workaround wäre ein zusätzliches Monitoring Target für die gleiche OUD Instanz
mit den Eigenschaften eines Directory Server zu discovern. Ein solcher Versuch schlägt in der aktuel-
len ersten Version des Plug-ins aber fehl. Der Agent erkennt, dass die OUD-Instanz als Proxy konfigu-
riert ist und verteilt deshalb die benötigten Directory Server Metriken nicht. Nahezu alle Anzeigen des
resultierenden OUD Directory Server Targets bleiben leer.
Es wurde beim Support ein Enhancement Request erstellt, der für das nächsten Release geplant ist. Ein
konkretes Release Datum ist derzeit aber nicht bekannt.
Bug 18717725 : EM12C OUD PLUGIN - NEEDS TO MONITOR THE LOCAL LDAP DATA STORE
Ein vollständiges Monitoring des OUD ist mit dem Enterprise Manager Plug-in derzeit nicht möglich.
Zumindest für die lokalen LDAP Stores des OUD und deren Replizierung müssen eigene Überwach-
ungsskripte erstellt werden.
Indentifizierung des Enterprise Users im Session Kontext
Eine Authentifizierung des Login Users gegen das Active Directory erfolgt dann, wenn die Datenbank
für EUS konfiguriert ist und der Login User nicht als lokaler (gewöhnlicher) Datenbankbenutzer exis-
tiert. Wird für diesen Enterprise User seitens der DBAs kein eigener „private Schema User“ erstellt,
taucht er in der Datenbank als der eine „Shared Schema User“ auf. Die Information über den eigent-
lichen AD-User geht dem DBA in den v$session Informationen verloren. Da zur Reduzierung der
administrativen Aufwände die Nutzung eines gemeinsamen Shared Schema Users angeraten ist, muss
man diese Kontext-Information mittels Logon Trigger in die v$session Informationen übernehmen.
CREATE OR REPLACE TRIGGER EUS_LOGON_TRIGGER
AFTER LOGON ON DATABASE
declare
l_client_info varchar2(4000);
l_ad_user varchar2(4000);
BEGIN
DBMS_APPLICATION_INFO.READ_CLIENT_INFO(l_client_info);
if length(l_client_info) > 0 then
l_client_info := ', '||l_client_info;
end if;
l_ad_user := sys_context('userenv','external_name');
l_ad_user :=
regexp_substr(sys_context('userenv','external_name'),'[^.*(cn=)][^(,)]*');
DBMS_APPLICATION_INFO.SET_CLIENT_INFO(l_ad_user||l_client_info);
End;

9. Auditierung von Enterprise Usern
Da der Enterprise User als Shared Schema User in der Datenbank agiert, stellt sich die Frage, ob die
Information über den AD-User auch beim Auditing verloren geht. Der folgende Testfall zeigt, dass
das nicht der Fall ist. Es muss lediglich über den Audit Session Key der zugehörige Login Datensatz
aufgerufen werden. Dieser enthält die benötigten Informationen.
SQL> select sid, username, schemaname, client_info
from v$session
where username in
('GLOBAL_TEST_USER', 'LOCAL_TEST_USER') order by 1
# Enterprise User Connect
SQL> conn "240531"
Enter password:
Connected.
SQL> show user
USER is "GLOBAL_TEST_USER"
# Activate DML Auditing
SQL> conn / as sysdba
SQL> audit insert table, delete table by "GLOBAL_TEST_USER" by access;
Audit succeeded.
# Execute DML
SQL> conn "240531"
SQL> insert into table1 values (1,'eins');
1 row created.
SQL> delete from table1;
1 row deleted.

10. Verweise
• Enterprise User Security Dokumentation
http://docs.oracle.com/cd/E11882_01/network.112/e10744/toc.htm
• Oracle Unified Directory Dokumentation
http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html
• Enterprise Manager Plug-in for OUD Dokumentation
http://docs.oracle.com/cd/E24628_01/nav/plugins.htm
• Directory Services Integration with Database Enterprise User Security
http://www.oracle.com/technetwork/database/security/dirsrv-eus-integration-133371.pdf
• MOS 1376365.1: MASTER NOTE FOR ENTERPRISE USER SECURITY
• MOS 18717725 – RFE BUG: EM12C OUD PLUGIN - NEEDS TO MONITOR THE
LOCAL LDAP DATA STORE
# Check Audit Entries
SQL> select a.sessionid, a.entryid, aa.action, aa.name, a.userid,
a.comment$text
from sys.audit_actions aa, sys.aud$ a
where a.action# = aa.action
and a.userid='GLOBAL_TEST_USER'
order by sessionid desc,entryid desc;

11. Kontaktadresse:
Marcel Pils
ACT IT-Consulting & Services AG
Rudolf-Diesel-Straße, 18
D-53859 Niederkassel
Telefon: +49 (0) 228-97125 0
Fax: +49 (0) 228-97125 40
Mobil: +49 (0) 173-730 8854
E-Mail marcel.pils@actgruppe.de
Internet: www.actgruppe.de
Kontaktadresse:
Andre Lünsmann
Barmenia Versicherungen
Barmenia-Alle, 1
D-42119 Wuppertal
Telefon: +49 (0) 202-438 2662
Fax: +49 (0) 202-438 032662
E-Mail andre.luensmann@barmenia.de
Internet: www.barmenia.de