One of the problems when troubleshooting why a 3-tier setup of NAV 2009 doesn’t work is, that the same error – typically this one on the SQL Server:
“Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON'”
can be caused by any number of problems between NAV Server, SQL Server and Active Directory settings.
One quite common cause of this problem is duplicate SPNs. This post describes the problem with duplicate SPNs, and how to locate and solve it.
What is the problem:
When the NAV Server and SQL Server are on two different machines, a connection between Role Tailored Client (RTC) and the NAV Server requires Kerberos. Kerberos uses SPNs to locate which Windows account the NAV Server is running under. For this reason, each SPN must point to exactly one Windows account.
Once you start setting up and troubleshooting a 3-tier setup it is easy to end up trying new SPNs on new accounts, and forgetting to remove the original SPNs.
How to check if you have duplicate SPNs:
This is easy if you have Windows 2008 somewhere on the domain. If you do, then from a command prompt, just run this command:
This command is new in Windows 2008, and was introduced exactly and specifically to help locating this problem.
If you do not have Windows 2008 anywhere on the domain, then use the command line tool called “ldifde” from a Windows Server 2000 or 2003.
For the purpose of finding duplicate SPNs, use ldifde from a command prompt like this:
ldifde -f “c:\x\AD.txt” -l ServicePrincipalName
This will export values of the ServicePrincipalName-property for all accounts in Active Directory to a text file. Here is an example of the output of this command:
dn: CN=SQLDUI SD.,CN=Users,DC=contoso,DC=com
Then you must search manually for your SPNs, and see if they appear more than once. In this example, the SPN “DynamicsNAV/NAV-SERVER:7046” is set up for both accounts navservice and SQLDUI, so in this case you would have to remove this SPN from one of the accounts.