(CC) Zugriffsrechte für ODBC Abfragen

Hallo,

ich wollte für einige User ein ODBC - Zugang anlegen, damit die auch Daten aus der Navision SQL Datenbank abfragen können. Jetzt habe ich aber folgendes Problem. In Naviosion selbst habe ich die Rechte gut angelegt. Geht aber ein User mit seinen Rechten über Excel --> ODBC auf die Datenbank, so kann dieser alle Tabellen sehen und theoretisch auch alle Daten aus allen Mandanten sich nach Excel importieren. Gibt es die Möglichkeit, das der User auch nur die Tabellen sieht, bei denen der User auch nur die Rechte drauf hat? Oder eine Alternative wäre, ich lege einen ODBC User an und gebe nur einige Tabellen frei?? Als Beispiel ODBC - Artikelstamm, nur die Tabelle Artikelstamm per ODBC freigeben.

Vielen Dank für Eure Hilfe.

Gruß

Elhamplo

Hi,

lies mal unter OT: Access in http://www.msdynamics.de/viewtopic.php?f=40&t=18741. Ich weis nicht wie Excel in dem Fall arbeitet, aber falls das auch erst mal die ganze Tabelle einließt ist das heftig.

Außerdem unbedingt der Hinweis, dass man via ODBC auch schreiben kann und das kann ganz schön in die Hose gehen.

Warum verwendest Du nicht stattdessen z. B. JetReports? Evtl. reicht die Express-Version aus (ist die noch kostenlos?).

Wenn das alles nicht richtig ist für euch könnte man auch noch ein weitere SQL-DB anlegen und nur mit den benötigten Tabellen in NAV verlinken und diese DB den ODBC-Usern zur Verfügung stellen.

Volker

Hallo,

welches NAV-Sicherheitsmodell setzt Ihr denn bei eurer NAV-SQL- Datenbank ein? unter "Datei\Datenbank\ändern\erweitert" solltest du das Sicherheitsmodell finden. Es sollte auf "Standard" stehen.

Gruß, Fiddi

[Datenkultur]

ODBC - Zugang anlegen, damit die auch Daten aus der Navision SQL Datenbank

Gehst Du per OLEDB Treiber auf die Datenbank, oder benutzt Du C/ODBC? Bei C/ODBC werden die Benutzerberechtigungen verwendet. Wenn Du per OLEDB auf die Datenbank gehst, dann ist deinem Treiber gar nicht bewusst, dass es sich um eine NAV Datenbank handelt. Da die NAV-Rechte in der Datenbank in Tabellen gespeichert werden, weiß der SQL Server natürlich nichts darüber. Du kannst aber natürlich einen User mit beschränkten Rechten auf der Datenbank erstellen. Du hast dann aber auch keine FlowField-Werte oder Lookup-Values.

Warum verwendest Du nicht stattdessen z. B. JetReports? Evtl. reicht die Express-Version aus (ist die noch kostenlos?).

Ideal für Auswertungen in Excel ist Jet Reports. Mit der kostenlosen Variante hast Du aber nur eingeschränkte Möglichkeiten. Anschauen lohnt sich aber.

Zuletzt geändert von Datenkultur am 5. April 2020 16:30, insgesamt 1-mal geändert.

Wenn ein normaler Benutzer Lesezugriff (vielleicht sogar Schreibzugriff; das wäre tödlich!) haben, dann wäre das ÄUßERST unvorteilhaft. Ein normaler Anwender sollte normalerweise keinen solchen Zugriff von Haus aus haben. Sorg erst einmal dafür, dass dieser Zugriff nicht mehr besteht!

Wenn du das geklärt hast, geht es darum, deinen Anwendern trotzdem einen komfortablen Zugriff auf die Daten zu gewähren. Möglichkeiten gibt es viele: Dataports, Reports (um in Navision zu bleiben), JetReports (wie schon eben erwähnt) und auch ODBC. Bei letzterem solltest du aber beachten, dass nur Lesezugriff besteht und der Zugriff sich nur auf die Daten beschränken sollte, die auch für den Anwender relevant sind.

