[gelöst] (CC) - Rechte für Admin-User

Hi,

ich würde gerne einen "Admin-User" einrichten, der wie der Name schon sagt für administratorische Tätigkeiten zuständig sein soll.
Bisher habe ich leider nur Probleme mit der Zusammenstellung der Rolle. Es müsste ja quasi das Gegenstück zur "Super(Daten)"-Rolle sein.
Er soll nämlich keine Daten verändern dürfen, außer Windows-/Datenbankanmeldungen, Style Sheets etc.

Hat jemand schon mal so eine Rolle gebaut oder kann mir sagen was ich alles beachten sollte?

Viele Grüße
Christoph

Zuletzt geändert von Nightwolf am 8. August 2012 14:06, insgesamt 1-mal geändert.

Hallo Nightwolf,

du willst also einen Admin mit Leserechten, der aber Benutzer anlegen darf?

Du gibst ihm die Rolle "Alle", bei der er zunächst einmal alle Objekte ausführen darf.
Dann gibst du ihm eine neue Rolle bei der er TableData Lesezugriff bekommt.
Dann brauch er noch jenachdem was er als Admin alles machen soll noch Systemrechte (im Beispiel 5820, 5821, 5830):

Beispiel:

Code:

Objektart, Objekt-ID, Objektname, Lesen, Einfügen, Bearbeiten, Löschen, Ausführen
Table Data, 0, Ja, Indirekt, Indirekt, Indirekt, Ja
System, 5820, Ja, Ja, Ja, Ja, Ja
System, 5821, Ja, Ja, Ja, Ja, Ja
System, 5830, Ja, Ja, Ja, Ja, Ja

Hier kann er dann nur indirekt Tabellendaten einfügen, bearbeiten, löschen.

Noch Restriktiver wäre:

Code:

Table Data, 0, Ja, Nein, Nein, Nein, Ja

Dann musst du ihm noch das Recht geben die Tabellendaten für die Rechtevergabe zu ändern: z.B. 2000000002, 2000000003, 2000000053, 2000000054. Das Problem wird dann aber sein, dass er sich dann trotzdem auch selber "Super" Rechte geben kann.

Beispiel:

Code:

Table Data, 2000000002, Ja, Ja, Ja, Ja, Ja
Table Data, 2000000003, Ja, Ja, Ja, Ja, Ja
Table Data, 2000000053, Ja, Ja, Ja, Ja, Ja
Table Data, 2000000054, Ja, Ja, Ja, Ja, Ja

Du könntest ihm natürlich das Recht nehmen bestehende Rollen zu bearbeiten oder zu Löschen.
Restriktiver:

Code:

Table Data, 2000000002, Ja, Ja, Nein, Nein, Ja
Table Data, 2000000003, Ja, Ja, Nein, Nein, Ja
Table Data, 2000000053, Ja, Ja, Nein, Nein, Ja
Table Data, 2000000054, Ja, Ja, Nein, Nein, Ja

P.S.: War nur ein Gedankenspiel - alles ungetestet.


mfg,
winfy

Hi Winfy,

erst Mal danke für deine Antwort.

Aber ich befürchte so einfach ist es nicht, denn in Nav kann ein User anscheinend nur die Rechte vergeben, die er selber auch hat. Sprich wenn er Schreib-Rechte auf eine Tabelle vergeben soll, muss er diese Rechte auch haben. Indirekt reicht dazu nicht aus.
Und somit bräuchte er dann alle Rechte die irgendein User bekommen können sollte. Also quasi wieder Super-Rechte.

Die Möglichkeit dem User alle Rechte bis auf den Objekt-Designer und die Menu Suite + Designer zu geben fällt auch raus, da der Admin User spezifische Einstellungen an der Menu Suite vornehmen können muss.

Noch andere Ideen? Ansonsten bleibt mir nur eine programmierteschnische Lösung.

Hi Winfy,

erst Mal danke für deine Antwort.

Aber ich befürchte so einfach ist es nicht, denn in Nav kann ein User anscheinend nur die Rechte vergeben, die er selber auch hat. Sprich wenn er Schreib-Rechte auf eine Tabelle vergeben soll, muss er diese Rechte auch haben. Indirekt reicht dazu nicht aus.
[..]
Noch andere Ideen? Ansonsten bleibt mir nur eine programmierteschnische Lösung.

Ich habe gerade mal meine obige Lösung getestet.
Sie klappt nur dann, wenn der "Admin"-User wenigstens die Rechte hat, wie er sie vergeben darf - richtig.

Das macht doch aber im Grunde auch Sinn, denn was macht es für Sinn wenn ein User mehr Rechte vergeben darf als er selbst hat? Dann könnte er sich so diese Rechte auch selbst geben und demnach hätte er auch die Rechte die er vergeben darf, oder?

