GWME-7.1.1-11 - Foundation update with Advanced LDAP

compared with
Current by Hans Kriel
on Sep 01, 2017 23:11.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (12)

View Page History
** The need to authenticate users whose accounts are located in multiple containers in the same catalog
** The need to authenticate users whose accounts are located in nested containers
** Corrected Exoadmin screen for Membership permissions
* GWMON-13139, GWMON-13126 - Resolve issue with a comma in the LDAP AD Distinguished Name field which cause 403 Not Authorized error on Role Search

Further we are rolling up the changes incorporated in other patches which alter war and jar files touched in this patch, these patches are no longer required and should not be applied once this patch has been deployed:
The patch directory will be noted *(in the production version of the updater)* with the facts of this update, along with backup files to be used in the uninstall phase if necessary.

Jar file names are correctly identified with -11 suffix. Note that the -11 suffix is important to you when executing the command line hash generator.

In the event that you had previously installed TB7.1.1-1 and/or TB7.1.1-8 this patch will detect the condition. It will handle both making a backup to restore the files involved as well as replacing the -1 and -8 patch files with the rolled up patches.

h2. Configuration

Application of this upgrade on a system using the default authentication requires no further configuration.

For LDAP support, "josso-gateway-config.xml" must reference "josso-gateway-ldap-stores.xml" and not the "josso-gateway-gatein-stores.xml".

Application on a system previously configured with Josso Ldap store will result in continued operation using the legacy credentials in the "josso-gateway-ldap-stores.xml" file.
h3. Enabling LDAP Authentication

The use of the LDAP authentication is controlled by the same setting in :"josso-gateway-config.xml" which is defaulted to use the local gatein store. To facilitate use of LDAP AD or OpenLDAP you will first change the following line. If LDAP was previously enabled the change will already be present.

Edit "josso-gateway-config.xml" and replacing:
h4. Security credential encryption

The security credential is still required as an encrypted string. Use the following command lines to generate the string, substituting the actual password for the example PASSWORD
{noformat}
/usr/local/groundwork/java/bin/java -cp /usr/local/groundwork/jpp/modules/org/jasypt/main/jasypt-1.9.2.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/codec/main/commons-codec-1.4-redhat-2.jar:/usr/local/groundwork/jpp/modules/com/groundwork/collage/main/collage-api-7.1.1-6.jar:/usr/local/groundwork/josso-1.8.4/lib/commons-logging-1.1.1.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/configuration/main/commons-configuration-1.6-redhat-2.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/lang/main/commons-lang-2.6-redhat-2.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/collections/main/commons-collections-3.2.1-redhat-2.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/lang3/main/commons-lang3-3.2.jar:/usr/local/groundwork/jpp/modules/com/chrylis/base58-codec/main/base58-codec-1.2.0.jar /usr/local/groundwork/jpp/modules/org/jasypt/main/jasypt-1.9.2.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/codec/main/commons-codec-1.4-redhat-2.jar:/usr/local/groundwork/jpp/modules/com/groundwork/collage/main/collage-api-7.1.1-11.jar:/usr/local/groundwork/josso-1.8.4/lib/commons-logging-1.1.1.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/configuration/main/commons-configuration-1.6-redhat-2.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/lang/main/commons-lang-2.6-redhat-2.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/collections/main/commons-collections-3.2.1-redhat-2.jar:/usr/local/groundwork/jpp/modules/org/apache/commons/lang3/main/commons-lang3-3.2.jar:/usr/local/groundwork/jpp/modules/com/chrylis/base58-codec/main/base58-codec-1.2.0.jar org.groundwork.foundation.ws.impl.JasyptUtils --encrypt PASSWORD 2>/dev/null
{noformat}
The result will look like this:
{noformat}

Alternatively, you may define two or more endpoints for the same LDAP, naming scope as the "BASE" (just the indicated container or OU) or "ONE LEVEL" (objects subordinate to the named base but _not the base_) instead of "SUBTREE" (the base name and all nested objects to the maximum depth). In this way you can limit the searches according to the manner by which the customer has organized users.

h4. LDAPS connections
{noformat}

h34. Examples

Here are three examples of working configurations.
Take special note of the "domain" portion of the configuration in each example. Both "windows2012" and "demo" are arbitrary. The actual domain names are "corp" and "demo". We suggest avoiding using the actual domain name so that it does not become the unconscious rule, later causing an error where the actual domain had a character like "." embedded.

Whatever you decide, the string you choose will be the one that users must enter, so for example "demo/jdoe" or "jsmith\windows2012"
Whatever you decide, the string you choose will be the one that users must enter, so for example "demo/jdoe" or "windows2012\jsmith". The slash can go either way, the form is always domain followed by slash followed by user.

Note that the port is not specified if the server you are pointing to is using default settings (389 for cert-less, 636 for LDAPs). In the third example you can see the form used for specified port.

{noformat}
# 'windows2012' AD endpoint:
#
core.security.ldap.config.server_type = AD
core.security.ldap.config.provider_url = ldaps://10.0.0.35:636
core.security.ldap.config.security_principal = cn=ldapauth,cn=Users,dc=demo,dc=com
core.security.ldap.config.security_credential = 3eH7t2u82Cc4nfeNqW7fxK3mboEMkMBmY