• Bonjourno!

     

    It’s that time of year again!  We’ll likely be seeing more and more LDAP(S) cases.  One instance that I’d like to point out is the infamous “Server is not operational” message.

     

    In this message, the “server” being referenced is the client’s directory server (Active Directory, eDirectory, or OpenLDAP).  This message is a response from our web server saying, “Hey…I can’t connect to the destination directory server for LDAP(S) authentication.  What gives?”  Anytime you or the client sees the “Server is not operational” message, it simply means that we cannot communicate with their directory server.

     

    This can be caused by only a handful of reasons:

    LDAP

    • Their directory server is offline
    • The username for the service account has changed
    • The password for the service account has changed
    • The destination IP address has changed

     

    LDAPS (in addition to the above)

    • A certificate has expired (on their directory server or the root that we have on our web servers)
    • The name of their directory server (Fully Qualified Domain Name) has changed

     

    More often than not, the client will want to simply throw the ball onto our collective laps, and we’ll have to tell them why we cannot connect.

     

    Questions to ask:

    • Can you confirm that your directory server is online and available?
    • What is the username for the LDAP(S) service account?
    • What is the password for the LDAP(S) service account?
    • What is your public IP address?

     

    I strongly suggest you don’t simply say to the client “We have the username for your service account listed as ‘ABC’ and the password as ‘XYZ’, with the IP address being ‘1.2.3.4’.”  This will almost always be answered with the old “Yeah yeah yeah…nothing has changed on our end.”  </facepalm>

     

    Once they give you the username, password, and IP address, and you confirm that’s what we have listed in Salesforce, send the case up and we’ll take it from there.

     

    Thanks,

    Sean