"Friendly" Dynamics NAV SOAP Services Configuration & SPNs

As I've mentioned, I make it a practice to secure as many services as possible using SSL over HTTPS and, whenever possible, I'll use friendly URLs to make it easy for support staff and users to find and remember those services. This article looks at configuring multiple SOAP services on the same Dynamics NAV 2018 application server, where I've got multiple tiers used for their respective third party applications (such as Jet Professional or other ISV products), and how service principal names (SPNs) play a vital role in properly configuring a SOAP service using SSL and a friendly domain name.

It does this by following the configuration of a Dynamics NAV SOAP service on a tier dedicated to a WMS ISV integration.

A little background info...

Configuring the NAV service account properly in the first place is a prerequisite for this article. An article from Microsoft, Provisioning the Microsoft Dynamics NAV Server Account, provides an excellent walk-through on how to do this.

Note that I also have installed a wildcard SSL certificate based on our domain name and have set the thumbprint in the service tier's general settings.

Also, I believe it is important to modularize your service tiers for their role. For example, I have a separate tier for our custom Dynamics 365 (CRM) integration, and a custom tier for our WMS integration. I also create separate tiers for the major departments in the organization. This allows me to manage resources and also to identify which area of the organization may be causing issues such as database locks. For the latter case, I am able to restart only the tier causing the lock, therefore only affecting a subset of users, and can work to better pinpoint what caused it in the first place.

1. Configure the URL

To start, you'll need to decide on the domain name to use for the particular tier's SOAP service. I recommend formalizing a naming scheme so that there is consistency across the platform. This should be documented and well communicated to your team.

For me, the tier is dedicated to running our WMS integration, and I have set out a naming convention whereby all NAV-related URLs look like https://nav[Service Type][Tier].mydomain.com. So for example, https://navsoapwms.mydomain.com. This is the URL I have chosen, and I will not only set the A record in the requisite DNS zone, but I am going to add it as an intranet site in our site-to-zone assignment list enforced by Group Policy.

2. Configure the Soap Service on the Dynamics NAV Service Tier

In the NAV Administration Console, we will first ensure that the Enable SOAP Services and Enable SSL checkboxes are checked. Then, we will set the SOAP Base URL parameter. This is going to take the form:

[Scheme]://[Domain]:[SOAP Services Port]/[NAV Service Tier Name]/WS/

For example:

https://navsoapwms.mydomain.com:9947/WMS/WS/

Figure 1, below, shows how this might look.

Figure 1: NAV SOAP Services Configuration

Hit save and restart the service tier like it will ask.

If you open your NAV client to that tier (assuming you have Client Services enabled on it) and navigate to Web Services, you should notice that the SOAP URL for each of your web services has been altered. This will look different depending on which tier you are connected to. Figure 2, below, shows this.

Figure 2: SOAP URLs within the NAV Client

3. Setting up the SPN for the NAV Service Tier's Service Account

Now we will set the SPN for the account running the service tier.

Open PowerShell as an Administrator, and let's first list the SPNs associated with the service account. Execute:

setspn -l [NAV Service Account Name]

You should receive output listing the various schemes (DynamicsNAV/... and HTTP/...) across the various ports you have configured on your tier. Two of them should be:

• HTTP/[Your NAV Server Name]:[Your SOAP Services Port]
• HTTP/[Your Fully Qualified NAV Server Name]:[Your SOAP Services Port]

If so, good, we can move on to configuring the additional one we will need for the new base SOAP url we have configured. If not, you will want to re-visit how you set up the NAV tier's service account. Refer to the background info at the beginning of this post.

In the same PowerShell session, execute:

setspn -a HTTP/[The Domain You have Configured for your SOAP Service]:[Your SOAP Services Port] [Your NAV Service Account Name]

For example:

setspn -a HTTP/navsoapwms.mydomain.com:9947 WMSTIER

Now, you should have everything you need to securely access your SOAP services via the friendly domain you created. To test this, open your NAV client to the tier you have been working on, and copy one of the SOAP URLs into your browser's address bar. Assuming your Windows account is permissioned to access it, it should resolve just fine with no 401 errors or anything like that.

NOTE: The loopback check on your local NAV server...

If you're trying all of this on your local NAV server, you may become frustrated that you cannot access the SOAP Service address. Try accessing from another domained machine. If it resolves, your likely dealing with a loopback check which will prevent you from viewing it on your local server. For this, you'll need to make a reigstry change. Refer to this article from Microsoft describing how to implement this. Note that I did not need to reboot the server for this to take affect (I am operating on Windows Server 2016).

Conclusion

This article has helped you configure a secure NAV SOAP service tier (using an SSL certificate) with a friendly domain name and the correct SPN settings for unimpeded authentication. If you are interested in exposing a SOAP service externally, I recommend reading my article on doing this securely using Azure's AD Application Proxy.