Beiträge von MacRulez2003

    Hi Peter,


    ja, aber ...


    der User war noch nicht gelöscht, sondern stand noch (absichtlich) im NAB. Er war halt nur Mitglied der Access-Deny-Gruppe.
    Ist Unternehmens-Policy: Wenn ein Mitarbeiter das Unternehmen verlässt, wird sein Dokument noch drei Monate behalten (um ggf. mit der ID auf verschlüsselte Inhalte zugreifen zu können). Er wandert dann in die Access-Deny-Gruppe.
    Das zentrale User Management hätte ihn nur aus allen anderen Gruppen herauslöschen müssen. Das ham die nich gemacht.


    cheers




    EKKI

    OK, Asche auf mein Haupt und ein Bier für alle die ich bei Gelegenheit mal treffe.


    Grund war:


    Das Usermanagement hatte den Benutzer, den ich getestet habe, zwar aus allen Gruppen rausgelöscht, aber nicht aus einer, die in der vierten Gruppenebene verschachtelt - Full Access Admin Rechte hat.


    Tja, so ist das mit dem Erben von Domino-Aufgaben ...


    Danke nochmal für Eure Hilfe.



    cheers




    EKKI

    Hallo zusammen,



    könnten wir uns erstmal um die primäre Frage kümmern?


    Nein, Agathe, bei einem normalen Loginscript wird das schwer. Du könntest Dir ein Notes-Script erstellen, das die Attachements aus dem names.nsf löscht, aber dazu solltest Du NotesScript können. Sofern das Attachement nicht im names ist, läßt dich der client die ID suchen.


    Wenn Du Dir das nicht zutraust, solltest Du eher den manuellen Weg wählen. Dokument öffnen, attachement löschen, Dok sichern.


    tja, isso.


    Nun zu den Anmerkungen der Moderatoren: Nunja, manchmal erbt man halt ziemlich viel Müll. Wie die Jungs schon schrieben: Änder' das mal schnell sonst kommst Du in Teufels Küche.



    cheers



    EKKI

    gleicher fehler auf einem 6.5.4er server.


    hätte da noch eine andere idee:


    unter NotAccessServer ist eine DenyAccess-Gruppe eingetragen. Diese enthält wiederum (aktuell 6) weitere Gruppen mit Personen, die das Unternehmen verlassen haben.


    Kann das sein, dass der HTML-Task die DenyAccess-Gruppen nicht sieht? Kann leider die Server gerade nicht neu starten, sonst hätte ich mal ne andere Gruppe eingetragen.



    cheers


    EKKI

    Hallo Taurec,


    erstmal Danke für Deine Mühe. Finde ich wirklich nett.



    also:


    - keine replizierkonflikte in der names.nsf.
    - versprochen: Die NotAccess-Gruppen sind dort eingetragen. Ich habe sogar meinen Test-User dezidiert aufgeführt.
    - sorry, den letzten Punkt verstehe ich nicht. In einem InternetSite-Doc kann ich den enforce nicht setzen. Ich habe den enforce nicht auf allen servern gesetzt, aber dort, wo ich mich authentifiziere (portal/gateway) und auf allen mailserver, die ich getestet habe. Das sollte reichen, oder?


    gehe jetzt der reihe alle meine server durch, mal sehen, wo ich noch fündig werde.



    cheers



    ekki

    Hallo Taurec,


    sorry. habe meinen post nochmal verändert. ist jetzt weniger komplex.


    Das verhalten habe ich auf ALLEN (!) mail servern.


    Zu deinen restlichen Fragen.


    - ja, der http task ist neu gestartet (ich dachte ich hätte das beantwortet mit dem serverneustart
    - ja, wir haben SSO aktiv (auch das hatte ich beantwortet.
    - Alle Server haben 8.5 (hatte ich das nicht geschrieben)
    - Nein, keine Replizierkonflikte, zumindest nicht in den entsprechenden Datenbanken.


    cheers




    EKKI

    Hallo Taurec,


    also: Portalserver ist 8.5, die Mailserver sind 8.5. SSO ist aktiv. Alle server neu gestartet.


    Anmeldung am Portalserver: diese meldung.
    Zugriff auf dem Mailserver mit direktem Link (also: http://notesserver.fqnd.tld/mail/mailfile.nsf): zugriff.


    tja.


    Das Problem ist vor allem wohl, dass der User ein gültiges Token bekommt. Nachdem er von der Mailjump am Portal abgewiesen wurde, kann er direkt (ohne erneute Passwortabfrage) auf seinen Mailserver zugreifen.


    cheers



    EKKI

    Hallo zusammen,


    hilft nicht echt weiter, aber hier bei uns: Domino 8.5 mit Client 6.5.4: Benutzer ist drei Wochen im Urlaub, kommt zurück und stellt fest, dass einige seiner Mails, die während des Urlaubs gekommen sind, gelesen sind. Kein anderer Zugriff während des Urlaubs.


    Das scheint nichts lokales bei Euch zu sein.



    cheers



    EKKI

    Hallo Bastian,


    danke für Deine Rückmeldung. Also: Admin-Hilfe sagt, dass dieses Feld für das jeweilige Protokoll (HTTP, Mail, etc.) die Settings des Server-Dokumentes übernimmt. Also: wer unter "Not Access Server" gelistet ist, hat keinen Zugriff per HTML, SMTP, IMAP ...
    Nur leider funktioniert es nicht ganz so wie erwartet.


    Mein Problem sieht so aus:


    An der Portalseite wird der User mithilfe einer Mailjump-Funktion auf seinen Mailserver geroutet. Dort wird die Datenbank per HTML geöffnet.
    Das Setting greift auf der Portalseite, der (nicht autorisierte) Benutzer wird mit einem HTML-500-Fehler abgewiesen. Soweit OK.
    Kennt der Benutzer aber den Pfad zu "seinem" Server und gibt diesen direkt im Browser ein, wird das Setting umgangen.
    Natürlich sind die DenyAccess-Gruppen auf allen Servern gleich gepflegt, auch die Serverdok-Settings sind gleich.


    Ich weiß da nicht mehr weiter.


    Viele Grüße



    cheers



    EKKI

    Hallo zusammen,


    bitte nicht schlagen wenn das ne blöde Frage ist (bin halt mehr admin) aber wie kann ich am einfachsten die Anzahl aller Dokumente in einer Datenbank mit einem Skript ermitteln. Ich habe mal die Onlinehilfe bemüht, finde aber unter "Domino:Classes" bei Notesdatabase keine Property, die so heißt.


    Vielen Dank für irgendwelche Tips




    cheers



    EKKI

    Hallo Armix,


    Hat der betreffende Benutzer so was wie ein mobiles Gerät (Du schriebst was von Traveller oder Blackberry).


    Und: Ich würde mal die Passwortsynchronisierung einschalten und das Passwort der ID ändern. Nicht das da noch so ein Ferkel mit einer alten User-ID die Maildatenbank durchforstet.


    (Wäre ja auch mal ne idee: in der Nutzungshistorie mal schauen, ob und wann ein User auf die Datenbank zugegriffen hat).



    Drücke Dir die Daumen.



    EKKI