OID 10g PL/SQL External Authentication Plugin to MS AD Not Behaving According to the AD Password Policies - AD Accounts Getting Locked Sooner Than Expected From Bad Password Attempts (Doc ID 566928.1)

Last updated on APRIL 11, 2017

Applies to:

Oracle Internet Directory - Version 9.0.4 to 10.1.4 [Release 10gR1 to 10gR3]
Information in this document applies to any platform.
This problem can occur on any platform.

Symptoms

Using the External Authentication PL/SQL based Plugin(s) in Oracle Internet Directory (OID) for authentication against Microsoft Active Directory (AD).

Already implemented workaround from <Note 444256.1> in the plugin package(s).

The plugin(s) had been working ok until a restart of AS/OID infrastructure.

Since then, experiencing erratic behaviour of the plugin(s) as compared to the AD password policies in
place. The login attempts failures/successes do not correspond to the AD password policies configuration.

For example, when the users login only once with a wrong password their accounts are locked in AD,
whereas AD is set to lock the user only after 4 successive wrong passwords.

Even after making adjustments to ensure all plugins' configuration were correctly set for their respective users' containers (stored in the orclPluginSubscriberDNList attribute of each plugin), the behavior changed to an AD account getting locked after only two bad password attempts, so the plugin continues not to work correctly.

After examining OID debugged logs and plugins debugged tables, OID fires only one plugin per login
attempt, for example:

In testing the following sequence of ldapcompares via command line, to mimic login attempts:
- 1 successfull compare operation
- 1 failed compare operation
- 1 successfull compare operation
- 3 failed compare operations

The OID debugged log shows the compares accordingly - selecting only the result = <ldap error code> corresponding lines:

23:37:07 * INFO : gslfrsASendLdapResult2 RESULT = 6 nentries=0 <<< 1 successfull compare op
23:37:43 * INFO : gslfrsASendLdapResult2 RESULT = 5 nentries=0 <<< 1 failed compare op
23:37:54 * INFO : gslfrsASendLdapResult2 RESULT = 6 nentries=0 <<< 1 successfull compare op
23:38:21 * INFO : gslfrsASendLdapResult2 RESULT = 5 nentries=0 <<< 1 of 3 failed compare op
23:38:26 * INFO : gslfrsASendLdapResult2 RESULT = 5 nentries=0 <<< 2 of 3 failed compare ops
23:38:32 * INFO : gslfrsASendLdapResult2 RESULT = 5 nentries=0 <<< 3 of 3 failed compare ops


However, the package debug table output reports failed attempts multiple times. Searching the debug table output for only the occurrences of "simple_bind_res" calls corresponding, there are two appropriate entries for the sucessful attempts (one with a timeout error 81 and a retry, which is normal and can be ignored), but it then reports fourteen (14) entries for failed attempts:

simple_bind_res: 0 <<< 1 successfull compare operation
simple_bind_res: 49 <<< 1 failed compare operation
simple_bind_res: 49
simple_bind_res: 49
simple_bind_res: 49
simple_bind_res: 49
simple_bind_res: 49
simple_bind_res: 49
simple_bind_res: 49
simple_bind_res: 81
retry unbind_res returns 0
simple_bind_res again: 0 <<< 1 successfull compare operation
simple_bind_res: 49 <<< 1 of 3 failed compare operations
simple_bind_res: 49
simple_bind_res: 49 <<< 2 of 3 failed compare operations
simple_bind_res: 49
simple_bind_res: 49 <<< 3 of 3 failed compare operations
simple_bind_res: 49


 

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms