Debugging Weblogic authentication
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.
Scroll down to see the complete article
Scroll down to see the complete article
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.
ApacheDS
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.
DefaultAuthenticator
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>
<javax.security.auth.login.FailedLoginException:
[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>
<javax.security.auth.login.FailedLoginException:
[Security:090302]Authentication Failed: User weblogic denied
LDAPAuthenticator
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 weblogic.security.providers.authentication.LDAPAtnDelegate.getDNForUser(LDAPAtnDelegate.java:3861)
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.
Conclusions
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: https://technology.amis.nl/?s=ldap
References
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
No comments:
Post a Comment