8. Juni 2015

Danke für die tolle Zusammenarbeit im vergangenen Oracle-Geschäftsjahr

Liebe Kunden, Partner und Kollegen,

Ende Mai ist das Oracle Geschäftsjahr zu Ende gegangen.
Ich bedanke mich bei Ihnen/Euch für die tolle Zusammenarbeit und freue mich schon jetzt auf die neuen Projekte in diesem Geschäftsjahr.



Liebe Grüße
Carsten Mützlitz

9. April 2015

Eine geniale Lösung für das Benutzermanagement - in nur einer Minute implementiert

Typischerweise haben viele Kunden bereits eine zentrale Benutzerverwaltung am Start. Im Allgemeinen ist das ein MS Active Directory.
MS AD: Eindeutige Identitäten
Nehmen wir z.B. den Benutzer "Suvad Sahovic". Dieser Benutzer existiert im MS AD und hat verschiedene Rollen im Unternehmen inne. Er ist DBA, Entwickler und Anwender einer HR Anwendung.
Im Sinne seiner Tätigkeit benötigt dieser Benutzer verschiedene Accounts und Tools, um seine Tätigkeiten auszuführen. Das bedeutet letztendlich
  • SSH Zugang, um auf die Systeme zu kommen
  • Entwickler Zugang, um z.B. mit dem SQL Developer zu arbeiten
  • Zugang als DBA, um eben diese Tätigkeit auzuüben
  • Zugang zur HR Anwendung als Endbenutzer
Es wäre schön, wenn der "Suvad" seine Tätigkeiten immer entsprechend des Zwecks durchführen kann, d.h. sein DBA Recht sollte er z.B. nicht als Entwickler oder HR-Endanwender ausführen.

Die Idee ist nun den Benutzer aus dem MS AD zu verwenden und damit einen Zugang einzustellen, mit dem alle Tätigkeiten ausgeführt werden können.

SSH Zugriff mit dem Account aus dem MS AD via Kerberos
Zugang ins Entwicklungstool ohne Username und PW mittels Kerberos

Zugang ins SQL Plus mittels Kerberos
  
Zugang als DBA
Zugang als HR Anwender
Ein Anwender arbeitet mit seinem Account aus dem MS AD automatisch zweckgetrennt in den Systemen und Anwendungen. Es existiert nur eine Benutzerverwaltung mit der man sehr viele Systeme und Anwendungen anbinden kann. Das reduziert die Komplexität und erhöht die Sicherheit.

Was bringt so eine Lösung für eine Datenbank-Umgebung?

  • Starke Authentifizierung (Kerberos) in der Oracle Datenbank Welt, die bereits in Ihrem Unternehmen weitgehend genutzt wird.
  • Zentralisierte Benutzerauthentifizierung durch bestehende Infrastruktur (Oracle Datenbank und MS Active Directory)
  • Zentralisiertes Password Management. Erzwingung der Passwortrichtlinien durch Einsatz der bestehenden Infrastruktur (MS Active Directory).
  • Zwecktrennung. Account Management und Applikations/DB Management wird voneinander getrennt.
  • Reduzierung der Komplexität. Durch Zentralisierung und Auslagerung werden viele Betriebsaufgaben überflüssig.
  • Reduzierung vieler administrativen DB Aufgaben. Bei den DBAs entfallen viele Aufgaben z.B. im Bereich User Management, Password Mgmt, etc.,die nicht anderweitig ausgelagert werden, sondern die einfach entfallen. Es wird die bestehende Infrastruktur dafür verwendet.
  • Keine User Repository Redundanzen. Es wird Ihr bestehendes User Repository (typischerweise MS Active Directory) als führendes Benutzer Verzeichnisdienst verwendet.
  • Einhaltung und Erzwingung der unternehmerischen Sicherheitsrichtlinien. Vorhandene Inkonsequenzen, falsche oder falsche implementierte Security Konzepte, verursacht durch menschliches Versagen, werden ausgeschlossen.
  • Einhaltung und Erzwingung der gesetzlichen Vorgaben.
  • Single Sign On. Es wird ein bestehendes unternehmensweites Single Sign On (basierend auf Kerberos) nachhaltig genutzt.
  • Erzwingung von Least Privilege Konzept. Durchgehendes Konzept, welches nicht umgegangen werden kann.
  • Eindeutigkeit und bessere Nachvollziehbarkeit.
  • Eindeutig mehr Transparenz.
  • Nutzung der bestehender Infrastruktur.
Wie implementiert so eine Lösung?

Wie man so etwas in ca. 1 Minute implementiert, zeigen wir auf dem Oracle Direct Security Day am 16.4.2015. Diese Veranstaltung wird online und live ausgestrahlt. Für eine Teilnahme muss man sich registrieren: http://bit.ly/ODSD2015

Wir freuen uns auf Sie, melden Sie sich noch heute an.

23. März 2015

Eine bewußte Entscheidung für die IT Sicherheit - Der Security Smoke Test

Der beste Schutz von IT Anwendungen ist Wissen. Nur dann werden bewußte Entscheidungen für die IT Sicherheit getroffen. Eine bewußte Entscheidung setzt immer voraus, dass der Entscheider der eine Entscheidung trifft, sich mit dem Thema intensiv auseinder gesetzt hat. Udd so muss es sein.

Bewusste Einscheidungen im Betrieb einer DB sollten immer folgende Dinge beinhalten:
  1. OS Härtung
    z.B. nach STIGs Stigs: openScap ist für Windows und UNix-Betriebssysteme verfügbar und Oracle liefert hier sogenannte Security Technical Implementation Guides.
    Auch die Dokumentation hält hier entsprechende Empfehlungen bereit:
    Security Guide for OL6
    Oracle Secure Configuration Initiave
  2.  DB Härtung
    z.B. nach STIGS und eigener definierter Standard. Natürlich auch unter Betrachtung des Oracle Security DB Guide
  3.  Prüfung der Anwendung und Anwendungssetup
  4. Zugriffskontrolle entsprechend least Privilege
  5. und eben all Ihre bewußten Entscheidungen
  6. ...
Der Security Smoke Test stellt eine schnelle Möglichkeit zur Verfügung, Systeme auf Sicherheit zu überprüfen.

Ein Smoketest ist eine Art Probelauf z.B. vor der Produktivsetzung nach einer Reparatur oder einem Releasewechsel. Fokussiert der Smoketest auf Security, dann ist es eben ein Probelauf für die Security.

In einem 3-Tages Schnell-Hack habe ich eine bewusste Entscheidung in einen Security Smoketest für Datenbanken gegossen. Und das ist dabei rausgekommen:
Mein Security Smoketest behandelt insgesamt 7 Bereiche, die er automtisiert gegen ein System testet:
  1. System Scan:
    Port Scanning, SID Scanning, Bruteforce Attacke für Standard Acounts
    Also ein typische Attacke auf DB Systeme wird durchgeführt
  2. DB Parameter
    Grobe Prüfung der sicherheitsrelevanten init.ora Parameter
  3. PW Management
    Default PW in der DB, User im PW File, PW Versionen
  4. Role Management
    Anwendungsbezogene Rollen, Rollen Ersteller (Zwecktrennung), Rolen KOmplexität, Standard Rollen an User (CONNECT, RESOURCE), Deadly Roles an User
  5. Privilegien
    Power-Privilegien, Network Packages Privilegien, Mögliche Privileg Eskalationen in Apps-Schematas, Privileg Eskalation (alle Benutzer)
  6. User Management
    Benutzergruppen, Profile, Security Attribute der Profile
  7. Audit Policy
    Fehlende Einstellungen lt. Oracle DB Security Guide
Alle Überprüfungen (17) werden mit einem Score versehen und dokumentiert. Der Gesamtscore stellt das zu erwartende Risiko einer Bedrohung dar. Je höher der Wert, desto höher die Bedrohung.

