Benutzer-Werkzeuge

Webseiten-Werkzeuge


dba:user_oracle_ad_integration

Oracle 19c - Centrally Managed Users - CMU - Autorisierung von DB Schemas/Usern in das Active Directory integrieren

Ziel: Integration der Benutzerverwaltung der Datenbank in das Microsoft Active Directory AD mit Hilfe des Centrally Managed Users (CMU) Features der Oracle 19c

funktioniert noch nicht richtig!

Centrally Managed Users - CMU

  • Eingeführt mit Oracle 18c
  • Keine extra Lizenzkosten falls EE bereits im Einsatz
  • Keine zusätzlichen Komponenten notwendig
  • User und Rollen über das MS Active Directory (AD) autorisieren
  • Mappt DB User und DB rollen auf AD User / AD Rollen im Active Directory
  • Ein AD Service Account wird im AD benötigt
  • Folgende Authentifizierungsmethoden werden unterstützt:
    • Passwort ( Passwort Anmeldung benötigt eine Erweiterung im AD! )
    • Kerberos ( Nur mit Microsoft Active Directory Kerberos Server !)
    • Public Key Infrastructure ( Secure Socket Layer in jeder Datenbank konfiguriert!)

Übersicht:   Oracle 19c - Centrally Managed Users - CMU - Autorisierung von DB Schemas/Usern in das Active Directory integrieren


Vorüberlegungen

