DB Owner Rechte im SQL für ALLE User?

Hallo,

wir haben bei uns SQL 2005 und MBS 4.0 im Einsatz. Meine Frage: Ich habe mir von unserem Partner sagen lassen das alle angelegten User im SQL (Datenbanklogins) DB_owner sein müssen in Kombination mit MBS 4.0
Ist das so richtig? Werden die Berechtigungen nur über MBS Rollen angepasst und vergeben?

Wäre dankbar für Hilfe und Tips wie ihr euere Berechtigungsstruktr handhabt.

Auf keinen Fall allen Usern Tor und Tür auf dem SQL Server öffnen. (vgl. http://msdn2.microsoft.com/de-de/library/default.aspx für Sicherheitsaspekte auf dem SQL Server). Über den Client können für die Nutzung alle Rechte eingestellt werden (einfaches oder erweitertes Sicherheitsmodell --> ab 4.0 SP3). Das vom Client erstellte Skript erstellt die nötigen Uservorgaben auf dem SQL Server.

Ich habe 4.0 noch nie eingerichtet, aber ich glaube nicht, dass es was das angeht sich sonderlich von 5.0 unterscheidet. Und in 5.0 langt es den angelegten Usern "public" zu geben. Alles andere wird in NAV geregelt und dann an die DB synchronisiert.

Korrekt. Allerdings gibt es teilweise gravierende Abweichungen zwischen 4.0 und 4.0 SP3, daher nur SP3 verwenden. Solange die xp_ndo.dll mit den extended stored procedures auf der DB Instanz vor dem 1. Start ist, gibt es i.d.R. keine Probleme. Wenn allerdings ein 5.0 Client installiert ist, warum nicht den Nutzen und die DB technisch auf 5.0 bringen?

Hallo und Danke schon mal für die Antworten.

Wir haben es eben mal ausprobiert und auf dem ein und den selben Server bei einer technischen sp3 datenbank den dbo weggenommen , man konnte sich weiterhin problemlos über MBS SP3 anmelden.

Am selben Server jedoch haben wir bei einer SP2 Datenbank den db owner weggenommen und konnten uns über MBS SP2 nicht mehr anmelden , zwar die Datenbanken "durchsuchen" aber ein Login war nicht möglich (unbekannter user und/oder pw).

Hat das wirklich was mit der SP version von MBS zu tun?

Kann so etwas auch mit der SQL Version zu tun haben ? Aktuell ist SQL 2005 SP1 installiert.


Danke und Gruss

Ein public reicht vollkommen aus. Dbowner wäre insofern gefährlich, da mit externen Tools dann auch alle Fibu-Daten eingesehen werden können.
Die Rollen und Rechte müssen dann aber bei jeder Rechte- bzw- Programm-Änderung in NAV gut gepflegt und synchronisiert werden, damit der Zugriff wieder klappt.

Hallo und Danke schon mal für die Antworten.

Wir haben es eben mal ausprobiert und auf dem ein und den selben Server bei einer technischen sp3 datenbank den dbo weggenommen , man konnte sich weiterhin problemlos über MBS SP3 anmelden.

Am selben Server jedoch haben wir bei einer SP2 Datenbank den db owner weggenommen und konnten uns über MBS SP2 nicht mehr anmelden , zwar die Datenbanken "durchsuchen" aber ein Login war nicht möglich (unbekannter user und/oder pw).

Hat das wirklich was mit der SP version von MBS zu tun?

Kann so etwas auch mit der SQL Version zu tun haben ? Aktuell ist SQL 2005 SP1 installiert.


Danke und Gruss

Gab es schon User auf der DB oder ist die neu attached worden? Es müssen dann alle Logins synchronisiert werden. D.h. ein Admin NAV stößt den Vorgang im Client an, nach dem parsen wird der CAL Code zu einem T-SQL Skript, welches dann direkt an den SQL geht (läuft nur wenn der NAV Admin auch SQL Admin ist).

P.S. SQL 2005 SP1 ist fast schon grob fahrlässig (unter Built 3159 quasi no go)

Wir nutzen auch SQL 2005 und haben ein ähnliches Problem.
Bei uns müssen auch alle DBO sein ... auch wenn mir jedesmal das Herz blutet.
Wir haben mal probiert es beim Update von 4x auf 5x raus zunehmmen allerdings funktionierten dann nicht mehr alle funktionen.

Mitte des Jahres haben wir auch das Sicherheitsmodel auf Standard gestellt. Naja es sind immernoch alle DBO. Wir vermuten das funktionalitäten die unser Partner eingebaut hat das braucht.

Wenn wer die Lösung findet wäre ich auf jedenfall auch daran interessiert.

Mfg Phil

Bei uns müssen auch alle DBO sein

Warum? Tresorschlüssel bekommt doch auch nicht jeder. Am Ende habt Ihr auch noch die Gehaltsabrechnung in der Datanbank und jeder Azubi kann die DB nach Access kopieren und mit nach Hause nehmen.

Volker

Also dass alle User db_owner sein MÜSSEN ist Quatsch - das war mit den allerersten 4er Versionen nötig, und auch damals schon konnte man das umgehen ...

Wichtig wäre immer die FEHLERMELDUNG zu kennen, i.d.R. sind es nämlich nur einzelne Objekte, auf denen die Zugriffsrechte fehlen.
Werden z.B. "Linked Objects" (Views) verwendet, dann wird oft vergessen die notwendigen Berechtigungen für die DB-Rolle "public" zu erteilen; z.B.

GRANT SELECT ON MyVIew TO PUBLIC

Hallo,

Ein ganz ähnliches Szenario haben wir bei einem Kunden:

Code:

Eingesetzte Software (Kunde):
---------------------
SQL-Server: 9.0.3294 / Enterprise 64 bit SP2
NAV 4.00 Sp2  (Build 22611)


dort geht es auch nur, wenn die normalen Navision-User Mitglied
von db_owner sind (SQL-Server).

Sind sie das nicht, ist noch nicht einmal eine Anmeldung an der Datenbank drin.
Fehlermeldung: Falscher Benutzername und/oder Passwort.
Gearbeitet wird ausschließlich mit Datenbankanmeldungen.

Ein zusätzliches Fehlerbild ist zu beobachten, wenn über Navision der Benutzer
eingerichtet werden soll --> dann hängt Navision bereits, wenn in der Tabelle "Benutzer"
die Zeile eingefügt wird; dann bekommt der Client keine Rückmeldung vom SQL-Server.
Im Aktivitätsmonitor des SQL-Servers stehen dann zwei Sitzungen von mir, die
zweite blockiert durch die erste -> die zweite steht dann im Status = Angehalten.
In der Spalte Befehl steht "UNKNOWN TOKEN", in den Prozessdetails = "sys.sp_grantdbaccess;1"

Möglicherweise kennt jemand beide Fehlerbilder in dieser Kombination ...

Nachtrag:
Wir haben versucht, dieses Szenario bei uns im Haus nachzustellen: Bei uns funktioniert
das natürlich alles, wie sich das gehört (gleiches Nav, aktuellerer SQL-Server):

Code:

Eingesetzte Software (im Haus):
---------------------
SQL-Server: 9.0.4053 / Developer 64 bit SP3
NAV 4.00 Sp2  (Build 22611)


Der Kunde sagt allerdings, am Service Pack sollte es nicht liegen, da sie ebenfalls
einen SQL-Server 9.0.4035 (= SP3) mit Navision Sp2 betreiben, wo dasselbe Problem auftritt.



ein gesundes neues Jahr wünscht

Torsten

WARUM es zu diesen Zugriffsproblemen kommt ist meist nicht ganz klar - ich denke, dass die "Synchronisation" bei "Security Model - Enhanced" zumindest Teilschuld trägt ... Die vermeindliche Lösung, alles User auf db_owner & Co zu setzen ist allerdings hoch kritisch - aus gegebenem Anlass verweise ich hier auf mein BLOG:
http://dynamicsuser.net/blogs/stryk/archive/2010/01/03/extended-database-hardening-nav-sql.aspx

Ich habe eine Lösung für mein Problem gefunden.

aus gegebenem Anlass verweise ich hier auf mein BLOG:
http://dynamicsuser.net/blogs/stryk/arc ... v-sql.aspx

Der Dank geht an Stryk, der mich auf den richtigen Weg gebracht hat.
Es hilft halt doch ungemein, wenn man weiß, was im Detail so passiert,
wenn man irgendwo draufdrückt, in diesem Fall beim "Synchronisieren".

Das Problem in unserem Fall war, dass der Kunde schon *immer* mit db_owner
gearbeitet hat (nein, *wir* waren nicht der Ratgeber), ein Synchronisieren war
deshalb nie notwendig und wurde auch nicht durchgeführt.

Meine Vermutung ist, dass ohne db_owner nichts ging, da selbst für den Zugriff auf
die Tabellen $ndo$dbproperty & Co. (Danke Stryk) nicht genügend Rechte
für den Anmeldevorgang (?) vorhanden waren. Die Rollen auf dem SQL-Server waren
ja nicht gepflegt (keine Synchronisation).

Der Fehler, dass sich beim Eintragen in die Benutzertabelle der Client selbst
blockiert, ist immer noch vorhanden. Ich ignoriere das, und weise anschließend
im SQL-Server die Datenbank dem Benutzer manuell zu, anschließend werden in Navision
die Rollen zugewiesen und synchronisiert. Dann konnte sich der neue Benutzer
auch an Navision anmelden -- und das mit "public"-Rechten.


Torsten