[gelöst] NAV2009R2 - The Login failed when connecting to SQL

[ThomasFerstl]

Ich versuche mich eben am Aufsetzen der 3 Tier-Architektur und bekomme die o.g. Fehlermeldung, wenn der RTC gestartet werden soll.

Das Setup sieht so aus:

SQL-Server "gondor", WinServer 2008 R2 Standard, SQL Server 2008 Standard (64 bit)
NAV-Server "osgiliath", WinServer 2008 R2 Standard, NAV 2009 R2
NAV-Client "tfer03", Win7 64 Bit, NAV 2009 R2

Der NAV-Server läuft unter einem eigenen Domänenuser (rtcuser), der (vorhandene) SQL-Server läuft als "LocalSystem". Die Schritte "Enabling the Object Change Listener" wurden erfolgreich durchgeführt. Greife ich vom NAV-Server per RTC auf die Datenbank zu, klappt soweit alles problemlos.

Als nächstes habe ich die Service Principal names für den NAV-Service und den SQL-Service eingerichtet (myDomain habe ich natürlich durch unsere Domäne ersetzt).

Code:

setspn -S DynamicsNAV/osgiliath.myDomain.com:7046 myDomain\rtcuser

Code:

setspn -S MSSQLSvc/gondor.myDomain.com:1433 myDomain\gondor

Da der SQL-Server ja als "LocalSystem" läuft, habe ich als User das Computerkonto angegeben.

Danach im ActiveDirectory in den Eigenschaften des "rtcuser" unter "Delegierung" "Benutzer bei Delegierung angegebener Dienste vertrauen", "Nur Kerberos verwenden" und dann den von "Gondor" bereitgestellten Dienst "MSSQLSvc" hinzugefügt (erscheint 2x als Benutzer/Computer gondor:1433 und gondor.mydomain.com:1433).

Der NAV-Service wurde neu gestartet und die Kerberos-Tickets mit "kerbtray" "gepurged" (auf dem NAV-Server, dem NAV-Client und dem Domänencontroller). Wie erwartet klappt der RTC-Zugriff vom NAV-Server nach wie vor. Vom NAV-Client erscheint jedoch nach wie vor die Fehlermeldung betreffend "Login failed". Ich vermute mal, daß ich entweder beim Einrichten der SPNs etwas falsch gemacht habe oder daß doch noch alte Kerberos-Tickets in der Domäne herumschwirren.

setspn -X liefert übrigens doppelte Einträge für MSSQLSvc und zwar einmal für das Konto "gondor" (hab ich ja eben erst eingerichtet) und exakt gleich für das Konto "SQL Admin" (das wohl von einem früheren Versuch übrig geblieben ist). Könnte es evtl. daran liegen? wenn ich die Einträge für "SQL Admin" mit setspn -D löschen will, meldet mir die Konsole zwar Vollzug, beim nächsten setspn -X sind die aber immer noch da?!?

Ich weiß langsam nicht mehr weiter. Hat jemand von euch eine schlaue Idee?

LG
Thomas

Zuletzt geändert von ThomasFerstl am 15. März 2016 12:29, insgesamt 2-mal geändert.

Hi,

für den NAV-Client werden die ServicePrincipleNames nicht benötigt.
Auch das ServiceTier ist egal, es kann sogar hernutergefahren sein.
Wichtig für die Verbindung zwischen NAV-Development-Client und Datenbank ist lediglich das du eine Verbindung zum SQL-Server aufbauen kannst und das der verwendete Benutzer die entsprechenden Rechte auf SQL-Seite hat.

Hierzu ein paar allgemeine Fragen:
Verwendest du Windows oder Datenbanklogin?
Kannst du die Datenbank auswählen nachdem du den SQL-Server (mit Instanz falls vorhanden) eingetragen hast?
Sind in der Datenbank bereits Benutzer angelegt?

Es handelt sich um eine bestehende Datenbank mit eingerichteten Windows-Logins. Der Zugriff über den ClassicClient klappt rundherum probemlos. Zusätzlich dazu soll nun aber auch der Zugriff über den RoletailoredClient eingerichtet werden.

Ok, bei nochmaligem lesen fällt mein FEhler sofort auf.
Du redest ja beide male vom RTC
Hast du mal die Firewall auf Osgiliath deaktiviert um zu schauen ob es daran liegt?

