Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 262 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
2009R2 | Kerberos authentication problems between NAS and Webservice
1ngoNaumann
Member Posts: 2
Hi folks, I have a Kerberos or delegation issue with Dynamics NAV 2009 R2 web service. I hope you guys can help me.
It is a somewhat unusual 2-tier model. The servertier runs with the same credentials as the webservice. Both share a process on the same computer. Portsharing is enabled. The NAS runs on port 7046, the WS on 7047. Both services logically run with the same service account. So far, so good.
The corresponding DB server is a 2014 always-on cluster with 2 nodes and one cluster resource. Here I have a different service account.
The SPN for 7046 and 7047 point to the APP and the WS-Server with the same service account.
The different service account of the DB cluster is bound to all 3 resources (cluster head, node1 and node 2) with port 1433 on all providers.
The problem I have. If I call the webservice by IP, hostname or FQDN on the application server itself respectively webserver itself with for example http://nserver:4047/DynamicsNav/WS/Services, I get the expected response. The same is true for a call directly on the DB resources.
But if I now execute the same call on a workstation outside the APP server to DB server delegation, I get the message that the DB server cannot acknowledge the authentication. The call fails.
But if I first let the user authenticate on the APP server itself and then repeat the call on his own workstation, it works. The generated security token is inherited in some way.
If I look at the event log of the NAS, I see calls that have not been deliberately initiated manually on the NAS, transfers to the DB service with empty Kerberos credentials or service principal names, which the DB service rejects.
If I let the user authenticate on the app server (NAS+WS) beforehand and then call the web service on his own workstation, the app server passes the Kerberos credentials as "known" to the DB service and the authentication succeeds.
My finding is, the delegation from NAS and web service to DB service work. This is also shown by the RTC, which has no problems at all. However, the credentials from the web service on 7047 are not being passed correctly to the NAS on 7046. As a result, the subsequent Kerberos packet sent to the DB service for authentication is empty in the principal name section. This in turn leads to rejection because the DB service cannot process the empty SPN.
What do you think should be done? How do I get the web service to pass the SPN to the NAS so it can authenticate with it to the DB service?
Thanks in advance for your help!
Cheers Ingo
It is a somewhat unusual 2-tier model. The servertier runs with the same credentials as the webservice. Both share a process on the same computer. Portsharing is enabled. The NAS runs on port 7046, the WS on 7047. Both services logically run with the same service account. So far, so good.
The corresponding DB server is a 2014 always-on cluster with 2 nodes and one cluster resource. Here I have a different service account.
The SPN for 7046 and 7047 point to the APP and the WS-Server with the same service account.
The different service account of the DB cluster is bound to all 3 resources (cluster head, node1 and node 2) with port 1433 on all providers.
The problem I have. If I call the webservice by IP, hostname or FQDN on the application server itself respectively webserver itself with for example http://nserver:4047/DynamicsNav/WS/Services, I get the expected response. The same is true for a call directly on the DB resources.
But if I now execute the same call on a workstation outside the APP server to DB server delegation, I get the message that the DB server cannot acknowledge the authentication. The call fails.
But if I first let the user authenticate on the APP server itself and then repeat the call on his own workstation, it works. The generated security token is inherited in some way.
If I look at the event log of the NAS, I see calls that have not been deliberately initiated manually on the NAS, transfers to the DB service with empty Kerberos credentials or service principal names, which the DB service rejects.
If I let the user authenticate on the app server (NAS+WS) beforehand and then call the web service on his own workstation, the app server passes the Kerberos credentials as "known" to the DB service and the authentication succeeds.
My finding is, the delegation from NAS and web service to DB service work. This is also shown by the RTC, which has no problems at all. However, the credentials from the web service on 7047 are not being passed correctly to the NAS on 7046. As a result, the subsequent Kerberos packet sent to the DB service for authentication is empty in the principal name section. This in turn leads to rejection because the DB service cannot process the empty SPN.
What do you think should be done? How do I get the web service to pass the SPN to the NAS so it can authenticate with it to the DB service?
Thanks in advance for your help!
Cheers Ingo
0
Answers
I don't know if the cluster plays a role in the problem but maybe it's an idea to make it work piece by piece. Start from the basics or basic 2 or 3 tier. If I would encounter an issue like this I would make this big problem smaller by fixings small problems first. Good luck!
Using netmon, I found that the client first gets a valid ticket from KDC1 (domain controller 1). Then the NST asks KDC2 (domain controller 2) and gets a Kerberos response with badoption 0xc. In my opinion this indicates a missing SPN or a wrong configuration. Whether the SQL AlwaysOn Cluster influences the behavior I could not find out yet.