NAV Web Services delegation problem

NicolaiH

Hi,

first a short explanation of my problem.

I have installed NAV 2009 SP1 in a 3-tier setup on 3 different machines. I can connect to the database using RTC, but I can not connect to the Webservice because of authentication problems with the SQL server.

I have been searching everywhere and tried every suggestion I have been able to find on mibuso, google and different blogs. I am running out of things to try so here I am begging for help


Here are some more detailed information about my setup:

NAV service-tier and WS server: app01l (Windows Server 2008 R2)
SQL database server: sql01l (Windows Server 2008 R2 & SQL Server 2008)

NAV Service and Webservice are running under NETWORK SERVICE account.
SQL service is running under MYDOMAIN\sql_service account.

app01l delegation is set to "Trust this computer for delegation to any service (Kerberos only)".
sql01l delegation is set to "Trust this computer for delegation to any service (Kerberos only)".

SPN for MYDOMAIN\sql_service account: (I guess they're not needed when I have enabled delegation to any service on the server?)

MSSQLSvc/sql01l:1433
MSSQLSvc/sql01l.nph.local:1433

HTTP namespace reservations:

I have checked the HTTP namespace reservations with the HttpNamespacManger tool found here:

(http://blogs.msdn.com/paulwh/archive/20 ... -8080.aspx)

It shows:

http://+:7047/

NAV Service runs on default port 7046 and the Webservice on 7047.

The RTC works fine from any machine in our domain.

I can access the Webservice through http://localhost:7047/RHLcronus/WS/Services on the app01l server.

I can not access http://app01l.nph.local:7047/RHLcronus/WS/Services from anywhere. It pops up asking for username and password and when I type that in i get this error message:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"&gt;
<s:Body>
<s:Fault>
<faultcode xmlns:a="urn:microsoft-dynamics-schemas/error">a:Microsoft.Dynamics.Nav.Types.NavDatabasePasswordException</faultcode>
<faultstring xml:lang="da-DK">The login failed when connecting to SQL Server sql01l.</faultstring>
<detail>
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">The login failed when connecting to SQL Server sql01l.</string>
</detail>
</s:Fault>
</s:Body>
</s:Envelope>

On sql01l in the eventlog I get this message:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: 192.168.153.32]

(I did look for previous errors and the message suggests, but there are none)

I hope someone in here can see where the problem is. I would really appreciate any help I can get.

Thank you!

Nicolai Hansen

jdubuc

We're having exactly the same issue here. Any luck since your post, Nicolai? Any advice from anyone else?

NicolaiH

jdubuc wrote:

We're having exactly the same issue here. Any luck since your post, Nicolai? Any advice from anyone else?

Hi jdubuc

No I have not been able to solve this yet unfortunately. I might have to try asking Microsoft for help if no one in here has any suggestions. When I do find a solution I promise I will post it in here.

jagtap.ganesh

Have you tried this option:

Majority of the time the error: “Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON” is caused by Wrong/Mistyped/Duplicate Service Principle Names and/or Misconfigured Delegation or older Kerberos ticket still being used.

Considering you are using the default NAV instance name DynamicsNAV, default ports and default SQL service name MSSQLSvc, your SPNs would be the following:

DynamicsNAV/<machine-name>:7046
DynamicsNAV/<Fully Qualified Domain Name machine-name>:7046
MSSQLSvc/<machine-name>:7046
MSSQLSvc/< Fully Qualified Domain Name machine-name>:7046

Once you have these added the SPNs including HTTP/<web service machine name>
it should work.

NicolaiH

Hello Ganesh

Thank you for your reply.

I made these SPNs:

RHLcronus/app01l:7046 mydomain\app01l
RHLcronus/app01l.mydomain.local:7046 mydomain\app01l
MSSQLSvc/sql01l:1433 mydomain\sql_service
MSSQLSvc/sql01l.mydomain.local:1433 mydomain\sql_service
HTTP/app01l mydomain\app01l

My NAV service instance is called RHLcronus, still running on port 7046.

Do I need something for port 7047 also?

After I made these changes I purged the kerberos tickets from all the servers involved (AD, SQL, Service-tier server and client machine) and restarted both Web Service and NAV service.

But I still get prompted for a login, and when I type in my username and password I get
the "The login failed when connecting to SQL Server sql01l" message. And in the sql01l server event log I get "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'." :-k

jagtap.ganesh

Hey Check this link,

http://blogs.msdn.com/nav_developer/arc ... setup.aspx

Apart from this,
Use Best Practice Analyzer Tool to find out where the problem lies.
You can download it from the following partner source login.
You need to install and run it from the Dynamics NAV Server (Middle tier) machine.

https://mbs.microsoft.com/partnersource ... zerNAV2009

#-o

NicolaiH

jagtap.ganesh wrote:

Hey Check this link,

http://blogs.msdn.com/nav_developer/arc ... setup.aspx
#-o

I added another SPN as suggested in the blog:

HTTP/app01l.nph.local nph\app01l

Because the Web Service and NAV service runs as Network Service I add the SPN to domain\machinename.

After this change I purged all Kerberos tickets, restarted the NAV and WS services, but still no luck, I still get the login prompt.

jagtap.ganesh wrote:

Apart from this,
Use Best Practice Analyzer Tool to find out where the problem lies.
You can download it from the following partner source login.
You need to install and run it from the Dynamics NAV Server (Middle tier) machine.

https://mbs.microsoft.com/partnersource ... zerNAV2009
#-o

I have tried the Best Practice Analyzer Tool, but it does not find any errors. All I get is 2 informational messages saying "64-bit operating system was detected" and "Microsoft Dynamics NAV 2009 SP1 Setup has been used to install the product".

alexpeck

Please be aware that Internet Explorer may not behave the same as your web service client. If you specify an http SPN with a port (e.g. 7047), you need to apply a hotfix and edit the registry for IE to work - http://support.microsoft.com/kb/908209. I know it says it applies to IE 6, but I think it also affects 7 & 8 (although I haven't personally verified that).

The classic web reference proxy that Visual Studio creates for you (if you add a service reference, press advanced, the Add Web Reference...) will also generate an SPN without a port (the above hotfix does not affect this). If you use a WCF service reference (using add service reference without pressing advanced), you can use an SPN both with or without a port. You must specify it in the config as follows (this is roughly what your config would look like for the customer card page):

<system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="Customer_Binding">
                    <security mode="TransportCredentialOnly">
                        <transport clientCredentialType="Windows" />                      
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
      <behaviors>
        <endpointBehaviors>
          <behavior name="Delegation">
            <clientCredentials>
              <windows allowedImpersonationLevel="Delegation"/>
            </clientCredentials>
          </behavior>
        </endpointBehaviors>
      </behaviors>
      <client>
          <endpoint address="http://host.domain.company.com:7047/DynamicsNAV/WS/CRONUS%20International%20Ltd./Page/Customer"
            binding="basicHttpBinding" bindingConfiguration="Customer_Binding" behaviorConfiguration="Delegation"
            contract="CustomerServiceReference.Customer_Port" name="Customer_Port" >
          <identity>
            <servicePrincipalName value="http/host.domain.company.com:7047"/>
          </identity>
        </endpoint>
      </client>
    </system.serviceModel>

NikolaiH: when you added an http SPN for the machine (which is correct when the service runs as NETWORK SERVICE), did you delete the http SPN you created previously? If there are two accounts (machine or user) in AD which have the same SPN (http/hostname), when your client tries to look up the service account based on the SPN it will fail.

Based on your client, determine whether you should specify a port or not in your http SPN. Then, to troubleshoot, try to:

• Use the ldp tool to find duplicate SPNs, then delete them.
• Enable Kerberos event logging - this should give you a bit more information to work with

The Best Practices Analyser validates http SPNs which contain a port. If you use http SPNs which do not contain a port (which it sounds like you did at least initially), BPA will not check them. This is an unfortunate limitation in the tool - we can't check and validate all the different ways it is possible to set this up.

Alex

jdubuc

We were finally able to get our particular Web Services app working in a full 3-tier environment by selecting "Use any authentication protocol" instead of "Use Kerberos only" on the Delegation tab for our service account.

Several articles & posts specifically say to select the "Use Kerberos only" option. Can anyone provide information on the implications of allowing any protocol, rather than just Kerberos? Is this a security concern?

Thanks.

alexpeck

I think this will enable Kerberos protocol transition. Your client will authenticate to the service using NTLM, then the service will obtain a Kerb ticket on the user's behalf in order to access SQL Server.

In this scenario, there is no mutual authentication (NAV authenticates the client, but not vice versa). This is less secure, because the client is not guaranteed to be connecting to the real NAV service. Without this mutual authentication, your service is more suceptable to man in the middle style attacks. Depending on the security requirements of your implementation, this may or may not be a significant limitation.

Alex

NicolaiH

I finally got my 3-tier setup to work earlier this week.

The first thing I did, which is probably not nessesary, was to add 2 extra SPNs:

HTTP/app01l.nph.local:7047 nph\app01l
HTTP/app01l:7047 nph\app01l

I already had:

HTTP/app01l.nph.local nph\app01l
HTTP/app01l nph\app01l

I will try to remove these again when I get some time, but I do not think that this was what solved my problem.

I think that the real problem for me was Internet Explorer security settings.

When I type http://app01l.nph.local:7047/RHLcronus/WS/Services that is seen as an Internet site, not local intranet as I expected. This does not work, not for me anyway. When I add the site to trusted sites, I get prompted for username and password and I am able to log in now with any user that has been added to Windows Logon in the NAV database. In the security settings under trusted sites in Internet Explorer there is a setting that makes IE automatically try to login with your current Windows username and password, this works fine.

If you leave out the fully qualified domain name (FQDN) and type http://app01l:7047/RHLcronus/WS/Services instead, the site is now seen as local intranet and I think that the default security settings for this allows Internet Explorer to automatically send your username and password.

I am really happy that I have this working now and I want to thank everyone in here for all your help I really appreciate it.

When I get some time I will try to write down exactly what is needed to run this kind of 3-tier setup (with Network Service logon for NAV services and domain user for SQL login) and post it in here of course.

Thanks everyone!

AlexWiley

jdubuc wrote:

We were finally able to get our particular Web Services app working in a full 3-tier environment by selecting "Use any authentication protocol" instead of "Use Kerberos only" on the Delegation tab for our service account.

Several articles & posts specifically say to select the "Use Kerberos only" option. Can anyone provide information on the implications of allowing any protocol, rather than just Kerberos? Is this a security concern?

Thanks.

We don't have a Delegation tab that we can find anywhere. We've also added a bunch of SPNs and can only login as the administrator. Doing research now on how to clear Kerberos tickets, but finding out where this authentications setting is would be helpful.

jdubuc

Alex, my understanding is that once you've registered at least one SPN for the account, the "Delegation" tab will appear in the Properties window for that account under Active Directory Users & Computers.

evildave

Hi Guys,

I know this maybe somewhat of a necro, but really struggling with the services and this topic has been the most informative up to now.

We are basically having the same issues as detailed here. The Web service and RTC service can be accessed from the server itself without issue. However trying to connect from any other machine results in a 'login failure when connecting to SQL Server SQLSERVER\INSTANCENAME'

To provide some background info on names/connections;

Servers
SQLserver01\Nav = This SQL instance houses the navision database
NAVDEV01 = This box hosts the Business Web Service and the NAV Server service

Database
NAV6 = This is the Navision database name

Windows Accounts
svc_sql = This is the account running the sqlserver service on SQLserver01
NAV-admin = This is the account running web service and NAV service on NAVDEV01

I created what i thought were the correct SPN's for the NAV-admin account;

SPN's
SQLserver01\Nav | SQLserver01.company.local | 1433
SQLserver01\Nav | SQLserver01.company.local | 7046
DynamicsNav | NAVDEV01.company.local | 7047
DynamicsNAV | NAVDEV01.company.local | 7046
HTTP | NAVDEV01 |
NAV | SQLserver01\Nav.company.local | 1433
NAVISION | SQLserver01.company.local | 1433
Navision | NAVDEV01 | 7046

Settings on this domain account under delegation are - 'Trust this user for delegation to specified services only' -> 'Use any authentication Protocol'

The frustrating part is that if try to connect to the web service from my remote machine using the NAV-admin account it works fine. However if I use another account that has full administration rights (super, all etc) on the database it fails(no account/machine is able to connect via the RTC unless its run from NAVDEV01). Checking the SQLserver01 logs informs me -
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error

The userid is being lost during transfer from NAVDEV01 to SQLserver01, obviously i had hoped that setting up the delegation would have fixed this (I guess I've set it up wrong)

I'm sure there's a large number of possible reasons this doesn't work, which is what I've been trying to run through. However I'm starting to reach the end of what i can think of in order to fix this. Any input from your guys would be most welcome and I'd really appreciate the time.

If you'd like me to supply any additional information here for you then just let me know.

Thanks again.

Dave

KentTranberg

Hi Evildave and others

Didt you manage to solve your problem? I have the same kind of problem at a NAV 2009 R2 installation and for the time beeing i do not know what is wrong.

Kind regards,
Kent

gaspode

alexpeck wrote: »

Please be aware that Internet Explorer may not behave the same as your web service client. If you specify an http SPN with a port (e.g. 7047), you need to apply a hotfix and edit the registry for IE to work - http://support.microsoft.com/kb/908209. I know it says it applies to IE 6, but I think it also affects 7 & 8 (although I haven't personally verified that).

I looked at this thread when trying to resolve a similar problem and did not realise the information provided here was the solution. Something that might help others connect the dots in future...

I realise this is an old topic, but when I encountered this problem recently none of the search results helped because none had been answered (or I didn't see the answer). Now that I have solved this problem I thought I would post the solution. NAV automatically registers the service principal names (SPNs) for the Web services has http/NAVSERVER:7047, etc. but Internet Explorer, Chrome, and .NET programs by default ignore the port when trying to authenticate (that is they are asking for a ticket to connect to http/NAVSERVER). If you manually register the SPN http/NAVSERVER to the user account that is running your NAV Server, it will work. Note that when trying to access the fully qualified machine name in IE you also need to add the machine to the trusted sites, but that's a different issue. Syntax is setspn -a http/NAVSERVER USERACCOUNT.