Navision 2009 webservices authentication issues on a three-tiers setup

Hi all,
I am trying to set up Navision 2009 webservices on a three-tiers setup, and I am having a lot of trouble to get authentication working.
When trying to log “locally” on the middle tier server using IE, authentication will work only if 1) I am logged in Windows as a valid Navision user and 2) the URL of Navision webservices has been added to the “Intranet” zone. In this case the logged-in user credentials will be passed on automatically to IE and I will get logged in.
If I try to specify manually a username/password or do not add the URL to Intranet zone, I will get successfully through the username/password prompt, but the XML webpage will display an error message [The login failed when connecting to SQL Server XXXXX\YYYYY.]. When trying to log in from a remote server authentication will simply not work, regardless of the logged-in user or IE settings, and webpage will display the same error message.
Now, this is where it gets interesting. AFTER a successful login on the middle-tier server with a given user (meaning locally, with proper logged-in user and correct IE settings) I will be able to log in both locally and remotely with that same user regardless of IE settings/logged-in user. All I have to do is to provide username/password when/if prompted.
A quick look to SQL server logs shows that when login fails. Navision tries to log in on SQL server as [NT AUTHORITY\ANONYMOUS] instead of the supplied credentials. I tried to check all I could think of (PTR records, SPNs, Delegation, user rights in SQL and NAV,…) but the issue persists.

  • Dynamics NAV 2009 R2 (build 32012)
  • Windows server 2012 R2 (build 9600)
  • SQL server 2012 (build 2128)

Any idea or suggestion is welcome :slight_smile:

Ideas, anyone?

NAV 2009 Three-Tiered Environment

There are two configurations for NAV 2009 three-tiered installation on multiple servers available - ‘Three Tiers On Two Computers’ and ‘Three Tiers on Three Computers’. The key characteristic of the first configuration is that the two server tiers - Microsoft Dynamics NAV Server and SQL Server - are on the same computer. If you install Microsoft Dynamics NAV Server and SQL Server on separate computers (‘Three Tiers on Three Computers’ configuration), you must set up delegation, to enable clients to use the Microsoft Dynamics NAV Server service’s credentials while interacting with a SQL Server database.

You can find more information about installing the three tiers on two computers on MSDN: Walkthrough: Installing the Three Tiers On Two Computers.

The ‘Three Tiers on Three Computers’ configuration is described here: Walkthrough: Installing the Three Tiers on Three Computers.

During the installation you can encounter the configuration problems. The information below will help you to solve them.







In case the MS Dynamics NAV 2009 three-tier environment is used with webservices connection and your website is in decentral hosting environment (separate domains for webserver and NAV server) the following is required:

- VPN connection must be set up between these environments;
- These domains have to be made trusted.


This will allow to delegate user rights (who runs the web application) to the MS Dynamics NAV.

Usage of HTTPS without a VPN in the described scenario does not work.

First check the accounts which are running the NAV and SQL services. Make notes of domain account names, machine names, and FQDN (Fully qualified domain name).

Check for Incorrect Service Principal Names (SPN’s)

When the NAV Server and the database are on separate machines and the NAV Service is running under a Domain Account. Two SPN’s have to be set up for the NAV Service:

  • Open the Windows command prompt;
  • Fill in the following command:


1



setspn -A DynamicsNAV/NAVSERV.yourDomain.yourCompany.com:7046 yourDomain\yourUser

  • Replace ‘yourDomain’, ‘yourCompany’, and ‘yourUser’ with the appropriate values.
  • In order to set up the second service (NAV 2009 Web Service) fill in the following command:


1



setspn -A http/NAVSERV.yourDomain.yourCompany.com yourDomain\yourUser

  • Replace ‘NAVSERV’ with the name of the computer running Microsoft Dynamics NAV Server, and replace ‘yourCompany’, ‘yourDomain’, and ‘yourUser’ with the actual company, domain, and user account names.

SPN for SQL Service is not needed if SQL is running under the NetworkService account.

SPN for SQL Server is needed if SQL Server is running under a Domain account - see ‘SQL SPN’ at the end of this chapter.

When the NAV Server and the database are on separate machines, and the NAV Service is running under NetworkService account:

  • No SPN is needed for the NAV Service;
  • SPN for SQL Service is not needed if SQL is running under NetworkService;
  • SPN for SQL Server is needed if SQL Server is running under a Domain account - see ‘SQL SPN’ at the end of this chapter.

Check Delegation

When running the NAV Service under a Domain Account Delegation has to be set up for the account running the NAV service.







The Delegation tab will only be present after adding the SPN to the domain user account.

  • Click ‘Start’, then click ‘Run’;
  • Type in ‘dsa.msc’ and click ‘OK’;
  • Expand the ‘Domain’ and then click on ‘Users’;
  • Locate the domain user account you are using, right click and select ‘Properties’;
  • Under that ‘Delegation’ tab, select the ‘Trust this user for delegation to any service (Kerberos only)’, then click ‘OK’. (This is not constrained delegation as mentioned in the Walkthrough, but this makes it a little easier to setup delegation. You can always come back after it is setup and working to implement constrained delegation);
  • Close the ‘Active Directory Users and Computers’ window.






For Constrained delegation, select Trust this user for delegation to specified services only and then select MSSQLSvc.