Wie würde ich vorgehen?
Fachabteilung A will Zugriff auf Sachposten. Nun könntest du hergehen und ihnen einfach die Berechtigung zum Lesen auf die Tabelle G/L Entry geben. Das wäre aber eher weniger sinnvoll. Die wenigsten Anwender könnten die Daten interpretieren ... Daher wäre mein Vorschlag: Erstelle einen aufbereiteten View in SQL mit dem die Fachabeilung arbeiten kann (evtl. Option IDs ersetzen, Summen, etc.). Erstelle Datenbankrollen und weise die neuen Views mit SELECT-Berechting dieser Rolle zu. Die Benutzer/AD-Gruppen erhalten dann die neue Datenbankrolle. Auf diese Weise hast du deinen ODBC-Zugriff, dieser ist aber schön abgesichert.

Hallo,

danke für Eure Antworten. Sorry das ich jetzt erst dazu komme zurück zu schreiben.

Ich habe mir Jetreports Express mal angeschaut. Es ist immer noch kostenlos. Ist aber in seinen Funktionen sehr eingeschränkt. Auch habe ich mir eine extra Rolle angelegt, nur auf die Artikeltabelle. Meld ich mich dann mit dem Benutzer der die Rolle hat im Jetreports Express an, zeigt er mir keine Tabelle an. Habs auch noch nicht rausgefunden woran das liegt.

Unser Sicherheitsmodell ist auf Standard eingestellt.

So wie ich das sehe, ist nicht der OLEDB Treiber oder der C/ODBC Treiber installiert. Wenn ich unter Systemsteuerung, Verwaltung, ODBC-Datenquellen schaue, finde ich nur was unter System-DSN. Da ist die Datenquelle mit einem SQL-Server Treiber zu finden. Kann ich mir dann den Treiber C/ODBC runterladen und eine neuen Verbindung herstellen?

Die Benutzer auf der SQL-Datenbank lege ich nicht an. Das macht unsere IT-Abteilung. Die Benutzt das mitgelieferte Programm SQL Studio Management. Da kann ich doch unter Serverrollen dann sehen, was für Rechter der user hat, oder??

@Sebastian Pfliegel

Wo und wie legst Du denn solche Views an??

Vielen Dank für Eure Hilfe!!!

Es mag ja sein, dass ich das bis jetzt falsch verstanden habe, aber wir legen keine User für NAV im SQL-Server direkt an. Wir machen das in NAV (Extras/Zugriffsrechte/Windows-Anmeldungen).

Wie werden denn bei euch die Rechte innerhalb NAV für die einzelnen User vergeben? Macht das auch die IT-Abteilung und setzt die Rechte für die User für jede einzelne Tabelle direkt im SQL-Server?

Und noch eine Frage. Wenn Du nicht zur IT gehörst, warum kümmerst Du dich dann um den Zugriff und dessen Absicherung? Wenn Du ein Tool für Auswertungen brauchst, dann schau Dir die Versionen von Jet Reports an oder such mal im Forum nach anderen Reporting/BI Lösungen. Da gab es etwas vor einiger Zeit.

Oder Du willst etwas ganz anderes erreichen, dann könntest Du mal sagen was konkret gemacht werde soll. Evtl. gibt es ja dafür ein ganz andere Alternative.


Volker

Die Benutzer auf der SQL-Datenbank lege ich nicht an. Das macht unsere IT-Abteilung. Die Benutzt das mitgelieferte Programm SQL Studio Management. Da kann ich doch unter Serverrollen dann sehen, was für Rechter der user hat, oder??

@Sebastian Pfliegel

Wo und wie legst Du denn solche Views an??