Ich sehe auch nicht wie dir da eine programmtechnische Lösung helfen kann?
Es sei denn er legt in Zwischentabellen die Benutzer inkl. Rechte an und ein "richtiger" Admin schaltet sie dann frei.

mfg,
winfy

Es soll einfach zwischen zwei Abteilungen strickt getrennt werden. Die eine soll User und deren Rechte anlegen dürfen + Menu Suite anpassen, aber keine anderen Daten anfassen können. Die Andere soll quasi die Datenverwalten (Controlling). Und ja die würde dann einem User sagen, dass dieser der Abteilung Admin angehört.

Da die Menu Suite stark vereinfacht ist, gibt es quasi nur ein Hauptmenüpunkt, dem unsere Lösung angehört und die dem Admin gegenüber unzugänglich gemacht werden muss, genau wie der Objektdesigner.

Und dann kann man eben eine programmiertechnische Lösung bauen, die im User Setup verwaltet wird. Klar müssen alle Stellen die die Tabellen füllen gesichert werden, aber dies wäre jedenfalls möglich. Zeitaufwendig und Umfangreich, aber immerhin eine Lösung.

Nur wollte ich diese Option eigentlich umgehen.

Aber danke für deine Hilfe :)

Es soll einfach zwischen zwei Abteilungen strickt getrennt werden. Die eine soll User und deren Rechte anlegen dürfen + Menu Suite anpassen, aber keine anderen Daten anfassen können. Die Andere soll quasi die Datenverwalten (Controlling). Und ja die würde dann einem User sagen, dass dieser der Abteilung Admin angehört.

Deine Intention habe ich verstanden und ich will dir auch nicht reinreden!

Lass mich bitte nur noch eine Anmerkung machen:
Wie willst du selbst mit dieser Lösung verhindern, dass dieser "Rechtevergabe-Admin" sich nicht selbst zum "richtigen Super-Admin" macht oder einen neuen Benutzer anlegt der Admin Rechte hat oder Passwörter bestehender Admins ändert usw., um sich später damit anzumelden?

Das ist doch der casus knacktus!

mfg,
winfy

Wenn ihr mit einer SQL-Datenbank arbeitet könnte das hier noch funktionieren:
Gib dem Benutzer Super-Rechte, und entziehe ihm dann auf dem SQL-Server für alle nicht benötigten Tabellen das Schreibrecht.

Außerdem auf jeden Fall im Änderungsprotokoll alle Benutzerrechte mitprotokollieren. Damit könnt ihr sicherstellen, dass wenn sich jemand die Berechtigung, dieser auch auffällt ;)

Was ist mit der NAV Rolle "SECURITY"?

Object Type Object ID Object Name Read Permission Insert Permission Modify Permission Delete Permission Execute Permission Security Filter
Table Data 2000000002 User Yes Yes Yes Yes
Table Data 2000000003 Member Of Yes Yes Yes Yes
Table Data 2000000004 User Role Yes Yes Yes Yes
Table Data 2000000005 Permission Yes Yes Yes Yes
Table Data 2000000053 Windows Access Control Yes Yes Yes Yes
Table Data 2000000054 Windows Login Yes Yes Yes Yes
System 5810 Tools, Security, Roles Yes Yes Yes Yes Yes
System 5820 Tools, Security, DB Logins Yes Yes Yes Yes Yes
System 5821 Tools, Security, Win. Logins Yes Yes Yes Yes Yes

Hab ich ihm ja oben (so ähnlich) vorgeschlagen, aber man kann ja nur Rechte vergeben die der User auch selbst hat.
Da der Rechtevergabe-Admin aber auch ihm höhergestellte Super-Admins anlegen soll, klappt das leider nicht.

mfg,
winfy

Hi,

nochmal danke für die vielen Antworten.

@Winfy:
Wenn der Admin-User beinah Super rechte bekommt. Sprich nur Einschränkungen im Systembereich hat, und zwar so, dass er nicht auf den Objektdesigner zugreifen kann. Danach wird ihm für alle wichtigen Formulare und Stapelverarbeitungen programmiertechnisch untersagt, dass er sie öffnen kann. Dann kommt er selber auch nicht an den Code ran.

@Danjo:
Ja, diese Lösung wäre super wenn es eine SQl-Datenbank wäre. Ist es aber leider nicht. Dennoch danke.

@Sebastian:
Änderungsprotokoll ist Pflicht :)

@Stryk:
Wie oben bereits erwähnt und von Winfy bestätigt würde dies leider nicht ausreichen.

Ich werde diesen Post auf erledig setzen, da ich eine Umsetzung habe. Zwar nicht die schönste wie ich finde, aber solange es noch keine SQL-Datenbank ist, geht es wohl nicht anders.

Viele Grüße
Christoph