Aktionen signieren

[SvenB]

Hallo @Notesler,

ich habe mal wieder eine (wahrscheinlich) blöde Frage: Wenn ein Benutzer beim Öffnen unserer Adressdatenbank nicht alle Aktionen zuläßt, funktionieren (logischerweise) nicht alle Schaltflächen (z.B. neuen Kontakt anlegen ...). Wie aber kann ich einem solchen Benutzer eine weitere "Chance" geben die Aktionen zuzulassen.

Wie Ihr sicher schon gemerkt habt, fehlen mir mit großer Wahrscheinlichkeit die richtigen Schlagwort, nehmt meine Aussagen also nicht zu wörtlich

Server: 6.5.4
Clients: 6.5.4


Ciao,
Sven

[mcilly]

Hi SvenB!

Wenn du Aktionen zulässt, ablehnst oder als vertrauenswürdig einstufst, dann wird das in der ECL (Execution Control List) deines Clients eingetragen. Geh dazu auf Datei -> Sicherheit -> Benutzersicherheit -> Was andere dürfen.
Dort kannst du einstellen was wer darf. Wenn du dort nun deinen Server drinnen hast, wo der User nicht alles zugelassen hat, dann kannst du entweder ...

1.) alle notwendigen Aktionen anhakerln
2.) oder die Einträge (Server, Benutzernamen) rauslöschen. Der User wird bei erneutem Zugriff dann wieder gefragt, was er erlauben will.

[boemitsu]

%edit% da war wohl jemand schneller...

Am besten ihr erstellt eine separate User ID, die ihr nur zum signieren von produktiven DB's gebraucht.

Über Policies könnt ihr diesen User in die ECL eintragen lassen, dann habt ihr dieses Problem nicht mehr.

Um dein Problem kurzfristig zu lösen, könnte man beispielsweise den Eintrag in der ECL dieses Users löschen und dann nochmals die DB aufmachen, danach erscheinen diese ECL Security Warnings nochmals. Aber dies löst das Problem nur kurzfristig und wird mit Sicherheit wieder auftauchen...

HTH

[SvenB]

Danke euch beiden!

Ich wusste, dass es nichts großes ist, aber wenn man nichtmal das entsprechende Vokabular hat ...

Nun gut, ich wünsche euch allen ein schönes Pfingsten!

[Peter S.]

Empfehle folgendes Vorgehen:

1. Keine Entwickler hat mehr entwicklerrechte auf produktiven Servern
2. Alle neuen und geänderten Schablonen bekommen die Admins
3. Die Admins signieren die Schablonen mit einer eigenen "Signatur-ID" z.B. "Template/FIRMA/DE" - Mit dieser ID sollten auch alle Agenten aktiviert werden.
4. Alle Anwendungen werden mit dieser ID signiert
5. Ihr pflegt im NAB unter "Aktionen" die "Administrations-ECL". Diese wird auf alle neuen APs automatisch übernommen. In diese ECL nehmt ihr die SIgantur-ID mit allen Rechte auf.
6. Um auch auf die vorhandenen APs diese Liste zu bekommen müssen die User in ihre ECL gehen und auf "Aktualisieren "klicken, oder ihr schickt eine Schaltfläche raus mit der "@RefreshECL" Formel (Siehe Admin-Hilfe)

(Evtl gibt es auch die Möglichkeit die ECL per Richtlinie/Profile zu aktualisieren)

[mcilly]

Kein Thema Sven.

1.) Wegen der ID für prod. Datenbanken, ja gute Idee. Wir signieren aber immer alles mit unserer Server ID.
2.) Du brauchst keine Policy um die ECL vom Server aus an die Clients zu pushen. Das geht im Names Adressbuch -> Aktionen -> Edit Administration ECL. Das was man hier einstellt bekommen alle Clients ab Version 6 automatisch beim nächsten Connect.
3.) Wir haben in der ECL */O/AT drinnen stehen. Ist zwar ein wenig unsicherer als eine eigene ID fürs Signieren zu nehmen, aber naja.
4.) Wenn einer eurer User nen Designer in die Hände bekommt, ist sowieso Feierabend.

Also dann, ebenfalls ein frohes Fest

[SvenB]

 

Ich bin zu blöd ... muss ich in der ECL alle Einträge löschen, oder gibt es eine Datei, die man alternativ killen kann ...?

Zumal: Ich sehe einige der erlaubten Signierer in der ECL nicht, obwohl ich an meiner Arbeitsstation den ganzen Schmonz erlaubt habe ... definitiv. Ich bin etwas verwirrt. 3rd-Party-Lösungen ... pah.

