8 Replies Latest reply on Mar 26, 2018 12:16 PM by Seth Long

    Unable to authenticate - "Logon plug-in returned no results"

    Seth Long Adventurer



      I work at a University that has campuses in two different physical locations (one in California, one in Oregon).  We have a Pharos server set up for each campus.  We are receiving an error on the Pharos logon touchscreens at the Oregon campus.  After selecting Print and before it asks to input a username, the message comes up (picture attached):


      "Pharos Server internal error


      An internal server error occurred.  Logon plug-in returned no results


      Please contact Pharos support."


      We use AD for user authentication.  I thought this error could be related to the ADLDAP Bank, meaning it's not properly communicating with AD.  However, we ran the following check in the Command Prompt and got the same results on both campuses:


      adldaplogon.exe ldaplog.txt trace jstudent [password]


      Since the results are the same and authentication is working fine on the California campus, I'm now thinking perhaps this is not the culprit.


      We compared the registry on the California campus server to the Oregon campus server, and saw that the Oregon campus server is missing the Pharos key under HKEY_LOCAL_MACHINE > SOFTWARE > Pharos (screenshot attached).  This key looks to contain license information.  Does the touchscreen run a license check every time it tries to authenticate?  If it runs a check and finds no stored key, could this cause the "no results" error message?


      We've sent an email to Pharos Support but not received a response yet, so I thought I would reach out to the community as well.


      Thanks in advance!

        • Re: Unable to authenticate - "Logon plug-in returned no results"
          Steven English Guide

          Seth Long,


          The license key should not be an issue at all, and if that is a secondary server as described I do not believe it even needs to be present at all (the license KEY section, not the license server).  That said, the section in your screenshot appears to be from the section of the registry applying to 64-bit programs.  If you scroll down a little lower, you will see the Wow6432Node folder in your screenshot which - upon expanding - will contain registry keys for the 32-bit apps on your server, including the "real" Pharos info.


          Typically when I see these results it is due to one of four things:

          1. ADLDAP plug-in missing or not found (unlikely since adldaplogon.exe installs by default, though the bank/script could be pointed to a different/non-existent path)
          2. ADLDAP server config (also unlikely based on the trace results showing success)
            1. Bad DNS resolution from the faulty print server to defined ADLDAP servers
            2. Completely missing ADLDAP server config in registry on the faulty print server
            3. Bad ADLDAP server config in registry on faulty print server (port, name, lookup user/pass, etc.)
            4. SSL issue due to certificates
          3. Timing Issues (details below)
            1. If the script has a timeout of 10 seconds, but the ADLDAPlogon executable takes 11 seconds to test against all the servers and write the results to temp, you wind up with the script reading the temp file prior to it being populated with the valid response.  In the end you are somewhat accurately being told that the results were not valid.
          4. Bad Logic in Script
            1. If a script is being used, bad script logic can result in a temp file being created and stranded if there is a exit path from the script before the file is deleted.  This can result in the server taking a significant amount of time to iterate through the randomized hexadecimal file names to locate a path that does not already exist.  Once all ~65k  files have been used, it will not process anymore logon attempts successfully.
            2. This one is usually most identifiable because of the loooong delays during the logon attempt.


          Hope this helps!




            • Re: Unable to authenticate - "Logon plug-in returned no results"
              Seth Long Adventurer

              Hello Steven,


              Thank you for your fast and very thorough reply.


              I verified that the bank is pointing to the correct path, so I don't think Number 1 is the issue, and as you mentioned, Number 2 is unlikely since the trace results showed success.


              In Number 3, you mentioned that the script timeout being too quick could cause the issue.  I am assuming we could simply edit the timeout to make it longer?  Do you have an idea of what the script name might be or where it is located?  I assume somewhere in the same folder as adldaplogon.exe?


              There is not an excessive delay during the logon attempt, so we could probably rule out Number 4.


              To complicate the matter, after my initial post, we tested the Account Station (where students add money to their print accounts), and we were able to successfully authenticate/logon there and add funds.  I'm perplexed why authentication would work here but not on the two touchscreens next to the printers.


              Thanks again for your time.

                • Re: Unable to authenticate - "Logon plug-in returned no results"
                  Steven English Guide

                  Seth Long,


                  I did not see this comment until after posting the one below.  Working the authentication path backward you may find that either the successful Pharos Stations are actually pointed to a different print server (e.g. California instead of Oregon) which may explain their difference in behavior, but it could also be that Pharos Station is using a different bank which would allow it to have a different script/logon event in place.


                  To work this backwards in Pharos Admin...

                  1. Go to Release Stations and highlight a functioning Station
                    1. Make note of the print server it is assigned to use
                    2. Make note of the bank it is assigned to use
                  2. Under Release Stations, highlight a non-functioning terminal
                    1. If different from the station above, make note of the print server it is assigned to use
                    2. If different from the station above, make note the bank it is assigned to use
                  3. Go to System > Banks
                    1. One at a time, highlight the bank from step 1 and 2 and note the following
                      1. Inspect the Logon event under plugins to see if a script or executable is being used
                        1. If an executable, verify the path, see comments below
                        2. If a script, make note of the name/label
                    1. It is not uncommon for an older site to have a logon event that is pointed to a specific exe path that does not exist on other servers.  Resolve this by creating a new bank for the new server, by making sure the file exists in the same path as the system has been instructed to look, or by making sure the file exists in the same place on both/all servers and then updating the executable path on the logon event (remember change control)
                    2. The same goes for scripts; Older scripts often have a hardcoded path to the executable instead of dynamically looking at the registry to determine where Pharos is installed and then looking within that folder for the file.  In your case, the script may be pointed to ADLDAP~2.exe which exists on the California server, but not on the Oregon server.  If you see this as an obvious solution, skip the section below, and don't forget to issue a change control.
                  5. If one or more scripts are in play, Go to System > Scripts
                    1. Repeat the steps below for each script
                      1. Highlight the script
                      2. In the lower center pane, click the three dots ... that appear in the right column on the row labeled source
                      3. Use Ctrl+A to select the entirety of the source script
                      4. Cancel back out
                      5. Paste the source into Notepad
                      6. Scan the source for confidential info (server names, username/password) and redact ******* as needed.
                      7. Save the scripts by name
                      8. Post here for review
                • Re: Unable to authenticate - "Logon plug-in returned no results"
                  Seth Long Adventurer

                  We are also getting errors like this in Event Viewer on the Oregon campus Pharos server:


                  Faulting application name: ADLDAP~2.EXE, version: 9.0.8467.14, time stamp: 0x536f2abc

                  Faulting module name: ADLDAP~2.EXE, version: 9.0.8467.14, time stamp: 0x536f2abc

                  Exception code: 0xc0000409

                  Fault offset: 0x00032fe1

                  Faulting process id: 0x1ae4

                  Faulting application start time: 0x01d3b02a727f8e19

                  Faulting application path: C:\PROGRA~2\Pharos\Bin\ADLDAP~2.EXE

                  Faulting module path: C:\PROGRA~2\Pharos\Bin\ADLDAP~2.EXE

                  Report Id: b033414a-1c1d-11e8-850f-00155d180b5c

                  Faulting package full name:

                  Faulting package-relative application ID:


                  Any ideas?

                    • Re: Unable to authenticate - "Logon plug-in returned no results"
                      Steven English Guide

                      Seth Long,


                      In that case it appears that the plugin itself is crashing or failing to launch.


                      1. First off, I notice that the filename has a ~2 on the end.  This would indicate that you either have more than one adldaplogon.exe in your bin folder, or the system expects that you have more than one.  I would try running the test from your initial post as follows in order to see whether or not the failure is replicable:
                        1. C:\PROGRA~2\Pharos\Bin\ADLDAP~2.EXE C:\PROGRA~2\Pharos\Bin\ldaplog.txt trace jstudent [password]
                      2. Is the system calling the executable directly, or is it being called via script?
                      3. Do you have any A/V or anti-malware that might be interfering with it's execution?
                      4. Is the file blocked?  I have seen servers that have Pharos installed but multiple files are blocked and it has caused anomalies.  Assuming things are installed in the default folders, you can run the commands below to clear the NTFS data stream which will "unblock" the files.



                      streams.exe -s -d "C:\Program Files (x86)\Pharos"

                      streams.exe -s -d "C:\Program Files (x86)\PharosSystems"

                      streams.exe -s -d "C:\ProgramData\Pharos"

                      streams.exe -s -d "C:\ProgramData\PharosSystems"

                        • Re: Unable to authenticate - "Logon plug-in returned no results"
                          Nic H Newbie

                          Thanks Steven,


                          I am helping Seth out. We did try copying the ADLDAP from the California server to the Oregon server as one of the first troubleshooting steps, it appears the short name cached when we removed the old one, I have corrected it and now a dir /x shows only the ADLDAP~1 and the errors started to reflect that change.


                          I went ahead and cleared out the streams and restarted the server... Still seeing the error in event viewer.


                          To address some of the other points in the posts above, no scripts are running during logon for the Bank other than the ADLDAP plug-in and the path is identical on both servers.


                          Is there a setting somewhere I can adjust the timeout for the ADLDAP plug-in?


                          Thank you again for your help

                            • Re: Unable to authenticate - "Logon plug-in returned no results"
                              Steven English Guide

                              Nic H,


                              Did you try running the command from the command line with the tildes in there?  I have seen some systems that do not like the short names because the 8dot3 naming convention has been disabled.  I am not sure if that would be applicable here or not though as you are getting what appears to be an actual crash of the plugin (links at the bottom can be explored if interested).


                              So that leaves us with a couple of things before you really just need someone to get on your system and take a look.  First, you could try copying the adldaplogon.exe file from the working server in case the plugin itself has become corrupted or is perhaps out of date and somehow the username/password combo is perhaps causing a crash due to special characters that were not supported years ago.


                              Second, you could create a batch file that calls the plugin to see if the issue is with how the plugin is being called.  I am likely pretty rusty on this one, but I think this sample will work with minor tweaking.  The %1 and %2 are the variables that will be fed into it (username and password), but honestly I have not used this in close to seven years.  If this does allow it to work, then you probably just want to get a simple AD authentication script from Pharos or get them to identify why it is failing to begin with.

                              cmd.exe /c c:\progra~2\pharos\bin\adldap~1.exe c:\progra~2\pharos\bin\out.txt trace %1 %2  2>&1






                                • Re: Unable to authenticate - "Logon plug-in returned no results"
                                  Seth Long Adventurer

                                  Hi Steven,


                                  Sorry for the late reply.  Thank you so much for your assistance with this.


                                  We worked with Pharos Support but unfortunately weren't able to find a solution.  We did however find a workaround by having the Oregon logon touchscreens point to the California Uniprint server for authentication.


                                  We will likely be upgrading our version of Uniprint later this year anyway, so we decided this workaround will be sufficient until then.  I'm going to go ahead and mark this thread as closed.


                                  Thanks again!