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 |
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 |
- Regelmäßiges Ändern von Kennwörtern
- Keine Zwecktrennung (der DBA macht einfach alles, Release Manager, Account Manager, etc.)
- Keine personalisierten DBAs, alle DBAs arbeiten mit SYS und SYSTEM
- und Sie kennen bestimmt noch viel mehr Maßnahmen, die nicht durchgeführt werden...
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 |
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:- 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)?
- Für den Aufbau des Oracle Unified Directories empfehlen wir die Nutzung einer eigener Maschine. Wir empfehlen den Aufbau mit Oracle Linux (64bit)
- Version des MS AD?
- Welches OS wird bei den DBA Workstations genutzt? Sind Oracle Clients installiert, welche Version?
- Welche DB Versionen (auf dem DB Server) werden eingesetzt, die mit EUS arbeiten sollen?
- Nutzen Sie Cloud Control für die Verwaltung der Datenbanken? Welche Version? Mit welchen Credentials arbeiten Sie aus Cloud Control heraus auf den Datenbanken?
- 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?
- Gibt es zusätzliche MS AD Forests?
- Der eine oder mehrere KDC (Key Distribution Center) Namen müssen bekannt sein. Wie heissen diese? (Beispiel: ad.de.oracle.com)
- Existiert bereits eine krb5.ini/krb5.conf Datei (Kerberos Konfigurationsdatei), die für den Aufbau von EUS mit Kerberos verwendet werden kann?
- 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 - Kann der MS AD Server mit dem DB Server Dateien austauschen(Notwendig für den Keytab)?
- 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?
- 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
- 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.
- 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. - 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 - 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 - Download JRE oder JDK 6 oder 7, falls noch nicht auf dem Linux Server vorhanden
Java-Download
Ablage nach /home/oud/software - (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 - 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:- Oracle Middleware Home
Hierin werden wir Oracle Unified Directory (OUD), Oracle Weblogic Server sowie das Application Development Framework (ADF) installieren.
Verzeichnisname: /app/Middleware - Oracle Home
Hier werden produktspezifischen Files zum OUD installiert. Dieses Verzeichnis befindet sich innerhalb des Middleware-Home.
Verzeichnisname: /app/Middleware/Oracle_OUD1 - Oracle Common Directory
Hier wird ADF abgelegt.
Verzeichnisname: /app/Middleware/oracle_common - 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 |
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 |
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 |
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 |
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 |
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
 |
| Abbildung 9: MS AD User, die als DBAs in der Datenbank arbeiten werden |
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 |
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:
- ou=people durch cn=users ersetzen
- ou-groups durch cn=users ersetzen
- dc=example,dc=com durch Ihren Kontext ersetzen, also bei mir ist das: dc=de,dc=oracle,dc=com ersetzen
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
- :%s/ou=people/cn=Users (3 Ersetzungen)
- :%s/ou=groups/cn=Users (3 Ersetzungen)
- :%s/dc=example,dc=com/dc=de,dc=oracle,dc=com (14 Ersetzungen)
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:
- Kerberos ist eine starke Authentisierung mittels Token
- Man braucht den MS AD nicht zusätzlich für EUS zu erweitern (Schemaerweitereung durch ein weiteres Password-Attribute, sowie ein Password-Filter)
- 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 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 |
 |
| Abbildung 12: MS AD im Zugriff des OUD-Proxy (ODSM) |
[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 |
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 |
 |
| Abbildung 15: SPN im MS AD überprüfen |
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 |
[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 |
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 |
 |
| Abbildung 20: Im Enterprise Manager beim OUD anmelden |
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 |
 |
| Abbildung 22: Enterprise Role eintragen |
 |
| Abbildung 23: Globale Role aus der DB mit der Enterprise Role im LDAP mappen |
 |
| Abbildung 24: LDAP-User der globale Role zuordnen |
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
Keine Kommentare:
Kommentar veröffentlichen