APEX and Active Directory(what is in bindDN?)

I was setting up Active Directory(AD) authentication for an Oracle APEX application. The settings seemed to be straight forward, but authentication did not succeed. So it was time to fire up ldapsearch from the Oracle db server serving APEX, but found same issues.

After a lot of googling, I did not find any issue being documented for this problem. Then I thought this may not be an issue per say, but how information is perceived by the AD server or how these accounts were set up in AD.

So went further digging on our side ...

I was using samaccountname for bindDN that seemed to work for some application(service) account, but not for my own account. Found some interesting info related to AD or how it was set up in our environment.

- If "samaccountname" to be used for bindDN, then it need to be suffixed with "@domain-name.com" as appropriate.
- One can use "cn" (sn, givenName) as the bindDN if it leads to a unique entry.
- One can use "dn" for bindDN, but this is not user friendly as it is a long one with all the OU and DC info.


Then there were a couple of service accounts that did not seem to have any problem authenticating using samaccountname only, without @domain-name.com appended to it. This one was very confusing initially, but found out that these service accounts were created with no last name(sn), so their first name(givenName) matched their cn and samaccountname. In essence, we thought we were specifying samaccountname for the service accounts, but it was reall their "cn".

So this is how APEX authentication scheme screen finally looked like.

Google search results were hijacked by search.search-tab.com

My wife told me a few days ago that the links from Google search results were hijacked on our home computer. Clicking on links from google keyword search results in Firefox showed unrelated pages, but cutting and pasting the URLs in the address bar seemed to work fine.


She logs in as a restricted Windows user and has been doing Alt+F4 on any ad-window or unrelated pop-ups that beat Fire-fox's block pop-up settings.

Malware bytes's Anti-malware some times showed that it blocked illegal access to an IP address, but it did not happen every time unrelated content showed up. Running Malware scan or Norton did not find anything whether it was a quick scan or full scan. After googling for some time, the problem was found to be related to "keyword.url" configuration property accessed through "about:config" URL. This URL was pointing to "search.search-tab.com" on our home computer. So I reset this property, restarted Firefox to see this problem come up again and the URL was still pointing to search-tab.com.

So I decided to manually clean up this entry found in both user.js and prefs.js under
Documents and Settings/<username>/Application Data/Mozilla/Firefox/Profiles/.default/ directory.

So it seems to be working since then, but I wonder how long?