Wenn du sagst, das macht eure IT-Abteilung, welche Rolle hast dann du inne? Ja, die SQL-Berechtigungen kannst du dort einsehen. Ihr solltet wirklich dringend prüfen, welche SQL-Berechtigungen ein normaler Anwender hat. Diese sollten sich normalerweise gerade einmal mit der Datenbank verbinden dürfen, mehr nicht! (den Rest macht die Anwendungsrolle von Navision). Die Views würdest du auch im Management Studio anlegen.

Hallo,

bei uns muss der User erst auf der SQL-Datenbank angelegt werden. Das macht die IT-Abteilung. Ist so gewachsen, dass alles was zum Server und Servervaltung gehört. Ich lege den User dann in Navision an und vergebe die Rechte, unter "Extras--> Zugriffrechte--> Datenbankanmeldungen.

Ansonsten bin ich für das ganze System seit kurzem zuständig. Ich mache eigentlich alles, bis auf die Reports, da ich mich da noch reinarbeiten muss. Sagen wir, ich habe die User nicht auf der Datenbank angelegt. Bis jetzt kam auch keiner mehr dazu.

Die ODBC Auswertungen sind noch aus der alten Navisin Version gewachsen. Da waren die Rechte wie die der User. Ich habe das Mamagement Studio nur mal kurz gesehen. Ich weiß, das man diese Tool auch als Auswertungstool nehmen kann, also so Projekte anlegen usw. Das anlegen der Views und mit einer Rolle zu verweisen müsstest Du mir dann mal genauer erklären.

Ja wir sind auch auf der suche nach einer BI-Lösung, aber ich kann nicht sagen wie lange das dauern wird, bis wir was passendes gefunden haben. Für Tipps wäre ich gerne Dankbar.

Gruß

Elhamplo

Die ODBC Auswertungen sind noch aus der alten Navisin Version gewachsen. Da waren die Rechte wie die der User. Ich habe das Mamagement Studio nur mal kurz gesehen. Ich weiß, das man diese Tool auch als Auswertungstool nehmen kann, also so Projekte anlegen usw. Das anlegen der Views und mit einer Rolle zu verweisen müsstest Du mir dann mal genauer erklären.

Klär wirklich ab, wer welche Berechtigung hat. So etwas ist unternehmenskritisch! Am Besten auch selbst testen (auch Schreibzugriffe, etc.).

Naja, dafür sollte man schon ein bisschen Ahnung vom SQL-Server haben. Grundsätzlich eine View erstellen, dann Datenbankrollen erstellen, welche auf diese View lesend zugreifen dürfen. Anschließend noch die Datenbankrolle den jeweiligen Benutzern zuweisen.

Ich muss nochmal wegen meiner Idee nachfragen eine zusätzliche Datenbank für den direkten Zugriff auf die Daten zu verwenden.

Szenario:
NAV-SQL-DB <=> Neue SQL-DB mit Views auf notwendige Tabellen in NAV

User hat eingeschränkte Rechte in NAV.

Kann ich denn in der neuen SQL-DB andere(geringere) Rechte setzen als in der NAV-DB? Falls ja, kann man NAV wie gewohnt verwenden und gibt nicht aus Versehen über die View Daten an User frei, die diese Daten in NAV nicht sehen dürfen/sollen. Man hätte so ein eigenes untergeordnetes System nur zur Auswertung mit entsprechender Rechtesteuerung.

Volker

[Datenkultur]

Ich habe mir Jetreports Express mal angeschaut. Es ist immer noch kostenlos. Ist aber in seinen Funktionen sehr eingeschränkt. Auch habe ich mir eine extra Rolle angelegt, nur auf die Artikeltabelle. Meld ich mich dann mit dem Benutzer der die Rolle hat im Jetreports Express an, zeigt er mir keine Tabelle an. Habs auch noch nicht rausgefunden woran das liegt.

