Aufzeichnung Benutzeraktivität in Mail-DB

Na vermutlich durch den OutOfOffice Agenten den ja er aktiviert hat

Das Mosaiksteinchen, was jetzt noch fehlt, ist der Absender der Empfangsbestätigung (so es sich denn auch wirklich um solch eine handelt).
Wenn es nur OoO-Meldungen handelt (und das sind keine Empfangsbestätigungen!), gilt taurecs Aussage. Wenn es aber tatsächlich ReturnReceipts sind - dann war der Benutzer es doch selber oder jemand hat seine ID und ein gültiges Passwort. Ein ReturnReceipt wird nur im FrontEnd ausgelöst ... Dirks Posting zielte ja bereits genau dorthin.

Dazwischen ist nichts mehr.

Bernhard

Auf deutsch heisst das eigentlich: Du weisst nichts. Die angeblichen ReturnReceipts hast Du offensichtlich nie gesehen, Regeln haben mit Benutzeraktivität nichts zu tun (bzw. sind eine Aktivität des Servers). Komischerweise kannst Du aber ausschliessen, dass die ID mehrfach vorhanden ist und das Passwort nicht bekannt wurde. Hm ...

Daher jetzt Butter bei die Fische:
- Wurden ReturnReceipts versandt in der Zeit, als der betreffende Mitarbeiter keinen Zugang zum Domino hatte? Ja oder nein?
- Wessen Name steht unter "Benutzeraktivität" in der fraglichen Zeit? Auch das hast Du ja noch gar nicht gesagt!

Hast Du hier ohne belastbare Fakten und ohne ausreichendes Basis-KnowHow einfach nur panisch reagiert, weil ein Schlipsträger hysterisch wurde?

Bernhard

Da man ReturnReceipts nur über das Frontend erzeugen kann, wurden diese daher durch einen Menschen erzeugt. Und wenn der rechtmässige Beistzer des ID-Files nachweislich nicht da war (auch nicht remote), dann erfreut sich diese ID also grösserer Beliebtheit als erwünscht.
Und - by the way - der unrechtmässige Besitzer ist nicht besonders helle, sonst hätte er das Auslösen der RRs vermieden

Bernhard

Eine schnelle Gegenmaßnahme wäre, die Kennwortüberprüfung für den User und auf dem Server zu aktivieren.
Sofort danach soll sich der richtige User mit einem geänderten Kennwort am Server authentifizieren,
damit der Fingerabdruck seines Kennwortes in seinem Personen-Dok gespeichert wird.

Dann sind zumindest alle ausgesperrt, die zwar die ID aber nicht mehr das gespeicherte Kennwort haben.

Gruß Steffen

Hmm, ich erinnere mich dunkel, es gibt einen Debug-Parameter, der zu jeder geöffneten Session auch die IP auf der Konsole anzeigt. So, wie auch die IP im Adminclient unter "Notes Users" sieht. Wird per default nämlich nicht geloggt. Hat aber den großen Vorteil: du siehst -sollte so ein Fall nochmal auftreten- von welcher IP der Login kam. Dann rede mit deinen Netzis, dass die in Erfahrung bringen sollen, wann wer welche IP hatte (DHCP, bei fester IP ungleich einfacher).

Ärgerlicherweise fällt mir der Parameter nur gerade nicht ein. Vllt. kennt den jemand?

Es ist ein reiner Konsolen-Befehl, den übrigens der Admin-Client sowieso jedesmal ausführt, wenn man mit diesem z.B. die Nutzerliste abruft.

show users

Liefert ganz normal die Nutzer, die gerade eine Session geöffnet haben und

show users debug

liefert noch deren IP dazu.

Allerdings ist es ein reiner Konsolenbefehl, da wird nichts permanent aufgezeichnet zum späteren Nachschauen. Und bitte keine "Ideen" wie z.B. per Programmdokument alle 5 Minuten aufrufen...

Ich verstehe generell die Schwierigkeit an der Nachvollziehbarkeit gerade nicht so richtig, schließlich hat jedes Personendokument ein deutlich sichtbares Feld mit der Bezeichnung "Notes Client-Computer" wo die Liste der PC's drinsteht, von denen aus mit dieser ID bereits irgendwann einmal zugegriffen wurde. Sogar Betriebssystem und Version stehen dabei.

Das sollte sehr schnell zum Erfolg führen und funktioniert auch im Nachhinein, es sei den der "Täter" ist jemand, der seine Spuren zu beseitigen wußte. In dem Falle ist es aber entweder ein Admin oder aber ihr solltet ihn sofort zum Admin machen oder sein Gehalt verdoppeln, scheinbar weiß der dann nämlich mehr über Notes als eure aktuellen Admins

Carsten

Funktioniert nur, wenn jeder seinen eigenen Rechner hat. Bei einer Citrixumgebung beispielsweise steht da der TS drin. Alternativ kann jemand mit genug bösem Willen auch einen Notesclient in einer VM starten und das Ding "Alf73" nennen...

Das stimmt alles Ralf, es gibt (auch und insbesondere außerhalb von Notes) noch etliche Dinge die zu einem sicheren Netzwerk gehören. Und wenn sich jeder mit einem beliebigen PC (oder einer VM) ins Netz einstöpseln kann und noch per DHCP bedient wird...ich rede mal nicht weiter, worums geht sollte klar sein.

Wenns tatsächlich ein TS ist dann tippe ich aber sogar mal darauf, dass der Kollege einen anderen Kollegen beauftragt hat, während seines Urlaubs mal ein weinige Spam aufzuräumen. Auch dass solls geben. Und es würde erklären, warum der Kollege an die ID rankommt.

Carsten

Ja, du hast da natürlich Recht. Es gibt eine Menge Punkte zu berücksichtigen und jeder dieser Punkte führt zu Argumenten dafür und dagegen. Da können wir uns die Köpfe heiß reden, bringt schlussendlich doch nichts.

Um auf das eigentliche Thema zurück zu kommen: ich würde ja einfach Schlüsselabgleich aktivieren und eine neue ID rechnen. Dann erstmal Schluss mit mysteriöser Benutzeraktivität. Nachteil: kommt der User wieder, ist auch Schluss mit alten verschlüsselten Mails. Aber Strafe fördert den Lerneffekt.

Wenn das nicht möglich ist, simpel und einfach den Benutzer in sämtlichen Gruppen im Notessinne unkenntlich machen, d.h. beispielsweise ein "#" voran stellen. Dann kommt die ID "Detlef Dummbeutel/Firma" nämlich zumindest mal auf keine DB mehr drauf (weil in der Gruppe dann ja ein User "#Detlef Dummbeutel/Firma" gelistet ist). Steht dann im Serverdokument beim Zugriff nicht ausgerechnet auch noch "*/Firma" drin, ist schon ein Schritt vorher Schluss.

Wenn der User dann zurück kommt, mit ihm ein ernsthaftes Erziehungsgespräch führen und schrifftlich festhalten lassen, dass er seine ID nicht weitergegeben hat und das niemals tun wird, inkl. Androhung arbeitsrechtlicher Maßnahmen (sofern bei euch die Weitergabe von IDs verboten ist, sonst hast du da keine Chance).

:wuet: Auf die einfachsten Dinge komm ich natürlich nicht... :wuet: