Problem 'No Access' mit kACL und lokalen DB

[gab]

Hallo Zusammen,

Client 6.5.5 / Server 6.5.5

- ich habe ein paar User in einer LN-Gruppe, die eine Netzwerkverbindung zum Server haben
und eine lokale Replik (mit kACL) und eben dieser Gruppe in der ACL nicht öffnen können ( Meldung "You are not authorized to access the database")

- Die Datenbank wurde ein paar Monaten per Policy lokal angelegt.
Warum nun der eine oder andere User nun auf einmal keinen Zugriff hat, entzieht sich meiner Kenntnis.

- Die in der Technote beschriebenen Ursachen und Abhilfemaßnahmen haben nichts geholfen ( Client neu starten, Update Server view index)
http://www-1.ibm.com/support/docview.wss?uid=swg21192746

Löschen der lokalen Replik Vor-Ort und Neuanlegen der Replik war die Lösung.

Frage: Kennt jemand eine Möglichkeit, diese Aufgabe per Skript (z.Bsp. Agent in Mail DB + Aufruf z.Bsp per Mailbutton, welche Repl. Historie löscht) zu lösen?
Das Problem ist, dass der Agent 'run as' lokal im Userkontext läuft und somit mir grade keine elegante Lösung einfällt. Jemand eine  Idee wie das Prolbem technisch zu lösen wäre?

Vielen Danke für Eure Hinweise,
Gruss Gab.

[Bastel123]

Moin,

welcher Zugriff war eingetellt beim Anlegen der Datenbank per ACL?

Falls default auf kein Zugriff war und die User nur per Gruppe Zugriff haben, so hast Du leider nur einen Datenbankrumpf, der nur auf Betriebssystemebene gelöscht werden kann :-).

Das ganze hat IBM leider so bestätigt. Man hat es (eventuell) an die Entwickler weitergeleitet.

Wenn der User als Person drinsteht oder Default auf Reader steht, so werden die richtigen Rechte bei der nächsten Replication gerade gerückt.

Ist nur schade, wenn man Datenbanken mit Default "No Access" hat.

Ein Fall für "We love Notes, but..."

Probier mal war passiert mit Default = "Depositor"

Bis dahin

Sebastian 

[gab]

Die DB ist kein Stub und wurde bis dato immer vollständig repliziert. Auf einmal geht bei bestimmten Usern lokal nichts mehr ("No Access" , wie bereits oben beschreiben)

Scheint mir ein Bug zu sein, normal ist dieses Verhalten jedoch nicht!?

Werde deinen Tip (besten Dank!)  befolgen und mal den Default auf Reader setzten.
Danach sollte der Client nach einer Replikation für die lokale DB hoffentlich die korrekte Rollen\Gruppenauflösung für den aktuellen User durchführen.

[koehlerbv]

Dieses Verhalten ist kein Bug, sondern eine Folge davon, dass es die kACL überhaupt gibt.
Die kACL muss ja derart funktionieren, dass auch ohne Vorhandensein des Domino Directorys die Zugriffsrechte ermittelt werden können. Hierzu wird bei der Erstellung (!) der Replik / der Kopie ein "Snapshot" der aktuellen Situation - bezogen auf die replizierende Person - erstellt.

Und wenn dann später eine andere Person ... Die ist im "Snapshot" natürlich nicht berücksichtigt.
Selbstverständlich macht das einem ggf. das Leben schwerer, aber: Ot works as designed.

Bernhard

[gab]

Vielen Dank. Wieder etwas dazugelernt, was das 'Snapshot Verhalten' angeht.

Jedoch frage ich mich, warum davon User betroffen sind, welche bereits lokalen Zugriff
hatten und nun auf einmal nicht mehr ( die Gruppe hat in anderen Datenbank mit kACL auf dem selben Rechner und für den selben User im übrigen funktioniert)

