Das Notes Forum
Domino 9 und frühere Versionen => ND9: Administration & Userprobleme => Thema gestartet von: (h)uMan am 22.09.16 - 14:47:25
-
Hallo zusammen,
merkwürdigerweise haben alle unsere Notes Client User heute fast zeitgleich einen Notes Sicherheitsalarm erhalten.
Programm signiert von: -Keine Signatur-
Am: - unbekannt -
Versucht wurde: [diverse Aktionen, z.B. Senden von Mail]
Verwendete Aktion: NotesUIDocumentSend
Domino: 9.0.1 FP6 HF310
Notes: 9.0.1 FP6 und FP7
Alle Entwickler und Admins sagen, sie haben keinerlei Änderungen an den DBs, Code, Richtlinien etc. durchgeführt. Bei einer ersten Kontrolle ist mir auch nichts derartiges aufgefallen.
Die ID, die wir zum Signieren von DBs verwenden, ist noch (lange) gültig.
Neue Anwendungen oder Tools (DBs) wurden nicht eingespielt.
Jemand eine Idee, warum der Alarm plötzlich auftaucht?
-
Hallo,
Hat eventuell jemand im Policy-Dokument (Security-Policy) auf dem Tab "Execution Control List" an der ECL herumgespielt und diese dann quasi neu an die Clients verteilt?
Andreas
-
Bei welcher Aktion/in welcher Datenbank kommt denn die Meldung? Irgendwas muss immer gemacht worden sein.
Gab es einen Templatewechsel?
Chris
-
Hallo,
Hat eventuell jemand im Policy-Dokument (Security-Policy) auf dem Tab "Execution Control List" an der ECL herumgespielt und diese dann quasi neu an die Clients verteilt?
Andreas
Habe ich geprüft, keine Änderungen erkennbar.
-
Bei welcher Aktion/in welcher Datenbank kommt denn die Meldung? Irgendwas muss immer gemacht worden sein.
Gab es einen Templatewechsel?
Chris
Mail-DB des Users
Dokument öffnen, senden etc.
"GetProfile", "Senden von Mail", ...
Kein Wechsel der Template-DB
-
Mail-DB des Users
Dokument öffnen, senden etc.
"GetProfile", "Senden von Mail", ...
Kein Wechsel der Template-DB
Und was steht denn in der ECL des Clients?
Was darf denn "-Default-" bzw. "-No signature-"
Andreas
-
Eine "domino-administrativ bedeutende Persönlichkeit" wurde bei Euch nicht zufällig letztens aus dem DD gelöscht?
Bernhard
-
Eine "domino-administrativ bedeutende Persönlichkeit" wurde bei Euch nicht zufällig letztens aus dem DD gelöscht?
Bernhard
Die sind noch alle drin ;)
-
Mail-DB des Users
Dokument öffnen, senden etc.
"GetProfile", "Senden von Mail", ...
Kein Wechsel der Template-DB
Und was steht denn in der ECL des Clients?
Was darf denn "-Default-" bzw. "-No signature-"
Bei Workstation und Java Applet jeweils nichts
Bei JavaScript jeweils
- Source Window (Read/Write),
- Other Window from same host (Read/Write)
- URL on same host (Open Access)
-
Hallo,
Wenn du meinst, dass bei "Workstation" keine checkbox gewählt ist, dann hast du doch den "Übeltäter".
Hier würde ich doch glatt vermuten, wenn wirklich kein User gelöscht wurde, der die Policy zuletzt bearbeitet hat,
dass jemand an der ECL in der Policy herumgespielt hat.
Andreas
-
Die Ursache geht mittlerweile mehr in Richtung Problem mit der cert.id bzw. deren Schlüsselaustausch.
In der Domino Server Konsole laufen durchgehend folgende Meldungen auf:
# Error processing certificate created by /ORG for /ORG: The subject's public key found in the certificate is not the one stored in our ID file for that entity.
# Problem with signature on policy document /ORG or one of the policy setting documents it specifies: The subject's public key found in the certificate is not the one stored in our ID file for that entity.
Die Policy Docs sind alle mit einer ID signiert, wo der Public Key in der ID mit dem im Directory übereinstimmt.
# AMgr: Error executing agent 'PublishHeldContent' in 'blog.nsf'. Agent signer 'server/ORG': The subject's public key found in the certificate is not the one stored in our ID file for that entity.
In den Notes Client Logs wird folgende Meldung geschrieben:
# Error processing certificate created by /ORG for /ORG: The subject's public key found in the certificate is not the one stored in our ID file for that entity.
Bei der cert.id ist passend zum Startzeitpunkt der o.g. Probleme ein Schlüsselaustauschzertifikat abgelaufen.
Momentan habe ich keine Idee, wie die Lösung aussehen muss. :-:
-
Hallo (h)uMan,
ach wie schön.
OK, fangen wir von vorne an:
- Beim Rollover vor zwei Jahren, ist da nur der Hauptzertifzierer (O) getauscht worden oder sind auch die weiteren Unterorganisationen, Server und letzendlich auch die Client IDs getauscht worden (so, wie es normalerweise durchgeführt werden würde).
- Habt Ihr einen ID-Vault und wurde der vor dem Rollover deaktiviert und anschließend neu aufgebaut?
- Gab es die Fehler in den lokalen Clientlogs auch schon vor dem Ablauf des Schlüsselaustauschtzertifikats?
- Ist die entsprechende Signierer ID der PolicyDocs, Schablonen und Co ebenfalls damals beim Schlüsseltausch berücksichtigt worden, d.h. hat sich jemand damit angemeldet und hat den Schlüsseltausch angenommen bzw. wurde deren Schlüssel getauscht, damit diese auch unter dem neuen Zertfizierer trusted ist?
Ich denke mal, die Signierer ID ist mit Ablauf des alten Org Schlüssels nun nicht mehr trusted und
muss mit dem neuem O/OU Zertifzierer(schlüssel) rezertifziert werden.
Grüße von
Sebastian
-
- Beim Rollover vor zwei Jahren, ist da nur der Hauptzertifzierer (O) getauscht worden oder sind auch die weiteren Unterorganisationen, Server und letzendlich auch die Client IDs getauscht worden (so, wie es normalerweise durchgeführt werden würde).
Ja
- Habt Ihr einen ID-Vault und wurde der vor dem Rollover deaktiviert und anschließend neu aufgebaut?
Ja und die 2. (Teil)Frage kläre ich noch
- Gab es die Fehler in den lokalen Clientlogs auch schon vor dem Ablauf des Schlüsselaustauschtzertifikats?
Ja, hat nur bis jetzt keiner mitbekommen ;)
- Ist die entsprechende Signierer ID der PolicyDocs, Schablonen und Co ebenfalls damals beim Schlüsseltausch berücksichtigt worden, d.h. hat sich jemand damit angemeldet und hat den Schlüsseltausch angenommen bzw. wurde deren Schlüssel getauscht, damit diese auch unter dem neuen Zertfizierer trusted ist?
Signiert wurde mit der server.id (DBs. Templates), Policy Docs mit einer speziellen "admin.id" (user). Mit der "admin.id" wurde sich angemeldet.
Ich denke mal, die Signierer ID ist mit Ablauf des alten Org Schlüssels nun nicht mehr trusted und muss mit dem neuem O/OU Zertifzierer(schlüssel) rezertifziert werden.
Besten Dank für den Tipp, dann werde ich das mal weiter verfolgen ...
-
Ich denke mal, die Signierer ID ist mit Ablauf des alten Org Schlüssels nun nicht mehr trusted und muss mit dem neuem O/OU Zertifzierer(schlüssel) rezertifziert werden.
Besten Dank für den Tipp, dann werde ich das mal weiter verfolgen ...
Sollte das nicht funktionieren und sich die Fehler mehren, ist das Zurücknehmen des Rollovers via Rezertifizierung des aktuellen Hauptzertfizierers mit dem alten (vor Rollover gesicherten) Hauptzertifzierer (also mit sich selbst) aus meiner Sicht keine Option mehr.
Die gesamte Infrastruktur ist ja bereits einmal durchgetauscht und die zwei Jahre sind rum, d.h. Clients und Server vertrauen dem alten Hauptzertifizierer nicht mehr.
Es bliebe dann nur noch die Option, den "neuen" Hauptzertifizierer einmal mit sich selbst zu Rezertifzieren und einmal den gesamten Rollover nochmals bis nach unten durchzuziehen (O --> OU --> Server --> Clients).
Da würde ich an Eurer Stelle aber Hilfe hinzuziehen.
Den Fehler aus dem lokalen Log wirst Du vermutlich auch danach nicht los, denn das scheint aktuell (?) ein Fehler zu sein.
Die IBM schreibt derzeit einen Fix, der das beheben soll, sprich den Fehler im lokalen Log, der u.U. keiner ist, nicht mehr anzeigen lassen soll.
Um ganz sicher zu gehen würde ich an Eurer Stelle einen PMR eröffnen. Die IBM hat Tools, mit denen die Integrität von IDs, deren Zertifizierer und der Zertifizierungskette überprüft werden kann.
-
PMR habe ich nun erstellt.