Für die Tabellen brauchst Du u.A. Leserechte auf die Tabelle "Objekt". Nimm besser einen normalen Navision Benutzer für Jet Express. Nur eine Rolle mit den Artikelposten reicht da nicht. Für die Artikelposten kannst Du nur den Tablebuilder verwenden. Das bedeutet Du kannst Artikelpostendaten in einen Pivot-Table übertragen und die dann per Pivot-Funktionen auswerten. Mit der Vollversion kannst Du in der Zelle definieren, welche Daten aus Navision dort ankommen sollen.

Ja wir sind auch auf der suche nach einer BI-Lösung, ... Für Tipps wäre ich gerne Dankbar.

Jet Reports Essentials

Das Tool ist wirklich nett. Ich kann Euch das gern mal per Onlinemeeting vorführen. Du kannst hier einen Termin anfragen, oder sende mir eine PN.

Solltet Ihr euch für SQL-Views entscheiden, dann vermeidet möglichst SQL-Joins. Das kann die Performance der Datenbank empfindlich beeinflussen. Eine Alternative für reines Reporting wäre z.B. ein täglicher readonly Database-Snapshot. Das ist aber alles nicht ohne, wenn man das professionell einrichten und bereitstellen möchte. Für Endanwender ist Jet Reports ganz bestimmt die bessere Wahl. Und letztlich auch die preiswerte vermute ich.

Zuletzt geändert von Datenkultur am 5. April 2020 16:31, insgesamt 1-mal geändert.

Hallo,

Ich wiederhole nocheinmal meine Frage:

welches NAV-Sicherheitsmodell setzt Ihr denn bei eurer NAV-SQL- Datenbank ein? unter "Datei\Datenbank\ändern\erweitert" solltest du das Sicherheitsmodell finden. Es sollte auf "Standard" stehen.

Ansonsten hat jeder Benutzer die Rechte in der SQL-DB, die Ihm per NAV- Recht eingeräumt wurde (Rolle SUPER = Zugriff auf alle Tabellen)

Es mag ja sein, dass ich das bis jetzt falsch verstanden habe, aber wir legen keine User für NAV im SQL-Server direkt an

Wer mit Datenbankanmeldungen beim NAV- SQL-Client arbeitet muss das so machen.
Wenn allerdings dieser Benutzer dann im SQL-Mgt.- Studio sysadmin bekommt, darf er natürlich alles.

Gruß, Fiddi

Fiddi:

Unser Sicherheitsmodell ist auf Standard eingestellt.

Fiddi:

hat geschrieben:Unser Sicherheitsmodell ist auf Standard eingestellt.

Sorry, wer lesen kann

Aber dann könnte der zweite Punkt noch zutreffen.

Gruß, Fiddi

Ähm ... ich denke, es wäre sinnvoll mal an dieser Stelle das Sicherheitskonzept von NAV ein wenig darzustellen (kurze Kurzfassung):

1. NAV User benötigen im SQL Server nur public Rechte; auf keinen Fall db_owner oder gar sysadmin!
2. EIn User meldet sich "public" in NAV an; die Authenfizierung läuft entweder über den SQL Server (Database Login) oder "trusted" über das OS (Windows Login)
3. Nach erfolgreicher Authentifizierung meldet sich die NAV Application mit einer "Application Role" am SQL Server an:
3.1. "Enhanced Security": jeder User verfügt über eine individuelle AR ("$ndo$ar${GUID}")
3.2. "Standard Security": die AR "$ndo$shadow" wird für alle User gemeinsam verwendet
Diese AR enthalten soz. das NAV Rechte-System übersetzt in SQL Rechte; damit können die NAV User nur auf die Tabellen zugreiffen, auf denen sie auch explizite Rechte haben

Diese AR können nur von der NAV Application verwendete werden; sie sind Passwort geschützt; die Passwörter sind verschlüsselt und soz. nur der finsql.exe bekannt!

