IBM Support

User Lookup Helper does not consider SSL Port correctly

How To


Summary

When using the Runtime environment (RTE) initialization of the User Lookup Helper (ULH), the SSL port is not considered correctly while ssl-enabled is defined in ivmgrd.conf.

When setting the non-ssl LDAP port in ldap.conf to 636, the ULH is connecting correctly.
The runtime trace shows that the connection uses <URL>:389:readwrite:5.
(FYI: One cannot use a different init method since you depend on a federated AD with Basic Users. )

The reason for this behaviour is that the ULH only works with Federated Registries and Basic Users if using RTE. It assumes SSL for directory connection.

The ULH cannot assume that it is running on the same appliance as a policy server, so it cannot rely on using ivmgrd.conf, and it has to use ldap.conf.

You should put a cert for internal LDAP into your registry keystore with AD cert and update ldap.conf, pd.conf, ivmgrd.conf and webseald.conf. Specify a keystore in your ldap.conf when there is SSL to AD if required.

And yes, ISAM is reading non-ssl port from LDAP servers and then is trying to connect via SSL. (ie. it uses the port parameter and not ssl-port parameter for connection so you need to change port to 636 to make it work.)

By the way, User Lookup Helper is also used for username password mechanism and within AAC mapping rule.

Steps

In order to circumvent this problem take the following setup procedure into account, that will enable you to use:
- UserName / Password AAC Authentication mechanism using the ISAM RTE
- the UserLookupHelper connecting to ISAM RTE (and all the configured federated repositories with basic users)
- the SCIM prerequisites
  • Configure the Runtime environment

    When initially configuring the RTE, select a local Policy server and a remote LDAP server pointing to your embedded LDAP (instead of local Policy Server/local LDAP server).
    Configure the connection to your local embedded LDAP using:
    - hostname: your appliance's LMI hostname
    - port: 636
    - enable ssl
    - Select a keystore that contains the CA certificates of ALL the federated repositories you want to connect to and also the CA for your embedded ldap.
    Reason: The embedded LDAP does not listen on port 636 on the localhost/loopback/127.0.0.1 interface !

  • Update ldap.conf

    Set the host to the ip address or hostname of your LMI, since it cannot be set to 127.0.0.1 as explained in the previous step
    Set the port to the same value as ssl-port (default:636) 
    e.g.
    [ldap]
    host = 192.168.18.250
    port = 636
    ssl-port = 636

    ssl-keyfile = yourkeystore.kdb

    The keystore you set here must contain all the CA certificates for the federated ldap.  It's likely you have a value there already if you configured Federated Directories already.
    In the default setup, you can export the server certificate from the keystore embedded_ldap_keys , and import it as a CA in "yourkeystore.kdb" .

    Update the bind-credentials, with the username and password for a user that can access the embedded ldap (e.g. cn=root)
    [bind-credentials]
    bind-dn = cn=root,secAuthority=Default
    bind-pwd = <password>

    The ISAM runtime will restart after these changes.
  • Update pd.conf

    Go to "Secure Web Settings -> Manage -> Runtime Component" and navigate to "Manage -> Configuration Files -> pd.conf"
    Edit the pdrte stanza.
    [pdrte]
    user-reg-type = ldap
    user-reg-server =
    user-reg-host = 192.168.18.250
    user-reg-hostport = 636

    Update user-reg-server with your LMI hostname .  Note that you may have to add a host record for your LMI !
    Update user-reg-host with your LMI public ip address (in this example, 192.168.18.250)
    Update user-reg-hostport to match the ssl port (default 636).

    In the ssl stanza enable the TLS 1.1 and 1.2 versions:
    [ssl]
    tls-v10-enable = no
    tls-v11-enable = yes
    tls-v12-enable = yes
     
  • Update ivmgrd.conf

    Go to "Secure Web Settings -> Manage -> Runtime Component" and navigate to "Manage -> Configuration Files -> ivmgrd.conf"

    Enable ssl, and assign the keystore you used earlier.
    ssl-enabled = true
    ssl-keyfile = yourkeystore.kdb
  • Update your WebSEALs / Reverse proxies

    The reverse proxies need to be instructed to connect over ssl.
    So for every reverse proxy, open the "Secure Web Settings -> Reverse proxy" page,  select the reverse proxies one by one and open the Configuration file (webseald.conf): "Manage -> Configuration -> Edit Configuration file"

    Find the [ldap] stanza and enable ssl :
    [ldap]
    ssl-enabled = yes
    ssl-keyfile = yourkeystore.kdb
    ssl-keyfile-dn =

    The keystore you select here should contain the CA certificates for your embedded ldap , and the federated repositories.  
    Leave the ssl-keyfile-dn empty, unless you're using Mutual TLS.

    Restart the reverse proxy after these changes, and repeat for all your reverse proxies.

Internal Use Only

  • https://cloudidentity.atlassian.net/browse/ISAMSUP-621   -  TS002042375
  • Thank you Tom Bosmans for https://www.gwbasics.be/blog.nsf/dx/the-only-correct-way-to-setup-the-isam-rte-with-basic-users-for-the-userlookuphelper.htm

Document Location

Worldwide

[{"Business Unit":{"code":"BU008","label":"Security"},"Product":{"code":"SSZU8Q","label":"IBM Security Access Manager"},"Component":"Advanced Access Control","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Edition":""}]

Product Alias/Synonym

TAM; SAM; ISAM

Document Information

Modified date:
23 August 2019

UID

ibm10884160