Die Firewall auf Osgiliath ist für alle "Zonen" deaktiviert, ja.

ein gemeiner Fehler ist auch, das du beim starten den RTC genau diesen: 'osgiliath.myDomain.com' Hostnamen angeben muss, sonst funktioniert der Connect nicht

Gruß, Fiddi

Würde ich dann aber nicht eher eine Meldung bekommen, daß die Verbindung zum Osgiliath nicht klappt? Es scheint ja so, als würde der Osgiliath versuchen, auf die SQL-DB auf Gondor zuzugreifen (was Gondor dann eben ablehnt).

setspn -X liefert übrigens doppelte Einträge für MSSQLSvc und zwar einmal für das Konto "gondor" (hab ich ja eben erst eingerichtet) und exakt gleich für das Konto "SQL Admin" (das wohl von einem früheren Versuch übrig geblieben ist). Könnte es evtl. daran liegen? wenn ich die Einträge für "SQL Admin" mit setspn -D löschen will, meldet mir die Konsole zwar Vollzug, beim nächsten setspn -X sind die aber immer noch da?!?

Ich meine, dass SPN's nur einmal vorhanden sein dürfen, anderfalls kann Kerberos nix prüfen. Evtl läßt sich SQL Admin nur nch beendigung des SQL-Dienstes löschen. VORSICHT: Vorher prüfen wofür der gebraucht wird.

Volker

Doppelte SPNs sind im Konflikt und funktionieren dann GAR NICHT!!!!!!!!!

Im SQL Log findest Du anonymous Logins statt dem echten User.

Okay, danke für den Hinweis. Das ist dann ja kein Wunder, daß der Gondor die Anfragen ablehnt. Da kann ich dann aber leider erst heute abend wieder ran.

So, ich habe den doppelten SPN für MSSQLSvc gelöscht gekriegt. Leider lehnt der SQL-Server immer noch konsequent jeden Login-Versuch ab.

Immer noch Anonymous Login im SQL Server Log?

Jepp. Im Log steht "Login failed for user 'NT-AUTORITÄT\ANONYMOUS-ANMELDUNG'. Ursache: Fehler bei der Überprüfung des tokenbasierten Serverzurgiffs mit einem Infrastrukturfehler"

Könntest Du mal Screenshots des Attribut Editors für Service Principal Names für die Service Accounts posten?

Du musst immer pro Eintrag "2" SPNs machen, einmal FQDN und einmal Netbios (nur rechnername)

Du meinst also, ich sollte setspn 2x ausführen, einmal für gondor.mydomain.com:1433 und einmal für gondor:1433?

jep.

oder/und beim Verbindungsaufbau genau die SPN angeben, die du eingerichtet hast.

Gruß, Fiddi

Herzlichen Dank an Alle, die mir in diesem Thread bisher mit Ratschlägen zur Seite gestanden haben. Was lange währt, so heißt es, wird endlich gut!

Nachdem unsere Haustechnik mir eine VM mit Windows Server 2008 R2 aufgesetzt hat, auf der ich schalten und walten kann, wie es mir beliebt, läuft die 3-Tier Architektur nun endlich. Meine Vorgehensweise bei Installation und Einrichtung ist grundsätzlich also nicht verkehrt. Bleibt nur noch herauszufinden, wieso das auf unserem Produktivsystem nicht klappt.

Eine kleine Sache bleibt allerdings noch zu erledigen. Da wir nicht für jeden Service-Tier eine eigene Maschine aufsetzen wollen (und das auch gar nicht können), soll auf dem Osgiliath ein zweiter Service-Tier installiert werden. Grundsätzlich ist das kein Problem. Wir haben das testweise schon öfter gemacht und lassen aktuell 11 Service-Tiers auf der selben Maschine laufen ... allerdings inklusive SQL-Server, der die entsprechenden Navision-Datenbanken vorhält.

Meine Frage ist jetzt, welchen Befehl ich absetzen muß, um den richtigen SPN für den zweiten NAV-Service ($NAV2) zu erzeugen? Wäre folgender Befehl richtig?

Code:

setspn -S DynamicsNAV[b]$NAV2[/b]/osgiliath.myDomain.com:[b]7048[/b] myDomain\rtcuser