iNotes6 und ACL fuer Kalenderzugriff

[Raymond]

Hallo Forum

wir haben auf einem Domino Server (Lotus Domino 6.5.3 Windows) iNotes im Einsatz. Um Kalenderdaten anschauen zu können, sollten die Mitarbeiter auf den iNotes Kalender eines anderen Mitarbeiters zugreifen können.

In der ACL besitzt "Default" No Access und "Read public documents", damit die Kalender Dokumente gelesen werden können. Anonymous hat nur "No Access". So sollten also authentifizierte User meiner Meinung nach die "Public Documents" lesen können.

Interessanterweise funktioniert das bei einigen iNotes Datenbanken, bei anderen nicht, obwohl die ACL absolut identisch ist 

Hat jemand von euch eine Idee, woran dies liegen könnte? Setze ich bei einer iNotes DB die Probleme macht "Default" auf "Reader", dann geht der Zugriff. Als "Reader" kann ich dann aber auch die Mails des anderen Mitarbeiters einsehen und nicht nur die Kalenderdaten, also ist dies keine Lösung.

Gruss und besten Dank für die Unterstützung
Ray

[m3]

Warum pfuscht Du an der ACL herum?
Die Looser, äh USER meine ich, müssen nur den Kalender freigeben und alles klappt wunderbar.

[Raymond]

ich "pfusche" an der ACL rum, weill das Freigeben der Kalender nicht funktioniert. Die Freigabe des Kalenders macht ja auch nichts anderes, als in der ACL das Flag "Read Public Documents" zu setzen.

Trotz allem bleibt die Fragestellung, wie es möglich ist, dass sich Datenbanken mit der gleichen ACL nicht identisch verhalten...

Gruss
Raymond

[Steve_O.]

Könnte ein cache-Problem des Servers sein...

[datenbanken24]

Ich denke zwar nicht, dass es Dein Problem lösen wird,
aber zur Info:

Wir haben eine ähnliche Konfiguration für iNotes (6.5.3 / 6.5.4)
und die User, die seit kurzem den MS IE 7 Browser benutzen,
sehen den iNotes Kalenderansichten im Web über überhaupt nicht mehr.

Intro, Mail und ToDo gehen wie vorher,
der Kalender ist leer - zeigt aber allerdings auch nicht mal das Monats-Grid.
Das wurde dann auch irgendwo von IBM bestätigt.

Gruß,
Uwe

[m3]

Interessanterweise funktioniert das bei einigen iNotes Datenbanken, bei anderen nicht, obwohl die ACL absolut identisch ist 

Hey Ray (das reimt sich )!

Wie äußert sich das "funktioniert nicht"? Fehlermeldung, keine Termine sichtbar, ...? Mehr Input == mehr Output.

Bis Du Dir sichtbar, dass in den DBs, in denen es "nicht funktioniert", die Termine nicht als privat markiert sind, die Besitzer der DB korrekt eingetragen sind, die Benutzer, an die delegiert wurden, korrekt eingetragen sind, ... ?

Normalerweise sollte für die Kalender-Delegation nicht an der ACL herumschrauben müssen. Ich würd den Fehler woanders suchen.

[Raymond]

Vielen Dank für die bisherigen Antworten

Freigabe direkt durch den User im Kalender, ohne manuelles veränder der ACL funktionierte eben nicht, deshalb bin ich nun mit diesem Problem konfrontiert. .. Es ist allerdings so, dass die Freigabe auf via Webbrowser im iNotes gesetzt wird, die meisten Benutzer haben keinen Notes Client.

"Funkioniert nicht" könnte glatt die Aussage vom User sein ;-) Ich meinte damit, dass man nicht auf die iNotes Datenbank des anderen Mitarbeiter zugreifen kann, obwohl man in der ACL "Read Public Documents" aktiviert hat.

Ich öffne also direkt er URL die iNotes Mail DB des Arbeitskollegen "5"  http://dominoserver/mail/Mitarbeiter5.nsf und kann nicht einloggen. Ich erhalte "Error401, User not authenticated", obwohl ich bei der DB Mitarbeter5.nsf "Read Public Documents" für alle Mitarbeiter gesetzt ist.

Ich denke eher nicht, das es am Server Cache liegt, da es reproduzierbar für die einzelnen Mitarbeiter Kalender ist.

Gruss
Ray

[datenbanken24]

Das interessante an Deiner Schilderung in #6 ist die Fehlermeldung.

"Error401, User not authenticated"

Wenn der User wirklich per ACL-Problem keinen Zugriff auf die Datenbank seines Kollegen hätte, dann würdest Du keine Fehlermeldung - sondern den Login-Dialog bekommen.

Ich bin mir fast sicher, Du bist schon drin in der Maildatenbank des anderen -
und IN der Datenbank passiert ein Fehler.

So eine Meldung kommt zum Beispiel, wenn ein WQS/WQO Agent in der Datenbank nicht mit einer ID unterzeichnet ist, die serverseitige Agenten aufrufen darf. Oder wenn ein Agent mit den Rechten des Users läuft, und eben mit dem aktuellen User das nicht darf.

Schau mal im Loguch "domlog" nach, ob es einen Eintrag gibt, der schon in irgendeiner Webseite der Maildatei, auf die Du zugreifst, bei User den eingeloggten User zeigt,
also darauf hinweist, dass der User bereist schon "ein Stück" in der Datenbank "drin ist".
Im Logbuch ("log") solltest Du dann, wenn dem so ist, erkennen, welches Element der Datenbank den Zugriffsfehler verursacht - denn wie gesagt, ich glaube nicht, dass es die Datenbank-Zugriffsrechte selbst sind.

Gruß,
Uwe

[Raymond]

Hallo Uwe

danke für deine Antwort. Meine Schielderung war vermutlich nicht präzise genug. Ich erhalte zuerst 3 x das Login Fenster, danach erhalt ich den Fehler User not authenticated.

Gruss
Ray

[m3]

Du arbeitest auf dem Server eh mit Session-Authentication und nicht mit Basic-Authentication, odrrrrrr?

[Raymond]

Nein, mit Basic Authentication. Ich sehe also nicht die Login Maske aus der domcfg.nsf, sondern einfach den "Browser"-Login.
Sollte meiner Meinung nach aber keinen Einfluss auf den Zugriff auf die Datenbanken, bzw. die ACL haben oder?

Gruss
Ray

[m3]

Ich würde jetzt doch glatt eine Runde Bier für dieses Forum verwetten, dass nach der Umstellung auf "Session-Authentication" alles problemlos funktioniert. 

[Raymond]

Tut mir leid, aber die Wette wäre verloren... Haben die Session Authentication aktiviert, das Verhalten bleibt aber gleich.
Obwohl die ACL identisch aufgesetzt ist, erhält bei der einen DB der Benutzer "You are not authorized to perform this operation.", bei der anderen kann er sich authentifizieren 

Gruss und besten Dank für alle bisherigen Tipps
Ray

[m3]

Damn.
Was sagen denn die Weblogs?