Scoring der Security nach Durchführung des Security Smoktests
Die Trendanalyse stellt den Gesamtscore der Auswertung entsprechend der Ausführungszeit gegenüber.
Trendanalyse entsprechend Score

Innerhalb der 7 Untersuchungsbereiche werden die Ergebnisse des Test sehr detailliert dargestellt. Die wichtigen Aussagen sind farblich markiert, wobei "geld" als Warning zu verstehen ist (Scorewert=5) und "rot" ist eine starke Bedrohung (Scorewert=20).
Detaillierte Darstellung des Systemscans
Betrachten man z.B. das Usermanagement innerhalb des Security Smoketest dann werden folgende Bereiche untersucht:
  • Benutzergruppen
    Hier kann man viele interessante Dinge ableiten. Welche Benutzergruppen existieren? Gibt es eine Verletzung der Zwecktrennung (z.B. Anwendungsuser ist Admin)? Wer sind die Anwendungsobject-Besitzer und wer die Anwendungsuser?
  • Profile
    Gibt es entsprechend den Benutzergruppen auch dedizierte Profile?
    Ist das PW-Management in den profilen eingeschaltet.
Benutzermanagement


Wie das nun im Detail funktioniert, verrate ich auf dem Oracle Direct Security Day am 16.4.2015 in Potsdam oder Online.
Diese Veranstaltung ist kostenlos. Die Anmeldung und weitere Informationen finden SIe unter http://bit.ly/ODSD2015

20. Februar 2015

Der OracleDirect Security Day am 16.4.2015 in Potsdam oder online

Am 16.4.2015 veranstalten wir bei Oracle in Potsdam einen OracleDirect Security Day.
Wir haben
  • 6 Präsentationen, 
  • 6 ganztägige Infosstände mit Live-Demos sowie 
  • einen Hands-on Workshop vorbereitet.