Ergo: Wenn sich ein User von "außern" anmeldet - z.B. via Excel/ODBC - dann hat der nur "public" Rechte und darf gar nix; er kann nicht einmal die Tabellen sehen! Wenn das nicht so ist (wie im Eingangsposting beschrieben) dann ist etwas furchtbar schief gelaufen; die User haben zu viele Rechte und es besteht ein ERHEBLICHES SICHERHEITSRISIKO!

Will man von "außen" auf eine SQL DB/Tabelle zugreiffen, so muss man die nötigen Rechte explizit vergeben. Nochmal: db_owner oder sysadmin & Co. sind KEINESFALLS EINE OPTION!

Hier sollte man im Prinzip so vorgehen:

1. Erstellen einer neuen Datenbank Rolle; z.B. db_odbc innerhalb der NAV DB
2. Zuweisen der expliziten Lese-Rechte für diese Rolle; z.B. GRANT SELECT ON [dbo].[Company$Item Ledger Entry] TO [db_odbc] usw.
3. Erstellen des ODBC Logins (Server-Ebene)
4. Erstellen des ODBC Users (Datenbank-Ebene) z.B. durch Zuweisen der DB
5. Zuordnen der DB Rolle db_odbc für den User ODBC
6. Zuordnen der DB Rolle db_denydatawriter für den User ODBC (DENY sticht GRANT, wenn dieser z.B. von irgendwo vererbt wird)

Damit ist alles wasserdicht (und REVISIONSSICHER!); der ODBC User kann nur lesen, was er wirklich lesen darf (und nix schreiben)!

Siehe dazu auch: http://dynamicsuser.net/blogs/stryk/archive/2010/02/16/extended-database-hardening-nav-sql.aspx

<MHO>
PS "Jet Reports":
ähm ... das Teil arbeitet ja mit der C/FRONT Schnittstelle ... die ist aber tot; ab NAV 2013 gibt's kein C/FRONT mehr ...
Ich würde mir heute kein "totes" ... oder sagen wir "sterbendes Pferd" mehr anschaffen. Wenn man schon SQL Server im Einsatzt hat, dann kann man BI auch richtig machen, z.B. mit Analysis Services, oder anderen 3rd party tools wie Qlik View etc. oder eben einfach nur in Excel.
</MHO>

PS "Jet Reports":
ähm ... das Teil arbeitet ja mit der C/FRONT Schnittstelle ... die ist aber tot; ab NAV 2013 gibt's kein C/FRONT mehr ...
Ich würde mir heute kein "totes" ... oder sagen wir "sterbendes Pferd" mehr anschaffen. Wenn man schon SQL Server im Einsatzt hat, dann kann man BI auch richtig machen, z.B. mit Analysis Services, oder anderen 3rd party tools wie Qlik View etc. oder eben einfach nur in Excel.

Das ist nicht ganz korrekt. Jetreports ist auch für NAV2013 verfügbar

Gruß, Fiddi

Oh! Das wusste ich nicht! Wie machen die das dann jetzt ohen C/FRONT? Läuft jetzt alles via WebServices?

Da im SQL-Server nichts einzurichten ist, vermute ich mal, das alles über den Webservice läuft.

Gruß, Fiddi

Ergo: Wenn sich ein User von "außern" anmeldet - z.B. via Excel/ODBC - dann hat der nur "public" Rechte und darf gar nix; er kann nicht einmal die Tabellen sehen! Wenn das nicht so ist (wie im Eingangsposting beschrieben) dann ist etwas furchtbar schief gelaufen; die User haben zu viele Rechte und es besteht ein ERHEBLICHES SICHERHEITSRISIKO!

Will man von "außen" auf eine SQL DB/Tabelle zugreiffen, so muss man die nötigen Rechte explizit vergeben. Nochmal: db_owner oder sysadmin & Co. sind KEINESFALLS EINE OPTION!

Genau so unterschreibe ich das! Man sollte sich auch mal die Public-Rolle ansehen, nicht dass dort herumexperimentiert wurde.

Hallo,

danke für Eure Antworten. Hat mich echt schon weiter gebracht.

