Multiple Tier Authentication

rtaranti

Hi there. After following the "three tiers on three computers" walthrough in the NAV 2009 nav_install.chm file, I ran into an authentication issue I cannot solve. I have asked Freddy K about this and he has kindly pointed to MIBUSO community in which I am familar with.

I am having an issue with my middle tier NAV server authenticating with my machine that is hosting the SQL server 2005 NAV database. Please note, these are all test machines being used for a proof of concept.

The NAV server is using the same test domain acount as the SQL server service for simplicity. My client reaches the NAV server with no issue. I set domain user delagation on the client settings config file. When the request reaches the SQL server, it is erroring due to AD sending it the ananymous login. We used setspn to register the mssqlsvc service with the sql machine and the test account. It stated that it (updated object), but I've had no luck. Interestingly, if I do list of the machines (sql server) spn's the new service does not show.

The message on the SQL server application log is "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. [CLIENT: <my NAV server IP>]"

Could anyone assist?

matttrax

I'm in the exact situation. I've executed the following code, changing ReplaceWithNavServerAccount to MYDOMAIN\NAVSERVICETIER$

CREATE LOGIN [ReplaceWithNAVServerAccount] FROM WINDOWS;
CREATE USER [ReplaceWithNAVServerAccount] FOR LOGIN [ReplaceWithNAVServerAccount];
CREATE SCHEMA [$ndo$navlistener] AUTHORIZATION [ReplaceWithNAVServerAccount];
ALTER USER [ReplaceWithNAVServerAccount] WITH DEFAULT_SCHEMA = [$ndo$navlistener];
GRANT SELECT ON [ReplaceWithYourDatabaseName].[Object Tracking] TO [ReplaceWithNAVServerAccount];
GO

I'm guessing it's trying to login anonymously because my service tier is running on the Network Service account and I didn't specify that in the above code? I really don't understand this part of it so any help (preferably in as much detail as possible for us non-SQL people) is most appreciated.

matttrax

Well, after days, and I do mean days, or working on this, I highly recommend going through the guide here:

http://msdn.microsoft.com/en-us/library/dd301254.aspx

Go through everything, even if you've already installed something, there might be additional components to install. And make sure your company doesn't have any weird security policies involving service accounts.

rtaranti

Thanks matttrax. Ironically, I just finished fixing the problem with the Fargo support team. Thanks guys! A couple areas we corrected are ensuring the spn's have the ports specified for the NAV service (7046) and the SQL service (1433). The other area we determined was a problem, was ensuring the domain account I was was using had select permission on the object listener table on the NAV database I was trying to access.

Thanks for the post. Fargo stated that the documentation on MSDN will be updated regularly and that they are working hard to clarify the steps required. I also asked them to post documentation on the approach for clustering the NAV servers for companies who wish to ensure failover capailities.

mihail_kolev

Hello,

I went the guide ( http://msdn.microsoft.com/en-us/library/dd301254.aspx ) and i still have problem: the RTC connect only from the machine running the NAV server, every other machine give error "Username and Password are invalid. Try again". I have set all spn, delegation settings etc. and now I'm realy confused... what i am missing. On the SQLServer computer i see that the client try to log with NT AUTHORITY\ANONYMUS LOGON. If somebody have any suggestions i'll be very happy to know

jagtap.ganesh

Hey Try this:

Action: Unable to connect RTC to the SQL server on a NAV 2009 SP1 SQL 3 tier environment

Result: Error in SQL log 'NT AUTHORITY\ANONYMOUS LOGON

Cause: SQL Cluster environment

Solution: Create 4 SPNs (2 local and 2 FQDN) and delegate to the Account under which SQL server is running
DynamicsNAV/<machine-name>:7046
DynamicsNAV/<Fully Qualified Domain Name machine-name>:7046
MSSQLSvc/<machine-name>:1433
MSSQLSvc/< Fully Qualified Domain Name machine-name>:1433

If its not clustered environment then, FDQNs are not required.
and delegate SQL SPNs to the user running service.

detlef

After the "Best Practises Analyser" reported no problems, I still couldn't connect.
Microsoft support helped me here:

"In you test enviroment, could you please bring up adsiedit.msc from Domain Controller and goto the user administrator, right click bring up the properties. Find useraccountcontrol double click on that and change the number to 17301504 which means TRUSTED_FOR_DELEGATION + TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION and then save it.
Please using "klist purge" on each server/PC to clear the kerbtickets. Then restart all the services(SQL and NAV service)."

This worked for me

The next time I logged on with the user, it asked me to change the password. So probably best to reset the password afterwards.