Vor Oracle Database 18c Release 1 (18.1) ist für eine Integration eine aufwendigeres Umgebung notwendig (Oracle Enterprise User Security und Oracle Internet Directory (bzw. Oracle Universal Directory). Diese Architektur ist aber zu komplex für kleinere Umgebungen.

Lizenz

Seit Oracle 18c EE kann hier ohne weitere Tools oder notwendige Addon Lizenzen zu EE das CMU Feature eingesetzt werden.

Diese Feature steht aber NICHT in der Standard Edition zur Verfügung, nur die EE und die XE unterstützen das!

Dokumentation ⇒ https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/integrating_mads_with_oracle_database.html#GUID-9739D541-FA9D-422A-95CA-799A4C6F488D

In SE kann nur auf Kerberos Authentifizierung gesetzt werden, siehe ⇒ Kerberos für die Authentifizierung eines AD Users in der Oracle DB verwenden - Proxy User verwenden

Aufwand

In einer sauber gemanget AD Umgebung ist die Einführung wohl eher nicht so problematisch, eine testweises Aufsetzen mit einen nur grob aufgebauten AD ist dagegen etwas schwieriger, da Zertifikate und Berechtigungen zu 100% passe müssen, passt hier etwas nicht lässt sich der Fehler nur schwer erkennen, das die Analyse von Fehlen sehr aufwendig ist.

Ablauf beim Aufbau einer Centrally Managed Users (CMU) Umgebung

Active Directory vorbereiten

  • Oracle Service User im AD (kann für alle Datenbank definiert werden)
    • Leserechte für das Suchen von User /Gruppe
    • Schreibreichte für das Aktualisieren von Login Informationen
  • Erweiterung des AD mit Oracle kompatiblen Passwort Filtern

Test Umgebung

Für die ersten Test eine Test Umgebung mit einer Eval Windows 2019 Server aufgebaut, hierzu gibt es viele Anleitung auch im Netz, siehe dazu z.B. https://robertscocca.medium.com/building-an-active-directory-lab-82170dd73fb4 und https://sid-500.com/2017/03/31/active-directory-zertifikatsdienste-teil-1-installation-einer-enterprise-root-ca/ .

Tool für LDAP Abfragen = >https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer

Bei Problem das Keyboard zu setzen ⇒ https://martinsblog.dk/windows-server-2016-systemsettingsadminflows-exe-error/

Auch ist es von Vorteil, zu Beginn die Kerberos Authentifizierung im alten Standard zuerst umzusetzen, siehe ⇒ Kerberos für die Authentifizierung eines AD Users in der Oracle DB verwenden - Proxy User verwenden , um schon mal die ersten Hürden zu bewältigen und um ersten Erfahrungen mit dem Thema zu sammlen.


AD Umgebung vorbereiten

AD Server muss auf ein Englisches OS eingestellt werden!

AD User für den Oracle Service Account anlegen
  • User „oracleDBConnect“ anlegen, Passwort vergeben, Checkbox „Password never“ expire! (unter Managed Service Accounts!)

Per CMD:

New-ADUser `
   -Name = "oracleDBConnect" `
   -UserPrincipalName = "orasync@pipperr.local" `
   -DisplayName = "Oracle Service Directory User" `
   -Description = "Service account for Oracle Database authentication." `
   -Path = "CN=Managed Service Accounts,DC=pipperr,DC=local" `
   -ChangePasswordAtLogon = $false `
   -PasswordNeverExpires = $true `
   -CannotChangePassword = $true `
   -Enabled = $true `
   -AccountPassword(Read-Host -AsSecureString "Initial Password:")
Rechte setzen über den "Delegation of control wizard"

Rechte Maus Tastes auf der Domain in „Active Directory User and Computers“ auf der Domain.

  • Rechte setzen
    • „Read Propertie“ AD user
    • „Write LockoutTme“ AD user

Alternativ Gruppe mit dem Rechten anlegen wie ein „OracleServiceAccountGrp“ und auf diese Gruppe die Rechte setzen

Permissions auf „user“:

  • Read lastLogonTimestamp
  • Read lockoutTime
  • Write lockoutTime
  • Read loginShell
dsacls "CN=oracleDBConnect,CN=Managed Service Accounts,DC=pipperr,DC=local" /I:P /G "pipperr\oracleDBConnect:WP;lockoutTime"
 
dsacls "CN=oracleDBConnect,CN=Managed Service Accounts,DC=pipperr,DC=local" /I:P /G "pipperr\oracleDBConnect:RP"

Passwort Authentifizierung aktivieren

Das MS Active Directory Schema muss um das Attribut orclCommonAttribute erweitert werden.

Die AD Gruppen ORA_VFR_MD5, ORA_VFR_11G und ORA_VFR_12C für den Oracle Passwort Filter werden angelegt um dann später die passenden Hashes zu erzeugen.

Achtung! Backup vor der Schema Anpassung vom AD erstellen! Kann nicht zurück gerollt werden!
Installation Password Filter auf dem Active Directory Server

! Die Umgebungssprache des AD Servers muss Englisch sein!

Der Filter wird benötigt um die Psswörter zusätzlich in einem Oracle spezifischen Hash abzulegen! Wird auf jeden beteiligten Domain Kontroller benötigt.

Datei „opwdintg.exe“ aus einen aktuellen Oracle 19c Home auf den Server kopieren, eine Dos Schell administrativ starten und von dort die Exe Datei starten!

  • Do you want to extend AD schema? [Yes/No]:
  • Schema extension for this domain will be permanent. Continue? [Yes/No]:
  • Found password filter installed already. Do you want to deinstall? [Yes/No]:
  • Do you want to install Oracle password filter? [Yes/No]:
  • The change requires machine reboot. Do you want to reboot now? [Yes/No]

AD Kontroller wird neu gestartet.

AD User anlegen

Ein neuen AD User anlegen der später die Rechte auf das Schema in der Test Datenbank erhalten soll.

Diese User die Gruppe ORA_VFR_12C zuweisen.

Da der Filter ja neu hinzugefügt wurde müssen bei bestehenden Anwendern die Passwörter neu gesetzt werden.


DB Umgebung vorbereiten

dsi.ora um AD zu hinterlegen

Auf der DB Umgebung muss der connect zum AD hinterlegt werden.

Am einfachsten in einer Datei dsi.ora neben der sqlnet.ora:

dsi.ora

DSI_DIRECTORY_SERVERS = (10.10.10.200:389:636)
DSI_DEFAULT_ADMIN_CONTEXT = "dc=pipperr,dc=local"
DSI_DIRECTORY_SERVER_TYPE = AD

AD Wallet hinterlegen

Root Zertifikat erzeugen

Root Zertifikat vom Active Directory Server exportieren und auf der Maschine ablegen, siehe dazu ⇒ https://wiki.processmaker.com/3.1/Export_the_Active_Directory_Certificate

Wallet erstellen

#als User oracle

mkdir /opt/oracle/wallet
 
 
cd /opt/oracle/wallet
 
orapki wallet create -wallet . -auto_login
User für die AD Abfrage in der Wallet hinterlegen
mkstore -wrl . -createEntry ORACLE.SECURITY.USERNAME oracleDBConnect
mkstore -wrl . -createEntry ORACLE.SECURITY.DN "CN=oracleDBConnect,CN=Managed Service Accounts,DC=pipperr,DC=local"
 
# Note: when prompted, your "secret/password" is the one for the Active Directory orasync user previously created
mkstore -wrl . -createEntry ORACLE.SECURITY.PASSWORD
 
Your secret/Password is missing in the command line
Enter your secret/Password:
Re-enter your secret/Password:
Enter wallet password:

AD Zertifikat in der Wallet hinterlegen

Cer File auf den Server in das /opt/oracle/wallet legen und importieren:

orapki wallet add -wallet . -cert *.cer -trusted_cert

Wallet anzeigen lassen:

 orapki wallet display -wallet .
..
 
Requested Certificates:
User Certificates:
Oracle Secret Store entries:
ORACLE.SECURITY.DN
ORACLE.SECURITY.PASSWORD
ORACLE.SECURITY.USERNAME
Trusted Certificates:
Subject:        CN=pipperr-CA,DC=pipperr,DC=local

LDAP prüfen

ldapsearch -b "DC=pipperr,DC=local" -D  "CN=oracleDBConnect,CN=Managed Service Accounts,DC=pipperr,DC=local" -h 10.10.10.200 -p 389 -q "CN=oracleDBConnect" description
ldapbind -D  "CN=oracleDBConnect,CN=Managed Service Accounts,DC=pipperr,DC=local" -h 10.10.10.200 -p 389 -q

Probem: error while loading shared libraries: libnnz19.so

ldapbind: error while loading shared libraries: libnnz19.so: cannot open shared object file: No such file or directory
 
#Fix as root:
[root@apex01 ~]# cd /usr/lib64
[root@apex01 lib64]#  ln -s /opt/oracle/product/19c/dbhome_1/lib/libnnz19.so libnnz19.so
[root@apex01 lib64]#  ln -s /opt/oracle/product/19c/dbhome_1/lib/libclntsh.so.19.1 libclntsh.so.19.1
[root@apex01 lib64]#  ln -s /opt/oracle/product/19c/dbhome_1/lib/libclntshcore.so.19.1 libclntshcore.so.19.1
ldapbind -D "CN=oracleDBConnect,CN=Managed Service Accounts,DC=pipperr,DC=local" -h 10.10.10.200 -p 636 -q -U3 -W "file:/opt/oracle/wallet" -Q "cn=oracleDBConnect" description
 
Please enter bind password:
Please enter SSL wallet password:
sgslufwrite: Hard error on write, OS error = 104
 SSL handshake failed
 
ldapbind -D  "CN=oracleDBConnect,CN=Managed Service Accounts,DC=pipperr,DC=local" -h 10.10.10.200 -p 636 -q -U3 -W "file:/opt/oracle/wallet" -Q
Please enter bind password:
Please enter SSL wallet password:
sgslufwrite: Hard error on write, OS error = 104
 SSL handshake failed

Fehler:

DB Konfigurieren

ALTER system SET ldap_directory_access='PASSWORD' scope=BOTH   sid='*';
ALTER system SET LDAP_DIRECTORY_SYSAUTH='YES'     scope=spfile sid='*';

Anmelden mit connect „Windows_domain\AD_Username“@TNS_Aliasname wie sqlplus „pipperr.local\dbuserapexdb“@oragpi .


DB User anlegen

CREATE USER ad_user IDENTIFIED GLOBALLY AS 'CN=dbuserapexdb,CN=Managed Service Accounts,DC=pipperr,DC=local'
 
GRANT CONNECT,resource TO ad_user;

Quellen

Namensauflösung von SQL*Net

Für die Integration der Namensauflösung von SQL*Net in das AD siehe auch hier http://www.pipperr.de/knowhow/ldap_sqlnet/ldap_sqlnet.html .

Bzw. unter Slideshare: [slideshare id=51535988&doc=ldapsqlnet-150812091051-lva1-app6892]

Kerberos Integration
Koppelung über das OS
Linux

Idee: User wird mit external identifiziert, der External User ist wiederum im OS des Servers per AD authentifiziert.

Lose Koppelung über LDAP
Cookies helfen bei der Bereitstellung von Inhalten. Diese Website verwendet Cookies. Mit der Nutzung der Website erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Computer gespeichert werden. Außerdem bestätigen Sie, dass Sie unsere Datenschutzerklärung gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website. Weitere Information
"Autor: Gunther Pipperr"
dba/user_oracle_ad_integration.txt · Zuletzt geändert: 2021/10/14 16:40 von gpipperr