"Not access Server" greift für HTTP-Server nicht.

    Hallo zusammen,


    ich habe ein kleines Security-Problem. Auf meinen Servern habe ich im Serverdokument unter "Not access Server" eine Access-Deny-Gruppe eingetragen. Diese wiederum enthält mehrere Gruppen mit Personennamen, welche keinen Zugriff erhalten sollen. Unter Ports -> Internet Ports -> Web habe ich "Enforce server access settings" auf "Yes" gesetzt. Die beteiligten Server neu gestartet.


    Dennoch können sich Benutzer, die ein Benutzerdokument mit Internet-Kennwort haben, über HTTP auf dem Server anmelden. Ich habe mir die Web-Config-Doks angeschaut und keine Option gefunden, das Login zu unterbinden.


    /Update:
    Also nochmal genauer: Mehrere Server unter Domino 8.5 . Zentrales Login mit WebSSO.
    Geht der Benutzer über eine zentrale Anmeldeseite, wird er abgewiesen. Ruft er den Link direkt auf (https://serverxy.fqdn.de/names.nsf), wird sein Passwort abgefragt und er erhält zugriff.



    Habe ich ein Feld übersehen? Greift "Not access Server" auch für HTTP-Server?


    Danke für Eure Ideen.



    cheers



    EKKI

    Hallo Ekki,


    dieses Feld greift so viel ich weiß nicht für den HTTP Server.


    Wenn ich dich richtig verstanden habe willst du einigen Usern den Zugriff via HTTP verwehren? Du könntest ihnen kein Webpassword zuordnen. Ohne Web password dürfen sie sich (wenn der server richtig conf. ist) nicht per http anmelden.

    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

    Und wenn du ohne dich zuvor auf dem Portalserver anzumelden direkt auf den Mailserver gehst und dort versuchst dich anzumelden, kommt dann die gleiche Meldung ?


    Welche Versionen sind die Server, habt ihr SSO aktiv, mal die HTTP Task durchgestartet, Replizierkonflikte geprüft auf den Mailservern ?

    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

    Du hast mich wohl falsch verstanden.


    Was ich meinte ist, wenn du ohne vorherigen Versuch der Anmeldung am Portalserver auf den Mailserver zugreifst.
    Was passiert dann ?


    Auf jeden Fall muss dann eine Passwortabfrage kommen und was danach folgt ist wichtig

    Gut damit ist es definitv ein Problem des Mailservers und hat nichts mit SSO oder so zu tun.


    Und was ist mit den restlichen Fragen aus meinem Posting ?


    Bitte beantworte wenn man dir helfen soll auch alle dir gestellten Fragen und nicht nur einen Teil

    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

    In welchen Datenbanken gibt es keine Replizierkonflikte ?
    Wichtig ist da vor allem das names.nsf mit Serverdokument/NoAccess Gruppen


    Und die NoAccess Gruppen sind auch sicher bei den Mailserver eingetragen und die Option Enforce ist da auch aktiv ?
    Und das Enforce ist nicht zufällig bei einer InternetSite nicht aktiv ?

    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

    Ja dort sollte es reichen.


    Aber es muss ein Konfigurationsproblem sein, da es ja auf den Mailservern nicht geht.
    Vergleich doch mal die Sicherheitseinstellungen ganz genau mit dem des Portalservers.
    irgendein Unterschied muss da sein, da es ja die gleichen Serverversionen sind

    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

    Also ich hab das gerade noch mal bei uns getestet (ebenfalls 8.5).
    Und da arbeitet die Einstellung genau so wie sie soll.


    Und die DenyAccess Gruppen muss er sehen, sonst würde es ja auch Notes-technisch nicht greifen.


    Wie gesagt: Ich bin sicher das ist eine Konfigurationseinstellung die bei euch nicht stimmt

    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

    ... sorry für den Nachtrag, aber dann solltest Du auch mal den adminp Prozess bzw. die Admin4.nsf überprüfen.
    Denn dieser Prozess sorgt dafür das gelöschte User auch aus Gruppen entfernt werden...


    ciao
    peter

    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