NAV 2009 Web Services on a three machine setup


Much like the setup of the RTC/NAV Server connection in NAV 2009. NAV 2009 Web Services needs to have a SPN added to properly authentic the users accessing it.

Consider the following scenario in Microsoft Dynamics NAV 2009. You have just completed the “Installing the Three Tiers on Three Computers” walkthrough. The NAV Role Tailored Client (RTC) is working. You have started the Microsoft Dynamics NAV Business Web Services service. When you attempt to view a Web Service URL in a web browser from a client machine you receive a login prompt. If you try to login, you are prompted three times before the process is stopped. An example of possible Web Service URLs is:

http://xxx:7047/DynamicsNAV/WS//Services
http://xxx:7047/DynamicsNAV/WS/SystemService

Note xxx is the server name of the Service Tier. This also assumes that you are using the default port (7047) and default service name (DynamicsNAV).

This problem occurs because a Service Principal Name (SPN) has not been added to the domain user account running the Microsoft Dynamics NAV Business Web Services service for the HTTP service, which is the normal service name used by web services.

Resolution

In order to eliminate the login prompts and allow authorized users to view the Web Services URL, you need to add the following SPNs to the domain user account running the Microsoft Dynamics NAV Business Services service.

HTTP/FullyQualifiedDomainNameOfNavWebServiceServer
HTTP/NameOfNavWebServiceServer

Now, I’m sure you all know if you use the ADSI Edit snap-in, or another utility such as the LDP or LDAP 3 utilities to incorrectly modify attributes to AD objects you could seriously mess up the AD, so be careful. Also, you need to be a domain admin to make the following changes.

To add the SPNs from a domain server, follow these steps:

  1. Click Start, click Run, type Adsiedit.msc, and then click OK.
    Note The ADSIEdit tool is included in the Windows Server 2003 Support Tools. If you are using Windows Server 2008 the ADSIEdit tool will already be installed. To obtain the Windows Server 2003 Support Tools, visit the following Microsoft Web site: http://www.microsoft.com/downloads/details.aspx?familyid=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en
  2. In the ADSI Edit snap-in, expand Domain [DomainName], expand DC= RootDomainName, expand CN=Users, right-click CN= AccountName , and then click Properties. If you are on a server running Windows Server 2008, you may need to first connect and bind to an instance.
    Notes
    DomainName is a placeholder for the name of the domain.
    RootDomainName is a placeholder for the name of the root domain.
    AccountName is a placeholder for the account that you specify to start the NAV Server service.
    If you specify a domain user account to start the NAV Server service, AccountName is a placeholder for the domain user account.
  3. In the Properties dialog window locate the servicePrincipalName attribute and double click it to open the Editor Dialog window.
  4. Using the following format enter the following two SPNs individually. Click the Add button to add each SPN.

    HTTP/FullyQualifiedDomainNameOfNavWebServiceServer
    HTTP/NameOfNavWebServiceServer

  5. When finished, click OK, and then OK. Finally close the ADSI Edit window.

Additional Information

Since Kerberos ticket usually expire after 10 hours, you may need to purge the current Kerberos tickets from client machine before the setup of the Microsoft Dynamics NAV Outlook Add-in can be completed in Microsoft Outlook.

With Kerbtray.exe, you can easily verify or remove (or both) Kerberos tickets from any of the associated computers that are being used. To download the Kerbtray utility, visit the following Microsoft Web site:

http://www.microsoft.com/downloads/details.aspx?FamilyID=4e3a58be-29f6-49f6-85be-e866af8e7a88&displaylang=en

Scott Wright
Microsoft Dynamics NA

Microsoft Customer Service and Support (CSS) North America

These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

