Pharos Uniprint 8.2 ADLDAP authentication failure

On a fairly recently installed test system of Pharos Uniprint 8.2 running on WIndows Server 2008 R2 (i.e. 64-bit OS) I configured the Pharos Remote bank to use the ADLDAPLogon.exe plugin. This allows you to authenticate users against your Active Directory rather than using the built-in Pharos authentication.

On my existing v8.0 Uniprint system this works fine and has been for about three years or so.

On the new (test) 8.2 system though I was getting the following error when trying to log on to Pharos Remote:

Your logon attempt was not successful. Either the details you supplied are incorrect, you do not have permission to access Pharos Remote, or there are no Print Servers available.

None of which were the case.

Looking in Pharos Administrator under System – Alerts I could see the following Warning entry:

User: my-pharos-remote-user
Severity: Warning
Error Code: 29500
Message: Logon failed for user my-pharos-remote-user

Pharos Remote uses the Pharos Remote bank, which was configured with the Logon plugin of:

C:\Program Files (x86)\Pharos\Bin\ADLDAPLogon.exe

This needs some registry values creating in the following key:

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Pharos\Plugins\AdLdapLogon\servers

The values are REG_SZ and are named as numbers, starting at 1, with the data containing a text string of the following form:

<Active Directory Server Name>:<AD bind account>:<password for the bind account>:<LDAP port>:0

So for example:

rcmdc1:pharos-ldap:S0mePa55word:389:0

You can create multiple values, increasing by 1, if you have multiple domain controllers. I have 1,2,3,4.

The ADLDAPLogon.exe can be tested on the command line in “trace” mode to help verify its functionality and assist with authentication failures. The syntax is:

adldaplogon.exe <output file> trace <username> <password>

where <username> and <password are those of the account you want to try and authenticate (or not), and <output file> is the file that adldaplogon.exe writes for the rest of Uniprint to interrogate for an “OK” or a “FAIL”.

Testing on the command line showed that everything was working fine. It just wasn’t working from Pharos Remote itself.

Time to get out the tools. I used Wireshark and Process Monitor.

Using Process Monitor I set a filter:

Column: Operation
Relation: is
Value: Process Create
Action: Include

This allowed me to see ADLDAPLogon.exe being called by PServer.exe, and more importantly, gave me the command line theh PServer was calling it with:

"C:\Program Files (x86)\Pharos\Bin\adldaplogon.exe" C:\Windows\Temp\Un8d91.tmp "my-pharos-remote-user" "premotepass" "Unknown"

So parameters being passed by PServer.exe are as follows:

1. Output file
2. Username
3. Password
4. Unknown

Next I used Wireshark to look at the data being sent to the first domain controller in the list (value 1 from the AdLdapLogon\servers registry key). I set a capture filter (via Capture – Options, in the Capture Filter box) of:

host 192.168.10.10

where that is the IP address of the domain controller rcmdc1. If the filter is valid the text box background goes green. Click Start and then try to logon via Pharos Remote.

Examining the captured data I could see some of the lines had LDAP in the Protocol column. One of these had the following in the Info column:

bindRequest(5) "<ROOT>" , NTLMSSP_AUTH, User: \pharos-ldapsasl

So that is where ADLDAPLogon is binding to AD to get more detail about the user to be authenticated. You can see that it’s binding as the account pharos-ldap. There were then various lines, and then one similar line to the above:

bindRequest(11) "<ROOT>" , NTLMSSP_Auth, User: \premotepasssasl

Now that’s interesting as the place where I’d expect to see the username (in this case my-pharos-remote-user) is actually showing the password to be tested for that account…!

So it seems as though either PServer.exe is passing the parameters to ADLDAPLogon.exe in the wrong order (or with something missing) or ADLDAPLogon.exe is not correctly handling the parameters that it’s being passed.

So from earlier testing on the command line in trace mode, the parameter order that worked was:

1. Output file
2. trace
3. Username
4. Password

But from PServer (not working) we’re actually getting:

1. Output file
2. Username
3. Password
4. Unknown

The parameters expected by ADLDAPLogon.exe are apparently:

1. Filename
2. Level
3. Username
4. Password

Note how when we get a success in trace mode on the command line the username is parameter number 3, but when it fails from PServer the password is parameter number 3. So to fix this we somehow need to pad out the parameters to shift the username to parameter 3 (and the password to parameter 4). The easiest & fastest way I could think of to do this was by writing a Command file, paramfix.cmd, containing the following:

@echo off
"C:\Program Files (x86)\Pharos\Bin\ADLDAPLogon.exe" %1 duff %2 %3 %4

Clearly I didn’t know how ADLDAPLogon was going to like being passed an invalid parameter, but I tried it and it worked. I saved this .cmd file into C:\Program Files (x86)\Pharos\Bin and changed the Pharos Remote Bank Logon plugin to be paramfix.cmd instead of ADLDAPLogon.exe.

Et voila, I can now authenticate against Active Directory when logging on to Pharos Remote. As Mr. Russinovich would say, case closed. (though actually I’ve passed this back to Pharos to get them to sort out why it’s not working in the first place, but at least I have a workaround in the meantime)

More info:

• PServer.exe version is 8.2.6005.221
• ADLDAPLogon.exe version is 8.2.6005.126