mit dem cRM beziehe Daten von einer Datenbank (und liefere Daten an diese DB) auf einem anderen Server. Die Verbindung wird hergestellt über eine View auf cRM-Seite und einen Verbindungsserver.
Der Verbindungsserver bleibt im Sicherheitskontext der aktuellen Anmeldung, einzig die combit-Anmeldung verwendet eine Anmeldung mit weitreichenden Rechten.
In der zweiten Datenbank tragen einige Tabellen beim Erstellen eines Datensatzes den Ersteller des Datensatzes ein (DEFAULT SUSER_SNAME()). Hier erhalte ich jedoch nur die weitergereichte combit-Anmeldung.
Habe ich den cRM falsch installiert, so dass ich den Sicherheitskontext nicht an die Datenbank weiterreiche?
Ist den am Client unter Konfigurieren \ Datenbank \ Datenbankverbindung… \ Anmelden auch „Windows Authentifizierung verwenden“ gesetzt? Hier kann auch ein eigener DB Benutzer hinterlegt sein.
Vielleicht kann noch jemand anderes helfen. Was aber immer gehen müsste ist den Benutzer gezielt zu schreiben, so das nicht der Default-Wert gesetzt wird. Dann schreibt ihn deine cRM Datenbank und die weiß ja welcher Benutzer in welchem Kontext angemeldet ist.
Zumal du vermutlich eine View mit INSTEAD OF Trigger an der View hast, sonst könntest du ja die Tabelle vom Verbindungsserver gar nicht im CRM sehen und auch nichts da rein schreiben. Dann muss die INSERT Anweisung in dem Trigger um eine Variable für den Usernamen ergänzt werden, ich nutze z.B. SYSTEM_USER dafür.
Wir müssen hier unbedingt zwischen der Datenbankserver-Anmeldung und der combit CRM Benutzeranmeldung sauber trennen.
Datenbankserver-Anmeldung: kann ein fester (ggf. auch komplett „kryptischer“) SQL Server Benutzer sein, kann Windows Authentifizierung sein. Hat nichts mit combit CRM Benutzerdaten („combit CRM Benutzername“) zu tun.
combit CRM Benutzeranmeldung: Ist die Anmeldung des Anwenders in der combit Software (ggf. vollautomatisch ohne Kennworteingabe über eine in der Benutzerverwaltung hergestellte Assoziation zw. einem Windows-Benutzernamen und einem cRM-Benutzerkonto).
Wenn nun im Datenbankserver-Kontext (z.B. Trigger, stored procedure o.ä.) der cRM-Benutzername für den aktuellen Kontext der „SQL Server Session“ ermittelt werden soll, dann geht dies über folgendes T-SQL snippet:
SELECT @username = Substring("program_name", 0, PATINDEX('%@%', "program_name"))
FROM sys.dm_exec_sessions
WHERE "session_id" = @@SPID AND PATINDEX('%@%', "program_name") != 0
Dieser Wert kann dann im aktiven Kontext weiterverarbeitet werden, d.h. ggf. beim „Hinüberschieben“ von Daten an den Linked-Server als Feldinhalt direkt schon gesetzt werden.
Im Kontext des Linked-Servers kann das Snippet nicht verwendet werden, weil der ja seine eigene sys.dm_exec_sessions hat, und diese nicht durch den combit CRM Client-Datenbankanmeldevorgang mit den cRM-Benutzerdaten (siehe Rahmen) präpariert wurde - der program_name wird dort nicht entsprechend gesetzt.
Ich habe am Wochenende die Datenbankverbindung auf „Windows Authentifizierung verwenden“ gesetzt. Wenn nun ein Trigger auf dem Linked Server einen neuen Datensatz in einer Tabelle erzeugt wird die Spalte „CreatedBy“ mit dem Default SUSER_SNAME() befüllt und das ist der Windows-Anmeldename.
Für meine Dokumentations- und Logtabellen ist diese Lösung ausreichend.
Um die letzte Unschärfe zu eliminieren müsste die Anmeldung an den cRM ebenfalls über eine Windows-Authentifizierung (als Single SignOn) erfolgen, dann kann ich mir so sicher wie möglich sein, dass der dokumentierte Benutzer auch derjenige war, der die dokumentierte Aktion durchgeführt hat. Ich werde also die entsprechenden Häkchen in der Benutzerverwaltung setzen .
Gegen das Weitergeben von Anmeldedaten, das schnelle Benutzen eines offenen Rechners bei einem Kollegen etc., also gegen menschlichen Missbrauch kann ich mich sowieso nur schwer verteidigen.
Für unsere Bedürfnisse scheint die Änderung der Anmeldung an das Datenbanksystem das Problem zu lösen.
.