Anyway ...
Dann muss ich mir wohl, obwohl es lt. obiger Technote nach einem Client Reconnect ein Refresh der lokal gecachten kACL geben soll (Zitat aus dem Link "The cached rights should update the next time the database is replicated.") , mir Gedanken machen, wie ich ein Refresh der ACL periodisch erzwingen kann.

Oder habe ich mich gedanklich verrannt?

[koehlerbv]

Du hast Dich gedanklich verrannt. Ein Refresh findet statt - oder eben nicht, weil kein Zugriff besteht. In letzterem Fall ist ein Refresh des ACL Snapshots unmöglich.

Bernhard

[Bastel123]

Moin,

ich finde es komisch, dass der Server beim Anlegen der Replik per Policy nicht weiß, wer in der Gruppe ist. Wenn nicht er wer denn dann?

Viele Grüße

Sebastian 

[koehlerbv]

Der Client (! - der erzeugt ja die lokale Replik mit kACL) weiss das schon, und er vermerkt im Snapshot, dass die ausführende Person Mitglied der Gruppe hat und welche Rechte diese Gruppe in der DB hat.
Viel Sinn macht es auch nicht, die anderen Mitglieder der Gruppe zu speichern - diese können sich ja ändern, und häufig ist es ja auch so in der Praxis: Ein neues Mitglied kommt hinzu, und dann braucht dieses neue Mitglied auch eine lokale Replik ...
Wichtig ist auch: Gespeichert wird der Schlüssel der Person (und daher ist die Gruppe an sich nicht hilfreich) - sonst wäre ja eine lokale Replik mit kACL perdu, wenn der Name der Person geändert wird.

Bernhard

[Bastel123]

Hallo Bernhard,

wenn die Replik erstmalig per policy gezogen wird sind die User aber doch im Netz und finden damit einen Server.

Außerdem haben wir noch ein mobileaddressbook im Einsatz in dem auch die Gruppen mit Mitgliedern sind. Könnte man das dafür nutzen?

Gruß

Sebastian

 

[gab]

Der Client (! - der erzeugt ja die lokale Replik mit kACL) weiss das schon, und er vermerkt im Snapshot, dass die ausführende Person Mitglied der Gruppe hat und welche Rechte diese Gruppe in der DB hat.
Viel Sinn macht es auch nicht, die anderen Mitglieder der Gruppe zu speichern - diese können sich ja ändern, und häufig ist es ja auch so in der Praxis: Ein neues Mitglied kommt hinzu, und dann braucht dieses neue Mitglied auch eine lokale Replik ...
Wichtig ist auch: Gespeichert wird der Schlüssel der Person (und daher ist die Gruppe an sich nicht hilfreich) - sonst wäre ja eine lokale Replik mit kACL perdu, wenn der Name der Person geändert wird.

Bernhard

Das ist richtig. Es werden keine Gruppeninformationen nach lokal repliziert , sondern nur einzelne Personen (Keys)
Ich habe es eben einmal mit LN + Server Release 8 getestet:

1) DB auf Server mit
   - kACL
   - Default = No Access     
   - Gruppe A (Mitglieder = User1 + User2 )

2) User 1 Repliziert die DB lokal auf sein Notebook per Hand oder erhält diese per Policy repliziert.

3) Test mit ID User1:  hat lokalen Zugriff

4) Danach sofort Wechsel der ID auf User2. Ergebnis: User2 hat KEINEN lokalen Zugriff ("No Access")

Erkenntnis: Wenn die Notebooks zwischen Usern mal getauscht werden, wird es Probleme mit dem
Zugriff auf diese DBs geben...

Abhilfe: Multiple User Installation?

[Bastel123]

Hallo Gab.

was für Policies setzt Du ein Organisational oder explizit?

Gruß

Sebastian

[gab]

Hallo Gab.

was für Policies setzt Du ein Organisational oder explizit?

Gruß

Sebastian

Explicit policies