Ich habe mir die Rechte auf der SQL-Dantebank angeschaut. Die User haben auf Grund einer Zusatzprogrammierung db_owner Rechte. Da bin ich aber dabei das mit dem Anbierter zu klären warum usw. War leider vor meiner Zeit.

Jetzt habe ich auf der SQL Testdatenbank (nur public Rechte) und in der Testumgebeung von Nav mir einenen neuen User angelegt auf die Tabelle Artikel. Anschließend habe ich auf der SQL Datenbank in der Tabelle Artikel selber des entsprechenden Mandanten den User mit nur Leserechte hinzugefügt. Das hat im Test sehr gut funktioniert. Ich habe mich mit dem User mit Excel per ODBC angemeldet und nur die Tabelle Artikel war zu sehen.
Bis wir eine BI Lösung haben, wollte ich mir daher ein paar ODBC User anlegen und das so machen.

@stryk: Deinen weg habe ich bis jetzt noch nicht so ganz verstanden.

@Fiddi: Nachdem das erste mal über Jetreports gesprochen wurde habe ich mir von einem anderen Anbieter was zukommen lassen. Soll aber nichts heißen

Danke Nochmal!!

Gruß

Elhamplo

Ich habe mir die Rechte auf der SQL-Dantebank angeschaut. Die User haben auf Grund einer Zusatzprogrammierung db_owner Rechte.

Also hier ein paar heiße Vermutungen, die oft zur db_owner-Ausrede führen:
1. Fehlende SELECT Rechte auf "Session" (alter Bug in NAV 5): GRANT SELECT on Session TO PUBLIC
2. Fehelende EXECUTE Rechte auf xp_enumusersids etc.: GRANT EXECUTE ON xp_ndo_enumusersids TO PUBLIC
3. Falsche Anwendung von "AutoIncrement": AI Felder müssen manuell mit 0 initialisiert werden!

@stryk: Deinen weg habe ich bis jetzt noch nicht so ganz verstanden.

Nun, das Prinzip ist so:
- Grundsätzlich habe alle User keine Rechte im SQL Server; also nur "public" (das ist die kleineste Rechte-Rolle)
- Das NAV Rechte-System ist ab Werk wasserdicht und darf niemals mit db_owner Rechten o.ä. umgangen werden!
- Für externe Zugriffe baut man eine Datenbank Rollen, die explizit die Rechte enthalten, die dieser User (außerhalb NAV) haben darf
(Eine Rolle ist ja quasi nur eine Sammlung von Zugriffsrechten auf z.B. Tabellen)

Hallo,

danke für die Antwort.

warum die alle db_owner Rechte haben, werde ich morgen mit unserem Anbieter klären. Ich habe das Recht bei einem User (natürlich mit Rücksprache) rausgenommen und wir sind bei einer Zusatzprogrammierung sofort auf einen Fehler gelaufen. Nach dem ersten kurzen Rückmeldung mit dem Anbieter mussten die db_owner Rechte bzgl. "Record Links" genommen werden.

Dann war mein Ansatz ja garnicht so falsch. Ich habe gestern auch einen extra User für ODBC angelegt. Der hat auf der SQL Datenbank nur das public recht. Dannach habe ich den User in den Eigenschaften der Tabelle des Mandanten den User mit nur Leserechten hinzugefügt. Melde ich mich jetzt über Excel ODBC auf die Datenbank an, sehe ich nur die beiden Tabellen und mehr nicht.

Gruß

Elhamplo

warum die alle db_owner Rechte haben, werde ich morgen mit unserem Anbieter klären. Ich habe das Recht bei einem User (natürlich mit Rücksprache) rausgenommen und wir sind bei einer Zusatzprogrammierung sofort auf einen Fehler gelaufen

Welche Fehlermeldung? Meine Wette: irgendwas in der Richtung "you are not allowed to execute command SET IDENTITY_INSERT ON"
Oder?