ERROR: "XCOMN0287E Error setting remote user id" XCOM for Windows using Kerberos (NTLM disabled)
search cancel

ERROR: "XCOMN0287E Error setting remote user id" XCOM for Windows using Kerberos (NTLM disabled)

book

Article ID: 225472

calendar_today

Updated On:

Products

XCOM Data Transport XCOM Data Transport - Windows

Issue/Introduction

Currently using NTLM authentication with domain controllers.
Due to the PetitPotam vulnerability need to disable NTLM so that Kerberos authentication is then used.
However, when that was tested it caused XCOM to fail with:

XCOMN0287E Error setting remote user id

Environment

XCOM™ Data Transport® for Windows

Cause

Missing DOMAIN parameter. Kerberos authentication will be used only for Domain user accounts.

Resolution

It was found that the first test had been run without setting the DOMAIN parameter on the transfer command line parameters or in the xcom.glb file on the initiate/receive server.

XCOM calls Microsoft's LogonUser API with "LOGON32_LOGON_INTERACTIVE" for dwLogonType and "LOGON32_PROVIDER_DEFAULT" for dwLogonProvider options. 
From Microsoft documentation:
LogonUserA function (winbase.h)
 
LOGON32_PROVIDER_DEFAULT
Use the standard logon provider for the system. The default security provider is negotiate, unless you pass NULL for the domain name and the user name is not in UPN format. In this case, the default provider is NTLM.

LOGON32_PROVIDER_WINNT50
Use the negotiate logon provider.

LOGON32_PROVIDER_WINNT40
Use the NTLM logon provider.
 
Per the explanation above for LOGON32_PROVIDER_DEFAULT, if the given parameters don't have a domain name and the username is not in UPN format it is using the NTLM provider. Using Domain name should mean the negotiate logon provider will then use Kerberos authentication.

After retesting the XCOM transfer with DOMAIN parameter set it was found to be successful when Kerberos authentication was being used.
So using XCOM with Kerberos authentication requires no additional configuration as long as the XCOM DOMAIN parameter is set.

Additional Information

However for outgoing transfers from the same server that DOMAIN parameter should not be set because it may cause problems at the receive server due to the DOMAIN parameter not being recognised or that server already having it set in its xcom.glb to be used as the default. What are the options to stop the DOMAIN parameter being set for outgoing transfers?
For outgoing transfers support tested with the XCOM initiate server having DOMAIN parameter set in its xcom.glb and the XCOM receive server first not having it set and then having it set. Tests done using a transfer .cnf file but the same results are valid for direct command line parameter use:

    1. XCOM initiate server has DOMAIN parameter set to DOMAIN1 in xcom.glb and XCOM receive server has no DOMAIN parameter set in xcom.glb.
       If the transfer .cnf file has DOMAIN set to no value ("DOMAIN=") then the trace file at the XCOM receive server shows "domain=<DOMAIN1>"
       If the transfer .cnf file has DOMAIN set to single space ("DOMAIN= ") then the trace file at the XCOM receive server shows no domain value i.e. "domain=<>"

    2. XCOM initiate server has DOMAIN parameter set to DOMAIN1 in xcom.glb and XCOM receive server has DOMAIN parameter set to DOMAIN2 in xcom.glb 
       If the transfer .cnf file has DOMAIN set to no value ("DOMAIN=") then the trace file at the XCOM receive server shows "domain=<DOMAIN1>"
       If the transfer .cnf file has DOMAIN set to single space ("DOMAIN= ") then the trace file at the XCOM receive server shows "domain=<DOMAIN2>"

So setting DOMAIN to a single space ("DOMAIN= ") for the transfer will both override the initiate server xcom.glb DOMAIN value and will itself be overridden by the receive XCOM server xcom.glb DOMAIN parameter if it is set.
Also see parameter order of precedence referenced in Create and Update Configuration Files Using the GUI