IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  Remote LDAP best practices

    Posted Sun January 24, 2021 10:43 AM
    The policy server uses the SecAuthrorityInfo object class in LDAP, which will contain some critical Policy Server information.
    In most cases, organizations already have and user registry configured based on some LDAP server.

    Assuming we want to configure Full Users when configuring ISVA, we can choose to configure ISVA LDAP server as local or remote. So we are faced with 3 different options. Which one is the recommendation?
    1. Use a local LDAP for SecAuthorityInfo and federate with the remote organization user registry LDAP server
    2. Use a remote LDAP for SecAuthorityInfo (based for example on SDS) and federate with the remote organization user registry LDAP server
    3. Use the remote organization user registry for both SecAuthorityInfo and its users. In this case, we do not need to federate anything.


    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------


  • 2.  RE: Remote LDAP best practices

    Posted Sun January 24, 2021 03:07 PM
    Hi Joao, My two cents.

    If you have decided to use Full User model, Embedded/Local LDAP is not recommended for Production deployments. In full user model with local LDAP for runtime, SecAuthorityInfo attribute secDn will be referenced in runtime LDAP as opposed to Federated LDAP. 

    For full user model, best practice deployment would be to use a Remote LDAP registry for both Runtime and User suffix (Your option 2 with SDS example without the need for another Federated repository). 

    If you wanted to use a Federated repository for Organizational User suffix, then Basic User model would be a good fit with Local/Embedded Runtime LDAP(SecAuthority Info) and Federated registry for users. (if you wanted to use multiple federated repositories, you need to account for duplicate User ID's as well)


    Regards,
    Rama

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

    Original Message


  • 3.  RE: Remote LDAP best practices

    Posted Sun January 24, 2021 07:42 PM
    Joao,
     
    Generally I would recommend to use basic users instead of full users as this does simplify your deployment and dependency on user registries.  You do lose certain capabilities (e.g. user based ACLs, user based password policy), but most customers generally don't use these capabilities anyway.  Are you sure that you need the full user capability?
     
    If you do need the full user capability the recommended approach really comes down to your environment and the size of your user population.  If your user population is relatively small you could use the embedded LDAP server and federate against the user registry, but this is not usually recommended for a production environment.  Out of the other two options, it is entirely up to you and your environment.  Some customers like the clear separation of using a different user registry for 'secAuthority=Default', while others don't like this approach as it means that they have to manage yet another user registry.
     
    I hope that this helps.
     
     

    Scott A. Exton
    Senior Software Engineer
    Chief Programmer - IBM Security Verify Access
    IBM Master Inventor
    Phone: 61-7-5552-4008
    E-mail: scotte@au1.ibm.com
    1 Corporate Court
    Bundall, QLD 4217
    Australia
     
     



    Original Message


  • 4.  RE: Remote LDAP best practices

    Posted Mon January 25, 2021 05:41 AM
    Edited by Joao Goncalves Mon January 25, 2021 05:44 AM
    The number of users in LDAP server will be around 1,000,000.

    I am planning to provide SCIM interface to allow self registration, changing personal data, password, and more. I believe this cannot be achieved if I use Basic Users. Or can changes to users through SCIM, is supported on basic users?

    SecAuthority=Default will only be used by internal ISVA users and policy server (could be local or remote LDAP), but Application users, using a separate baseDN, will be in a remote LDAP server. If I use SecAuthority in ISVA local LDAP, creating Full users, I would have a replication of them in the local LDAP which I believe would be a bad choice. Creating a remote LDAP in ISVA, for full users, would likely be a better choice.

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------

    Original Message


  • 5.  RE: Remote LDAP best practices

    Posted Mon January 25, 2021 06:24 AM
    Let me add a couple of non-technical considerations more focusing on the user population and their lifecycle requirements. I am primarily a Identity Management expert so I really do not want to dispute the technical pro and cons of using the different options.
    But you should carefully consider the challenges of the lifecycle of a user - just because they need to be in your ldap it does not necessarily mean that you want to have them included in ISVA - and more problematic the other way around - i.e. there may be users that will need to be in ISVA but not in your corporate ldap.
    The problem is specifically common in MS AD organizations because MS promotes the view of AD to be THE enterprise registry - but this is seldom the reality...
    I always try to make clients aware of good old security practices when discussing the - i.e. uncoupling of lifecycle from infrastructure (that is the above thing) and separating backend and frontend security - e.g. it is probably a good solution to have your MS AD being integrated directly via ad groups for most enduser application - but what about highly privileged services -  both accounts/application - it is important to adhere to good practices here to limit an intruder to traverse laterally which is very simple if you put all eggs into the MS AD basket...

    ------------------------------
    Franz Wolfhagen
    IAM Technical Architect for Europe - Certified Consulting IT Specialist
    IBM Security Expert Labs
    ------------------------------

    Original Message


  • 6.  RE: Remote LDAP best practices

    Posted Mon January 25, 2021 06:52 AM
    Thanks for your insight.
    Currently the user registry, with 1,000,000 registered users is based on a Relational Database. They need to be moved to an LDAP server, managed by ISVA. The LDAP server won't be MS AD, but IBM SDS configured with high availability in a master-master configuration.

    In fact, I never had in mind having 1,000,000 users in ISVA local database. But, I have the option of configuring the Policy Server to use a local or a remote LDAP server. I can also configure a federated user registry.

    The issue was, which is the best practice. I am now convinced that the best option is in fact, creating a remote LDAP server, and there is no need to federate the user registry.

    Here is the reasoning, and please correct me if I'm wrong:
    If I federate a remote LDAP using the Full User model, all users will be copied to the ISVA LDAP registry, and the federated repository will be synchronized with the ISVA LDAP. So, I would have 2 LDAP servers the users replicated.
    If I don't federate I will only get 1 copy of the LDAP server.
    Having the ISVA configured with a local LDAP registry, would mean that all 1,000,000 be inside ISVA, which takes a lot of space, but with your insight, it is not even advisable or recommended, and I agree with you.

    So, I think I found the answer to my question!

    Again, please correct me in any way if you believe my arguments are not correct!

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------

    Original Message


  • 7.  RE: Remote LDAP best practices

    Posted Mon January 25, 2021 03:37 PM
    Joao,

    The SCIM interface can be used to manage users in any federated registry and the users do not need to be full users - they can be basic users.  I would strongly recommend using basic users unless you really need the capabilities provided with full users.  The official knowledge centre provides information on the differences between basic and full users.

    Thanks.

    Sent from my iPad



    Original Message


  • 8.  RE: Remote LDAP best practices

    Posted Mon January 25, 2021 04:46 PM
    Edited by Joao Goncalves Mon January 25, 2021 04:46 PM
    Thanks for the feedback. Here is the thing.
    I will be using 1 single LDAP server (IBM SDS) although configured in master-master cluster configuration.
    Are you suggesting that I use 2 instances of LDAP in SDS?

    One Instance LDAP_App for the Application users that will be federated in ISVA, and another instance LDAP_isva as a remote LDAP server for the policy server?

    In this case, I can in fact create the Basic Users from LDAP_App, and I can use SCIM to access this LDAP_App for Self-care and user registration.

    Are you recommending that this should be the correct approach?

    i just don't understand the reason for this!

    ------------------------------
    Joao Goncalves
    Pyxis, Lda.
    Sintra
    +351 91 721 4994
    ------------------------------

    Original Message


Related Content