Webservice Authentifizierung zum NAS

Hi folks, ich habe ein Kerberos oder Delegationsproblem mit dem Webservice von Dynamics NAV 2009 R2. Ich hoffe, Ihr könnt mir helfen.

Es ist ein etwas unübliches 2-tier Model. The servertier läuft mit den selben credentials wie der Webservice. Beide teilen sich einen Prozess on the same computer. Portsharing ist eingeschaltet. Der NAS läuft auf Port 7046, der WS auf 7047. Beide Services laufen logischerweise mit demselben Serviceaccount. Soweit, so gut.

Der korrespondierende DB-Server ist ein 2014er Always-On-Cluster mit 2 nodes and one Cluster Ressource. Hier habe ich einen abweichenden Serviceaccount.

Die SPN für 7046 and 7047 zeigen mit demselben Serviceaccount auf den APP sowie auf den WS-Server.

Der abweichende Serviceaccount des DB-Clusters ist mit allen 3 Ressourcen (Clusterkopf, Node1 and Node 2) mit Port 1433 auf alle Anbieter gebunden.

Das Problem I have. Rufe ich den Webservice per IP, hostname oder FQDN auf dem Applikationserver selbst beziehungsweise Webserver selbst mit beispielsweise http://nserver:4047/DynamicsNav/WS/Services auf, bekomme ich den erwarteten Response. Dasselbe gilt für einen Aufruf direkt auf den DB-Ressorcen.

Aber wenn ich nun denselben Call auf einer Workstation außerhalb der APP-Server to DB-Server Delegation ausführe, erhalte ich die Message dass der DB-Server die Authentifizierung nicht quittieren kann. Der Aufruf schlägt fehl.

Wenn ich nun aber zuerst den User am APP-Server selbst authentifizieren lassen und dann an seiner eigenen Workstation den Aufruf wiederhole, funktioniert es. Der dabei erzeugte Securitytoken wird in irgendeiner Art vererbt.

Schaue ich mir das Eventlog des NAS an, sehe ich Calls, die vorher nicht bewusst von Hand auf dem NAS initiiert wurden, Übergaben an den DB-Service mit leeren Kerberos Credentials beziehungsweise Service Principal Names, die dieser ablehnt.

Lasse ich den Anwender vorher sich bewusst auf dem App-Server (NAS+WS) vorher authentifizieren, und rufe dann auf seiner own Workstation den Webservice auf, reicht der App-Server die Kerberos Credentials als "bekannt" an den DB-Service durch und die Authentifizierung gelingt.

Meine Erkenntnis ist, die Delegation ab NAS- und Webservice zum DB-Service funktionieren. Was auch der RTC zeigt, der keinerlei Probleme hat. Allerdings werden die Credentials des Webservice auf 7047 nicht korrekt zum NAS auf 7046 übergeben. Was zur Folge hat, dass das nachfolgende Kerberos-Paket, das zum authentifizieren an den DB-Service gesandt wird, im Bereich des Principal name leer ist. Das führt wiederum zur Ablehnung, da der DB-Service den leeren SPN nicht verarbeiten kann.

Was ist eurer Meinung nach zu tun? Wie bekomme ich den Webservice dazu, den SPN an den NAS durchzureichen, damit er sich mit diesem beim DB-Service authentifizieren kann?

Vielen Dank vorab für eure Hilfe!

Cheers Ingo

nicht wundern, dein Beitrag ist für mich etwas confusing written, deshalb stelle ich possibly stupid Fragen .... ...nimm's mir nicht übel, aber das musste sein ;)

Du schreibst NAS meinst aber bestimmt NST.
das hier

http://nserver:4047/DynamicsNav/WS/Services

soll bestimmt das sein

Code:

http://nserver:7047/DynamicsNav/WS/Services

was mich wundert - warum DynamicsNAV?
wie heißt der NST für den Webservice? ...oder war das in 2009 noch ganz anders, als "heute"...ich glaube nicht

somit wäre doch der aufruf

Code:

http://nserver:7047/<DEINWEBSERVICENST>/WS/Services

according to ^^
https://cloudblogs.microsoft.com/dynamics365/no-audience/2008/08/09/nav-2009-how-to-publish-a-web-service/

hast du auch mal mit den verschiedenen Einstellungen am NST (der den Webservice veröffentlicht) gespielt?
sprich "Use NTLM Authentication" ...keine Ahnung ob's was bringt.

und dann hab ich noch das hier, aber das hast du bestimmt schon durchgeforstet:
https://forum.mibuso.com/discussion/40371/nav-web-services-delegation-problem

Danke... den Hieb hatte ich förmlich erbettelt werde mich künftig mehr ins Zeug legen.

Mit

Code:

http://nserver:7047/DynamicsNav/WS/Services

hast du recht - ist auch so. Das NST lautet auf DynamicsNav, daher auch der Name im Aufruf. An den Einstellungen NTLM ja/nein etc. habe ich überall gedreht, aber leider ohne Erfolg.

Danke auch für die Links. Die SPN sind alle gemäß den Empfehlungen gesetzt. Auch die Delegationen mit Kerberos only habe ich eingestellt sowie die Domänen in die sicheren Seiten aufgenommen. Das Ergebnis ist immer dasselbe: das Kerberostoken bleibt leer sobald ich außerhalb des Middletier auf den Webservice zugreife. Packe ich alle Services auf den Datenbankserver (meine größte seelische Qual ) läuft alles ohne Probleme.

vielleicht hilft dir einiges aus dem Beitrag weiter:
http://www.msdynamics.de/viewtopic.php?f=40&t=16035

spiegelt doch das Verhalten bei dir soweit auch wieder, wenn ich das grob überfliege

