Debugging Weblogic



Login information and group memberships (identity) often are centrally managed in Enterprises. Many systems use this information to, for example, achieve Single Sign On (SSO) functionality. Surprisingly, access to the Weblogic Server Console is often not centrally managed. This is caused by a common misconception that achieving centrally managed Weblogic Server Console authentication/authorization is difficult. As a result, often there are many local Weblogic Server users or everyone uses system users. Both workarounds have obvious disadvantages.


If you can obtain user and group information from a centrally managed authorization/authentication provider, you only need to manage those users there. As an additional benefit, the developers only need to keep track of a single password instead of a password per server. This increases security and developer productivity. Also it reduces operational cost. Your server landscape could for example look like the image below where minimal effort is required for user administration while still implementing a separation of concerns between development/test and acceptance/production. This separation is usually a requirement when different people are responsible for the environments and/or environments are on different network segments.



An LDAP server is often used to manage identity. Usually there is already a managed directory service provider present in an organization such as Oracle Directory Server or Microsoft Active Directory which contains users, groups and login credentials. In Weblogic Server you can configure authentication providers to allow usage of such servers to allow access to the Weblogic Server Console.


The complexity of using an external LDAP provider as authenticator for Weblogic Server, is often overestimated, especially if a configuration does not work as expected. What can you do to find out what’s wrong? In this article I will provide suggestions on how authentication using an external LDAP server can be debugged in order to lower the bar to apply this configuration pattern.


Debugging authentication using Weblogic Server Console


The below decision tree can help with debugging configuration issues in a Weblogic Server. The steps are also described in the text below in more detail. The tree is specific to a configuration where you can login with users from the DefaultAuthenticator (Weblogic embedded LDAP server) and from an external authentication provider.




Because changes in authentication provider configuration usually require a server restart, a trial and error approach is not recommended.





I will use ApacheDS as an example open source LDAP provider. This is not a provider for which a specific authenticator exists in Weblogic Server (such as for Oracle Directory Server or Microsoft Active Directory). That is why the general LDAPAuthenticator needs to be used.



Control flags and authentication provider order


The control flags and provider order determine the authentication behavior of Weblogic Server. If an authentication provider has the control flag REQUIRED, then every user needs to be present also in that authentication provider. This is the default setting for the DefaultAuthenticator. The DefaultAuthenticator uses the Weblogic Server embedded LDAP server. If you want to allow login of users which are only present in another authentication provider but still allow the users in the embedded LDAP to login, the DefaultAuthenticator and other authentication provider should have their control flag set to SUFFICIENT. Mind the order of the authentication providers. The LDAPAuthenticator cannot be the first authentication provider. More specific authentication providers do not have this limitation.







The LDAP queries


An important part in configuring Weblogic Server is setting the correct queries to determine the users and groups. A query is executed using a connection with a user which is specified as the Bind DN (distinguished name). This is usually a system user with administration privileges on the LDAP server. The query itself consists of a Base DN which defines which part of the LDAP server will be searched and the actual LDAP query. Bind DN, Base DN and query depend on your LDAP configuration and structure.


LDAP servers can use different patterns to identify members of groups. The Weblogic Internal LDAP server has its groups listed under the specific users using the wlsMemberOf attribute and uses so-called dynamic groups to determine group members. The default ApacheDS LDAP structure has the users listed as part of the group using the uniqueMember attribute (static groups). These 2 examples require different queries. You can use your favorite LDAP browser (for example Apache Directory Studio or JXplorer) to create and test your query before configuring it in Weblogic Server. Also carefully look at the default queries.



The GUID Attribute


In order to uniquely identify an LDAP object, the GUID (global universal identifier) attribute is used by Weblogic Server. This is an attribute available as part of every relevant LDAP object. Different LDAP servers use different default GUID attributes. If no default attribute is present, the entryUUID attribute can be used, because it should be available in every LDAP server (RFC4530).



Browse users and groups


The first thing to do after you have configured the queries and Weblogic Server has been restarted, is to check under your security realm if the users and groups from your newly created authentication provider are visible. Also open up a user and check the groups tab under that user since a different query is used to obtain groups for a specific user. If the groups cannot be fetched for the user, there is probably something wrong with the group query or with the defined GUID Attribute.



Try logging in


If the users and groups are visible, it is time for the final test. Try to login the Weblogic Server Console using a user within a group that is allowed (Monitor, Operator or Administrator). If the first login fails and the second works, then most likely you’ve neglected to set the GUID Attribute. Also mind that for Oracle SOA, the user also needs to have one or more of the application roles SOAMonitor, SOAAdmin or SOAOperator in order for the Enterprise Manager Fusion Middleware Control to function properly.

If it works, you’re done. If it doesn’t work, read on.



Debugging authentication using log files


Authentication debug flag

The LDAP authentication can be debugged by setting the debug flag for DebugSecurityAtn. This can be done by clicking the server in Weblogic Server Console, go to the debug tab and browse the relevant setting under weblogic, security, atn.


You can now see a lot of security related information in the server logfile such as connection issues, login attempts and LDAP queries. Below are some examples for the DefaultAuthenticator and for an external LDAP server accessed with the LDAPAuthenticator.




