…wissen Sie wirklich was Ihr Notes Client da so treibt?
Im Rahmen der Überarbeitung der ECL Listen (Unternehmensweit) haben unsere Domino/Notes Administratoren einige Workstation ECL Policies eingerichtet, die uns in Ihren Auswirkungen auf eine Interessante Spur gebracht haben.
Speziell ging es um die “-NO SIGNATURE-” oder “-Keine Signatur-” Daten die in der ECL (Execution Control List) jedes Notes Clients vorhanden sind.
Unsere Administratoren sind, meiner Meinung nach völlig zu Recht, davon ausgegangen, das alles was nicht signiert wurde erst einmal prinzipiell nicht auf der Anwendung oder auf dem Rechner irgendwie eingreifen darf. Sie haben also per Policy sämtliche Haken bei diesem Eintrag (-Keine Signatur-), der wie gesagt Standard auf JEDEM Notes Client ist rausgenommen. Diese Aktion hatte einige, eher ungewöhnliche Seiteneffekte.
Hier ist einer davon, den jeder für sich gerne nachvollziehen kann.
Schritt 1: Man erstellt eine neue Anwendung. Diese Anwendung ist ganz einfach. Eine Maske mit genau einem RTLite Feld. Typ Anhang.


Schritt 2: In den Eigenschaften der Maske stellt man auf dem dritten Reiter (Starten, Rakete) die Auswahl AutoStart auf “erster Anhang”

Speichern nicht vergessen ….
Schritt 3: Man erstellt in der eben erzeugten Maske ein Dokument und hängt eine Datei (Spreadsheet, Präsentation oder etwas anderes) an. Anschließend speichert man das Dokument.
Schritt 4: Wichtig. Nicht vergessen. Jetzt nimmt man in der ECL des Clients dem Eintrag -Keine Signatur- alle Rechte weg.

Schritt 5: Um hundertprozentig sicherzugehen das keine Rechte irgendeiner ECL Einstellung im Client verblieben sind schließt man jetzt alle offenen Notes Clients. (Ja auch den Admin und den Designer).
Schritt 6: Nachdem man den Client wieder gestartet hat öffnet man das vorhin geschriebene Dokument und erhält folgende Meldung:


Mancher wird sich jetzt vielleicht fragen wo ist da jetzt das Problem. Signier doch einfach die Anwendung mit deinem Namen und dann geht das schon.
Der Witz an der Sache ist.
Da kann der Admin oder der Entwickler, oder wer auch immer für das Signieren zuständig ist solange signieren bis er schwarz wird.
Egal ob per Server, AdminP, Designer Client oder mit SignEZ von Ytria. An der Meldung wird sich nichts ändern.
Diesen Teil des Codes (wobei hier ja wirklich nichts codiert wurde) KANN MAN NICHT SIGNIEREN. Was zur Folge hat, das entweder die Anwender wahnsinnig werden, oder die Administratoren ihre ECL Standards runterschrauben müssen.
In diesem Fall heist das, das per Default dem Programm das von -Keine Signatur- signiert wurde die Rechte gegeben werden MÜSSEN auf das DATEISYSTEM ZUZUGREIFEN UND EXTERNE PROGRAMME AUSZUFÜHREN.

Noch interessanter wird das ganze Spiel, wenn man es mit vielen @dblookups in einer Anwendung, speziell in einer Maske die zur Navigation verwendet wird, spielt. Das was da passiert war übrigens auch der Grund, warum wir uns überhaupt einmal um dieses Thema gekümmert haben.
Ich wage jetzt einfach einmal die Behauptung, das dieses Verhalten, das unter 8.5.1 Revision 20090929.1223 ohne Probleme nachstellbar ist, unter dem Rest der Notes Clients habe ich das noch nicht probiert, ein potentiell signifikantes Einfallstor für Viren und anderen Schadcode darstellt. Welcher Administrator legt sich schließlich gerne und freiwillig mit sämtlichen Benutzern in seiner Organisation an?
März 22nd, 2010 at 20:49
Das klingt nicht gut!
Habt Ihr schon einen SPR oder PMR dafür?
März 23rd, 2010 at 08:41
Bis jetzt nicht. Aber da du schon der zweite bist der danach fragt …
April 20th, 2010 at 13:57
Das ist meiner Meinung nach aber auch schon unter 7 und ich meine auch unter 6.5 schon so gewesen. Das Problem hatte ich da auch schon mal.