Ziel: Integration der Benutzerverwaltung der Datenbank in das Microsoft Active Directory AD mit Hilfe des Centrally Managed Users (CMU) Features der Oracle 19c
Centrally Managed Users - CMU
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.
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!
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
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.
Active Directory vorbereiten
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 Server muss auf ein Englisches OS eingestellt werden!
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 Maus Tastes auf der Domain in „Active Directory User and Computers“ auf der Domain.
Alternativ Gruppe mit dem Rechten anlegen wie ein „OracleServiceAccountGrp“ und auf diese Gruppe die Rechte setzen
Permissions auf „user“:
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"
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.
! 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!
AD Kontroller wird neu gestartet.
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.
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
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
#als User oracle
mkdir /opt/oracle/wallet cd /opt/oracle/wallet orapki wallet create -wallet . -auto_login
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:
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
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:
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 .
CREATE USER ad_user IDENTIFIED GLOBALLY AS 'CN=dbuserapexdb,CN=Managed Service Accounts,DC=pipperr,DC=local' GRANT CONNECT,resource TO ad_user;
Centrally Managed Users - CMU
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]
Metalink:
Allgemein:
=
Steht Oracle Advanced Security Option (ASO) zur Verfügung:
Idee: User wird mit external identifiziert, der External User ist wiederum im OS des Servers per AD authentifiziert.