Bevor ich mich hier in die Arbeit stürze hätte ich gerne mal was erfragt. Meine Benutzer verwenden die Windows Authentifizierung um sich mit der Datenbank zu verbinden. Dabei „umgehen“ sie natürlich das Rechtemodell vom Combit CRM, wo sie je nach Gruppe Rechte auf einzelne Masken haben oder eben nicht. In der Datenbank hingegen sieht jeder alles, weil in der AD oder der DB keine gleichwertige Berechtigungsgruppe wie im CRM existiert.
Eine AD Verknüpfung habe ich auch nicht weil Professional Version. Ich müsste also, um das sauber zu trennen, eine AD Gruppe für jede Combit-Gruppe anlegen und die Sichten und Tabellen über diese Gruppen erlauben und dann alle Gruppen in beiden Welten parallel pflegen, oder habe ich noch eine andere Option?
Wie genau funktioniert das wenn alle Combit Benutzer den selben SQL Benutzer haben? Kann dann nur die Anwendung Combit CRM die Datenbankabfrage absetzen und der Benutzer sieht das Passwort nicht oder kann der im Hintergrund z.B. aus Excel auch einfach eine Abfrage starten?
Bei einer SQL Server Authentifizierung würde nur combit CRM sich (mit diesem SQL Server Benutzer) verbinden können, sofern Sie niemandem sonst das Kennwort verraten. Dementsprechend müssten Sie dann noch zusätzlich die Windows-Benutzer in den SQL Server Sicherheitseinstellungen deaktivieren/einschränken, um den weiteren, alternativen Zugang durch andere Tools per Windows Authentifizierung abzuklemmen.
Das hatte ich ja quasi so geschrieben. Was aber passiert genau wenn alle einen einheitlichen DB User in den Einstellungen gesetzt haben?
Vermutung:
Die sehen das Passwort nicht bzw. können es nicht auslesen.
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.
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.
Für Schreibvorgänge kann man über eine zusätzliche Spalte den CRM User-Namen mit geben.
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.
Hm okay alles in allem könnte ich jetzt beide Wege gehen. Also entweder alles mit einem DB Benutzer umsetzen und die Trigger prüfen oder in der AD und SQL die Berechtigungsgruppen parallel abbilden. Auch wenn das mehr Arbeit ist werde ich wohl eher das machen, dann ist es irgendwie sauberer.
Ich will es Ihnen nicht ausreden. Ich bin mir jedoch nicht sicher, ob das Nachbauen der combit CRM Berechtigungen im SQL Server durchgängig mit vertretbarem Aufwand (wenn überhaupt) möglich ist, deswegen haben wir ja auch überhaupt eine eigene Benutzerverwaltung, anstatt das auf das Datenbanksystem abzuwälzen.
Mir fallen auf Anhieb direkt drei nicht-triviale Herausforderungen ein, wenn diese im SQL Server abgebildet werden sollen:
Datensatzrechte: Jede:r Außendienstmitarbeiter:in darf nur die Kontaktedatensätze sehen, die er:sie selbst betreut.
Änderungsrechte: Vertriebsmitarbeiter:innen dürfen nur Verkaufschancen bearbeiten, die sie selbst betreuen, sollen aber grundsätzlich alle sehen können, um die Gesamtpipeline betrachten zu können.
Feldrechte: Nur Salesmanager dürfen bei Kontaktedatensätzen die Felder Umsatz_LaufendesJahr und Umsatz_Vorjahr sehen. (Drastischeres Beispiel: Wer darf das Feld „Ergebnis_HIVTest“ sehen?)
…doch Obacht: es gibt noch das „Basisrecht für neue Ansichten“-Projekt-Recht, wodurch sich das Fallback-Recht ergibt, das für Ansichten gilt, für die für eine Gruppe (resp. Benutzer) noch niemals irgendwas konfiguriert wurde, d.h. es gibt für diese Ansicht-Gruppe(bzw. -Benutzer)-Kombination (noch) gar keinen entsprechenden N:M Ansichtenrechte Datensatz.
Das mit den Datensatz-Rechten ist natürlich korrekt aber das ist derzeit nicht getrennt, zumal auch keine Umsatzdaten oder derlei bedeutsame Informationen im CRM stehen.
Für PowerBI werde ich aber sowieso mit RLS arbeiten sobald mein neuer SQL Server steht, das ginge also mit den neueren SQL Versionen grundsätzlich auch.
Wenn ich Combit CRM mit Rechten auf ausgewählte Tabellen in der DB starten will dann erwartet er von mir immer das Recht für CREATE TABLE, warum muss ein Benutzer das haben?
Wenn ich dann CREATE TABLE gewähre ist er der Meinung ich hätte keine Rechte auf den „eingegebenen Schemanamen“ (42000) dabei habe ich Rechte auf einige Tabellen aus dem Schema nur eben nicht alle. Mir ist nicht ganz klar was er hier erwartet.
Früher waren alle Combit CRM Benutzer automatisch db_owner, das möchte ich definitiv reduzieren.
Mir ist auch nicht klar was er meint, dann sind wir schon zwei. Das sollte dann wohl im Support als Case weitergeführt werden, Sie können aber einmal Debwin vor dem combit CRM starten und gucken, bei welcher Abfrage denn der Fehler überhaupt ausgegeben wird, dann klingelt es bei uns vielleicht schneller. Kann es an einem „dbo.“ Präfix liegen?
Wenn eine Solutiondatenbank geöffnet wird, deren Struktur nicht zu der von dieser combit CRM Version erwarteten Struktur passt (interne Tabellen fehlen etc.) dann würde er - nach vorherige Rückfrage „Es ist eine Datenbankanpassung …“ - diese versuchen zu createn. Ansonsten fällt mir ad hoc gerade kein Fall ein, wann combit CRM überhaupt eine Tabelle createn wollen würde /sollte, von eigenen Scripten mal per SQLShell Objekt jetzt mal abgesehen.
Obacht: db_owner und create table Rechte sind nicht zwingend synonym.
Ja gut da wird sicherlich das Problem schon liegen. Ich gebe dem Benutzer nur Rechte auf die tatsächliche Daten-Datenbank (bei mir heißt sie kreativ „combit“) und auf darin enthaltene Tabellen mit Daten für die Sichten. Es gibt aber natürlich darin noch Tabellen dbo.cmbt_xxx und eine eigene Datenbank combit_cRM_System mit Tabellen combit_cRM_System.dbo.cmbt_xxx. Brauchen meine User (Schreib-)Zugriff auf alle diese Tabellen?
Ja - da steckt Terminverwaltung und alles mögliche drin (welche Datensätze sollen beobachtet werden, Zusammenstellung von manuellen Filtern etc. pp.) - ich kenne keine cmbt_ Tabelle, die in der Solution-Datenbank ohne Schreibrechte auskommt.
Vermuten würde ich das nur ein Lese/Schreibzugriff auf die Tabellen der Daten-DB notwendig ist. In UserPwds kann ich ja den Benutzer unmöglich rein lassen…
Sie können Ihr combit CRM mit mehreren Solutions in getrennten Datenbanken parallel nutzen.
Das, was dem combit CRM System gemeinsam ist, ist die Lizenz, die aktiv angemeldeten Benutzer:innen und natürlich überhaupt die gesamte Benutzerverwaltung nebst Berechtigungen und benutzerspezifische Einstellungen. Diese für das gesamt-System relevanten Tabellen sind in der (one-and-only) „Systemdatenbank“. Die Solution-spezifischen Daten (Kundendaten, Umsatzdaten etc., aber eben auch die ggf. damit verknüpften Verwaltungsinformationen wie Termine, Aufgaben, Überwachte Datensätze, Workflow-Zustände, etc. pp - siehe oben, die eben einen Bezug zu den Solutiondaten haben) sind in der jeweiligen Solution-Datenbank.
Diese Trennung ermöglich auch die Weitergabe der combit CRM Solution(-Daten) unabhängig von der combit CRM INSTALLATION (im Sinne von Lizenzzertifikate, Benutzer-Logins, Kennwort-Hashes, Benutzer-Einstellungen etc. pp).
Wie gesagt, in der Systemdatenbank werden Benutzereinstellungen gespeichert (cmbt_Files) und auch die Übersicht der Benutzeranmeldungen (cmbt_LoginInfos) geschrieben und aktualisiert, um nur mal kurz willkürlich 2 Tabellen zu nennen, die definitiv Schreibzugriff benötigen.
Lesezugriff brauchen Sie aber, sonst kann der combit CRM Client das eingegebene Anmeldekennwort ja nicht validieren. (In der Datenbank steht nur der Kennwort-Hash mit einem Salt.)
Schreibzugriff: brauchen Sie, wenn die Anwender:innen ihr combit CRM Kennwort ändern können sollen.
Löschrechte wäre ein Punkt, den ich persönlich verweigern würde.
Alles in allem: Wenn Sie granulare Datenbankserver-Zugriffsrechte am combit CRM vorbei brauchen/wollen, dann ist die Authentifizierung per SQL Server Auth mit einem expliziten dafür eingerichteten SQL Server Datenbankbenutzer (bspw. „combitCRM“) das Mittel der Wahl. Alles andere führt von einer Frage zur nächsten und übernächsten.
Ich persönlich müsste mich aus dem Thema jetzt leider ausklinken, ich übergebe diesen Thread hiermit der Community.
Ja ich merke wie weit das führt, macht auch vor SPs nicht halt. Ich habe mich jetzt umentschieden und einen allgemeinen DB-Benutzer angelegt, wie kann ich den Loginnamen und PW an alle Benutzer verteilen? Registry wäre ja zumindest für Passwort schlecht.
Normalerweise kümmert sich da bei einem Roll-out das Client-Setup automatisch drum, nachdem Sie den ersten Client einmalig korrekt „manuell“ eingerichtet haben und diese Einrichtung auch für alle anderen Clients am Ende der Installationsroutine „freigeben“.
Da es in Ihrem Fall jetzt um das nachträgliche Patchen der Informationen geht, verteilen Sie in Ihrem Fall Ihre Registry-Einträge DBServer, ClientType und SchemaInfo1, SchemaInfo2, SchemaInfo3, SchemaInfo4 (sofern vorhanden) von (und nach) Computer\HKEY_CURRENT_USER\Software\combit\combit Relationship Manager\Settings
Die Informationen dort sind zum Teil AES-256 verschlüsselt.
Das sollte dann wohl im Support als Case weitergeführt werden, Sie können aber einmal Debwin vor dem combit CRM starten und gucken, bei welcher Abfrage denn der Fehler überhaupt ausgegeben wird, dann klingelt es bei uns vielleicht schneller. Kann es an einem „dbo.“ Präfix liegen?