[mcilly]

Nicht ALLE löschen, nur die von eurem Unternehmen. Denn es gibt auch Standardeinträge von der IBM z.B. Lotus Notes Template Development, die darfst du nicht löschen, sonst ist der Teufel los.
Eine Datei? Soweit ich weiß, schreibt er das ins ID File, bin mir aber nicht sicher. Die solltest du aber nicht löschen.

Du musst natürlich mit der ID einsteigen mit der du die ECL Änderungen getätigt hast. Also, wenn du nun mit deiner eingestiegen bist, dann siehst du in der ECL nicht das was der User bestätigt hat, sondern deine.

[SvenB]

... *sigh*

Dachte die ECL-Daten würden oder wurden mal in die Desktop.dsk / Desktop6.ndk geschrieben - ist wohl ein Irrglaube.


Ciao
Sven

[Peter S.]

Stimmt schon die ECL ist in der desktop.dsk (.ndk)

Aber die ECL an deinem AP hat mit der Administrations-ECL im NAB erstmal nichts zu tun.

[mcilly]

Stimmt schon die ECL ist in der desktop.dsk (.ndk)

Aber die ECL an deinem AP hat mit der Administrations-ECL im NAB erstmal nichts zu tun.

1.) Wie meinst du das? Natürlich hat die ECl des Clients was damit zu tun. -> "Die Workstation-ECL wird zusammen mit der Administrations-ECL des Servers aktualisiert."

2.) Die Administrations-ECL dient als Schablone für alle Workstation-ECLs. Immer wenn ein neuer Notes Client installiert wird, kopiert das Konfigurationsprogramm die Administrations-ECL aus dem Domino Verzeichnis in das persönliche Adressbuch auf der Notes Client-Workstation. Also weder ID File noch die desktop.

[boemitsu]

2.) Du brauchst keine Policy um die ECL vom Server aus an die Clients zu pushen. Das geht im Names Adressbuch -> Aktionen -> Edit Administration ECL. Das was man hier einstellt bekommen alle Clients ab Version 6 automatisch beim nächsten Connect.

Dann wären ja Policies wie refresh bzw. update der ECL Settings sinnlos...

Bin der Meinung (=nicht getestet), dass der Einsatz von Policies dennoch notwending ist, wenn man Änderungen an der Admin-ECL an bestehende Clients propagieren möchte...

[mcilly]

Nein das stimmt so nicht. Es ist so wie ich gesagt habe.

1.) Die Client ECLs (auch die von bereits bestehenden) wird sofort mit Änderung der Admin ECL geändert, sobald der User den Client einmal schließt und wieder öffnet, dann einfach seine Mail DB öffnet.
2.) Unten in der Statusleiste steht dann: ECL Aktualisierung/Änderung abgeschlossen.
3.) Unter Sicherheit -> was andere dürfen -> ist die Änderung ersichtlich.

Fazit: ECL Änderungen auch OHNE Policy möglich.

[Tode]

@mcilly: Das halte ich DEFINITIV für ein Gerücht.

Die Workstation ECL wird nur aktualisiert, wenn:

- eine entsprechende Sicherheits- Richtilinie existiert
- eine Workstation neu aufgesetzt wird
- der Befehl "@RefreshECL" abgesetzt wird
- Der Aktualisieren- Button gedrückt wird.

Hier ein Auszug aus der Admin- Hilfe:

Wenn Sie die Administrations-ECL bearbeiten, nachdem die Benutzer das Konfigurationsprogramm ausgeführt haben, und Sie keine Sicherheitsrichtlinie verwenden, können Sie die Workstation-ECLs der Benutzer mit Hilfe einer der folgenden Vorgehensweisen aktualisieren.
Verwenden Sie die @RefreshECL-Funktion über ein Memo oder ein allgemeines Datenbankereignis
Weisen Sie die Benutzer an, ihre ECLs über das Dialogfeld "Benutzersicherheit" zu aktualisieren.


Wird also bei Dir automatisch aktualisiert (ohne neuinstallation), dann habt Ihr Richtlinien, die das steuern.

beomitsu ist absolut im Recht.

Tode

[mcilly]

Yoo ihr habt ja soo Recht. Ich bins leider von der falschen Seite angegangen. Habe die Admin ECL angepasst, Client geschlossen, gestartet, ECL am Client war geändert. Das war für mich dann sonnenklar.

Nach eurer eifrigen Dementierung bin ich dann doch noch in die Policys (Security Settings) rein und siehe da: Aktualisierung, wenn Admin ECL changed!!!

Naja, so kann man sich irren - nb is perfect ...