WebLogic supports several types of external authentication providers. Any LDAP v2 or v3 compliant LDAP server should work. Next, we cover the configuration of the Microsoft Active Directory provider in detail, to provide us also with the support for Kerberos Single Sign-On (SSO) integration in a Microsoft domain network; we will see this in Chapter 5, Integrating with Kerberos SPNEGO Identity Assertion.
There are lots of advantages by connecting an existent Users and Groups infrastructure. It permits us to centralize any object (Users and Groups) and centrally manage the security rules and policies without the need to access the WebLogic server. Also, any change applied on Active Directory is logically and dynamically propagated to WebLogic security.
To configure our provider faster and easier, we can use the WebLogic console (advanced users can also use the WebLogic Scripting Tool (WLST) to make many configuration changes) with an administrative user. Go to the Security Realms menu and click on Providers. Now we need some important information, which is as follows:
The console path for Providers is Security Realms | myrealm | Providers.
Click on the Lock & Edit button, proceed to the New button, naming your provider with a personal reference, select the type as LDAPAuthenticator and click on OK.
More important is the order of providers; WebLogic Security Framework supports more than one Authentication Provider for multipart authentication.
The Authentication Providers need to be arranged in the order in which they will be called; it is important to plan the correct sequence in the login process, the first one starting at the top. You need to use the Reorder button to do it.
I advise you to leave the default providers as they are. In this way, you separate and preserve the internal groups and users, most importantly the WebLogic administrator, and you start managing WebLogic without any external providers (think about some connectivity issues to the LDAP/Active Directory server). Afterwards, mapping internal groups to external groups becomes an easy task.
You need to create the same group name in the external provider and associate the external users to it. For this rule, remember that the Active Directory Server also has a default group called Administrators; these users will be automatically grouped as WebLogic Administrators when the provider is configured.
The console path to work with the Control Flag parameter is Security Realms | myrealm | Providers | Authentication. Another important parameter present in all authenticator is the Control Flag parameter. It establishes how the login sequence uses the Authentication Provider. Using it, we can tweak the security flow process. The available options are as follows:
In our scenario, we need to configure one provider connected to Active Directory and leave the default provider, reorder the most-used provider on top, (in our case Active Directory) and switch to SUFFICIENT all the provider control flags, as shown in the following diagram:
Obviously, to configure this provider, we need to have an Active Directory domain structure configured with some groups and users, and know some specific attributes of any customization about your internal LDAP.
Let's start to review the parameters in detail.
A detailed explanation of the connection parameters are as follows:
test.directory.int:1090 test2.directory.int:1091 test3.directory.int
.3268
).EXAMPLEDOM.INTUsers ecnicalusr
LDAP user, we use cn=tecnicalusr
, cn=Users
, dc=exampledom
, dc=int
. Remember, the pre-configured folders in the Active Directory are defined as cn
(for example, Users), the custom folders objects will be ou
in your principal definition path.The parameters for Users are as follows:
dc=exampledom
, dc=int
.(&(sAMAccountName=%u)(objectclass=user))
The parameters for the Groups tab are as follows:
dc=exampledom, dc=int
.(&(cn=%g)(objectclass=group)).
0
, only the direct membership group will be found. If you specify any positive number, for example, 1
, WebLogic will be able to find the first group membership and the second group inclusion level.The parameters for Static groups are as follows:
cn
group
member
(&(member=%M)(objectclass=group))
The General parameters section is as follows:
I recommend you to specify the number of seconds; if you set this parameter to 0
, no time limits will be set and you can incur a slowdown in performance and a potential stuck thread problem. Another important aspect of impacting 0
seconds configuration is if you have a list of Active Directory servers, this will not be used because the process is still awaiting a response from the first server in the list. For a good failover, the time is well set between 10-15
seconds in a production environment where more than one Active Directory servers don't increase this number too high. If this timeout is low, you can improve the performance of the login authentication phase in case of an Active Directory failure; this permits us to balance the second Active Directory node in the list.
1
to switch fast to the second backup Active Directory server; in this way the user login phase can't still wait on the browser side and avoid a timeout issue.0
, no timeout occurs; configure 0
only if you have more than one Active Directory server and some parallel connections, otherwise consider setting up some seconds after a query times out, to avoid a stuck thread problem in a waiting query response.6000
. Consider tuning this value, according to the dynamicity of your Active directory user and group configurations.GroupID
attribute defined in the Active Directory; the default value is objectguid.
Leave any other setting to the default value or customize it if you have any specific requirement. Now, remember to save any changes made if you have configured your WebLogic installation in production mode. Apply these changes with the green flag button and restart all the servers and also the Admin Server.
After startup, go to Security Realms | myrealm | Users and Groups and check if users and groups are configured in your Active Directory server, otherwise check your WebLogic Admin Server logfile and jump to the Troubleshooting problems section.
If you have too many results in the list, you can filter on top of the table using the Customize this table link. Here, you can insert a filter using a filtering criteria text string or search using a query such as username*
. You can also specify the number of rows displayed per page.
The console path to work with the Performance option is Security Realms | myrealm | Providers | MyProvider | Performance.
In this section, you can tune some parameters according to your Active Directory users and groups' hierarchy dimensions. The Hierarchy Caching option can improve the server performances; disable this function only if you have poor WebLogic server system resources or a small Active Directory tree without nested groups.
The first flag defines if the WebLogic server will be able to cache some levels of the hierarchy group memberships or not. Some hierarchy functions are as follows:
100
. Increase this value if you have many nested groups. Oracle recommends a value of 1024
.60
seconds. Oracle recommends setting this value to 10
minutes, but keep in mind all the previous considerations.The console path to work with this option is Security Realms | myrealm | Performance | Enable WebLogic Principal Validator Cache.
To improve your WebLogic Security Framework performance, keep this option enabled—it's enabled by default. Here, you can set the number of principals to be cached; the default value is 500
.
WebLogic security realm is a fundamental part of the startup phase. Here, in the first instance, the server needs to find the user configured to boot the Admin serve; after this, we need to have all the security providers—including the Authentication Provider—that have a JAAS Control Flag set to OPTIONAL to complete the initialization phase.
If the initialization phase cannot be completed correctly, the WebLogic server boot fails, displaying an error similar to the following one:
<BEA-090870> <The realm "myrealm" failed to be loaded:
If you have some problems connecting from the Active Directory side, you can look for some errors in your WebLogic logfiles. Let me show you some error messages, as shown in the following code snippet:
Caused by: netscape.ldap.LDAPException: error result (49); 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 525, v1772; Invalid credentials
In the previous error message, the error result (49)
error value is encountered when you have provided invalid credentials to log in in the Active Directory Server. In the previous error message, you can also find the LDAP error code 525
.
The following are some LDAP error codes and their corresponding descriptions:
525
: User not found52e
: Invalid credentials530
: Not permitted to log in at this time531
: Not permitted to log in from this workstation532
: Password expired533
: Account disabled701
: Account expired773
: User must reset password775
: User account lockedThe following exception can be encountered when WebLogic can't connect to the Active Directory server. To troubleshoot this problem check your Hostname/IP or Port:
Caused by: netscape.ldap.LDAPException: Connection refused (91)
If the error (32)
error message is raised, then check the filter configurations. This error is encountered when the filter can't find any entries that match the search filter criteria.
To find out more about the LDAP error code, check out the com.novell.ldap.LDAPException
class from http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPException.html, or try to look for the class LDAPException
on the Web using your favorite search engine.
Locking a user is an internal process; it doesn't impact the Active Directory users. If you enable the User Lockout option with an Active Directory configuration, remember you need to unlock this user using the WebLogic Admin Console and not using the Active Directory Users and Group Microsoft utility tool.
Think of this as a pre-filter that will cache a user state (enabled or disabled) on the WebLogic layer. It is a better choice for simplifying and centralizing the user security policy lockout on the Active Directory side to disable this feature.