Centrify DirectAudit 2.0 and above.
In a DA 2.0 configuration, the collector was configured with Windows authentication but the diagnostics for some reason show that the collector is trying to "bind as an anonymous user". For the SQL login, an AD group was configured and machine account was added to the group. Snippets of the diags (shown below). What does this mean?
Establishing connection with Collector: Success
Getting collector's current status: The Audit Store Database is not connected
Getting Collector's current Installation: NGDCDirectAuditInst1 (locally configured)
Getting Collector's current Audit Store:
Machine IP address(es): 10.177.251.20
Machine is joined to: r1-core.r1.yourcompany.com
Machine is in site: FTW@r1.yourcompany.com
AD Object: r1-core.r1.yourcompany.com/R1/Information_Security/Unix/CentrifyDA_Collectors/Vegas-Installation-709703a3-b31d-4585-aa94-120e74d0bde7
Object GUID: d622532b-c440-4a51-a8f6-c0701bd8e9a9
Installation Id: e8a04798-9979-4051-9d3c-843885a21d00
Subnet(s): None configured
Trusted Agents: None configured
Trusted Collectors: None configured
Audit Store Active Database:
Machine's Installation: NGDCDirectAuditInst1 (locally configured)
Machine's Audit Store is 'AuditStore1' because it services site 'FTW@r1.yourcompany.com'
Attempting to connect to Audit Store:
Max Pool Size=300
Failed to connect to Audit Store: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
There are some scenarios where this can happen.
Scenario: Failure to resolve IP/netbios name of SQL server to its FQDN
Error message: Authentication failure (Login failed for NT AUTHORITY\ANONYMOUS user)
Possible causes - DNS issue
If the DNS infrastructure is not setup properly, the SQL client cannot resolve the IP/netbios name of the SQL server to its FQDN. In such cases, the SQL client won't be able to locate the service connection point for the SQL server and so Kerberos authentication will fail. One telltale sign of this scenario is "authentication failed for anonymous login" error. To verify that its indeed a DNS issue, try to ping the IP address of the SQL server using the ping command with -a switch and observe the output of the command.
e.g. C:\>ping -a 10.0.0.1
If the command cannot resolve the IP address to its FQDN, it means the client wont be able to find the SCP for the SQL server and hence connection to the SQL server from this client machine using kerberos will fail.
In this case, the SQL configuration was correct however it turned out from the Application server, we could not connect to the Audit Store as the FQDN name of the SQL server could not be resolved (ping or nslookup).
In the above example, the customer was using a local hosts file (instead of DNS) with short name and FQDN next to it on the same line. Separating the lines
( FQDN first and short name next) in the local file hosts (under C:\windows\system32\drivers\etc) helped resolve the name/IP of the SQL server & this eventually allowed the DA agent to connect to the collector.
At the time of writing this KB, Centrify is looking to see if the message about authentication (it has nothing to do with the same) can be changed to make it meaningful. For now, please rule out name resolution issues from the collector by making sure the DNS is configured properly.