Gegenzertifikate / Vertrauensstellung zwischen zwei Domino-Umgebungen erstellen

1. Ziel

Der Domino Server venus/landstuhl/de/conats (stanoc-Server) soll auf den Domino-Server App01/Demo (Kundenserver) zugreifen können und Manager-Zugriff auf bestimmte Datenbanken erhalten.

Auch der User Development/stanoc soll auf den Domino-Server App01/Demo zugreifen können und Manager-Zugriff auf bestimmte Datenbanken erhalten.

2. Vorgehensweise

2.1. Netzwerkverbindung

Eine funktionierenden und stabile Netzwerkverbindung auf TCP Port 1352 vom stanoc System zum Kundenserver ist vorausgesetzt und wird hier nicht weiter beschrieben.

2.2. Gegenzertifikate erstellen

2.2.1. Safe-IDs erstellen

Um nicht die komplette Server-ID transferieren zu müssen, empfiehlt es sich aus Sicherheitsgründen, eine Safe-ID der beteiligten Server-ID-Dateien und des stanoc Admin-Users zu erzeugen.

Dazu im Domino Administrator den Punkt “Certification” → “ID Properties…” öffnen, die ID Datei auswählen (ggf. Passwort eingeben) und dann unter “Your Identity → Your certficates” bei “Other Actions…” “Export Notes ID (Safe Copy)…” aufrufen:

Open

Für alle beteiligten Server/Administrator auf beiden Umgebungen wiederholen.

Die Dateien dann zum jeweils anderen Admin Client transferieren.

2.2.2. Gegenzertifkate erzeugen

Im Domino Administrator unter “Zertifizierung” → “Gegenzertifizieren… “ die Zertifizierer ID-Datei auswählen und das Kennwort eingeben

Open

Anschließend die übertragene Safe-ID Datei auswählen

Beim Subjekt dann den Server/Administrator auswählen und auf “Gegenzertifizieren” klicken

→ Für alle übertragenen Safe-IDs wiederholen.

→ Auf beiden Systemen durchführen

Im Anschluss sollten die Gegenzertifikate in der names.nsf vorhanden sein. Hier Sicht Kundenserver:

2.3. Zugriffsrechte auf Server

2.3.1. In Zugriffsgruppe eintragen

Auf dem Kundensystem dem stanoc-Server Zugriffsrechte geben: Dazu z.B. den stanoc-Server in die Gruppe “OtherDomainServers” eintragen …

2.3.2. ACL der names.nsf

… und in der ACL der names.nsf (dort sollte die Gruppe bereits enthalten sein) …

2.3.3. Trusted Server

… und im Serverdokument hinterlegen(Sicherheit → Vertrauenswürdige Server):

2.4. Zugriffsrechte auf Datenbanken auf dem Kundensystem

Die ACL der entsprechenden Datenbanken um den stanoc-Server und den stanoc Admin erweitern und die korrekten Rechte geben(abhängig von der Applikation).

Um Design auszulesen (Analytics / Shift / Web Access) wird mindestens das Zugriffsrecht “Entwickler” benötigt. “Leser” reicht nicht aus.

2.5. Verbindungsdokument zum Kundenserver hinzufügen

Im stanoc Server ein Verbindungsdokument anlegen(keine Replikation, kein Mailrouting, kein Zeitplan), das die Verbindung zum Kundensystem ermöglicht:

2.6. Public Key des Kundenservers im stanoc Server bekannt machen

Falls es beim trace vom stanoc Server aus zu einem Fehler Unable to connect: Your public key was not found in the Domino Directory kommt …

… muss man dem stanoc Server das Serverdokument des Kundensystem bereitstellen.

Option 1(die einfachste/schnellste Methode): Eine unverschlüsselte lokale Transfer-Datenbank mit dem Serverdokument des Kundenservers vom Kunden zu stanoc übertragen und dann direkt in die names.nsf des stanoc Servers übertragen. Bietet sich an, wenn sich am Public Key des Kundenservers während des Projekts nicht ändern und auch sonst keine Daten aus der Kunden-names.nsf als Authentifizierungsmethode benötigt werden

Option 2(aufwändige Methode): Eine Replik der Kunden-names.nsf auf dem stanoc Server erstellen (ggf. erst per unverschlüsselter lokaler Replik übertragen) und per Directory Assistance einbinden.

Nachdem der Public Key bekannt gemacht wurde, sollte der Trace funktionieren:

2.7. Zugriff per stanoc Administrator User

Beim ersten Zugriff auf den Kundenserver wird eine Aufforderung der Erstellung eines Gegenzertifikats angezeigt:

→ Diese bestätigen.

Ggf. wäre es auch sinnvoll, Verbindungsdokumente in der lokalen names.nsf des Administrators anzulegen.