IBM Security Verify

 View Only
Expand all | Collapse all

Verify Access - LDAP replication

  • 1.  Verify Access - LDAP replication



  • 2.  RE: Verify Access - LDAP replication

    Posted Mon December 12, 2022 03:11 PM

    David,

     

    I don't fully understand what you are asking.  However, if you are asking whether ISVA can be configured to use multiple LDAP replica's for authentication the answer is yes.  On top of this you also have the ability to specify which replicas are read-write and which replicas are read-only.   For further information refer to the product documentation: https://www.ibm.com/docs/en/sva/10.0.5?topic=tasks-ldap-failover-configuration

     

    Thanks.

     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access

    IBM Master Inventor

    cid4122760825*<a href=image002.png@01D85F83.85516C50">

     

     






  • 3.  RE: Verify Access - LDAP replication

    Posted Mon December 12, 2022 04:54 PM

    Hi Scott, thanks for your anwser, It is clear to me that we can have multiple LDAP servers in replica and in various modes (read / write) but can it be guaranteed that the LDAP Master server only receives write requests (not read request)? This operational model for LDAP servers currently works and the client would like to maintain it.



    ------------------------------
    David Vicenteño Sanchez
    ------------------------------



  • 4.  RE: Verify Access - LDAP replication

    IBM Champion
    Posted Mon December 12, 2022 05:52 PM

    Hi David,  Below are my two cents...

    My assumption is that the current microservices component can differentiate between a write and read request before sending the request to write/read server.

    When using ISVA, we need to identify the transactions native/custom to WebSEAL/SCIM/AAC components and then route the transactions accordinly to write or read server.

    For example

    1. If SCIM is used for Self-care, the connection settings could be pointed to Write server.

    2. If WebSEAL/infomap is primarily used for AuthN and AuthZ purposes, you can just simply point to read-only replicas

    3. Other option is to use an InfoMap solution that can emulate the write/read transactions of microservices and use the appropriate connection settings to call write or read server.

    Hope it helps..


    Regards,

    Rama



    ------------------------------
    Rama Yenumula
    ------------------------------



  • 5.  RE: Verify Access - LDAP replication

    Posted Mon December 12, 2022 06:49 PM
    Edited by David Vicenteño Sanchez Tue December 13, 2022 10:09 AM
    Hi Rama, yes your assumption is totally correct, the current microservices component can differentiate between a write and read request before sending the request to the write/read server. I think it's an excellent idea that you have given me, thank you very much.

    ------------------------------
    David Vicenteño Sanchez
    ------------------------------



  • 6.  RE: Verify Access - LDAP replication

    Posted Tue December 20, 2022 04:14 PM

    Hi Rama, I have managed to solve the problem of the replicas in the ldap.conf file, thank you very much for the advice, how can I point to the replica server(s) in an infomap? I usually just use the standard authentication code "var authn = user.authenticate(password);"  Thanks in advance. Regards



    ------------------------------
    David Vicenteño Sanchez
    ------------------------------



  • 7.  RE: Verify Access - LDAP replication

    Posted Mon December 12, 2022 06:03 PM

    Hello David,

    As Scott mentioned before we do have the ability to define LDAP replicas for the Reverse Proxy component.

    The 'ldap.conf' has the following types of entries:

    host

    replica

    The 'host' entry is the equivalent to 'ldaphost,port,readwrite,5' with respect to how it acts with the defined replicas.

    The defined replicas take a hostname, port, mode, and priority with '10' being the highest.

    If you wanted a scenario where writes only went to the primary and reads all went to other servers you could set up your ldap.conf like so:

    [ldap]

    ...

    host = primaryserver.dns.domain

    port = 636

    ...

    replica = readonlymember1.dns.domain,636,readonly,10

    replica = readonlymember2.dns.domain,636,readonly,10

    replica = readonlymemberN.dns.domain,636,readonly,10

    replica = readonlymember9.dns.domain,636,readonly,10

    This would tell the Reverse Proxy to make read requests to the pool of replicas unless they were not available at which point it would send read requests to the priority '5' server, unless that was also unreachable.

    Here are the documentation references for each:

    'host' : https://www.ibm.com/docs/en/sva/10.0.5?topic=ldapconf-host
    'port' : https://www.ibm.com/docs/en/sva/10.0.5?topic=ldapconf-port
    'replica' : https://www.ibm.com/docs/en/sva/10.0.5?topic=ldapconf-replica

    These three entries used together determine how the Reverse Proxy instance communicates with the directory servers.

    I believe the above information was also provided via slack as well.



    ------------------------------
    JACK YARBOROUGH
    ------------------------------



  • 8.  RE: Verify Access - LDAP replication

    Posted Mon December 12, 2022 06:50 PM
    Thank you very much Jack, I will try these configurations just like the ones that Rama has proposed to me.

    ------------------------------
    David Vicenteño Sanchez
    ------------------------------



  • 9.  RE: Verify Access - LDAP replication

    Posted Tue December 13, 2022 07:11 PM
    Edited by David Vicenteño Sanchez Tue December 13, 2022 07:11 PM

    Is it mandatory to use secure port  and the associated certificate database for LDAP instances? I tried but I get these errors




    ------------------------------
    David Vicenteño Sanchez
    ------------------------------



  • 10.  RE: Verify Access - LDAP replication

    IBM Champion
    Posted Tue December 13, 2022 07:57 PM

    Hi David, Glad the suggestion helps you.

    From error message in above thread(line 104),  it appears that the bind credential to connect to LDAP is incorrect.

    Just to isolate the issue, Assuming valid user credentials,

    1. Try and access the LDAP on both secure and non-secure port using an LDAP client utility. Make sure server side setup for both secure and non-secure is good.

    2. Then try and execute pdadmin user login from the WebSEAL servers runtime. If it works,
    3. Try and test authentication via WebSEAL login and if it fails, there is a possibility of WebSEAL ldap entry corruption under secAuthority tree.


    It is not mandatory to use secure port from verify access but ,it's always a best practice to setup LDAP/Directory server on secure port.



    Regards,
    Rama



    ------------------------------
    Rama Yenumula
    ------------------------------