3. Mai 2012 15:22
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.