Ich hatte mir ja eigentlich vorgenommen, den heutigen Blog-Artikel ein bisschen an das Ergebnis des gestrigen Halbfinals anzupassen und hatte mir schon Überschriften wie "3:1 für den Traveler in der eigenen Domino Domäne - die Vor- und Nachteile noch einmal in Zeitlupe" zurecht gelegt. Aber 7:1... soooo viele Vorteile gibt's dafür nun auch wieder nicht! 
Nun ja, es wird bestimmt auch ohne direkten Bezug zur WM klappen:
Im folgenden Artikel werde ich euch also das Konzept des IBM Traveler Servers in einer eigenen Domino Domäne erläutern. Das Konzept hat den Ursprung in den kurzen Updateintervallen für den Traveler Server, bedingt durch die stetige Weiterentwicklung der Smartphones. Um hier Schritt zu halten, muss man entweder seine komplette Domino Infrastruktur stetig aktuell halten oder man macht sich davon unabhängig und entkoppelt den Traveler Server von der vorhandenen Domino Infrastruktur.
Die Entkopplung ermöglicht es uns, den Traveler Server unabhängig von der restlichen Domino Infrastruktur immer auf die aktuellste Softwareversion zu bringen. Dadurch laufen wir (fast) nicht mehr Gefahr,
- dass Mitarbeiter ein neues Smartphone bekommen, welches womöglich nicht von unserer Traveler Version unterstützt wird.
- dass uns ein Software Update auf einem vorhandenen Smartphone die Traveler Kompatibilität nimmt.
Mögliche Fehler und Bugs können so natürlich auch zeitnah gepatcht werden.
Für die Entkopplung gibt es zwei Umsetzungsvarianten, die abhängig von der vorhandenen Domino Infrastruktur unterschiedliche Vorteile haben:
Variante 1: Traveler Server in eigener Domino Domäne und Organisation
Bei dieser Variante ist der Traveler Server in einer eigenen Organisation und Domäne. Dadurch haben wir maximale Sicherheit, was allerdings einen etwas höheren Einrichtungsaufwand bedeutet.
Abb. 1: Der Traveler Server ist in seiner eigenen Organisation und Domäne unabhängig von der restlichen Domino Infrastruktur installiert.
Der Traveler Server kann immer aktualisiert werden
Da sich der Traveler Server in einer eigenen Domäne befindet, kann er unabhängig von der restlichen Domino Infrastruktur aktuell gehalten werden. Damit sind Konstellationen wie eine 8.5.3 Domino Server Infrastruktur in Kombination mit einem 9.0.1 Traveler Server ohne Einschränkungen möglich.
Mehr Sicherheit
Der Traveler Server sollte unbedingt in der DMZ des Netzwerkes stehen, da er einen Service ins Internet anbietet. Mit der DMZ wird der Server auf Netzwerkebene von dem Intranet abgeschottet, auf Domino Ebene schaffen wir das durch eine eigene Domino Organisation und haben so eine weitere Sicherheitsebene, da der Traveler Server nur sehr limitierten Zugriff auf die bereits bestehende Organisation der restlichen Domino Infrastruktur hat.
Sind in dieser Konstellation verschlüsselte E-Mails möglich?
Ja! Trotz getrennter Organisationen ist es möglich, verschlüsselte E-Mails über den Traveler zu lesen und zu schreiben. Dazu müssen die Notes ID Dateien der Benutzer in den Postfächern hinterlegt werden. Für Details verweise ich auf den Blogeintrag von Stephen Bailey zu dem Thema. Falls diese Lösung für euer Unternehmen zu aufwändig ist, ihr aber auf die Verschlüsselung von E-Mails nicht verzichten wollt, solltet ihr euch alternativ die zweite Umsetzungsvariante anschauen.
Voraussetzungen:
- Netzwerkkonnektivität zwischen dem Traveler Server und den Mailservern über den Port 1352 (NRPC)
- Gegenzertifikate zwischen der Traveler Server ID und der Organisation der Mailserver
- Einbindung des Adressbuchs der Mailserver via Directory Assistance auf den Traveler Server
- Zugriffsberechtigung des Traveler Servers auf die Mailserver sowie Editor-Rechte auf das Adressbuch der Mailserver
- Manager-Rechte auf die Postfächer der Traveler Benutzer für den Traveler Server
- Notes ID in den Postfächern der Traveler Benutzer (Optional, aber zum Lesen von verschlüsselten E-Mails notwendig)
Variante 2: Traveler Server in eigener Domino Domäne und vorhandener Organisation
Bei dieser Variante ist der Traveler Server in der bestehenden Domino Organisation und in einer eigenen Domäne installiert. Dadurch erkaufen wir uns die weniger aufwändige Einrichtung, gerade wenn E-Mail-Verschlüsslung via Traveler gefordert ist, mit einer etwas verminderten Sicherheit. Der Vorteil der problemlosen Aktualisierbarkeit bleibt erhalten.
Abb. 2: Der Traveler Server ist weiterhin in der Organisation des Unternehmens installiert – hier aber in einer eigenen Domäne.
Unterschiede zu Variante 1
- Der Traveler Server benötigt keine Gegenzertifikate zur bestehenden Organisation, da er Teil dieser ist.
- Damit über den Traveler Server verschlüsselte E-Mails gelesen und geschrieben werden können, müssen die Notes ID Dateien der Benutzer lediglich im IBM ID Vault liegen und der Traveler Server muss Zugriff auf die ID Vault Datenbank haben.
- Auf Domino-Ebene findet keine Trennung zwischen Intranet und DMZ statt.
Generell empfehlen wir unseren Kunden die Variante 1 aufgrund der höheren Sicherheit. Aber natürlich hat Variante 2 auch ihre Vor- und Nachteile. Die Frage, welche Variante letztendlich für euch die beste ist, können wir gerne in den Kommentaren diskutieren ...
... genauso wie die Frage nach dem besseren Endgegner am Sonntag: Niederlande oder Argentinien??
In diesem Sinne: Fiiiiinaalee!!