When running the NAV Service under NetworkService account, Delegation has to be set up for the machine running the NAV service.

  • Click ‘Start’, and then click ‘Run’;
  • Type in ‘dsa.msc’ and click ‘OK’;
  • Expand the ‘Domain’ and then click on ‘Computers’;
  • Locate the computer name, right click and select ‘Properties’;
  • Under that ‘Delegation’ tab, select the ‘Trust this machine for delegation to any service (Kerberos only)’, then click ‘OK’;
  • Close the ‘Active Directory Users and Computers’ window.

Check SQL Logins and OCL

Adding the login(s) to SQL Server and setting up the Object Change Listener (OCL):







OCL is not required if the NAV Server and SQL Server are on the same machine and the NAV service is running under Network Service account.

If using a Domain User to run services, make sure the login has been added to both SQL Server and NAV. Also check that user has Full Control to the server folder (the default path to the server folder is the following: C:\Program Files\Microsoft Dynamics NAV\60\Service).

The account may already exist in SQL Server but the permissions must be manually set correctly:

  • Open Microsoft SQL Server Management Studio;
  • Click ‘Security’ to expand the tree-view, right-click ‘Logins’, and then select ‘New Login’.
    This opens the ‘Login - New’ dialog box;
  • Add the domain user account in the ‘Login’ name field, using the following format:

domain\domainUser

  • Click ‘OK’ to exit the ‘Login - New’ dialog box;
  • Click ‘Databases’, ‘Demo Database NAV (6-0)’ or other database name, and then click ‘Security’ to expand the tree view;
  • Under ‘Security’, right-click ‘Users’, and then select ‘New User’.
    This opens the ‘Database User - New’ dialog box;
  • Add the domain user account in the ‘User’ name and ‘Login’ name field, using the following format:

domain\domainUser.

Add $ndo$navlistener in the Default schema field:

  • Click the ‘Securables’ page;
  • Click ‘Add’, click ‘OK’, click ‘Object Types’, check ‘Tables’ and then click ‘OK’. Click ‘Browse’, check the ‘[dbo].[Object Tracking]’, click ‘OK’, click ‘OK’ again.
    In the ‘Explicit permissions’ check ‘Grant’ on the ‘Select permission’;
  • Click ‘OK’ to exit the ‘Database User - New’ dialog box;
  • Close Microsoft SQL Server Management Studio.






If the NAV server and SQL Server are on different machines and the Network Service account is running the NAV Service, then the Login and OCL must be set up using the same steps but for the machine account rather than the domain user.
Use the steps described earlier, but replace the domain account with the machine account with the following form: <computername>$.

Check the configuration of Delegation for the RTC

  • Change the ‘ClientUserSettings.config’ on the computer running the RTC, under the current user’s profile, to define that a domain user account is to be used when connecting to the NAV Service tier.

On Windows Vista or Windows Server 2008, the default location is:

X:\Users\AppData\Local\Microsoft\Microsoft Dynamics NAV

On Windows XP or Windows Server 2003, the default location is:

X:\Documents and Settings\Local Settings\Application Data\Microsoft\Microsoft Dynamics NAV

  • Add the following key to the file:


1





  • There are two possible values: ‘NetworkService’ and ‘DomainUser’. To enable delegation, set the parameter to ‘DomainUser’.

This will need to be repeated for all workstations that will be using the RTC.







After confirming all items above and making the necessary changes, be sure to stop and start the NAV Server service before you attempt to re-connect using the RTC. If you still encounter the error message, remember that Kerberos tickets last for ten hours, so if you add/change the SPN, you may either have to wait for any existing tickets to expire or download KerbTray and attempt to expire any existing tickets. This is found in the Windows Server 2003 Resource Kit, which can be downloaded from here.

Check the SQL Service SPN (optional)

An SPN for SQL Server is composed of the following elements:

  • ServiceClass: This identifies the general class of service. This is always MSSQLSvc for SQL Server;
  • Host: This is the fully qualified domain name DNS of the computer that is running SQL Server;
  • Port: This is the port number that the service is listening on;
  • yourDomain\yourUser: This is the user which runs the service.

For example, a typical SPN for a computer that is running SQL Server is:

MSSQLSvc/SQLSERVER1.yourDomain.yourCompany:1433 yourDomain\yourUser

Use the following command to add this SPN:



1



setspn -A MSSQLSvc/SQLSERVER1.yourDomain.yourCompany:1433 yourDomain\yourUser

The format of the SPN for a default instance and the format of an SPN for a named instance are not different. The port number is what ties the SPN to a particular instance.






Once u do all those things please update domain policy among all ur comp[uters it will work :slight_smile:

Thanks a million! I will check asap and update here =)

Good news is that there is some progress. The settings in this guide were already in place, but it made me think to the way webserver is being accessed. I changed back to “false” in CustomSettings.config and ggot it working under the following conditions.

  • The URL used to access webservices must use the NETBIOS name of the server (hostname without domain suffix). FQDN or IP address wont work.

  • Machine used to access webservices must be on the domain.

  • IE must be started with the credentials of the user that needs to log into webservices, either by having this user logged on the windows session launching IE - or - by right-clicking then selecting “Run as a different user” on IE.

  • IE must have the URL of webservices (basically the NETBIOS name of the server) in the “Intranet” zone so that credentials are passed automatically (filling credentials manually when prompted wont work).

Now, i am not sure if this is normal behavior or if i have missed something… any experience with that?