Agentenzugriff auf entfernte Server geht nicht - was tun?

    Hallo Leute, Unser SQL-basierter Zeiterfassungsserver schickt Kalendereintrags-Emails an eine Notes-MailIn-Datenbank. In dieser Datenbank läuft dann ein eventgesteuerter Agent, der bei sich ändernden Dokumenten angetriggert wird und der dann auf Postfächer auf dem Server selber und auf entfernten Servern zugreift und dort Kalendereinträge macht.


    Das Problem ist eigentlich ein sehr Einfaches, wir finden aber die Lösung nicht. Wenn wir den Agenten mit dem Notes-Client und der Admin-ID, die volle Rechte hat, manuell per rechter Maustaste ausführen, läuft er durch und macht die Kalendereinträge, alles in Ordnung.


    Wenn der Agent aber wie oben beschrieben bei dem automatisierten Durchlauf alleine losläuft und auf entfernte Server innerhalb der Domäne zugreift, kommt es zu einer Fehlermeldung, die im Log folgendermassen aussieht:


    29.09.2008 11:39:54 AMgr: 'Agent 'MailInAbwesenheitTermin' in 'mail\AHBMailin.nsf' will run on behalf of 'Server/...'
    29.09.2008 11:39:54 AMgr: Agent ('MailInAbwesenheitTermin' in 'mail\AHBMailin.nsf') printing: DEBUG: Bestimme Mail-DB und Mail-File von User@email.de
    29.09.2008 11:39:54 AMgr: Agent ('MailInAbwesenheitTermin' in 'mail\AHBMailin.nsf') printing: DEBUG: Ergebnis: Mail-Server ist CN=Entfernter Server/OU=..., Mail-File ist mail\user.nsf
    29.09.2008 11:39:54 AMgr: Agent ('MailInAbwesenheitTermin' in 'mail\AHBMailin.nsf') printing: DEBUG Delete: Öffne Mail-File mail\user.nsf auf Server CN=entfernter Server/...
    29.09.2008 11:39:54 AMgr: Agent ('MailInAbwesenheitTermin' in 'mail\AHBMailin.nsf') printing: DEBUG Delete: Öffnen erfolgreich.
    29.09.2008 11:39:54 AMgr: Agent ('MailInAbwesenheitTermin' in 'mail\AHBMailin.nsf') message box: Fehler 4063 (Z: 35) beim Verarbeiten Mail-FehlzeitenTermin, Löschen Termin (Mail-Datei: mail\user.nsf): Database CN=Entfernter Server/...!!mail\user.nsf has not been opened yet


    Auf dem Server selber, wo die MailIn-DB liegt, geht es hingegen.
    Aktuell ist der Agent mit der Server ID gezeichnet, ist aber völlig egal, womit wir ihn zeichnen, er läuft einfach nicht.


    Wir haben schon geschaut nach folgendem:


    - Server und Admin haben Managerrecht auf die Postfächer
    - Server sind alle untereinander in der Gruppe Trusted Server enthalten.
    - Gruppe LocalDomainServers darf auch alle Arten von Agenten ausführen.
    - Wenn ich auf die Zieldatenbank den effektiven Zugriff anzeigen lasse , habe ich Managerrecht.


    Was können wir tun? Habt Ihr eine Idee?


    #Gruss Marco

    wie sehen denn die berechtigungen auf den server aus?


    server-dok -> security


    ps. bitte achte auf das themenpräfix!!!

    -*-*-*-*-*-*-*-*-*-*-*-


    woher soll ich wissen was ich denke, bevor ich höre was ich sage???

    Es gibt eine Gruppe "$Server Bank", da sind unsere Server alle drin, und diese Gruppe widerrum ist in folgenden Feldern eingetragen:


    Access server:
    Create databases & templates:
    Create new replicas:
    Create master templates:
    Trusted servers:


    sowie bei den Agenten:


    Run unrestricted methods and operations:
    Run restricted LotusScript/Java agents:
    Run Simple and Formula agents:


    Ist meiner Meinung nach richtig so, zumindest ausreichend. Ich lese überall, dass es an dem Feld "Trusted Servers" liegt, aber auch da sind die Server direkt eingetragen.

    Und hat der entfernte Server und der Signer des Agenten denn auch Zugriff auf die MailDatenbank um sie zu öffnen ?.


    Denn die Server Sicherheitseinstellungen definieren ja nur das grundsätzliche Recht auf den Server zuzugreifen. Auf welche DBs dieser darf hängt dann von der ACL ab.

    Das hat er, das war das erste, was ich überprüft hatte. Unsere Server stehen alle in einer Gruppe $ServerBank , die widerrum in allen Postfächern als Manager eingetragen ist.


    Zur Erinnerung: Es geht ja auch, wenn man den Agenten manuell laufen lässt.....also aus dem Client heraus und mit der Admin-ID, die ebenfalls Manager ist. Zeichnet man aber den Agenten mit der gleichen Admin-ID, geht es nicht und es kommt zur oben genannten Fehlerledung. Ebenso passiert dies, wenn der Agent mit der Server-ID gezeichnet ist.

    Du hast leider nur die Hälfte meiner Frage beantwortet:


    Unter welcher ID läuft der Agent und hat dieser Zugriff auf den anderen Server und die dortigen MailFiles ?


    Du hast nur von den Servern gesprochen, oder hast du den Agent damit unterzeichnet ?

    Hab ich doch oben geschrieben:


    "Zeichnet man aber den Agenten mit der gleichen Admin-ID, geht es nicht und es kommt zur oben genannten Fehlerledung. Ebenso passiert dies, wenn der Agent mit der Server-ID gezeichnet ist."


    Am Liebsten wäre mir, wir können den Agenten mit der Server-ID zeichnen....oder gibt es da Bedenken gegen?


    Ich hatte auch zum Test schon den Server explizit in die ACL eingetragen, da ich dachte, es läge vielleicht an der Gruppenauflösung, ist aber der gleiche Effekt.


    Wieterhin steht die Gruppe $ServerBank auch in den diversen Secutity-Feldern wie Trusted-Server drin.

    Sorry, aber durch das "Zeichnet" ist das irgendwie untergegangen. Ist auch ne etwas seltsame Wortwahl dafür.


    Sagt denn das Log des Zielservers etwas über den verweigerten Zugriff aus, wenn ja was ?

    Naja, die Logeinträge (unter Miscellaneous Events) hab ich ja oben schon gepostet.....zuerst sagt er "Öffnen erfolgreich" , dann kommt aber "Database has not been opened yet".


    Hab das schonmal im LDD recherchiert, da lösen sich überall die Probleme durch aufnehmen der Server in das Feld "Trusted Servers".....nur, das hab ich schon gemacht.


    Ich weiss echt nicht mehr weiter.....hab auch schon den Server mit seiner direkten Bezeichnung da reingenommen und nicht über unsere Gruppe, ändert aber nix....

    Nein hast du eben nicht, denn ich wollte den Inhalt des Logs des Zielservers auf dem die Mail-DB tatsächlich ist.


    Und die Meldungen in dem Logausschnitt sagen ohne den dazugehörigen Code gar nichts aus, denn von diesem hängt es ab was da ausgegeben wird.

    Hab den Fehler nach laaaangem Suchen gefunden. Im Feld "Run on behalf" unter der Lasche mit dem Schlüssel in den Agenten-Eigenschaften stand jemand drin, der kein Recht auf das Postfach hat.


    taurec
    Danke, Dein Tip hat mich letztenendes darauf gebracht, denn im Log des Zielservers stand der User drin, da wusste ich, dass das was faul sein musste. Hätt ich auch selber draufkommen müssen, aber irgendwie schaut man immer nur im Log des zugreifenden Servers nach...


    Frage mich allerdings eines: "Run on behalf" heisst ja "Im Namen von...ausführen"....aber warum macht er das nur, wenn er eventgesteuert loshechelt und nicht auch, wenn ich als Person das mit dem Notesclient manuell mache???