Zugriff zwischen 2 Notesdomänen für weiteren Admin einrichten

[maxritti]

Guten Morgen zusammen,

ich möchte mal ein kleines Problemchen schildern, was ich nicht ganz nachvollziehen kann.

Es geht dabei um 2 Dominoserver, die in 2 unterschiedlichen Notesdomänen arbeiten.
Sagen wir Server S1 ind Domäne D1 und S2 in Domäne D2 und dabei gibt es die Organisationen O1 und O2.

In O1 wurde eine Querzulassung für S2 durchgeführt.
In O2 eine Querzulassung der O1.

Nun gibt es in O1 einen Adminaccount, der auch prima auf dem S2 administrieren kann.
Es wurde nun ein zweiter Account eingerichtet. Sobald dieser versucht auf den S2 zuzugreifen, kommt die Meldung:

"Server Error: Your public key was not found in the Domino Directory"

Soweit auch korrekt, da die Benutzer nicht explizit querzugelassen sind, wohl aber die Organisationen.
Und auch keine Personendokumente von denen im names.nsf des S2 existieren.
Die Gruppen wurde auch schon mehrfach kontrolliert, dass der A2 in den gleichen Gruppen (Sowohl in D1 als auch D2) ist.

Das komische ist, dass A1 problemlos arbeiten kann.
Ein "trace s2" auf der Konsole von S1 klappt auch wunderbar.
Wird allerdings ein "trace s1" auf der Konsole des S2 gemacht, kommt auf s2 zunächst ein "Connected to s1" in der log.nsf des s1 aber dies:

S2 from host [xx.xx.xx.xx:63950] encountered non-fatal problem during authentication: Your public key was not found in the Domino Directory

Wobei im names.nsf auf S1 das Dokument für S2 existiert.
Wir haben die Querzulassung des S2 auch schon mal erneuert, da wurde das gleiche Dokument im names angepasst.

Erklären kann ich mir das ganze nicht.
Zum einen kann der A2 nicht auf S2 zugreifen. Was aber vermutlich eine Folge der Querzulassungsproblematik ist.

Hat dazu jemand einen Tip?

[Wolfgang]

Ich vermute mal, es gibt eine Replik der names.nsf von S1 auch auf S2 und ein Directory Assistance auf S2, in dem diese Replik eingebunden ist.
Und ich vermute weiterhin, in dieser Replik gibt es ein Personendokument für A1, aber das für A2 fehlt.
 
Gruß
Wolfgang

[maxritti]

Danke Dir für Deinen Ansatz.
Es ist aber nicht so, dass die Adressbücher repliziert werden.

Auf jedem Server brav sein eigenes DD, zwar per DD noch andere Adressbücher eingebunden.
Die sind aber nur für die Benutzer um Adressen zu speichern.

Was mich halt wundert ist die Tatsache, dass auf s1 etwas wegen einem Key angemerkt wird, wenn s2 sich verbinden möchte.
Zwar non-fatal und er verbindet sich auch, klingt aber komisch.

Ggf ist das A2 Problem ein Folgefehler davon.

[Manfred W.]

"Server Error: Your public key was not found in the Domino Directory"
...
S2 from host [xx.xx.xx.xx:63950] encountered non-fatal problem during authentication: Your public key was not found in the Domino Directory

Was mich halt wundert ist die Tatsache, dass auf s1 etwas wegen einem Key angemerkt wird, wenn s2 sich verbinden möchte.
Zwar non-fatal und er verbindet sich auch, klingt aber komisch.

Das ist ja auch logisch wenn die Adressbücher nicht repliziert werden. Dann hat der Server die Public Keys der User und Server aus der anderen Domäne nicht, und kann deren Identität nicht überprüfen.

Dass A1 auf S2/O2 zugreifen kann könnte vielleicht daran liegen, dass A1 in O2 manuell gegenzertifiziert wurde.

Das Replizieren der Domino Directories (und einbinden über Directory Assistance oder notes.ini) vereinfacht das ganze halt, weil die Server dann sämtliche Public Keys aus der anderen Domäne haben.
Wir arbeiten hier auf diese Weise auch mit 3 Domino Domänen.

[maxritti]

Dass A1 auf S2/O2 zugreifen kann könnte vielleicht daran liegen, dass A1 in O2 manuell gegenzertifiziert wurde.

Und genau das ist auch ein Punkt.
A1 ist nicht explizit gegenzertifiziert.
Dürfte demnach genauso wenig wie A2 aus S2/O2 zugreifen dürfen.
Geht aber und ich finde so keine Spur in O2 für A1.

Gehe der Sache nun auch nicht mehr nach - auch wenn es mich doch interessieren würde, warum A1 klappt und A2 nicht.
Es handelt sich um ein Legacysystem (leider) und der S2 wird eh bald (wann auch immer das genau sein wird) ausgeknippst. 

[CarstenH]

Gegenzertifiziert (= der ID wird vertraut) und Vergleich des öffentlichen Schlüssels sind zwei verschiedene Dinge.

Trotz Gegenzertifikat kann ein Vergleich des öffentlichen Schlüssels fehlschlagen (sowohl wegen Abwesenheit als auch bei Unterschied).

Und beim fehlgeschlagenen Vergleich ist es lediglich eine Einstellungsfrage, ob nur eine Meldung ausgegeben (Warnung) oder gleich der Zugriff gesperrt (fatal) wird.

Carsten

[maxritti]

Danke Dir für die weiterführende Info.

Have a nice weekend.