OAS Sign-In Delays: When AD Users Are Fast but weblogic Is Slow
This case focused on lookup delays in the Authentication Provider chain rather than server resources. We examined where time was spent while looking up the weblogic account, which was absent from AD, and reviewed connection/search limits and referral behavior. Provider order and JAAS Control Flags also determine which provider runs next and whether the overall sign-in succeeds.
At first, this sounded like a typical “post-migration performance” complaint: after moving to OCI, users said sign-in felt slow and the UI felt slow. But once we timed sign-in properly, a very specific pattern showed up.
Normal business users (from AD) sign in quickly, similar to on-prem.
But the weblogic account (admin user) takes 2+ minutes to sign in.
And that delay is consistent across both WebLogic Console and Analytics.
Note: dashboard load time can be slow for all users for a completely different reason (query/DB track). I intentionally separated that from the sign-in issue in this post.
- Normal users: managed in Microsoft AD
- weblogic: exists only in embedded LDAP (DefaultAuthenticator)
- Security Realm: ADAuthenticator + DefaultAuthenticator
The absence of weblogic from AD is not itself a fault. A slow AD lookup can delay sign-in for a local account. Whether authentication proceeds through DefaultAuthenticator, and whether it ultimately succeeds, also depends on provider order and each JAAS Control Flag.
Flow to check in this case: enter weblogic → inspect the AD lookup result → authenticate through DefaultAuthenticator as determined by provider order and JAAS Control Flags → check the overall result
In reality, the AD provider can spend time in multiple places: establishing the LDAP connection, performing the search, or chasing referrals. If any of those steps wait too long, the “not found” result is delayed, and the admin sign-in feels “stuck”.
Do not assume that a user absent from AD immediately falls through to the next provider. Check provider order and JAAS Control Flags as well as lookup timing. Review connection limits, search-result limits, and any expansion of the lookup through referrals separately.
During the slow sign-in window, we repeatedly saw multiple LDAPConnThread threads and a recurring socketRead0 pattern. Even when the Java thread state shows RUNNABLE, the stack can represent native I/O wait (waiting on a response).
java.net.SocketInputStream.socketRead0 java.io.BufferedInputStream.read / fill netscape.ldap.ber.stream.BERElement.getElement netscape.ldap.LDAPConnThread.run
Seeing LDAP wait patterns does not automatically prove LDAP is the root cause. The stronger proof is to correlate the actual login request thread (ExecuteThread / request thread) and show it is blocked in the authentication path.
PID=<bi_server1_pid> jcmd $PID Thread.print > /tmp/bi_server1_td_1.txt sleep 10 jcmd $PID Thread.print > /tmp/bi_server1_td_2.txt sleep 10 jcmd $PID Thread.print > /tmp/bi_server1_td_3.txt
We separated lookup timing from the scope of directory searches. Connection limits, search-result limits, and referrals address different parts of the request. Reducing lookup latency does not automatically change provider order or the conditions for successful authentication.
-
Set a finite Connect Timeout
Connect Timeout limits the time to establish an LDAP connection, in seconds. A value of 0 specifies no connection timeout limit. The existing 10–30-second example is not a universal recommendation; choose a value using measured normal connection times and failure-handling requirements.
Key pointConnect Timeout only covers establishing the connection. If the connection succeeds but the LDAP search is slow, you need a separate search/response time limit.
-
Set a finite Results Time Limit (search/response)
Results Time Limit limits the wait for LDAP search results, in milliseconds. Do not apply the existing 2000–5000 ms example unchanged: check normal lookup times, group size, and the behavior of your WebLogic version. This setting alone does not guarantee a bound on total sign-in time or every socket wait.
-
Use “Follow Referrals” only when required
Check whether referrals extend a lookup to another LDAP server. They may be required for authentication across domains or directories. Before disabling them to reduce latency, confirm the intended lookup targets, access permissions, and authentication requirements.
-
Keep Alive is supportive, not the main fix
Keep Alive concerns connection reuse. Review connection reuse separately from connection, search, and socket-wait limits. No single setting guarantees a worst-case sign-in time.
-
Restart after changes
Use the documentation and administration interface for your WebLogic version to determine whether each change is dynamic or requires a restart. If a restart is required, plan the maintenance window, impact, and rollback, then compare sign-in times before and after the change.
The weblogic sign-in time dropped from “minutes” to a shorter, more predictable window (tens of seconds). AD user sign-in remained fast.
Do not change REQUIRED to SUFFICIENT solely to address latency. REQUIRED means that this provider must authenticate successfully. With both AD and local users, review provider order and all Control Flags against the intended success and failure conditions for both groups. The existence of a local account alone does not make REQUIRED a universally safe choice.
Investigate lookup latency separately from authentication policy. Measure time spent in AD and check how each provider success or failure contributes to the overall result. Do not identify a particular Control Flag or timeout as the cause without the complete configuration and evidence.
Even if AD quickly returns user not found, subsequent processing depends on provider order and JAAS Control Flags. If responses are slow, examine connection, search, referrals, and socket waits separately, then compare actual sign-in timings.
- Measure WebLogic Console sign-in time with weblogic (3 trials)
- Measure Analytics sign-in time with weblogic (3 trials)
- Confirm AD user sign-in performance did not regress
- If still slow: recapture dumps and correlate request threads ↔ LDAP wait paths
If sign-in is normal but dashboards remain slow, investigate that stage separately. Work with the DBA on Physical SQL, execution plans, and DB waits. If query timings do not explain the delay, also check result delivery, networking, server processing, and browser rendering.