- Die sehen das Passwort nicht bzw. können es nicht auslesen.
korrekt
- Der Client lässt nur SQL Querys aufgrund von Masken Eingabe / Ausgabe. Hat der Benutzer keine Rechte auf eine Maske und kann auch keine neue Maske erstellen kann er auch nicht im Kontext des DB Users Abfragen ausführen.
korrekt - letztlich ist immer die combit CRM Benutzerverwaltung davorgeschaltet
- Die DB sieht nur den DB User aktiv, nicht welcher CRM User sich dahinter verbirgt. Trigger, Query Analyzer etc. wissen also nicht, wer da aktiv ist.
Das ist am Server über die SPID ermittelbar (egal bei welcher Authentifizierungsmethode. Wie genau, finden Sie hier:
Wir haben diesen Weg gewählt, weil Windows Domain-Usernamen nicht unbedingt auch nur annähernd mit Benutzername/Rollenamen in combit CRM korrelieren müssen, gerade wenn es generalisiert verwendete Benutzer („Mailing“, „Workflow“, „Administrator“, …) sind, die nicht an einer konkreten Person des Unternehmens (=deren Windows Auth) angebunden sind.
- Für Schreibvorgänge kann man über eine zusätzliche Spalte den CRM User-Namen mit geben.
Um das Thema kümmert sich der cRM vollständig selber für alle Felder vom Typ ‚Erfassungsbenutzer‘ und ‚Änderungsbenutzer‘', ebenso f+r alle combit CRM-seitig erzeugten Trigger (Datensatzüberwachung, Geocodierung, Serverseitige Ereignisse etc. pp) - ebenso alle Trigger der combit Solutions. In eigenen Triggern und SQL Funktionen: siehe vorheriger Punkt.
Für alle Anwender:innen und Administrator:innen ändert sich hinsichtlich der combit CRM Benutzernamen in der Anwendung durch eine Umstellung von Windows Auth auf einen oder mehrere dezidierte SQL Server Benutzer nichts.