Comments (13)

  1. brunojohansson says:

    Thanks for this info. Is the Credentials property in the _Binding class supported in order to allow defining credentials in code, e.g.

          Dim _service As New WebService.Item_Binding

           Dim _credentials As System.Net.ICredentials = New System.Net.NetworkCredential("myname", "mypwd", "ourdomain")

           _service.UseDefaultCredentials = False

           _service.Credentials = _credentials

    I can’t seem to get this to work, always get an unauthorized error.

    Am I missing something?

    /Bruno

  2. scowri says:

    Thank you for the comments Bruno!

    I’m not all the familiar with VB, so I setup a similar test using C# and I was able to provide alternate NetworkCredentials and still access the NAV Web Service I had setup.

    I suggest verifying that the default credentials work first. Then make sure that the user credentials you are passing in have a login and proper permissions in NAV.

    Scott Wright

    Microsoft Dynamics NA

    Microsoft Customer Service and Support (CSS) North America

    These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.  

  3. When I started blogging just short of two years ago, there weren’t too many NAV blogs. I don’t bother

  4. rtaranti says:

    Hi there.  This  question may fall under a seprate posting for the NAV server but I could not find one so… I am having an issue with my middle tier NAV server authenticating with my machine that is hosting SQL server 2005. Please note, these are all test machines for a proof of concept.  I am testing the three-tier approach as this is how will we use it in production.

    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.  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 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 spn’s the new service does not show.  Could you assist?

  5. scowri says:

    Hi rtaranti,

    Thank you for the post! I understand that you are having some issues with your NAV 2009 3 tiers on 3 machines setup.

    My first recommendation is to make sure you have setup your NAV install as described in the "Installing the Three Tiers on Three Computers" walkthrough. This walkthrough can be found at the following link:

    Installing the Three Tiers on Three Computers

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

    Since this gives a single setup scenario with very specific requirements, if your setup differs, you could run into issues. I have been involved with updating this walkthrough and the next version should be better. It is also planned to update the MSDN documentation on a regular basis, so keep checking back.

    It sounds like you are getting an error similar to the following in the SQL Server log:

    "Login Failed for user ‘NT AuthorityANONYMOUS’ LOGON"

    That tells me that something is incorrect in your SPN/delegation setup. When working with SPNs, the two most common issues are mistyped SPNs and duplicate SPNs.

    Mistyped SPNs are pretty straight forward, is the SPNs isn’t correct, authentication will fail. Double check to make sure you don’t have any typing mistakes in your SPNs.

    Since SPNs are used to uniquely identify service accounts, there cannot be more than one for each service (in this case we are usually only interested in the NAV Server service and the SQL Server service). If there are duplicate SPNs a KDC error is generated on the domain controller in the System log. The following KB article explains these errors in detail.

    Event ID 11 in the System log of domain controllers

    http://support.microsoft.com/kb/321044

    For delegation, I would recommend starting with ‘open’ or unconstrained delegation. The walkthrough describes how to setup constrained delegation. To not use constrained delegation when setting up delegation you would select ‘Trust this computer for delegation to any service (Kerberos only)’ instead of ‘Trust this computer for delegation to specified services only’. After you have the setup configured successfully, you would then go back on limit the delegation to specific services.

    I hope this information helps!

    Due to the nature and complexity of setting up a 3 tier installation of NAV if you need further assistance I would recommend submitting a support incident thru PartnerSource.

    Scott Wright

    Microsoft Dynamics NA

    Microsoft Customer Service and Support (CSS) North America

    These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

  6. rtaranti says:

    Greetings,  I have a follow up question in the use of "delegation".  If am using a specific domain service account to run my production NAS (not to be confused with NAV) server for NAV 3.7B, do I run any risk in setting up delegation for this account so I can use it in testing the NAV 2009 service tier? In other words, will it open up any security holes or damage the priviledges the account has currently?

  7. scowri says:

    Hello rtaranti,

    Sorry for the delayed reply!

    As far a reusing an existing account already running a NAS to run the NAV 2009 Service tier, I don’t see a problem doing this. As long at the accounts permissions are properly limited (i.e. not an admin) adding the settings needed for delegation shouldn’t interfere or open up security needlessly.

    Scott Wright

    Microsoft Dynamics NA

    Microsoft Customer Service and Support (CSS) North America

    These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

  8. rtaranti says:

    Thank you for the response Scott.  I have a one more on this subject I would like to ask.  I am now using my NAV server domain service account to run two separate NAV servers, each on their own machine.  One is for development and the other for system testing.  Since each spn associated with the account is unique I have no issues expect when trying to switch between the servers with a “running” client.  

    In other words, if I switch the client machines clientusersettings.config server settings and then open the client I have no problem bouncing between servers, but when I try to do this from the running client, I get the sql login message issue we saw from my earlier posts.  

    Any recommendations on how to solve this…besides using completely separate service accounts?  : I would like to avoid having too keep track and maintain a bundle of service accounts for my landscape.

    Best Regards (and welcome back),

    Robert

  9. scowri says:

    Hello Robert,

    That is a very good question! I would recommend having your partner submit a support incident on this issue.  

    I’ve been able to repro the issue in a test environment, but it’ll take more time to look at what could be causing it.

    I did find that if you run both NAV Servers with the Network Service account, instead of a domain account, switching between NAV Servers within a running RTC doesn’t produce an error.

    Scott Wright

    Microsoft Dynamics NA

    Microsoft Customer Service and Support (CSS) North America

    These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

  10. awillis says:

    Hello Scott,

    First, very good Blog. This is information I have not been able to find anywhere else.

    I am currently receiving the "Login Failed for user ‘NT AuthorityANONYMOUS’ LOGON" error when attempting to view any WSDL from a what would be considered the "client machine" in the three tier architecture. However, I can view the WSDL using IE on the Server tier.

    This may be caused by the following:

    In the walkthrough "Installing the Three Tiers on Three Computers", I am instructed to setup Delegation. This option in only available if your domain functional level is Windows 2003.

    Currently my domain is Windows 2000 native and I cannot raise the domain functional level because we have a couple of older severs that are Windows 2000.

    So my question is that on a domain such as mine, where i have approx. 40 servers, if at least one of those servers are Windows 2000 and delegation is not available, is there any other option for using the three tier architecture?

    Regards,

    Aaron

  11. scowri says:

    Hello Aaron,

    Thank you for your comment! I’ll be glad to answer your question as best I can.

    Yes, if you are running on a Windows 2000 native level domain you do have an option for running NAV 2009. While it is not possible to setup constrained delegation on a Windows 2000 DFL, it is possible to setup open (aka general) delegation. This would not be recommended due to the possible security risks, but it is an option.

    Setup of delegation in Windows 2000 native DFL is a bit different. The following have steps for setting up delegation on Windows 2000 native domain.

    Allow a user to be trusted for delegation

    http://technet.microsoft.com/en-us/library/cc739474.aspx#BKMK_2

    Allow a computer to be trusted for delegation

    http://technet.microsoft.com/en-us/library/cc738491(WS.10).aspx

    Other than the above, configuration would be the same as when using Windows 2003 native DFL.

    We have done some very limited testing of this scenario in Support and have had mixed results. We have set it up successfully using the Network Service, but not a Domain User account.

    I hope the above information will be helpful. If you have more questions I would suggest submitting a support incident (or having your partner submit one) to NAV Support.

    Scott Wright

    Microsoft Dynamics North America

    Microsoft Customer Service and Support (CSS) North America

    These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.

  12. Mark Kinsella says:

    Hi Guys,

    I've been through the "Installing the Three Tiers on Three Computers" walkthrough, and now my RTC is working fine. I now need to follow the instructions above for the Web services. Just wondering, do I need the port number (i.e. :7047) at the end of the setspn string when setting the SPN through a command prompt for the web service??

    Thanks,

    Mark

  13. scowri says:

    Hello Mark,

    You should not include a port number on the HTTP SPNs as shown in this post.

    If you would like to "cover all your bases" you could add a pair of HTTP SPNs with the port number and a pair without port numbers; these shouldn't interfere with each other. My testing showed that you only needed the HTTP SPNs without port numbers so I didn’t include the other pair to reduce possible confusion.

    I have been told this is due to a bug in IE when using a non-standard port (i.e. something other than port 80). I have included the following KB article that discusses this issue.

    Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port in Windows XP and in Windows Server 2003

    support.microsoft.com/…/en-us

    Since NAV doesn’t use IIS I’m not sure the fix from the KB fully applies to us, so removing the port number from the HTTP SPNs has been the recommendation.

    Scott Wright

    Microsoft Dynamics North America

    Microsoft Customer Service and Support (CSS) North America

    These postings are provided "AS IS" with no warranties and confer no rights. You assume all risk for your use.