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:
- LDAP Authentication Provider type
- Provider-specific configuration attributes of the LDAP Authentication Provider
- Review performance options that control the cache
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:
- REQUIRED: This setting establishes that the provider will always be used; the user needs to be checked in order to obtain a trusted access. In any case the authentication continues to follow down to the other providers in the list.
- REQUISITE: This setting establishes that the user must pass the provider check in order to be granted access, after that, subsequent providers will be executed.
- SUFFICIENT: This setting establishes that the provider does not require the user to pass its check. If it fails, the next provider in the list will be consulted. If the authentication succeeds, no other providers will be used.
- OPTIONAL: This setting establishes that the provider's check can be passed or not. If all providers are configured to OPTIONAL, the user needs to pass the authentication phase in one of that.
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:
- Host: Here, you need to specify one or more Active Directory server; the list separator is a blank space. In a production environment, it is a good choice to specify more than one server for high availability. If some host has a different listening port, specify that in the list, otherwise the port specified in the next field will be used. For example,
test.directory.int:1090 test2.directory.int:1091 test3.directory.int. - Port: Here, you need to specify the Global Catalog TCP/IP listening port (default
3268). - Principal: Here, you need to specify a valid Active Directory base. The user can connect to Global Catalog and make an LDAP query. We need to specify a correct Distinguished Name (DN) of the LDAP user. Suppose we have a
EXAMPLEDOM.INTUsers ecnicalusrLDAP user, we usecn=tecnicalusr,cn=Users,dc=exampledom,dc=int. Remember, the pre-configured folders in the Active Directory are defined ascn(for example, Users), the custom folders objects will beouin your principal definition path. - Credential: Principal user password used to connect to the LDAP server.
- SSLEnabled: Specifies whether an encrypted SSL channel will be used to connect to an LDAP Server. This depends on your Active Directory configuration.
The parameters for Users are as follows:
- User Base DN: Here, you specify the base distinguished name, where our users and groups are located in the Active Directory tree. You can configure the complete tree of Active Directory or a subtree, considering an improved performance while performing search, to dedicate a subtree with a small subset of users and groups. For example,
dc=exampledom,dc=int. - User From Name Filter: Here, you specify the correct filter to search Active Directory users; the default Active Directory configuration can report this query as
(&(sAMAccountName=%u)(objectclass=user)) - User Search Scope: Here, you can select subtree—by choosing this option, the query can navigate on subtree Active Directory levels. It is a good choice, if your configuration doesn't have a dedicated level and you need to cut down some of the trees.
- onelevel: In this case, the query ends on the Active Directory level specified on User Base DN.
The parameters for the Groups tab are as follows:
- Group Base DN: Here, you specify the base distinguished name on the same lines as that of User Base DN and in which level the LDAP query starts for finding the groups. For example,
dc=exampledom, dc=int. - Group From Name Filter: Here, you specify the filter to search Active Directory groups; the default Active Directory configuration reports the query as
(&(cn=%g)(objectclass=group)). - Group Search Scope: In the same way as the User setting, you can define if the query falls down to subtree or stays on the tree specified in the Group Base DN parameter.
- Group Membership Searching: Here, you can select the group searching options. Limited as well as unlimited searches can be made in the groups using this setting.
- Max Group Membership Search Level: If, in the previous parameter, you have selected the limited option, here you can specify how many nested user groups follow. If you specify
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:
- Static Group Name Attribute: In the Active Directory, you need to set this parameter to
cn - Static Group Object Class: In the Active Directory, you need to set this parameter to
group - Static Member DN Attribute: In the Active Directory, you need to set this parameter to
member - Static Group DNs from Member DN Filter: These search filters, which extract the distinguished name of a member of a group, return the distinguished name of the static LDAP groups that contain that member, and set this as
(&(member=%M)(objectclass=group))
The General parameters section is as follows:
- Connection Pool Size: To start with, we can leave the default value as it is. Subsequently, we can tune this parameter if the single queries take a lot of time and the pool will be exhausted.
- Connect Timeout: Here, specify the maximum time in seconds to wait for, until the connection to the LDAP server is established.
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 impacting0seconds 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 between10-15seconds 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. - Connection Retry Limit: This number specifies the total attempts to be made to connect to the LDAP server if the first connection failed. Increase this number to a higher value if you have a single Active Directory server, otherwise set this parameter to a lower value,
1to 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. - Parallel Connect Delay: This parameter specifies the delay in seconds between concurrent connection attempts to multiple LDAP servers; set this parameter to one or more to create connections in parallel, and not serialized if you have an Active Directory failover list.
- Results Time Limit: This parameter specifies the maximum number of milliseconds for the LDAP server to wait for results before a timeout error is raised. If you specify
0, no timeout occurs; configure0only 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. - Cache Enabled: This parameter enables or disables an internal WebLogic cache LDAP flag to improve your performance.
- Cache Size: This parameter defines the size of the cache in KB. Increase this size if you have large Active Directory structure objects and some free WebLogic server resources.
- Cache TTL: This parameter specifies how long the internal cache will be flushed and reloaded. Oracle recommends a value of
6000. Consider tuning this value, according to the dynamicity of your Active directory user and group configurations. - GUID Attribute: This parameter specifies the name of the
GroupIDattribute defined in the Active Directory; the default value isobjectguid.
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:
- Max Group Hierarchies in Cache: This defines the size of the cache used to store group membership hierarchies; the default value is
100. Increase this value if you have many nested groups. Oracle recommends a value of1024. - Group Hierarchy Cache TTL: This defines the number of seconds the cached object will be stored in memory. If you have a quiet static group membership situation, increase this parameter to reduce the queries to the LDAP server and speed up the process exploiting internal cached data. Otherwise, if you have high dynamic membership changes, leave this parameter to the default value of
60seconds. Oracle recommends setting this value to10minutes, 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 locked
The 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.