An authentication failure error was received while adding the server to the SPE 9 Console scanner group
search cancel

An authentication failure error was received while adding the server to the SPE 9 Console scanner group

book

Article ID: 270070

calendar_today

Updated On:

Products

Protection Engine for NAS

Issue/Introduction

When attempting to add a Windows server to a scanner group via the Protection Engine Console, the result was a failure returned in a box with the following content:

Failed to add following server(s): <ip address>. Reason: Authentication failed due to invalid LDAP configurations

Troubleshooting:

- Verified that the contents of the "LDAP Configuration" section of "C:\Program Files\Symantec\Scan Engine\RestAPI\application.properties" was correct. This file exists on all SPE 9 servers.

Example:  Note: The names and addresses for this example are fictional / changed, but the scenario is accurate.

sperestapi.ldap.enabled=true   
sperestapi.ldap.url=Raptor-dc.jurassic.local      { responded when pinged.  NSLOOKUP returned an address }
sperestapi.ldap.port=389                                   { LDAP port 389 was accessible and listening when attempt was made to telnet to it }
sperestapi.ldap.basedn=DC=Jurassic,DC=local
sperestapi.ldap.groupdn=CN=SPE-NAS-Admins,OU=Groups,DC=Jurassic,DC=local          { Ran the command:  dsquery group -name SPE-NAS_Admins.  It returned  CN=SPE-NAS-Admins,OU=Groups,DC=Jurassic,DC=local }
sperestapi.ldap.ssl.enabled=false

 

Environment

Release : 9.0.0, 9.0.1.5

Cause

A DNS record had the wrong address for the named LDAP controller "Raptor-dc.jurassic.local". There were several other domain controllers responding to the DSQUERY command which gave the illusion that all was correct. However the address for the controller named in application.properties (in this case Raptor-dc.jurassic.local ) was different.

The address that was returned by NSLOOKUP was 10.253.109.251, which did respond to a ping request. But the server that responded was not a domain controller nor did it have a copy of the directory on it.

It was verified that the correct address for server Raptor-dc.jurassic.local  was 10.253.109.250 which actually resolved to a different name.

Resolution

Put the following entry into the SPE server's hosts file (C:\Windows\System32\drivers\etc\hosts)

10.253.109.250    Raptor-dc.jurassic.local

After saving the hosts file the attempt to import the server was correct because it contacted the named LDAP controller at its correct address and not what the DNS resolver was giving out.

The above workaround allowed the SPE server to be imported and managed but the eventual solution was to fix the record in the DNS resolver(s) forward lookup records. And then running IPCONFIG /FLUSHDNS on the server(s)