Skip to Main Content
HCL Domino Ideas Portal

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

Status No Plans to Implement
Workspace Domino
Categories Administration
Created by Guest
Created on Mar 17, 2021

LDAP: Acquire email address from external LDAP during Namelookup

Please provide a way to leverage the initial access performed by Domino to fetch additional attributes during the user logon phase.

Wants to access some additional attributes like Email id from LDAP.

This requirement came up because user have several thousands of access per minute and the LDAP is remote to the Domino application.

When using @Namelookup especially in a Directory Assistance context federating external LDAP servers (e.g. using [Exhaustive] lookup-type) the third parameter (itemtoreturn)

should be able to return an arbitrary array of attributes.

@NameLookup( [ lookupType ] ; username; itemtoreturn )

In the syntax above, the "itemtoreturn" should include additional attributes like "departmentNumber":"employeeNumber":"telephoneNumber" and so on.

This will allow to leverage the Directory Assistance internal pooling mechanism without requiring to make additional LDAP calls at application level increasing execution speed and I/O.

  • Attach files
  • Guest
    Reply
    |
    Sep 5, 2021

    Thanks Thomas for your additrional contribution but, as specified in previous comments, the intent of this request/idea is to make additional calls to the LDAP leveraging existing DA pooling in an environmente where customer(s) do not wanto to replicate/import external data into Domino Directory in any way.

    On the other hand these accesses are currently executed by LotusScript agents which are much less efficent than core C/C++ code requiring the set up new socket and LDAP bind operation for each call and hence impacting the server the scalaility.

    Furthermore attributes to be retrieved could be passed as list/array so the number of calls could be lowered to one.


    Hope this clarifies.


    Thanks a lot.

  • Admin
    Thomas Hampel
    Reply
    |
    Sep 4, 2021

    For each attribute, and for each time this @function is called, the server would have to reach out to the remote LDAP. That will be causing a significant impact to performance and scalabilty of Domino. Since there already is an LDAP connection, syncronization of the data into the Domino directory is what you need to do.

  • Guest
    Reply
    |
    Apr 21, 2021

    Customers often do not allow external LDAP entries to be imported into domino.

    Furthermore this is against the principal of Directories Federation for which DA has been used.

  • Admin
    Thomas Hampel
    Reply
    |
    Apr 21, 2021

    Why not set up DirSync and create a person document automatically?

  • Guest
    Reply
    |
    Mar 22, 2021

    When using @Namelookup especially in a Directory Assistance context federating external LDAP servers (e.g. using [Exhaustive] lookup-type) the third parameter (itemtoreturn)

    should be able to return an arbitrary array of attributes.

    @NameLookup( [ lookupType ] ; username; itemtoreturn )


    In the syntax above, the "itemtoreturn" should include additional attributes like "departmentNumber":"employeeNumber":"telephoneNumber" and so on.


    This will allow to leverage the Directory Assistance internal pooling mechanism without requiring to make additional LDAP calls at application level increasing execution speed and I/O.