Below you can see the DefaultAuthenticator is used (Weblogic Internal LDAP v2 server). The user dummy is not found. You can also see the LDAP query which is being executed to find the user.


<BEA-000000> <authenticate user:dummy>

<BEA-000000> <getConnection return conn:LDAPConnection { ldapVersion:2 bindDN:""}>

<BEA-000000> <getDNForUser search("ou=people,ou=myrealm,dc=DefaultDomain", "(&(uid=dummy)(objectclass=person))", base DN & below)>

<BEA-000000> <DN for user dummy: null>

<BEA-000000> <returnConnection conn:LDAPConnection { ldapVersion:2 bindDN:""}>

<BEA-000000> <getConnection return conn:LDAPConnection { ldapVersion:2 bindDN:""}>

<BEA-000000> <DN for user dummy: _NOT_EXIST_>

<BEA-000000> <returnConnection conn:LDAPConnection { ldapVersion:2 bindDN:""}>

<BEA-000000> < [Security:090302]Authentication Failed: User dummy denied.


In the below example, you can see the user weblogic is found but an incorrect password was used.


<BEA-000000> <authenticate user:weblogic with DN:uid=weblogic,ou=people,ou=myrealm,dc=DefaultDomain>

<BEA-000000> <getConnection return conn:LDAPConnection { ldapVersion:2 bindDN:""}>

<BEA-000000> <authentication failed 49>

<BEA-000000> <returnConnection conn:LDAPConnection { ldapVersion:2 bindDN:""}>

<BEA-000000> < [Security:090302]Authentication Failed: User weblogic denied





In the below examples, the LDAPAuthenticator is used to access an external ApacheDS LDAP server. Below, the LDAP server cannot be accessed.


<BEA-000000> <authenticate user:maarten>

<BEA-000000> <new LDAP connection to host localhost port 10389 use local connection is false>

<BEA-000000> <Connecting to host=localhost, port=10389>

<BEA-000000> <connection failed netscape.ldap.LDAPException: Permission denied: connect (91); Cannot connect to the LDAP server>


The below example is a bit more difficult.


<BEA-000000> <authenticate user:maarten>

<BEA-000000> <getConnection return conn:LDAPConnection {ldaps://localhost:10389 ldapVersion:3 bindDN:"uid=admin,ou=system"}>

<BEA-000000> <getDNForUser search("ou=users,ou=system", "(&(uid=maarten)(objectclass=person))", base DN & below)>

<BEA-000000> <returnConnection conn:LDAPConnection {ldaps://localhost:10389 ldapVersion:3 bindDN:"uid=admin,ou=system"}>

<BEA-000000> <java.lang.NullPointerException at


After a retry with the same credentials login succeeded. The cause is related to the GUID Attribute setting. If left empty, this error occurs. After disabling the LDAP cache, the error also does not occur anymore, hinting to usage of the GUID Attribute by the LDAP cache.





As shown in this article, there are several things to mind when configuring an external LDAP server for authentication to the Weblogic Server Console. Debugging issues however, as shown, is not difficult. In this article I have provided a decision tree, important background information considering settings and some examples to help you with the most common errors. The benefits of centrally managing users for the Weblogic Server Console are obvious. You can dramatically reduce the amounts of users which need to be managed. This has security benefits, increases developer productivity and reduces operational cost. Below are several suggestions to pay attention to when configuring Weblogic Server to use an external LDAP provider.

  • Every security provider configuration change, requires a Weblogic Server restart.
  • The Weblogic Server logs shows the LDAP queries executed. You can test these same queries with an external LDAP client such as Apache Directory Studio. Testing the queries first might reduce the number of restarts required to get a configuration working.
  • Pay special attention to the control flags. If the DefaultAuthenticator is set to REQUIRED (the default setting), setting another LDAP provider to SUFFICIENT, will not allow users to login unless they are also present in the DefaultAuthenticator. When using an external LDAP and the DefaultAuthenticator + external LDAP authenticator have their control flag set to SUFFICIENT and a user is not present in the DefaultAuthenticator, the external LDAP is queried.
  • When using an external LDAP server using the LDAPAuthenticator as the first authentication provider, Weblogic Server will not start anymore. This can be fixed by editing the config.xml file and changing the order of the providers. When using a more specific LDAPAuthenticator (when available for your LDAP server) this problem does not occur.
  • If you need to login twice before authentication is successful, check the GUID Attribute in the provider specific properties of the LDAPAuthenticator
  • Check which LDAP server is queried. The embedded LDAP server can easily be confused with an external server.


For more specific information and background, you can check out several articles on the AMIS Technology blog site concerning this topic:



Fusion Middleware Securing Oracle WebLogic Server: Configuring Authentication Providers

Oracle® Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite. Roles and Privileges for Oracle SOA Suite Users in Oracle Enterprise Manager

Weblogic Server Fails to Start when Configured for LDAP Authentication (Doc ID 1331981.1)

Apache Directory Studio


OTECH MAGAZINE #7  spring 2015        copyright otech magazine 2015