und hier ist das Vorhehen (ob's richtig ist, weiß ich leider nicht) wohl auch ganz gut beschrieben

https://help.sana-commerce.com/sana-commerce-93/installation/prepare-nav-environment/nav-2009-threetier-environment

...du bist mein Held der Woche!

Der 2. Link hat es gebracht. Die Delegation des Domainusers für das NST auf den SQL-ServiceUser mit Port 1433 war des Pudels Kern und die Rettung meines jungfräulichen SQL Clusters

Klasse Sache! Danke, dass du dich durch mein strange's Denglisch gearbeitet und deine Zeit dafür geopfert hast. Ich wünsche dir und der Community ein Frohes Fest!

Meines ist schon heute

immer sehr gern und das mit dem Denglish ist doch völlig ok - wollte dich nur aufziehen (hat ja geklappt) ;)
freut mich, dass es geholfen hat

PS: Held der Woche....es ist doch schon Freitag - jetzt hab ich nur bis noch Sonntag den Titel

Hallo zusammen, ich hätte den Titel Held des Jahres zu vergeben
wir haben das folgende, reproduzierbare Delegationsproblem mit Dynamics NAV 2009R2 im Zusammenhang mit Webservices und drehen uns aktuell im Kreis. Vielleicht hatte jemand schon mal ein ähnliches Problem.

Der Aufbau ist ein 3-Tier, wobei NST und Webservice auf demselben Rechner laufen und sich einen Prozess teilen.

APP01 = NST und Webservice-Host
gw49s* = Datenbankhosts für MSSQL 2014 Cluster

dynamicsNavProd = AD-Account für NST und Webservice
s_ssegw49scl01 = AD-Account für MS-SQL-Servercluster

Domain: frascio.local

Sie SPNs sollten meiner Meinung nach richtig gesetzt sein.

DynamicsNavProd:
Registrierte Dienstprinzipalnamen (SPN) für CN=Service DynamicsNAV Prod, OU=Serviceaccounts, OU=SBSUsers,OU=Users,OU=MyBusiness,DC=frascio,DC=local:
HTTP/gw49scl01.frascio.local:7047
HTTP/gw49sql01.frascio.local:7047
HTTP/gw49sql02.frascio.local:7047
HTTP/gw49sql02.frascio.local
HTTP/gw49sql01.frascio.local
HTTP/gw49scl01.frascio.local
HTTP/gw49scl01
HTTP/gw49sql02
HTTP/gw49sql01
HTTP/app01
HTTP/app01.Frascio.local
HTTP/app01:7047
HTTP/app01.Frascio.local:7047
DynamicsNAV/app01.frascio.local:7046
DynamicsNAV/app01:7046

s_ssegw49scl01:
Registrierte Dienstprinzipalnamen (SPN) für CN=s_sseGW49SCL01, OU=SQL, OU=Serviceaccounts, OU=SBSUsers,OU=Users,OU=MyBusiness,DC=frascio,DC=local:
MSSQLSvc/GW49SQL02.frascio.local:1433
MSSQLSvc/GW49SQL02:1433
MSSQLSvc/GW49SQL01.frascio.local:1433
MSSQLSvc/GW49SQL01:1433
MSSQLSvc/GW49SCL01.frascio.local:1433
MSSQLSvc/GW49SCL01:1433

Schalten wir die Delegierung des NST-Serviceusers auf Kerberos Only kann sich der Nav-Service-User problemlos gegen alle Hosts im Netzwerk authentifizieren und somit auch auf die diversen Freigaben im Netz zugreifen, die für den Tagesbetrieb benötigt werden. Allerdings funktioniert dann die Authentifizierung des Webservices gegen den NST nicht, obwohl beide auf derselben Maschine laufen. Wir erhalten im Eventlog eine Kerberosfehlermeldung die zeigt, dass der Webservice ein leeres bzw. anonymes Token übergibt und somit die Authentifizierung verhindert.

Schalten wir dann im AD auf "any Protocol" und tragen hier als Gegenüber den DB-Serviceuser mit 1433 ein, funktioniert der Webservice sofort, aber der Zugriff auf alle anderen Hosts geht verloren. Der Nav-Serviceuser kann sich dann nur noch gegen den eigenen Host authentifizieren und nur auf die eigenen Freigaben zugreifen.

Der RTC funktioniert in beiden Szenarien problemlos.

Kennt jemand dieses Verhalten? Was müsste eingestellt sein, damit sowohl der Zugriff auf die Hosts des Netzwerkes, als auch der Webservice funktioniert?

Ich habe das jetzt auch mal mit netmon und fiddler geprüft. Ich sehe am Client das Aushandeln via Kerberos (Paket startet mit YII...) Das Ticket um den NST bzw. Webservice anzufragen bekomme ich vom KDC1 = DC1 - das passt noch. Dann fragt das NST den 2. Domaincontroller = KDC2 nach einem Ticket und bekommt an dieser Stelle allerdings ein badoption 0xc als response. Mit diesem anonymen Ticket versucht der Webservice die Kommunikation mit dem DB-Cluster und scheitert folgerichtig. Alles schreit nach einem fehlenden SPN oder zumindest einer fehlerhaften Konfiguration.

Mit dem Kerberos Configuration Manager von MS konnte ich 2 fehlende SPN identifizieren. Aber auch nach deren Setzen gibt es leider keine Veränderung im Verhalten. Inwieweit der Always-On-Cluster das Verhalten beeinflußt, konnte ich noch nicht herausfinden. Allerdings vermute ich das Problem vielmehr im double hop, den es in der 2-Tier-Architektur vorher so nicht gab. Glauben bedeutet aber nicht Wissen.

Vielleicht jemand eine Idee dazu?