This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How does iManager chose which LDAP servers to use?

aka "Why is iManager trying to bind to THAT server?"

For iManager logging set to all errors
# grep bind /var/opt/novell/iManager/nps/WEB-INF/logs/debug.html

shows soo many fails, because those aren't servers it should be talking to (such as old problem servers we are trying to retire)

including it trying to bind to the tree name.  I didn't think I had to work those into the certs.

Including digging into other systems at other clients, I still haven't seen a successful bind.

KM000015076 pointed me this way, and I have yet to see a difference on this level between Universal Password setting working or not.

But now that I find another thing that has certain expectations of cert and LDAP details, I want to know more.

________________________

Andy of KonecnyConsulting.ca in Toronto
Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • Verified Answer

    +1  

    Hi Andy,

    in case you are using a "typical" iManager setup, I suppose the "bind destination" depends on the information provided during login. E.g

    From what I know, you can either define the tree name (in this case iManager will try to connect to the "preferred" eDir host, probably the one running on the same box as the iManager you adress in the URL but I am not 100% sure).

    If you want to bind to a specific replica, you can either enter IP OR FQDN of that specific eDirectory host you want to bind to. In case you are using custom ports (some other than the 524 default port) you can also enter it via [address]:[port].

    In case of secure LDAPS connections:

    It depends which certificate is being using to secure the LDAP connection to you LDAP server(s). Have a look here.

    https://www.netiq.com/documentation/imanager/imanager_admin/data/bx8g5g8.html

    Best regards,
    Philipp

  • 0   in reply to   

    Yes, part of the issue was having the tree name in that field that says 'Tree' if there is nothing in it.  Changing to the IP of the server fixed it over the weekend, which confirms what you posted

    why it couldn't just try its own local LDAP instance...    sigh

    So if you want to have Universal Password work without the NMAS errors, you either need to have the host SSL certs that your <tree>.domain.local point to be created with that tree name in the SAN,  or don't use the tree name in there.    blah, ugly or non-resilient.  

    cool cert bits for tomcat/java in that link,  thank you, and thank you for your assistance.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.