Password Filter Registry Key On One AD Server Reverting Back To OID Physical Hostname After Reconfigured To Use Load Balancer Hostname
(Doc ID 1368738.1)
Last updated on MAY 21, 2021
Applies to:Oracle Internet Directory - Version 11.1.1 and later
Information in this document applies to any platform.
Several Active Directory (AD) / Domain Controllers (DC) and/or Primary Domain Controllers (PDC) servers were all working fine with Oracle Internet Directory (OID) 11g, i.e., 18.104.22.168 or higher.
Later introduced a load balancer (LBR) that does a ldapbind to both OID servers using a service account. The setup is that everything will point to the primary OID server and if the ldapbind fails, it points to secondary server.
Changed the OID servers' hostnames in new SSL certificates installed in the two OIDs to be the LBR hostname, e.g., <LBR_HOSTNAME.DOMAIN> (which DNS resolves to the primary OID server, e.g., <PHYSICAL_HOSTNAME.DOMAIN>). Reconfigured all the Password Filters to point to the LBR hostname of <LBR_HOSTNAME.DOMAIN>.
All DCs are working fine with this arrangement, and passwords are sync'd to OID with no problems.
However one PDC and one DC do not work in this configuration. The Password Filter worked for one sync cycle and then it stopped working.
After some trial and error, found that the value for one of the Password Filter related registry keys in AD, the OIDHost, was reverting from the LBR hostname back to the OID physical hostname on its own. The same set of keys could be found in different locations, i.e.:
Also found that, after manually updating the OIDHost value back to the LBR hostname, the Password Filter would work for another cycle, but then the key value would revert back to the wrong value again each time.
When the problem happens, it also logs an Event log message:
The certificate received from the remote server does not contain the expected name. <etc>
As seen in <Note:431478.1>, but it only occurs while the hostname is incorrectly set in the registry, and the error states it expects the physical hostname accordingly.
Tried other changes with no success, including:
- Rerunning and reinstalling the Password Filter with setup.exe (which does keep/show the correct hostname immediately after the registry key is manually updated)
- Checking whether being logged on or off to the Windows console made a difference (but it did not)
- Doublechecked forward and reverse hostname lookup DNS resolution, and also compared it to all nodes
Since this was only failing on a couple AD servers, attempted a full reinstall of the O/S and even switched one of the problem nodes to a new hardware and O/S version even, but the same problem persisted with the same nodes, plus later on one other node started to be affected the same way.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document