The setting I'm talking about is an Oracle Universal Directory (OUD) which works as a proxy between Oracle databases and Active Directory (AD) where the users are managed. Unfortunately it stopped working. Even when a user changed the password in AD, it could not log in with this password to the database, but always got
ORA-01017: invalid username/password; logon deniedThis can have many reasons.
A check in Middleware/instances/euist_inst/OUD/logs/access(.log) shows
[03/Mar/2020:13:09:00 +0100] MODIFY PROXY_REQ conn=1654 op=5 msgID=6 s_credmode=use-specific-identity dn="cn=Username,ou=...,dc=..." s_conn=1002 s_msgid=7983 [03/Mar/2020:13:09:00 +0100] MODIFY PROXY_RES conn=1654 op=5 msgID=6 result=53 Message="00000057: LdapErr: DSID-0C090F64, comment: Error in attribute conversion operation, data 0, v3839^@" etime=1 s_authdn=CN=Oracle ... [03/Mar/2020:13:09:02 +0100] DISCONNECT conn=1654 reason="Client Disconnect"there is a MOs Note which describes the situation EUS Login Failure of AD Users Proxied by OUD: LdapErr: DSID-0C090CE0, comment: Error in attribute conversion operation (Doc ID 2612535.1) But neither the cause
They are not OUD-native. They have an AD format and indicate some problem with the passwords in AD.nor the solution
Contact your AD administrator to determine the meaning of the AD portion of the error to fix this problem.helps a lot.
Still asking the AD admin is a good idea. After some back & forth this line in eventlog on AD Server is an important step:
Code Integrity determined that a process (\...4\Windows\System32\lsass.exe) attempted to load \...\Windows\System32\oidpwdcn.dll that did not meet the Microsoft signing level requirements.
"c:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\signtool.exe" verify oidpwdcn.dll File: oidpwdcn.dll Index Algorithm Timestamp ======================================== SignTool Error: No signature found. Number of errors: 1
The first attempt was to replace (quite old) oidpwdcn.dll with orapwdfltr.dll from modern opwdintg.exe
But a first check with signtool.exe didn't show any signature, and LSA also refused it.
At that point, a SR at MOS was required. It went quite fast and Oracle confirmed, there is no signed version at that time. To get the latest orapwdfltr.dll, Bug 31134430 : NEED TO HAVE ORAPWDFLTR.DLL SIGNED BY MICROSOFT was opened and after reasonable time a signed ddl was provided. (I can not confirm nor decline, if additional contacts to Oracle were involved)
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\signtool.exe" verify /v orapwdfltr.dll Verifying: orapwdfltr.dll Signature Index: 0 (Primary Signature) Hash of file (sha256): 2A14712107D424FF5577EF5C3D111CF66DB40F6226047ADC4F31389D69F437EB Signing Certificate Chain: Issued to: VeriSign Class 3 Public Primary Certification Authority - G5 Issued by: VeriSign Class 3 Public Primary Certification Authority - G5 Expires: Thu Jul 17 01:59:59 2036 SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5 Issued to: Symantec Class 3 Extended Validation Code Signing CA - G2 Issued by: VeriSign Class 3 Public Primary Certification Authority - G5 Expires: Mon Mar 04 01:59:59 2024 SHA1 hash: 5B8F88C80A73D35F76CD412A9E74E916594DFA67 Issued to: Oracle America Inc. Issued by: Symantec Class 3 Extended Validation Code Signing CA - G2 Expires: Thu Jan 28 01:59:59 2021 SHA1 hash: 1CB08E9B70B917E64407A4F2665799D58B171F89 The signature is timestamped: Thu Apr 23 03:33:05 2020 Timestamp Verified by: Issued to: DigiCert Assured ID Root CA Issued by: DigiCert Assured ID Root CA Expires: Mon Nov 10 02:00:00 2031 SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 Issued to: DigiCert SHA2 Assured ID Timestamping CA Issued by: DigiCert Assured ID Root CA Expires: Tue Jan 07 14:00:00 2031 SHA1 hash: 3BA63A6E4841355772DEBEF9CDCF4D5AF353A297 Issued to: TIMESTAMP-SHA256-2019-10-15 Issued by: DigiCert SHA2 Assured ID Timestamping CA Expires: Thu Oct 17 02:00:00 2030 SHA1 hash: 0325BD505EDA96302DC22F4FA01E4C28BE2834C5 SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. Number of files successfully Verified: 0 Number of warnings: 0 Number of errors: 1
Still a proper login was not possible as orclCommonAttribute was not populated after a password change. It's important to read the documentation to opwdintg.exe as this installation program not only applies the ddl (instpflt.bat), but also extends the schema (etadschm.bat). (beside other changes) 3 groups are added: ORA_VFR_11G, ORA_VFR_12C and ORA_VFR_MD5. Only if users belong to the proper group, it's matching password algorithm is used to populate orclCommonAttribute.
After the test user was added to the first group (and it's password was changed again) login on th etest-DB was possible again.
If you want to use this new, signed ddl, at the time of this post, no regular source is available (afaik). I recommend to open a SR at MOS and ask for a signed version of orapwdfltr.dll. Maybe it helps to drop a comment about Bug 31134430 đ
A bit THANK YOU to Stefa Oehrli who answered uncountable number of questions.
Keine Kommentare:
Kommentar veröffentlichen