An diesem Tag widmen wir uns ausschließlich der IT-Sicherheit. Wir zeigen typische Gefahren und deren sinnvolle Lösungen.
Drei Hightlights möchte ich schon heute nennen:
  1. Der Security-Smoke-Test (den werde ich vorstellen)
  2. Eine Lösung zum Benutzermanagement, die das Password-Problem auflöst, Zwecktrennung automatisch implementiert und erzwingt, sowie erheblich Admin-Aufwände (vorgestellt von meinem Kollegen Suvad Sahovic.
  3. die Firma eperi hat den Gewinner der Cyber Challenge Germany ermutigt einen Live Hack auf eine ungeschützte Datenbank vorzunehmen.
Natürlich gibt es weitere Highlights, lassen Sie sich überraschen.
Eine Übersicht des Tages finden Sie auf meinem offiziellen Oracle Blog. Die Registierung zu diesem kostenlosen Event führen Sie unter http://bit.ly/ODSD2015 durch.

Das Programmheft finden Sie hier.

Oracle Direct Security Day am 16.4.2015 in Potsdam

26. September 2014

DOAG SIG Security 2014 in Hamburg: Enterprise User Security for DBAs #eus4dbas

Auf der SIG Security der DOAG habe ich über das Thema Enterprise User Security für DBAs referiert oder anders gesagt "Wie erfülle ich innerhalb einer Stunde Compliance- Anforderungen?".
Im Nachgang die Folien auf Slideshare:

15. September 2014

Bedrohung Verlust der Verfügbarkeit: In-Memory mal anders erklärt

Um es mal auf den Punkt zu bringen: Geniale Konzepte sollten auch weitererzählt werden. Mit der Oracle In-Memory Option hat Oracle gezeigt, wie man mit einem Patch-Release erhebliche Mehrwerte schaffen kann. Die Aktivierung dieser Option ist sehr einfach, also das Gegenteil von komplex!

27. August 2014

Oracle DB Security: Enterprise User Security für DBAs (EUS4DBAS)

Einführung

Die Idee mit diesem Post ist zu zeigen, wie sinnvolle Security in dem Betrieb von Datenbanken verwendet werden kann. Heute sind Unternehmen und Behörden sehr vielen Anforderungen ausgesetzt. Nicht nur die geschäftlichen Anforderungen, sondern vor allen Dingen die gesetzlichen Anforderungen gilt es, sinnvoll und effektiv umzusetzen. Es soll eine Nachhaltigkeit entstehen, die neue Anforderungen mehr oder weniger automatisch für die Zukunft abdeckt.

Betrachten wir nur das Bundesschutzgesetz (BDSG) und Datenschutzverordnungen der einzelnen Bundesländer (DSVO). Diese fordern im Umgang mit personenbezogenen Daten eine erhöhte Sensibilität. Gerade auch im Bereich der Administration bedeutet das, dass eine Zwecktrennung (Berechtigungen), regelmäßige Passwortänderungen und weiteres durchgeführt wird. Für eine ordnungsgemäße Datenverarbeitung nach aktuellem Stand der Technik ist es zwingend notwendig, dass die administrativen Tätigkeiten nachvollziehbar sind. Das LDSG und die DSVO stellen hierfür konkrete Anforderungen. Bei jeder administrativen Tätigkeit muss stets der Ausführende ermittelt werden können. Auch Oracle empfiehlt in seinem Security Guide die Nutzung personalisierter DBA Accounts in der Datenbank.

Dieser Post beschreibt ein Konzept, welches wir Enterprise User Security für DBAs (EUS4DBAS) nennen. Das Ziel ist genau die genannten gesetzlichen Anforderungen im Bereich der DBAs umzusetzen und gleichzeitig vorhandene Investitionen zu nutzen und dadurch erhebliche Aufwände im Betrieb einzusparen. Aber auch eine erhöhte Sicherheit zu implementieren, die klare Konzepte verfolgt (mehr Transparenz, mehr Kontrolle, mehr Nachvollziehbarkeit, Eindeutigkeit) und ganz wichtig Komplexität abbaut.
Abbildung 1: Enterprise User Security für DBAs
In der Regel haben viele Unternehmen bereits ein zentrales Benutzermanagement z.B. für Windows aufgebaut. Alle Mitarbeiter mit einem Windows Desktop Rechner werden i.d.R. im MS Active Directory verwaltet. Warum müssen noch zusätzliche Benutzerrepositories betrieben werden? Wie Sie wissen, kann jede Oracle Datenbank ihre eigenen Benutzer verwalten. Die Oracle Datenbank Enterprise Edition verfügt über die Funktion Enterprise User Security. Genau diese Funktion ermöglicht es bereits bestehende Benutzerrepositories für Oracle Datenbanken einzubinden und diese LDAP User in der Datenbank zu nutzen, ohne diese Benutzer noch einmal zusätzlich in der Datenbank anzulegen.

Warum dieses hervorragende Konzept „Enterprise User Security“ sinnvoll ist, beschreibt die Komplexitätsberechnung ComplexDBAMgmt für die kleine Benutzergruppe der DBAs. Würde man alle anderen Benutzergruppen hinzuberechnen, dann wäre die Komplexität wahrscheinlich so groß, so daß die Bedrohung „Verlust der Kontrolle“ gegeben ist. Betrachten Sie bitte nachfolgende Grafik (Abb. 2).
Abbildung 2: Berechnung Komplexität des Account Managements für DBAs
Sie sehen anhand der Berechnung, dass auch für eine kleine Benutzergruppe von 10 DBAs ein Aufwand entstehen kann, der so groß ist, das man wesentliche Maßnahmen für einen sicheren Datenbank-Betrieb vermeidet, wie
  1. Regelmäßiges Ändern von Kennwörtern
  2. Keine Zwecktrennung (der DBA macht einfach alles, Release Manager, Account Manager, etc.)
  3. Keine personalisierten DBAs, alle DBAs arbeiten mit SYS und SYSTEM
  4. und Sie kennen bestimmt noch viel mehr Maßnahmen, die nicht durchgeführt werden...
Also, warum vermeiden wir nicht die Komplexität? Stattdessen nutzen wir für die 10 DBAs das bestehende Benutzerrepository MS AD und gleichzeitig alle Policies, die diese Repository bereits eingestellt hat, wie Selfservices (PW-Reset), PW-Policies (starke Passwörter), starke Authentisierungsverfahren etc..

Das charmante an diesem Konzept ist: Sie investieren einen Aufwand von ca. 1 Stunde, um eine Umgebung zu implementieren, die Ihnen erhebliche Vorteile verschafft und für eine Nachhaltigkeit in der Zukunft sorgt.

Hinweis:
Ein Zeitaufwand von 1h Stunde ist für erfahrene Admins, die wissen was sie tun. Folgen Sie diesem Konzept dauert der erste Aufbau etwas länger. Sie müssen das Dokument lesen und verstehen und die einzelnen Schritte ausführen. Beim zweiten Mal wissen Sie was Sie tun müssen und dann geht es zügig voran.


 

Vorbereitende Schritte

Eine Umgebung die bestehende Benutzerrepositories mit einer Oracle Datenbank verwenden kann, sieht wie in Abb.3 beschrieben aus. Genau diese Umgebung bauen wir in diesem Konzept auf und beschreiben jeden einzelnen Schritt im Detail. Der Aufwand ohne Download-Zeit der Software Komponenten beträgt ca. 1 Stunde, wenn man alle Schritte kennt und den Aufbau bereits mehrmals durchgeführt hat.
Abbildung 3: Enterprise User Security Umgebung mit MS AD und Kerberos Authentisierung
Warum benötigt man Oracle Unified Directory und greift nicht direkt auf den MS AD Server aus der Datenbank heraus zu, fragen Sie sich bestimmt. Diese Frage ist berechtigt. Die Antwort ist: „Eine Oracle Datenbank kann im Bereich EUS nur mit einem Oracle LDAP wie OUD kommunizieren. Will man andere LDAP Dienste nutzen, so müssen diese über einen Oracle LDAP Dienst eingebunden werden.

Achten Sie bitte darauf, dass die Kommunikation zwischen den Komponenten in Abb.3 funktioniert und nicht durch eine Firewall blockiert wird.

 

Vorbereitung und Informationen

Bevor wir mit der Umsetzung beginnen, benötigen wir folgende Informationen bzw. gehen davon aus, dass bestimmte Komponenten bereits existieren:
  1. Die Komponenten Oracle Datenbank (11.2.0.4) und MS AD existieren bereits. Hostname, Port der Server benennen. Wie heissen, die DBA User Accounts (in der DB und im MS AD)?
  2. Für den Aufbau des Oracle Unified Directories empfehlen wir die Nutzung einer eigener Maschine. Wir empfehlen den Aufbau mit Oracle Linux (64bit)
  3. Version des MS AD?
  4. Welches OS wird bei den DBA Workstations genutzt? Sind Oracle Clients installiert, welche Version?
  5. Welche DB Versionen (auf dem DB Server) werden eingesetzt, die mit EUS arbeiten sollen?
  6. Nutzen Sie Cloud Control für die Verwaltung der Datenbanken? Welche Version? Mit welchen Credentials arbeiten Sie aus Cloud Control heraus auf den Datenbanken?
  7. Gibt es nur eine AD Root Domain (Z.B. oracle.com) oder gibt es auch child domains (de.oracle.com)? Wie lauten genau die Root und die Child Domains?
  8. Gibt es zusätzliche MS AD Forests?
  9. Der eine oder mehrere KDC (Key Distribution Center) Namen müssen bekannt sein. Wie heissen diese? (Beispiel: ad.de.oracle.com)
  10. Existiert bereits eine krb5.ini/krb5.conf Datei (Kerberos Konfigurationsdatei), die für den Aufbau von EUS mit Kerberos verwendet werden kann?
  11. Wie sieht ein typischer User im MS AD aus? Beispiel Distinguished Name: cn=carsten,cn=Users,dc=de,dc=oracle,dc=com . Vielleicht liegen die User auch in einer gesonderten Organisation Unit, Bsp. DBAs:
    cn=carsten,cn=Users,ou=DBAS,dc=de,dc=oracle,dc=com
  12. Kann der MS AD Server mit dem DB Server Dateien austauschen(Notwendig für den Keytab)?
  13. Sind die DB Server (DNS Name) genau in der gleichen Root Domain? Wie ist die Namenskonvention (DNS Name) der DB Server? Wie lauten die DNS Namen von einem DB Server?
  14.  Beim Aufbau der Umgebung muss ein MS AD Admin vorort sein (wegen Keytab, User anlegen,...). KTPASS Tools müssen vorhanden sein. Benennen Sie einen MS AD User (Proxy User) mit lesenden Zugriff in das MS AD
  15.  NTP Server benennen? Alle Server müssen eine identische Zeit aufweisen

 

Download der Software Komponenten

Für den Aufbau der Umgebung mit Oracle Unified Directory benötigen wir nachfolgend aufgeführte Software-Komponenten, die im Vorfeld auf den dafür zur Verfügung gestellten Server heruntergeladen werden sollten.

Wir werden später den OUD-Server im Proxy-Mode aufbauen. In diesem Mode wird ein lesender Zugriff in MS AD realisiert. Eine redundante Datenhaltung wird somit vermieden.
Bereiten Sie Ihren Linux Server vor. Installieren Sie Oracle Linux 5 oder 6 (siehe Certification Matrix) und richten Sie einen Benutzer „oud“ ein, der der Gruppe „oud“ angehört.

Certification Matrix: Bitte Ihr Betriebssystem überprüfen:
http://www.oracle.com/technetwork/middleware/id-mgmt/identity-accessmgmt-certmatrix-1932870.xls
Installation Guide OUD 11gR2, vorbereitende Schritte: http://docs.oracle.com/cd/E49437_01/install.111220/e23737/before_you_install.htm#solBEFORE-YOU-INSTALL-OPENDS 


Als user „oud“ einloggen und die Software downloaden.
Die Software legen wir im Verzeichnis: /home/oud/software ab. Für jedes Produkt ein eigenes Verzeichnis anlegen.
Als erstes laden wir die Software aus dem Internet.
  1.  Oracle Unified Directory 11.1.2.
    Gehen Sie auf die Website:  https://edelivery.oracle.com
    und melden Sie sich an.
    Folgen Sie den Hinweisen im Installation Guide:
    also: Bitte Oracle Fusion Middleware unter LinuxX86-64 auswählen
    Oracle Fusion Middleware Identity Management 11g R2 Media Pack  anchecken und
    continue clicken
    Click Download für Oracle Unified Directory 11g 11.1.2.2.0
    Der Download startet und wird im Server unter /home/oud/software/oud abgelegt.
  2. Oracle Weblogic Server 10.3.6 (brauchen wir für Admin Oberfläche ODSM)
    Gehen Sie auf die Download-Website (Weblogic 10.3.6)
    download: Oracle WebLogic Server 11gR1 (10.3.6) + Coherence – (Achtung entsprechend der OS Version die richtige Version herunterladen. Ich nutze die 64-Bit Version, also vierte Spalte)
    See als Files (+) aufklicken.
    Package Installer: Generic (1TB)
    Bitte darauf achten, ob Sie die 32bit oder 64bit Version benötigen.
    Ablage nach /home/oud/software/weblogic
  3. ADF Framwork downloaden (brauchen wir für Admin Oberfläche ODSM)
    Bitte Version Application Development Runtime 11.1.1.7 unter „Application Development Runtime“ auswählen und downloaden: siehe ADF Download
    Ablage nach /home/oud/software/adf
  4. Download JRE oder JDK 6 oder 7, falls noch nicht auf dem Linux Server vorhanden
    Java-Download
    Ablage nach /home/oud/software
  5. (optional) Apache Directory Studio herunterladen
    Die Adminumgebung für den Oracle Unified Directory benötigt man nicht für den täglichen Gebrauch. Hierfür kann man stattdessen auf dem Server oder auf den Admin Desktop einen geeigneten LDAP-Browser nutzen. Wie z.B. das Directory Studio von Apache.
    http://directory.apache.org/studio/downloads.html
    Ablage nach /home/oud/software/ApacheDir
  6. Aktueller Bundlepatch zum OUD herunterladen: Doc-ID: 1905631.1 (vom Juli 2014)
    Über My Oracle Support (support.oracle.com) den richtigen Bundle Patch Number: 11.1.2.2.1 Patch:18662903 vom 15 Juli 2014 herunterladen
    Ablage nach /home/oud/software/patch

 

EUS aufsetzen - Installation und Konfiguration

Ich werde in diesem Beitrag darstellen, wie einfach es ist, eine gesetzeskonforme Lösung für das Setup der DBAs in Oracle Datenbanken zu implementieren. Eine Lösung, die nicht nur gesetzeskonform ist, sondern auch erhebliche Aufwandsreduzierungen in der Verwaltung von personalisierten DBAs in allen ihren Oracle Datenbanken mit sich bringt.

 

Installation und Setup Oracle Unified Directory

Folgende Verzeichnisse werden wir auf dem Linux System nach der Installation vorfinden:
  1. Oracle Middleware Home
    Hierin werden wir Oracle Unified Directory (OUD), Oracle Weblogic Server sowie das Application Development Framework (ADF) installieren.
    Verzeichnisname:   /app/Middleware
  2. Oracle Home
    Hier werden produktspezifischen Files zum OUD installiert. Dieses Verzeichnis befindet sich innerhalb des Middleware-Home.
    Verzeichnisname:  /app/Middleware/Oracle_OUD1
  3. Oracle Common Directory
    Hier wird ADF abgelegt.
    Verzeichnisname:  /app/Middleware/oracle_common
  4. Oracle Weblogic Domain Directory
    Es wird eine Weblogic Domain abgelegt.
    Verzeichnisname:  /app/Middleware/user_projects

 

JAVA JDK 6 oder höher vorbereiten

Für die Installation benötigen wir für das OUD eine Java Version von mindestens Version 6. Falls das Java in der notwendigen Version nicht zur Verfügung steht, müssen Sie diese Version nachinstallieren. Öffnen Sie ein Terminalfenster auf dem OUD-Server:
Wechseln des Benutzers zu root und Java nachinstallieren (Download Java)
[oud ~]$ su -
[root ~]$ cd /home/oud/software
[root ~]$ rpm -ivh /home/oud/software/jdk-7u67-linux-x64.rpm


Java wird dann nach /usr/java installiert.

 

Linuxumgebung setzen

Bevor wir mit der Installation weiter machen, setzen wir die Linux-Umgebung für den oud Benutzer. Öffnen Sie ein Terminalfenster und editieren Sie die .bash_profile im Homeverzeichnis von OUD:
[oud ~]$ vi .bash_profile
JAVA_HOME=/usr/java/jdk1.7.0_67
INSTANCE_NAME=oud-proxy
OUD_HOME=/app/Middleware/Oracle_OUD1
PATH=.:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/oud/bin:$JAVA_HOME/bin:/app/Middleware/Oracle_OUD1/bin
export PATH JAVA_HOME INSTANCE_NAME OUD_HOME
[oud ~]$ source .bash_profile


Die Umgebung ist gesetzt. Testen Sie die Umgebung:
[oud ~]$ echo $INSTANCE_NAME

 

Oracle Unified Directory (OUD) installieren

Wir befinden uns immer noch auf dem OUD-Server und sind als „oud“ angemeldet. Nun installieren wir alle Komponenten, die wir für den OUD benötigen. Als Erstes installieren wir die OUD-Software, dann WebLogic Server, dann Oracle Directory Service Manager (ODSM) mit ADF und zum Schluß spielen wir noch den aktuellen OUD Bundle-Patch ein.
Nun packen wir die die OUD Software aus:
[oud ~]$ cd software/oud
[oud oud]$ unzip /home/oud/software/Oracle\ Unified\ Directory\ 11g\ 11.1.2.2.0_V43020-01.zip


Nun die OUD Software installieren, hierzu in das richtige Verzeichnis wechseln und den Installer ausführen;
[oud oud]$ cd /home/oud/software/oud/Disk1
[oud Disk1]$ ./runInstaller -jreLoc /usr/java/jdk1.7.0_67/

Der Installer startet, folgende Einstellung nehmen wir vor:
Software Updates (Support) Einstellungen: Wenn Sie möchten, ansonsten Skip Software Updates; OUD Base Location Home /app/Middleware, Oracle Home Directory Oracle_OUD1, alles andere lassen wir auf Default.
Abbildung 4: OUD-Installer, 7 einfache Schritte
Dieser Vorgang dauert wenige Minuten, dann ist die OUD Software installiert.

 

Oracle Weblogic Server (WLS) 10.3.6 (11g) installieren

Nun wird der Weblogic Server installiert. Dieser wird für den Betrieb des OUD-Admin-Tools „Oracle Directory Service Manager (ODSM)“ benötigt.
Weblogic Server installieren:
[oud ~]$ cd /home/oud/software/weblogic
[oud weblogic]$ /usr/java/jdk1.7.0_67/bin/java d-64 -jar wls1036_generic.jar


Der Installer wird aufgerufen. Wir erstellen ein neues Middleware Home /app/Middleware. Wenn der Installer sagt, Verzeichnis ist nicht leer, wollen wir trotzdem mit Installation fortfahren. Entscheiden Sie selber, ob Sie Security Updates benötigen. Wir führen dann eine Custom-Installation durch und wählen nur Weblogic Server ohne Coherence. Am Ende der Installation auf Run Quickstart verzichten.
Abbildung 5: WLS-Installer, 10 einfache Schritte
 Dieser Vorgang dauert ca. 10 Minuten.

 

Application Developerment Framework (ADF) und Oracle Directory Service Manager (ODSM) installieren 

ADF ist notwendig für die Admin-Application (ODSM).
ADF unzippen und dann installieren. Bei der Installation sind keine expliziten Einstellungen notwendig. Wir installieren in das /app/Middleware Verzeichnis und nutzen oracle_common als Oracle Home:
[oud ~]$ cd /home/oud/software/adf
[oud adf]$ unzip ofm_appdev_generic_11.1.1.7.0_disk1_1of1.zip
[oud adf]$ cd Disk1
[oud adf]$ ./runInstaller -jreLoc /usr/java/jdk1.7.0_67/jre

Abbildung 6: ADF-Installer, 8 einfache Schritte
Auch diese Installation dauert wenige Minuten.

Nun können wir Oracle Directory Services Manager (ODSM) deployen. OUD, Weblogic und ADF müssen bereits installiert sein. Was wir ja eben getan haben.
Dazu rufen wir den Configuration Wizard des Weblogic Servers auf:
[oud ~]$ /app/Middleware/oracle_common/common/bin/config.sh

Wir erstellen eine neue Weblogic Domain "odsm". Wir wählen die zu installierende Komponente Oracle Directory Services Manager aus (Oracle JRF wird automatisch mitgewählt).
Hierzu tragen Sie als Domainnamen odsm ein. Wählen das Password für den Administrator weblogic. Wählen Sie bitte ein sicheres Passwort aus. In meinem Fall verwende ich "welcome1" (PS: Das ist übrigens kein sicheres Password). Achten Sie auch darauf, dass Sie mit dem richtigen JDK installieren. Wir nutzen immer das gleiche JDK. In meinem Fall JDK7.
Abbildung 7: WLS-Configuration Wizard für ODSM, 8 einfache Schritte
Auch dieser Vorgang dauerte wenige Minuten.

 

OUD Bundle Patch vom Juli 2014 einspielen

Alle OUD Komponenten sind installiert. Nun spielen wir den aktuellen Patch (bitte zum Zeitpunkt des Lesens nach aktuellen Patches schauen) ein.
[oud ~]$ cd software/patch
[oud patch]$ unzip p18662903_111220_Generic.zip
[oud patch]$ cd  18662903/OUD/


Lesen Sie nun die Readme.html mit einem Browser und informieren Sie sich über die notwendigen Schritte. Im Grunde wird beschrieben, wie der Patch eingespielt werden muss und was noch zu beachten ist: Also, der Patch wird eingespielt durch:
[oud OUD]$ /app/Middleware/Oracle_OUD1/OPatch/opatch apply

So, der Patch ist eingespielt und die OUD Software ist aktuell und kann konfiguriert werden.
Für einen ersten Test starten wir jetzt das Admin-Tool ODSM. Um einfach zu sehen, ob der Weblogic läuft.
Dazu fahren wir den Weblogic Server hoch. Öffnen Sie hierzu ein Terminal Fenster auf dem OUD-Server und starten den WLS:
[oud ~]$ /app/Middleware/user_projects/domains/odsm/bin/startWebLogic.sh

Beim Bootvorgang wird das Adminserver Verzeichnis angelegt:
/app/Middleware/user_projects/domains/odsm/servers/AdminServer
Im Bootvorgang wird der Adminuser abgefragt. Bitte geben Sie als User weblogic und als Password welcome1 (oder ihr eigenes Password) ein. Warten Sie nun bis die Meldung "Server started in RUNNING Mode" erscheint. Dann ist der Weblogic Server erfolgreich gestartet.
Damit der WLS automatisch startet (ohne Passwordeingabe) können Sie ein boot.properties File anlegen.
[oud ~]$ cd /app/Middleware/user_projects/domains/odsm/servers/AdminServer/
[oud AdminServer]$ mkdir security
[oud AdminServer]$ cd security
[oud security]$ vi boot.properties


Tragen Sie nun die richtigen Credentials für den Admin-User ein. Bei mir sind das:
username=weblogic
password=welcome1

Sobald der Server hochfährt, wird das Password automatisch in der boot.properties verschlüsselt und eine Eingabe ist dann nicht mehr notwendig.
Der WLS ist hochgefahren und ODSM kann aufgerufen werden. Öffnen Sie hierzu einen Browser und geben die URL http://<server>:7001/odsm ein. In meinem Fall
http://oud.de.oracle.com:7001/odsm
Es erscheint das Login-Fenster vom ODSM. Mehr wollten wir an dieser Stelle nicht sehen.
Abbildung 8: ODSM Login Browserfenster
WLS läuft und ODSM ist auch deployed.

 

Konfiguration des OUD als Proxy und Anbindung des MS AD

Nun starten wir die Konfiguration einer neuen OUD Instanz. Damit beim Anlegen dieser neuen Instanz der richtige Name verwendet wird (ansonsten asinst_1), haben wir bereits eine Umgebungsvariable angelegt. Bitte überprüfen Sie, ob die Variable gesetzt ist und „oud-proxy“ ausweist:
[oud ~]$ echo $INSTANCE_NAME

Wir wollen ein OUD-Proxy aufsetzen und somit vermeiden, dass die Daten aus dem MS AD redundant gespeichert werden. D.h. der Proxy greift auf den MS AD zu und liest die notwendigen Daten direkt aus dem MS AD. Hierfür benötigen wir einen Nutzer aus dem MS AD, der einen lesenden Zugriff auf die MS AD Daten besitzt. Er muss die Daten, also die DBAs, lesen können, die wir benötigen. Fragen Sie Ihren MS-AD-Admin welchen Nutzer er für Sie zur Verfügung stellen kann. In meinem Fall nutze ich den Administrator Benutzer, womit ich vollen Zugriff auf alle Daten im MS AD habe:
Host: ad.de.oracle.com Port: 389 (nicht verschlüsselt)
Username: administrator
Password: <password>

Im MS AD habe ich zwei DBA-Benutzer angelegt:
  • Suvad (DBA): suvad@de.oracle.com
  • Carsten (DBA): carsten@de.oracle.com
Beide Benutzer gehören der Gruppe DB-ADMINS an.
Abbildung 9: MS AD User, die als DBAs in der Datenbank arbeiten werden
Nun kreieren wir eine neue OUD Instanz „oud-proxy“.
Wir öffnen ein Terminalfenster und arbeiten immer noch als „oud“ User:
[oud ~]$ cd /app/Middleware/Oracle_OUD1 

In diesem Verzeichnis findet man alle OUD Konfiguration Setup Tools. Wir wollen einen OUD-Proxy anlegen, der sich mit dem MS AD Server verbindet. Daher rufen wir das Proxy Tool auf:
[oud Oracle_OUD1]$ ./oud-proxy-setup

Da wir EUS aufsetzen, muss unbedingt secure access enabled werden. Wir wählen als Proxy unseren Server-Host oud.de.oracle.com aus. Die LDAP Ports sind 1389 und LDAPS 1636. Der AdminPort für den Zugriff des ODSM ist 4444. Root-User des OUD ist cn=Directory Manager und ich wähle das Password=oracle (wählen Sie hier ein sicheres Password). Fügen Sie den MS AD Server hinzu und setzen den Naming Context auf „dc=de,dc=oracle,dc=com“. Der Naming Context muß Ihrer Umgebung entsprechen. Am besten Sie schauen mit einem LDAP Browser in Ihrem MS AD und schauen wie die Root DN aussieht, diesen Kontext wählen Sie dann.
Laufzeitoptionen, d.h. spezielle Tuning Parameter, braucht man für einen OUD-Proxy nicht extra setzen. Die automatisch eingestellte Konfiguration ist bereits für einen Proxy-Einsatz bestmöglich eingestellt.
Abbildung 10: OUD-Proxy INstanz, wenige einfache Schritte
Der OUD-Proxy ist eingestellt. Wie Ihnen wahrscheinlich aufgefallen ist, haben wir zwar den MS AD Server benannt, aber noch keinen User, der durch OUD genutzt werden kann, um die entsprechenden User aus dem MS AD zu lesen.

 

OUD-Proxy Post-Installation Steps

Die Remote Credentials für den MS AD wird im Workflow Element des Proxies hinterlegt. Wir werden hier den Admin-User eintragen. Es empfiehlt sich aber für unseren Fall einen User einzutragen, der nur eine Leseberechtigung hat. Den User konfigurieren über die Kommandozeile. Theoretisch kann man auch den ODSM (das Admin-Tool) nutzen, ich finde die Kommandozeile aber einfacher.
Als erstes legen Sie bitte ein Password-File an, in dem wir das Password des OUD Admin (cn=Directory Manager) hinterlegen. Wenn wir mit der Konfiguration fertig sind, löschen Sie diese Datei bitte.
[oud ~]$ touch /tmp/password.txt
[oud ~]$ vi /tmp/password.txt
oracle


In dem dem File steht nur das password „oracle“, sonst nichts.
Nun richten wir den Remote User mit Zugriff auf MS AD ein. Das entsprechende Workflow-Element mit Zugriff auf MS AD heißt „proxy-we1“ (wird automatisch so gewählt). Der Administrator User hat im MS AD den entsprechenden Distinguish Name cn=administrator,cn=users,dc=de,dc=oracle,dc=com. Ihr User heißt wahrscheinlich anders. Mit dem „\“ am Ende jeder Zeile, sagen Sie dem Kommando, dass es noch nicht zu Ende ist und in der nachfolgenden Zeile weitere Eingaben erfolgen:
[oud ~]$ cd /app/Middleware/oud-proxy/OUD/bin/
[oud ~]$ dsconfig set-workflow-element-prop \
--element-name proxy-we1 \
--set remote-root-dn:cn=administrator,cn=users,dc=de,dc=oracle,dc=com \
--set remote-root-password:oracle \

--hostname oud.de.oracle.com \
--port 4444 \
--trustAll \
--bindDN cn=Directory\ Manager \
--bindPasswordFile /tmp/password.txt \
--no-prompt


Die Besonderheit von EUS ist auch, dass das Mapping der LDAP-Welt mit der DB-Welt im LDAP abgespeichert wird. Hierfür wird das sogenannte OracleContext verwendet. Dieses wollen wir im OUD abspeichern, da die MS AD Admins es nicht so gerne sehen, wenn fremde Veränderungen, die nicht von Microsoft stammen, eingespielt werden. Daher müssen wir dem OUD noch mitteilen, dass der OracleContent (angelegt durch das oud-proxy-setup) nicht im MS AD gesucht werden soll. Auch der Directory Manager befindet sich im OUD und nicht im MS AD. Folgendes Kommando führen wir hierzu aus (achten Sie bitte darauf Ihren eigenen Context zu setzen (dc=de,dc=oracle,dc=com anpassen)):
 [oud ~]$ dsconfig set-workflow-element-prop \
--element-name proxy-we1 \
--add exclude-list:cn=Directory\ Manager \
--add exclude-list:cn=oraclecontext,dc=de,dc=oracle,dc=com \

--set remote-ldap-server-bind-dn:cn=administrator,cn=users,dc=de,dc=oracle,dc=com \
--set remote-ldap-server-bind-password:oracle \
--hostname oud.de.oracle.com \
--port 4444 \
--trustAll \
--bindDN cn=Directory\ Manager \
--bindPasswordFile /tmp/password.txt \
--no-prompt


Unser OUD weiss nun, wie er auf den MS AD zugreift, und dass das OracleContext nicht im MS AD gespeichert ist. Mit dem Einspielen des OracleContext durch das oud-proxy-setup wird ein LDIF-File eingespielt, der leider den falschen Naming-Context aufweist. Unser Naming-Context ist „dc=de,dc=oracle,dc=com“ (Fragen Sie Ihren MS AD ADMIN, welchen Wert Sie einstellen müssen). Im OUD wird aber derzeit noch „dc=example,dc=com“ verwendet. Auch die Speicherorte der Gruppen und User im MS AD müssen noch bekannt gegeben werden. Hierzu müssen wir eine LDIF Datei editieren und einige Einstellungen durch die richtigen Werte ersetzen. Die Änderungen werden wir mit dem „vi“ durchführen, das ist besonders einfach:
[oud ~]$ cd /app/Middleware/Oracle_OUD1/config/EUS/

Folgende Ersetzungen müssen wir vornehmen:
  1. ou=people durch cn=users ersetzen
  2. ou-groups durch cn=users ersetzen
  3. dc=example,dc=com durch Ihren Kontext ersetzen, also bei mir ist das: dc=de,dc=oracle,dc=com ersetzen
[oud EUS]$ vi modifyRealm.ldif

Das Replace in "vi" ist sehr einfach. ESC Taste drücken und
:%s/pattern/replace Syntax eingeben und mit ENTER abschliessen, also in unserem Fall
  1. :%s/ou=people/cn=Users   (3 Ersetzungen)
  2. :%s/ou=groups/cn=Users   (3 Ersetzungen)
  3. :%s/dc=example,dc=com/dc=de,dc=oracle,dc=com   (14 Ersetzungen)
mit ESC und :wq speichern wir unsere Änderungen und kommen zurück zur Kommandozeile.
Nun müssen wir die Veränderungen in der modifyRealm.ldif im OUD einspielen. Hierfür gehen wir direkt über den LDAPPort 1389. Also nicht über den Admin-Port für ODSM.
[oud EUS]$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager"  -j /tmp/password.txt -v -f modifyRealm.ldif

Es sollten bei Anpassung des OracleContext keine Fehlermeldungen auftauchen.
Achtung:
In der Dokumentation http://docs.oracle.com/cd/E49437_01/admin.111220/e22648/eus.htm#CJABDBJJ hat sich leider ein Fehler eingeschlichen. Hier wird der Admin-Port des OUD angegeben. Richtig ist aber der LDAP Port.


Für die EUS Nutzung wollen wir auch Kerberos verwenden. Das hat drei wesentliche Vorteile:
  1. Kerberos ist eine starke Authentisierung mittels Token
  2. Man braucht den MS AD nicht zusätzlich für EUS zu erweitern (Schemaerweitereung durch ein weiteres Password-Attribute, sowie ein Password-Filter)
  3.  Und man realisiert für die DBAs ein SSO. Der DBA authentisiert normal über seinen Windows Desktop. Dabei wird der Kerberos Token (Ticket) erzeugt und mit diesem Token kann sich der DBA an seine Datenbanken anmelden ohne erneut Username/Password eingeben zu müssen.
Für die Kerberos Nutzung müssen wir noch zwei weitere Attribute im OracleContext ändern. Diese Attribute sind der Kerberos Name, den MS AD verwendet. Diesen Namen müssen wir auf den richtigen Eintrag im OracleContext mappen.
Für das erste Attribute legen wir eine neue ldif-Datei an und benennen das richtige Mapping für das Attribute orclCommonNichNameAttribute. Achten Sie bitte darauf, dass hier Ihr Context eingetragen wird (dc=de,dc=oracle,dc=com anpassen):
[oud EUS]$ vi NickNameAttribute.ldif
dn:cn=Common,cn=Products,cn=OracleContext,dc=de,dc=oracle,dc=com
changetype: modify
replace: orclCommonNicknameAttribute
orclCommonNicknameAttribute: userPrincipalName


mit ESC :wq speichern wir unsere Einträge
Wir machen die Änderng dem OUD bekannt:
[oud EUS]$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j /tmp/password.txt -v -f NickNameAttribute.ldif

Ein letztes Mapping müssen wir noch durchführen, damit nicht der Fehler "ORA-28293: No matched Kerberos Principal found in any user entry" entsteht. Oracle erwartet einen „krbPrincipalName“-Wert. Doch in meinem MS AD wird das Attribute „userPrincipalName“ verwendet. Dieses Mapping für Kerberos muss nun auch angepasst werden. Achten Sie bitte auch wieder darauf, dass hier Ihr Context eingetragen wird (dc=de,dc=oracle,dc=com anpassen):
[oud EUS]$ vi KerberosPrincipal.ldif
dn: cn=Common,cn=Products,cn=OracleContext,dc=de,dc=oracle,dc=com
changetype: modify
replace: orclCommonKrbPrincipalAttribute
orclCommonKrbPrincipalAttribute: userPrincipalName


mit ESC :wq speichern wir unsere Einträge
Nun ändern wir auch dieses Mapping im OUD mittels ldapmodify
[oud EUS]$  ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j /tmp/password.txt -v -f KerberosPrincipal.ldif

Hinweis lt. Dokumentation:
Wenn Sie kein Kerberos verwenden wollen, muss das NickNameAttribute auf  sAMAccountName gemappt werden.
Siehe My Oracle Support Note:
OUD: Active Directy As External Directory Not Working For EUS (Doc ID 1570893.1)
Dann müssen aber wie gesagt noch ein paar weitere Änderungen am MS AD vorgenommen werden, wie Schemaerweiterung und Password-Filter Installation.
Näheres hierzu bitte in der Dokumentation verfolgen.  

Ich hatte den WebLogic Server in der Zwischenzeit gestoppt, vielleicht taten Sie das auch.
Nun fahre ich den Weblogic Server mit der odsm Domain wieder hoch:
[oud EUS]$ cd /app/Middleware/user_projects/domains/odsm/bin/
[oud bin]$ startWebLogic.sh


Ich öffne ODSM und hinterlege meine Login Credentials:
http://oud.de.oracle.com:7001/odsm

Abbildung 11: OUD-Proxy Login für ODSM
Gehen Sie in den Datenbrowser , nun haben Sie Zugriff auf Ihre User und Groups in MS AD. Sie können hierfür auch jeden beliebigen LDAP Browser nutzen. Über das OUD-Proxy haben Sie nun Zugriff auf die MS AD User und Gruppen und zwar in der Berechtigung des MS AD User, den Sie für den OUD-Proxy eingestellt haben. Meine Konfiguration zeigt mir nachfolgendes Bild:
Abbildung 12: MS AD im Zugriff des OUD-Proxy (ODSM)
Der OUD-Proxy mit Zugriff auf MS AD und allen notwendigen Einstellungen, um ein EUS mit Kerberos für die Oracle Datenbank zu verwenden, ist fertig aufgesetzt. Der letzte Schritt ist die Password-txt zu löschen:
[oud EUS]$ rm /tmp/password.txt

Der Aufwand für die Installation und Konfiguration, wenn man alles richtig macht, beträgt weniger als eine Stunde. Die restlichen Minuten unseres Stunden-Budgets verbrauchen wir nun, um Kerberos aufzusetzen und die Datenbank an das LDAP anzubinden.

Kerberos für eine bestehende Oracle Datenbank einstellen

Nachfolgend finden Sie die Schritte für eine Kerberos Konfiguration einer bestehenden Oracle Datenbank der Version 11.2.0.4.
Hinweis Kerberos Konfiguration:
Eine detaillierte Beschreibung finden Sie in der Oracle Dokumentation

 

Einstellungen im MS AD

Wir müssen einen neuen Benutzer für das SPN (Service Principal Name) Mapping im MS AD erstellen. In meinem Fall nehme ich den Eintrag „carstentestdb“. Also einen eindeutigen Eintrag für die DB, die wir anbinden möchten.
Abbildung 13: MS AD SPN Mapping User anlegen
In der Hosts Datei tragen wir den DB-Server ein. Mit Hostname und IP-Adresse. Die Hosts Datei finden Sie unter c:\windows\systems32\drivers\etc\hosts.
XX.XXX.XXX.XXX    db.de.oracle.com carstentestdb

Nun können wir die Keytab erzeugen. Gehen Sie zum MS AD Server und geben in der Kommandokonsole (cmd) folgendes Kommando ein.
ktpass -princ ORCL/db.de.oracle.com@DE.ORACLE.COM -mapuser carstentestdb +rndPass -crypto all -ptype KRB5_NT_PRINCIPAL -out c:\keytab.carstentestdb

Abbildung 14: Keytab auf dem MS AD Server erstellen
Im MS AD carstentestdb Eintrag überprüfen. In der Usermaske im Bereich Konto wird in dem Feld Benutzeranmeldename der richtige SPN (Service Principal Name) angezeigt.
Abbildung 15: SPN im MS AD überprüfen
Keytab zum DB Server kopieren. Ich kopiere die Keytab mittels WinSCP auf den DatenbankServer:
MS AD von c:\keytab.carstentestdb nach DBServer /etc/keytab.carstentestdb
Abbildung 16: Keytab auf den DB Server kopieren

 

Einstellungen für Kerberos auf dem DB Server

Wir geben den Hostname des MS AD in der Hosts-Datei (/etc/hosts) bekannt. Zusätzlich tragen wir für den DB Server noch den Alias-Namen „carstentestdb“ passend zum SPN Eintrag im MS AD ein.
xx.xxx.xxx.xxx ad.de.oracle.com ad
xx.xxx.xxx.xxx db.de.oracle.com db carstentestdb

Der nächste Schritt ist das Anpassen der Kerberos Konfigdateien im DB Server bzw. falls noch nicht vorhanden, eine neue Datei zu erstellen.
Öffnen Sie ein Terminalfenster auf dem DB Server und melden sich als root an. Die Konfiguration befindet sich im /etc Verzeichnis
[oud EUS]$ su -
[root ~]$ vi /etc/ krb5.conf
[libdefaults]
default_realm = DE.ORACLE.COM
clockskew = 3000
forwardable = true
default_tkt_enctypes = arcfour-hmac-md5
[realms]
DE.ORACLE.COM = {
kdc = ad.de.oracle.com

}
[domain_realm]
.de.oracle.com = DE.ORACLE.COM
de.oracle.com = DE.ORACLE.COM


Mit :wq speichern Sie Ihre Anpassungen. Wie gesagt, die Daten gehören zu meiner Umgebung und dienen hier nur als Beispiel. Bei anderen MS AD Umgebungen kann das anders aussehen.

Nun editieren wir die krb5.realms Datei. Diese befindet sicht auch im /etc Verzeichnis.
[root ~]$ vi /etc/krb5.realms
.de.oracle.com = DE.ORACLE.COM


Der DB Server muss nun auch mit dem MS AD für eine Kerberos Kommunikation bekannt gemacht werden. Hierfür muss die sqlnet.ora angepasst werden. Diese Anpassungen wird der „oracle“ User auf dem DB-Server durchführen:
[root ~]$ su – oracle
[oracle ~]$ vi $ORACLE_HOME/network/admin/sqlnet.ora
SQLNET.AUTHENTICATION_SERVICES= (BEQ, KERBEROS5)
SQLNET.KERBEROS5_REALMS = /etc/krb5.realms
SQLNET.KERBEROS5_CONF=/etc/krb5.conf
SQLNET.KERBEROS5_KEYTAB=/etc/keytab.carstentestdb
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=ORCL

SQLNET.KERBEROS5_CONF_MIT=true
SQLNET.FALLBACK_AUTHENTICATION = TRUE


Nach dieser Änderungen startet man den DB Listener durch.
[oracle ~]$ lsnrctl stop
[oracle ~]$ lsnrctl start


Damit wir die Kerberos Authentisierung in der Datenbank testen können, wird ein Benutzer in der Datenbank als „externally“ anlegt. Wir erstellen einen User in der DB (krbuser@DE.ORACLE.COM) externally:
[oracle ~]$ sqlplus system/oracle@orcl
SQL > create user "SAHOVIC@DE.ORACLE.COM" identified externally as 'SAHOVIC@DE.ORACLE.COM';
SQL > grant CONNECT TO "SAHOVIC@DE.ORACLE.COM";


Nun testen wir Kerberos auf dem DB Server, der unter Linux läuft:
[oracle ~]$ okinit sahovic
Kerberos Utilities for Linux: Version 11.2.0.4.0 - Production on 21-AUG-2014 11:14:20
Copyright (c) 1996, 2013 Oracle.  All rights reserved.
Password for sahovic@DE.ORACLE.COM: ........


[oracle ~]$ oklist
Kerberos Utilities for Linux: Version 11.2.0.4.0 - Production on 21-AUG-2014 11:14:24
Copyright (c) 1996, 2013 Oracle.  All rights reserved.
Ticket cache: /tmp/krb5cc_501
Default principal: sahovic@DE.ORACLE.COM
   Valid Starting           Expires            Principal
21-Aug-2014 11:14:17  21-Aug-2014 19:14:20  krbtgt/DE.ORACLE.COM@DE.ORACLE.COM
 

[oracle ~]$ sqlplus /@orcl
SQL >show user
USER is "SAHOVIC@DE.ORACLE.COM"


Somit ist Kerberos auf dem DB-Server konfiguriert und erfolgreich getestet. Natürlich kann man nun auch die Oracle Clients und u.U. auch die DB Links anpassen.

 

Einstellungen für EUS auf dem DB Server

OUD läuft und spricht mit MS AD, Kerberos als Authentisierungsverfahren läuft auch auf dem DB Server und spricht mit MS AD. Nun müssen wir noch EUS aktivieren. Nachfolgend führe ich die Quicksteps auf.

Hinweis:
Eine gute Beschreibung zum Aufsetzen EUS inkl. der DB finden Sie übrigens in der My Oracle Support Note: OUD-EUS configuration steps (Doc ID 1675625.1).

Als erster Konfigurationschritt rufen wir netca auf, um die ldap.ora zu generieren.

Wir wollen eine "Directory Usage Configuration" vornehmen. Den Directory Type belassen wir auf Oracle Internet Directory und setzen die Einstellungen von unserem OUD. OUD-Host und Port sowie Context: dc=de,dc=oracle,dc=com
[oracle ~]$ netca
Abbildung 17: netca zur Erstellung der ldap.ora
Der netca erstellt die Datei im Verzeichnis $ORACLE_HOME/network/admin/ldap.ora
[oracle ~]$ cat $ORACLE_HOME/network/admin/ldap.ora
# Generated by Oracle configuration tools.
DIRECTORY_SERVERS= (oudserver:1389:1636)
DEFAULT_ADMIN_CONTEXT = "dc=de,dc=oracle,dc=com"

DIRECTORY_SERVER_TYPE = OID


Nun muss noch die DB mit dem OUD-Server registriert werden. Dazu verwendet man den Database Configuration Assistent (dbca):
[oracle ~]$ dbca

Wir wählen „Configure DB Options“, wählen die richtige DB aus, und sagen „YES, register the Database“. Danach tragen Sie den OUD Admin ein, sowie geben ein Password für das Wallet an.
User DN: cn=Directory Manager
Password: Welcome1

Wallet Password (bitte ein gutes Password wählen): Welcome1
Keine weiteren Eingaben und die DB am Directory Service registrieren.
klkölks
Abbildung 18: dbca zum Registrieren der DB ans OUD
So die Infrastruktur steht. Nun müssen wir noch einiges in der DB vorbereiten und das Mapping zwischen DB und OUD vornehmen.
Als erstes die DB: Als „system“ legen wir ein globales Schema und eine globale DBA-Rolle in der DB an, die wir später mappen.
[oracle ~]$ sqlplus system/oracle@orcl
SQL > create user global_dba_schema identified globally;
SQL > create role global_dba_role identified globally;
SQL > grant dba to global_dba_role;


Der globale DBA Einstieg für personalisierte DBAs ist nun in der Datenbank eingerichtet. Hat aber noch keine Wirkung. Nun, müssen wir das Mapping mit dem LDAP vornehmen. Das machen wir im Enterprise Manager. Ich nutze das Datenbase Control auf dem DB Server : https://db.de.oracle.com:1158/em/console
Im Bereich Server klicken wir auf Enterprise User Security:
sdsds
Abbildung 19: EUS Konfiguration im Enterprise Manager
Im Enterprise Manager melden wir uns am OUD an:
Abbildung 20: Im Enterprise Manager beim OUD anmelden
Manage Enterprise Domains" ausführen. „OracleDefaultDomain“ klicken und dann „Configure“ ausführen. Im Bereich User-Schema Mapping erstellen wir ein neues Mapping:
Den Nutzerbaum mappen wir auf das global_dba_schema. Also den Subtree cn=users,dc=de,dc=oracle,dc=com mit global_dba_schema.
Abbildung 21: Schema-Mapping im Enterprise Manager
Jetzt erstellen wir die Enterprise Role ENTERPRISE_DBA. Auf den Reiter „Enterprise Roles“ gehen und „create“ clicken. Wir tragen den Namen „Enterprise_DBA" ein.

Abbildung 22: Enterprise Role eintragen
Nun fügen wir der Enterprise Rolle eine DB Rolle hinzu. Klicken Sie auf „Add“ und melden sich dann als DBA (system/oracle) an. Wählen Sie die Rolle „GLOBAL_DBA_ROLE“.
Abbildung 23: Globale Role aus der DB mit der Enterprise Role im LDAP mappen
Nun müssen wir noch die Grantees, also die beiden DBAs suvad und carsten aus dem MS AD über den OUD hinzufügen. Beide erhalten mit der Zuordnung einen Zugriff oder besser eine Autorisierung als DBA für diese Datenbank. Klick auf „Grantee“ TAB und dann auf „ADD“. Wir fügen jeweils die beiden DBAs aus.
Abbildung 24: LDAP-User der globale Role zuordnen
Hinweis:
Eine Zuordnung einer MS AD Gruppe kann auch gewählt werden.

EUS mit Kerberos und Zugriff auf MS AD Nutzer ist fertig (ohne Desktop Clients). Das Aufsetzen des EUS im DB Server kann auch mittels Kommandotools leicht automatisiert werden: Copy ldap.ora, silent dbca Registrierung etc..

Zum Schluß testen wir EUS mit Kerberos auf dem DB Server. Zwei DBA User aus dem MS AD sind suvad@de.oracle.com und carsten@de.oracle.com und sollten in der DB als DBAs arbeiten können, ohne diese dort angelegt zu haben:
Als erstes TGT-Ticket holen
[oracle ~]$ okinit suvad
[oracle ~]$ oklist


Der User hat sich an Kerberos authentisiert und sein Token erhalten. Nun meldet er sich an die DB an (ohne Passwort, sondern mit dem Kerberos TGT) und die DB autorisiert über OUD (MS AD) den Benutzer und er kann als DBA arbeiten.
[oracle ~]$ sqlplus /@orcl
SQL > show user
USER is "GLOBAL_DBA_SCHEMA"
SQL> select * from session_roles;
DBA Rollen werden angezeigt.....
SQL> select sys_context('USERENV', 'ENTERPRISE_IDENTITY') from dual;
SYS_CONTEXT('USERENV','ENTERPRISE_IDENTITY')
-----------------------------------------------------------------------

cn=suvad,cn=Users,dc=de,dc=oracle,dc=com


Zusatzinformationen

 

Zeit

Achten Sie bitte darauf, dass alle Komponenten eine identische Zeit aufweisen. Entweder stellen Sie die Zeit manuell nach oder synchronisieren über einen oder mehrere NTP Server.

 

Kerberos Anpassungen für den Windows Client

Es empfiehlt sich einen passenden Oracle Client zum Datenbank Server zu installieren. Folgende Client sqlnet.ora muss angepasst werden:
SQLNET.AUTHENTICATION_SERVICES = (KERBEROS5)
SQLNET.KERBEROS5_CONF = C:\WINDOWS\krb5.ini
SQLNET.KERBEROS5_CONF_MIT = true
SQLNET.KERBEROS5_CC_NAME = OSMSFT://
SQLNET.FALLBACK_AUTHENTICATION = TRUE


Für Windows 7 muss zusätzlich die Datei C:\Windows\System32\drivers\etc\services angepasst werden.
Die Einträge
kerberos           88/tcp    krb5 kerberos-sec      #Kerberos
kerberos           88/udp    krb5 kerberos-sec      #Kerberos

müssen durch die nachfolgenden Einträge ausgetauscht werden

kerberos           88/tcp    kerberos5 krb5 kerberos-sec      #Kerberos
kerberos           88/udp    kerberos5 krb5 kerberos-sec      #Kerberos

 

OUD HA Aufbau

Falls Sie den OUD Ausfallsicher machen müssen, folgen Sie bitte der My Oracle Support Note: „Enabling EUS with OUD-PROXY in HA mode for AD. (Doc ID 1609960.1)“

 

EUS User in der V$SESSION sichtbar machen

Siehe My Oracle Support Note: “How to Get The Name Of Enterprise User in V$SESSION? (Doc ID 1447631.1)”.

Schlusswort

So, wahrscheinlich haben Sie mehr als eine Stunde gebraucht. Aber da Sie jetzt die Key-Steps kennen und wissen, was zu tun ist, wird es beim zweiten Mal sicherlich nur 1 Stunde dauern.