smis_secure mail in der srg / testbericht situationen / Dok.-Nr: Version: 2.2 TBS.008 Status: Klassifizierung: Autor: Verteiler: Final Erik Mulder, Thanh Diep Erik Mulder, Thanh Diep
Testbericht Situationen, Seite 2 / 236 Änderungskontrolle Version Datum Name Bemerkungen 1.0 11.11.2002 EM; TD 1. Entwurf 1.1 14.11.2002 EM; TD Einfügen der Situation 2 1.2 21.11.2002 EM; TD Anpassung der Situationen 1.3 27.11.2002 EM; TD Komplettierung bis Situation 2 1.4 28.11.2002 EM; TD Einfügen der Situation 3 und 4 2.0 02.12.2002 EM; TD Überarbeitung des Dokuments 2.1 06.12.2002 EM; TD Einfügen der Testfallbeschreibungen 2.2 11.12.2002 EM; TD Überarbeitung, Fertigstellen
Testbericht Situationen, Seite 3 / 236 Das Ziel dieses Projektes ist eine Umgebung bereitzustellen, wo e-mails sicher übertragen werden können. Das heisst, die e-mails werden signiert, damit der Absender eindeutig identifiziert werden kann, und verschlüsselt, damit kein anderer als der Empfänger die Nachricht betrachten kann. Dies wird erreicht, indem Sender sowie Empfänger ein Schlüsselpaar, bestehend aus einem public und einem private Key, ausgestellt wird. Mit Hilfe des eigenen private Keys, der nur privat zugänglich ist, können e-mail signiert werden. Mit Hilfe des public Keys des Empfängers, der für jeden zugänglich ist, können e-mails verschlüsselt werden. Die Signierung bzw. die Verschlüsselung kann nur mit dem entsprechenden Gegenstück des Schlüsselpaares verifiziert bzw. aufgehoben werden. Weiter wird der public Key mit einem Zertifikat authentifiziert, um diesen Key einem bestimmten User zuzuordnen. Unsere Lösung soll Schritt für Schritt die Realisierung einer PKI (Public Key Infrastructure) in einer Windows Umgebung beinhalten. Eine PKI beinhaltet die Erstellung und Verwaltung von Zertifikaten und dem dazugehörenden Schlüsselpaar. Die Lösung soll zudem die automatische Publizierung dieser Zertifikate innerhalb einer Unternehmung in einem Unternehmungsweiten Adressbuch ermöglichen. Damit die Anforderungen erfüllt werden, ist eine Reihe von Tests durchgeführt worden. Die Testbeschreibungen sowie die Resultate und Erkenntnisse dieser Tests sind in diesem Dokument festgehalten.
Testbericht Situationen, Seite 4 / 236 Inhaltsverzeichnis 1 Einleitung... 11 1.1 Zweck des Dokumentes... 11 1.2 Bemerkungen... 11 1.3 Referenzierte Dokumente... 12 2 Überblick... 13 2.1 Ziel... 13 2.2 Testumgebung... 13 2.3 Infrastruktur... 14 2.4 Testfälle... 15 2.5 Gesamtvorgehen... 18 3 Aufsetzen der Maschinen... 19 3.1 Ziel dieses Kapitels... 19 3.2 Vorgehen... 20 3.3 Basic Image des Servers Mainsmis... 22 3.3.1 Windows 2000 Server... 22 3.3.2 Updates... 23 3.3.3 Zusätzliche Software... 23 3.3.4 TCP/IP Einstellungen... 24 3.3.5 Zusammenfassung und Image... 24 3.4 Basic Image des Servers Celerina... 25 3.4.1 Windows 2000 Server... 25 3.4.2 TCP/IP Einstellungen... 26 3.4.3 Zusammenfassung und Image... 26 3.5 Advanced Image des Servers Mainsmis Part 1... 27 3.5.1 DNS Vorbereitungen... 27 3.5.2 Active Directory... 28 3.5.3 DNS Konfiguration... 37 3.6 Advanced Image des Servers Celerina Part 1... 40 3.6.1 DNS Vorbereitungen... 40 3.6.2 Zonentransfer... 41
Testbericht Situationen, Seite 5 / 236 3.6.3 Active Directory... 44 3.6.4 DNS Konfiguration... 52 3.7 Advanced Image des Servers Mainsmis Part 2... 55 3.7.1 Zonentransfer... 55 3.7.2 Zusammenfassung und Image... 57 3.8 Advanced Image des Servers Celerina Part 2... 58 3.8.1 Global Catalog Server... 58 3.8.2 Zusammenfassung und Image... 59 3.9 Image des Clients... 60 3.9.1 Windows 2000 Professional... 60 3.9.2 TCP/IP Einstellungen... 60 3.9.3 Updates... 60 3.9.4 Zusätzliche Software... 61 3.9.5 Zusammenfassung und Image... 61 3.10 Zustand des Systems nach dem Aufsetzen... 62 4 Testfälle und Berichte Situation 1... 63 4.1 Einleitung und Erklärungen... 63 4.1.1 Beschreibung der Testsituation 1... 63 4.1.2 Testfälle... 64 4.1.2.1 Enterprise Solution... 64 4.1.2.2 Stand-alone Solution... 65 4.1.3 Benötigte Infrastruktur... 66 4.1.4 Vorgehen... 67 4.2 Vorbereitung... 68 4.2.1 Server Mainsmis... 68 4.2.1.1 Advanced Image laden... 68 4.2.1.2 User in Active Directory eintragen... 68 4.2.1.3 Typical Install des Exchanges... 68 4.2.1.4 Connectors... 70 4.2.1.5 Service Pack / Updates... 71 4.2.2 Clients... 71 4.3 Enterprise Solution... 72 4.3.1 CA und KMS - Testfall 1.1.1... 72 4.3.1.1 Vorgehen... 72 4.3.1.2 Aufsetzen einer Enterprise CA... 72 4.3.1.3 CA Installation verifizieren... 78 4.3.1.4 Verfallsdatum des CA Zertifikates... 79 4.3.1.5 Policies einfügen... 80 4.3.1.6 Installation eines Key Management Services (KMS)... 81 4.3.1.7 Zusammenfassung... 83 4.3.2 Enrollment und Token - Testfall 1.1.2... 84 4.3.2.1 Vorgehen... 84 4.3.2.2 Theorie... 84
Testbericht Situationen, Seite 6 / 236 4.3.2.3 Enrollment mit Tokenübergabe auf Disk oder Papier... 85 4.3.2.4 Enrollment mit Tokenübergabe per mail... 86 4.3.2.5 Start des Enrollments... 87 4.3.2.6 Erster Start des Outlooks... 90 4.3.2.7 Anfordern eines Zertifikats... 92 4.3.2.8 Installieren des Zertifikats... 95 4.3.2.9 Erkenntnisse... 98 4.3.3 Signiertes Mail - Testfall 1.1.3... 99 4.3.3.1 e-mail senden... 99 4.3.3.2 e-mail empfangen...100 4.3.3.3 Erkenntnisse...100 4.3.4 Verschlüsseltes Mail Testfall 1.1.4...101 4.3.4.1 Enrollment für tata...101 4.3.4.2 e-mail senden...102 4.3.4.3 e-mail empfangen...102 4.3.4.4 Erkenntnisse...102 4.3.5 Export/Import private Key - Testfall 1.1.5...103 4.3.5.1 Theorie...103 4.3.5.2 Private Key exportieren...104 4.3.5.3 Private Key importieren...105 4.3.5.4 Erkenntnisse...106 4.3.6 Schlüsselgenerierung - Testfall 1.1.6...107 4.3.6.1 Theorie...107 4.3.6.2 Erkenntnisse...107 4.3.7 Zertifikats-Publizierung - Testfall 1.1.7...108 4.3.7.1 Publizierung der Zertifikate...108 4.3.7.2 Betrachtung der Zertifikate...108 4.3.7.3 CA Zertifikat...110 4.3.7.4 Erkenntnisse...111 4.3.8 CRL - Testfall 1.1.8...112 4.3.8.1 Theorie...112 4.3.8.2 Locations der CRL...112 4.3.8.3 Automatische Publizierung...113 4.3.8.4 Manuelle Publizierung...114 4.3.8.5 Bezug und Betrachtung der CRL...116 4.3.8.6 Erkenntnisse...118 4.3.9 Policies und Extensions - Testfall 1.1.9...119 4.3.9.1 Policies...119 4.3.9.2 Extensions Theorie...121 4.3.9.3 Windows 2000 PKI Extensions...124 4.3.10 Expiration eines Zertifikats - Testfall 1.1.10...130 4.3.10.1 CA Zertifikat expired, Zeitdifferenz Server/Client...130 4.3.10.2 CA Zertifikat expired, keine Zeitdifferenz Server/Client...133 4.3.10.3 Falsche Systemzeit Client...133 4.3.10.4 CA Zertifikat erneuern...133 4.3.10.5 User Zertifikat erneuern...134
Testbericht Situationen, Seite 7 / 236 4.4 Stand-alone Solution... 136 4.4.1 CA und KMS - Testfall 1.2.1...136 4.4.1.1 Vorgehen...136 4.4.1.2 Aufsetzen einer Stand-alone CA...136 4.4.1.3 CA Installation verifizieren...139 4.4.1.4 Verfallsdatum des CA Zertifikates...139 4.4.1.5 Installation eines Key Management Services (KMS)...139 4.4.1.6 Zusammenfassung...139 4.4.2 Zertifikat via Browser Testfall 1.2.2...140 4.4.2.1 Vorgehen...140 4.4.2.2 Bezug Zertifikat mit Mozilla...141 4.4.2.3 Installation Zertifikat in Mozilla...151 4.4.2.4 Kopieren des Zertifikats und private Key auf Maschine...158 4.4.2.5 Bezug Zertifikat mit Internet Explorer...162 4.4.2.6 Erkenntnisse...166 4.4.3 Signiertes Mail - Testfall 1.2.3...167 4.4.3.1 e-mail senden...167 4.4.3.2 e-mail empfangen...168 4.4.3.3 Erkenntnisse...169 4.4.4 Verschlüsseltes Mail Testfall 1.2.4...170 4.4.4.1 Enrollment für tata...170 4.4.4.2 e-mail senden...170 4.4.4.3 e-mail empfangen...170 4.4.4.4 Erkenntnisse...170 4.4.5 Export/Import private Key - Testfall 1.2.5...171 4.4.6 Schlüsselgenerierung - Testfall 1.2.6...172 4.4.7 Zertifikats-Publizierung - Testfall 1.2.7...173 4.4.7.1 Publizierung im AD mit einer Stand-alone CA...173 4.4.7.2 Publizierung der User-Zertifikaten im File system...177 4.4.7.3 Erkenntnisse...177 4.4.8 CRL - Testfall 1.2.8...178 4.4.8.1 Locations der CRL...178 4.4.8.2 Revoke eines Zertifikats...179 4.4.8.3 Publizieren der CRL...179 4.4.8.4 Bezug der CRL...180 4.5 Erkenntnisse der Situation 1... 183 5 Testfälle und Berichte Situation 2...185 5.1 Einleitung und Erklärungen... 185 5.1.1 Beschreibung der Testsituation 1...185 5.1.2 Testfälle...186 5.1.3 Benötigte Infrastruktur...187 5.1.4 Vorgehen...188
Testbericht Situationen, Seite 8 / 236 5.2 Vorbereitung... 189 5.2.1 Server Mainsmis...189 5.2.1.1 Forest Preparation for Exchange...189 5.2.1.2 Domain Preparation for Exchange...191 5.2.1.3 Typical Install of Exchange...191 5.2.1.4 Connectors...191 5.2.2 Server Celerina...192 5.2.2.1 Domain Preparation for Exchange...192 5.2.2.2 Typical Install of Exchange...192 5.2.2.3 Connectors...194 5.2.3 Clients...194 5.3 Trusts und Interconnection Testfall 2.1... 195 5.3.1 TCP/IP Einstellungen, DNS und Zonentransfer...195 5.3.2 Trusts zwischen Active Directories...195 5.3.2.1 Theorie...195 5.3.2.2 Verifizieren existierender Trusts...196 5.3.2.3 Erstellen von Trusts...197 5.4 CA und KMS - Testfall 2.2... 200 5.5 Bezug Zertifikat in pkiad1 - Testfall 2.3... 200 5.5.1 Bezug des Zertifikats...200 5.5.2 Global Addressbook...200 5.5.3 Global Catalog Server...200 5.6 Bezug Zertifikat (pkiad2) - Testfall 2.4... 201 5.6.1 KMS Enrollment...201 5.6.1.1 Neuer KMS Administrator...201 5.6.1.2 Global Catalog Server auf Celerina starten...202 5.6.2 Web Enrollment...204 5.6.3 Erkenntnisse...205 5.7 CRL - Testfall 2.5... 206 5.8 Erkenntnisse der Situation 2... 207 6 Testfälle und Berichte Situation 3...209 6.1 Einleitung und Erklärungen... 209 6.1.1 Beschreibung der Testsituation 1...209 6.1.2 Testfälle...210 6.1.3 Benötigte Infrastruktur...211 6.1.4 Vorgehen...212 6.2 Infrastruktur überprüfen... 213 6.3 Erkenntnisse der Situation 3... 213
Testbericht Situationen, Seite 9 / 236 7 Testfälle und Berichte Situation 4...215 7.1 Einleitung und Erklärungen... 215 7.1.1 Beschreibung der Testsituation 1...215 7.1.2 Testfälle...216 7.1.3 Benötigte Infrastruktur...217 7.1.4 Vorgehen...218 7.2 Infrastruktur überprüfen... 219 7.3 CA Testfall 4.1... 220 7.3.1 Rechtenvergabe...220 7.3.2 Subordinate CA Installation...223 7.4 Kontakt Testfall 4.2... 226 7.4.1 Erstellen eines Kontakts...226 7.4.2 Unternehmensweite Adressliste erstellen...229 7.5 Erkenntnisse der Situation 4... 231 8 Schlusserkenntnisse der Testfälle...233 9 Literaturverzeichnis...235
Testbericht Situationen, Seite 10 / 236 Tabellenverzeichnis Tabelle 1: Legende zu den Grafiken der Testsituationen...16 Tabelle 2: Spezifikation der Testsituationen...17 Tabelle 3: Vorgehen Basic Image der Maschinen...20 Tabelle 4: Vorgehen Advanced Image der Maschinen...21 Tabelle 5: Testfälle der Situation 1 mit einer Enterprise CA...64 Tabelle 6: Testfälle der Situation 1 mit einer Stand-alone CA...65 Tabelle 7: Vorgehen Situation 1...67 Tabelle 8: Vorgehen Testfall 1.1.1 CA und KMS, Enterprise Solution...72 Tabelle 9: Vorgehen Testfall 1.1.2 Enrollment und Token, Enterprise Solution...84 Tabelle 10: Felder von X.509 V1...121 Tabelle 11: Felder des Enterprise Root CA Zertifikats...125 Tabelle 12: Felder des Stand-alone Subordinate Zertifikats...127 Tabelle 13: Felder des User Zertifikats...129 Tabelle 14: Vorgehen Testfall 1.2.1 CA und KMS, Stand-alone Solution...136 Tabelle 15: Vorgehen Testfall 1.2.2 Zertifikat via Browser, Stand-alone Solution...140 Tabelle 16: Wichtigste Unterschiede Enterprise CA Stand-alone CA...183 Tabelle 17: Testfälle der Situation 2...186 Tabelle 18: Vorgehen Situation 2...188 Tabelle 19: Testfälle der Situation 3...210 Tabelle 20: Vorgehen Situation 3...212 Tabelle 21: Testfälle der Situation 4...216 Tabelle 22: Vorgehen Situation 4...218 Tabelle 23: Erkenntnisse aller Situationen...233 Tabelle 24: Erkenntnisse betreffend CA s...234
Testbericht Situationen, Seite 11 / 236 1 Einleitung 1.1 Zweck des Dokumentes Dieses Dokument soll die Resultate und Erkenntnisse der Testfälle in den Testsituationen 1 bis 4 festhalten. Die Testfälle sind in Kapitel 2.4, Seite 15 festgehalten. Basierend auf diesem Dokument soll danach das Anwendungshandbuch erstellt werden. 1.2 Bemerkungen Bei den Betriebssystemen (Server und Client) sowie allen anderen Software-Produkten handelt es sich um englische Versionen. Eventuelle Auszüge sind deswegen auf englisch geschrieben. Das gleiche gilt für alle Screenshots. Die Screenshots sollen als Hilfe dienen. Die Angaben die darin gemacht werden, treffen teilweise nur für unsere Installation/Infrastruktur zu oder sind erfunden, und müssen nicht in jedem Fall mit ihrer Installation übereinstimmen. Damit sind insbesondere IP- Adressen und Namen gemeint. Für die eigene Installation sind die nötigen Angaben deshalb an ihre Umgebung/Infrastruktur anzupassen.
Testbericht Situationen, Seite 12 / 236 1.3 Referenzierte Dokumente [1] HERMES, Ausgabe 95 [2] Advanced Security in Exchange 2000, Part 1 to 3 Windows &.NET Magazine Network, www.winnetmag.com - ase_pt1.pdf - ase_pt2.pdf - ase_pt3.pdf [3] Windows 2000 Server and KMS interoperability Microsoft White Paper - w2k_server_kms.pdf [4] Windows 2000 CA configuration to publish Certificates in AD of trusted domain Microsoft Knowledge Base Article 281271 - mkba_281271.pdf [5] How to: Create or move a Global Catalog in Windows 2000 Microsoft Knowledge Base Article 313994 - mkba_313994.pdf [6] XADM: Advanced Security Revocation Not Immediate Microsoft Knowledge Base Article 181450 - mkba_181450.pdf
Testbericht Situationen, Seite 13 / 236 2 Überblick 2.1 Ziel Das Ziel ist eine Musterlösung für eine PKI Umgebung zu erstellen. Mit dieser PKI Umgebung soll ein sicherer e-mail Verkehr gewährleistet werden. Das heisst, die e-mails können signiert und verschlüsselt übertragen werden, wobei das eine das andere nicht voraussetzt. Um dieses Ziel zu erreichen führen wir eine Reihe von Tests durch, um herauszufinden, wie eine PKI aufgebaut wird und wie sie erfolgreich eingesetzt werden kann. Die PKI muss verschiedene Anforderungen erfüllen. Mitarbeiter (interne und externe User, mit einem Active Directory Account) sollen ein Zertifikat beziehen können Kunden (Customer, vorerst ohne einem Active Directory Account) sollen ein Zertifikat beziehen können Alle Mitarbeiter verfügen über ein einziges globales Adressbuch In diesem globalen Adressbuch werden die Zertifikate der Mitarbeiter automatisch publiziert Zwischen den internen, externen Usern und den Customers ist ein signierter und/oder verschlüsselter e-mail Verkehr möglich In diesem Dokument sollen alle Erkenntnisse und Resultate dieser Tests festgehalten werden. Basierend auf diesem Dokument soll danach das Anwendungshandbuch erstellt werden. 2.2 Testumgebung Um gewisse Annahmen treffen zu können, dachten wir uns eine grössere Firma aus. Diese Annahmen halfen uns bei Entscheidungen. Zudem konnten wir unsere Testreihen mehr spezifizieren. Unsere erfundene Unternehmung beschäftigt mindestens 500 Mitarbeiter, die auf mehrere Abteilungen verteilt sind. Jede Abteilung besitzt ein eigenes Active Directory, wo die Mitarbeiter der Abteilung registriert sind, und wird unabhängig von den anderen Abteilungen verwaltet. Die Domains sind in einem Forest platziert. Dieser Forest wird von dem Domain Controller erstellt, der als erster eingerichtet wird. Indem alle nachfolgenden Domain Controller in diesen Forest platziert werden, wird automatisch ein Vertrauen zwischen den Domain Controllern und somit auch den Active Directories aufgebaut. Jede Abteilung hat ihren eigenen Exchange Server, worauf sich die Mailboxen der Mitarbeiter befinden. Indem aber nur eine einzige Exchange Organisation erstellt wird, haben alle Mitarbeiter, ganz gleich aus welcher Abteilung, die gleiche e-mail Domain (zum Beispiel @firma.ch).
Testbericht Situationen, Seite 14 / 236 Die Customer können ins Active Directory eingetragen werden. Entweder als normale User oder nur als Kontakt. Dies kann je nach Firmenpolitik definiert werden. 2.3 Infrastruktur Für die Durchführung unserer Tests stand uns folgendes Netzwerk zur Verfügung. Dieses Netzwerk eignet sich sicher nicht dafür, um ein die Domain Architektur einer grossen Firma nachzubilden. Dies ist für unsere Testreihen aber auch nicht nötig. Es reicht, wenn wir über zwei Server verfügen, damit wir die Möglichkeit haben, zwei Domains mit je einem Active Directory zu erstellen. Zudem verfügen wir über zwei Clients. Unser Netzwerk besteht aus den Maschinen Server Mainsmis, Hauptserver, 147.87.70.6 Server Celerina, zweiter Server, 147.87.70.119 Client Lapunt, 147.87.70.103 Client Spina, 147.87.70.115 Damit das Dokument einfach und verständlich bleibt, haben wir in allen nachfolgenden Kapiteln die Namen der Maschinen verwendet, um diese zu bezeichnen.
Testbericht Situationen, Seite 15 / 236 2.4 Testfälle Aufgrund der Annahmen, die wir betreffend unserer fiktiven Unternehmung getroffen haben, entschieden wir uns für vier Testsituationen, die Schritt für Schritt bearbeitet werden. Diese sind nachfolgend grafisch dargestellt.
Testbericht Situationen, Seite 16 / 236 Element Beschreibung User oder Customer Windows 2000 Server mit Active Directory Exchange 2000 Server Windows 2000 CA Internet 1. - 4. Kommunikation zwischen zwei Punkten (Testsituationen 1 bis 4) Registriert in AD Logisches System, Gruppe von Benutzern Tabelle 1: Legende zu den Grafiken der Testsituationen
Testbericht Situationen, Seite 17 / 236 Nachfolgend sind die vier Testsituationen, die in der Grafik mit Pfeilen dargestellt sind, kurz beschrieben. Es handelt sich dabei nur um eine grobe Beschreibung. Eine detailliertere Beschreibung entnehmen sie bitte den einzelnen Unterkapiteln, in denen auch das Vorgehen sowie die Resultate und Erkenntnisse der Situationen festgehalten sind. Testsituation 1. Mail inside AD Spezifizierung Die User sind im gleichen Active Directory registriert Die User besitzen ein Exchange Mail Konto Die User erscheinen im gleichen Adressbuch Ausgestellte Zertifikate werden automatisch im Adressbuch veröffentlicht Signierter/Verschlüsselter e-mail Verkehr 2. Mail AD - AD Die User sind in verschiedenen Active Directories registriert Die User besitzen ein Exchange Mail Konto auf verschiedenen Exchange Servern Die User erscheinen im gleichen globalen Adressbuch Ausgestellte Zertifikate werden automatisch im globalen Adressbuch veröffentlicht Signierter/Verschlüsselter e-mail Verkehr 3. Mail Extern Intern Die User sind in verschiedenen Active Directories registriert Der externe User arbeitet ausserhalb der Unternehmung Die User besitzen ein Exchange Mail Konto auf verschiedenen Exchange Servern Die User erscheinen im gleichen globalen Adressbuch Ausgestellte Zertifikate werden automatisch im Adressbuch veröffentlicht Signierter/Verschlüsselter e-mail Verkehr 4. Mail Customers - Intern Der interne User ist in einem Active Directory registriert Der Customer ist nicht in einem Active Directory als normaler User registriert, allenfalls als Kontakt Der interne User besitzt ein Exchange Mail Konto Der User und der Customer können im gleichen Adressbuch erscheinen An den internen User ausgestellte Zertifikate werden automatisch im Adressbuch veröffentlicht An den Customer ausgestellte Zertifikate können automatisch im Adressbuch veröffentlicht werden, ist aber von Microsoft defaultmässig nicht vorgesehen Signierter/Verschlüsselter e-mail Verkehr Tabelle 2: Spezifikation der Testsituationen
Testbericht Situationen, Seite 18 / 236 2.5 Gesamtvorgehen Die Testsituationen wurden der Reihe nach durchgeführt. Die Erkenntnisse einer Situation flossen in die darauffolgenden ein. Dies erlaubte uns eine komponentenartige Entwicklung. Die schlussendliche Lösung kann dann erstellt werden, indem diese Komponenten/Teilergebnisse zusammengefügt werden. Nachfolgend ein Überblick über das gesamte Vorgehen während dieser Phase des Projektes. Aufsetzen der Maschinen, erstellen einer Basis o Betriebssystem Windows 2000 o Active Directory o Sicherstellen der Netzwerkeinstellungen der Server und der Clients Tests der Situation 1 durchführen o Exchange installieren, für internen Gebrauch o PKI einrichten o Bezug und Verwaltung Zertifikat o Sicherer e-mail Verkehr zwischen User eines AD s o Erkenntnisse festhalten Tests der Situation 2 durchführen o Zweiten Server aufsetzen o Zweiten Exchange Server installieren, für internen Gebrauch o PKI einrichten o Bezug und Verwaltung Zertifikat o Sicherer e-mail Verkehr zwischen User verschiedener AD s o Erkenntnisse festhalten Tests der Situation 3 durchführen o Externe User erstellen o Exchange installieren, für internen und externen Gebrauch o PKI einrichten o Bezug und Verwaltung Zertifikat o Sicherer e-mail Verkehr zwischen internen und externen User o Erkenntnisse festhalten Tests der Situation 4 durchführen o Customer eventuell als Kontakt aufnehmen o Exchange installieren, für internen und externen Gebrauch o PKI einrichten o Bezug und Verwaltung Zertifikat o Sicherer e-mail Verkehr zwischen interne User und Customer o Erkenntnisse festhalten Schlussfolgerungen o Zusammenfassung o Erkenntnisse
Testbericht Situationen, Seite 19 / 236 3 Aufsetzen der Maschinen 3.1 Ziel dieses Kapitels Die Server sowie auch die Clients werden in unserem Fall für Testzwecke verwendet. Dabei kann es durchaus vorkommen, das sich die Konfiguration des Systems nach verschiedenen durchgeführten Tests nicht mehr für anderweitige Tests eignet. Um nicht nach jeder Testsituation den Server und die Clients neu aufsetzen zu müssen, haben wir von einem stabilen System mit dem Programm Power Quest Drive Image 5.0 ein Image erstellt, das auf Wunsch neu geladen werden kann. Um auf alle Eventualitäten vorbereitet zu sein, haben wir vom Server zwei Images erstellt (basic und advanced), von den Clients je eines. Auf diese Weise kann relativ schnell ein stabiler Zustand des Systems hergestellt werden. Nachfolgend wird beschrieben, welche Zustände des Systems die Images beinhalten. Am Schluss dieses Kapitels ist ein Netzwerk aufgebaut, dass sich für die kommenden Tests eignet und dank der Images, die wir erstellen, sehr schnell wiederhergestellt werden kann. Es ist jedoch zu erwähnen, das nicht für alle kommenden Tests das gesamte Netzwerk benötigt wird. Testsituation 1 zum Beispiel benötigt den Server Celerina nicht.
Testbericht Situationen, Seite 20 / 236 3.2 Vorgehen Zuerst setzen wir den Server Mainsmis auf. Nachdem das erledigt ist, kann der Celerina Server aufgesetzt werden. Letzterer wird für die erste Testsituation noch nicht gebraucht. Wichtig: Bevor auf Celerina das Active Directory installiert wird, muss das Active Directory auf Mainsmis fertig installiert sein, da dieser Server nebst einer neuen Domain auch den Forest (siehe mehr dazu später) erstellt und verwaltet. Celerina wird als zweiter Server auch eine neue Domain erstellen, wird diesen aber in den nun bereits existierenden Forest platzieren. Bevor auf Mainsmis ein Zonentransfer gemacht werden kann, muss die Domain pkiad2 auf Celerina existieren. Das heisst, der Transfer sollte erst gemacht werden, wenn auf Celerina das Active Directory installiert worden ist. Um den Punkten gerecht zu werden, die unter Wichtig notiert worden sind, wurden die advanced Installationen von Mainsmis und Celerina in jeweils zwei Parts unterteilt. Nachfolgend ist der Vorgang, die beiden Maschinen für das basic und das advanced Image vorzubereiten, tabellarisch dargestellt. Damit soll ersichtlich werden, wo der Vorgang identisch bzw. unterschiedlich ist. Server Mainsmis Server Celerina Basic Image Windows 2000 Server aufsetzen Windows 2000 Server aufsetzen - mit default Einstellungen - mit default Einstellungen - TCP/IP Settings - TCP/IP Settings DNS konfigurieren DNS konfigurieren - preferred DNS: Mainsmis - preferred DNS: Celerina - alternate DNS: Celerina - alternate DNS: Mainsmis Tabelle 3: Vorgehen Basic Image der Maschinen
Testbericht Situationen, Seite 21 / 236 DNS vorbereiten Server Mainsmis Advanced Image Server Celerina Active Directory installieren - Domain Controller für eine neue Domain - neuen Domain Tree erstellen - neuen Forest erstellen DNS konfigurieren - Active Directory integrated - Dynamic updates DNS vorbereiten Zonentransfer - secondary Zone pkiad1 einfügen Active Directory installieren - Domain Controller für eine neue Domain - neuen Domain Tree erstellen - in existierenden Forest platzieren DNS konfigurieren - Active Directory integrated - Dynamic updates Zonentransfer - Secondary Zone pkiad2 einfügen Global Catalog Server - Einrichten Tabelle 4: Vorgehen Advanced Image der Maschinen
Testbericht Situationen, Seite 22 / 236 3.3 Basic Image des Servers Mainsmis Dieses Image wurde mit einem einfachen Windows 2000 System erstellt, damit wir schnell einen Basis-Zustand einrichten konnten. Es eignete sich dafür, ganz neue Situationen auszutesten. Das Image beinhaltet verschiedene Updates und Software, jedoch keine, die den Verlauf folgender Testfälle beeinflussen könnten. 3.3.1 Windows 2000 Server Die Windows 2000 Server Hauptmaschine wird mit nachfolgend beschriebenen Optionen und Eigenschaften aufgesetzt. Name: smis Organization: smis Computername: Mainsmis Bei der Auswahl der Komponenten werden die Default-Einstellungen übernommen. Zusätzlich werden nur die Management and Monitoring Tools, Networking Services und Media Services ausgewählt. Jeweils mit den Default-Einstellungen aller Subkomponenten. Die Netzwerkeinstellungen nehmen wir von Hand vor. Dabei installieren wir zusätzlich zu den Default-Einstellungen, welche uns Microsoft vorschlägt, die Services QoS Network Monitor Driver. In den Properties-Einstellungen des Protokolls TCP/IP geben wir bekannte IP-Adressen bereits an: IP Address: 147.87.70.6 / 24 Gateway Address: 147.87.70.250 / 24 Als preferred DNS Server ist vorzugsweise der eigene anzugeben. Falls eventuelle andere DNS Servers bekannt sind, können diese bereits unter alternate DNS Server angegeben werden. Nach einem Neustart und Beendigung der Installation, erscheint ein Fenster, wo der Server konfiguriert werden kann. Je nachdem ob dieser Server der einzige im Netzwerk ist, oder ob es bereits andere gibt, wird die Option This is the only server in the network oder One or more servers already run in this network gewählt.
Testbericht Situationen, Seite 23 / 236 3.3.2 Updates Nachdem der Server nun soweit fertig installiert ist, empfiehlt es sich, das neueste Service Pack und die zusätzlichen Updates (auch die vom Internet) zu installieren. Dies kann unter Umständen etwas länger dauern, da die Updates nicht alle gleichzeitig installiert werden können, sorgt aber für ein sicheres und stabiles System. Zusätzliche Windows 2000 Komponenten wie das Resource Kit und die Support Tools werden von uns als nächstes installiert. Für das Resource Kit wird die entsprechende CD mit der Software benötigt, da sich diese Komponente nicht auf der Windows 2000 Server CD befindet. 3.3.3 Zusätzliche Software Wenn sich das System nach allen Service Packs und Updates in einem stabilen und aktuellen Zustand befindet, kann wahlweise zusätzliche Software installiert werden. Dabei kann es sich zum Beispiel um Software wie Office Browser Editor Winzip Acrobat Reader SSH Secure Shell Client handeln. Diese Programme und Tools werden heute sehr oft benötigt, und deshalb haben wir uns dafür entschieden, diese jetzt bereits zu installieren.
Testbericht Situationen, Seite 24 / 236 3.3.4 TCP/IP Einstellungen In den TCP/IP Einstellungen wird folgende Konfiguration vorgenommen. Als preferred DNS Server wird der eigene angegeben. Als alternate DNS Server der zweite Server in unserem Netzwerk, also Celerina. Auf diese Weise wird eine DNS Anfrage erst mal von beiden Servern verarbeitet, und erst, wenn beide Server diese Anfrage nicht verarbeiten können, nach aussen weitergeleitet. 3.3.5 Zusammenfassung und Image Das basic Image auf Mainsmis beinhaltet folgende Komponenten und Konfigurationen: Windows 2000 Server Updates Anwendungssoftware TCP/IP Settings Es wurden noch keine Konfigurationen der DNS gemacht. Das Image, das wir nun von diesem System erstellen, eignet sich sehr gut für die Testreihen, bei denen von Grund auf spezielle Konfigurationen, auch im Bereich DNS und Active Directory, nötig sind.
Testbericht Situationen, Seite 25 / 236 3.4 Basic Image des Servers Celerina Dieses Image entspricht ziemlich genau dem basic Image des Mainsmis Servers. Einziger Unterschied sind Namen und IP Adressen, weswegen wir hier nur die Kapitel Windows 2000 Server und TCP/IP Settings erwähnen wollen. Für die anderen nötigen Schritte verweisen wir auf das Kapitel 3.3, Seite 22. 3.4.1 Windows 2000 Server Die zweite Windows 2000 Server Maschine wird mit nachfolgend beschriebenen Optionen und Eigenschaften aufgesetzt. Name: smis Organization: smis Computername: Celerina Bei der Auswahl der Komponenten werden die Default-Einstellungen übernommen. Zusätzlich werden nur die Management and Monitoring Tools, Networking Services und Media Services ausgewählt. Jeweils mit den Default-Einstellungen aller Subkomponenten. Die Netzwerkeinstellungen nehmen wir von Hand vor. Dabei installieren wir zusätzlich zu den Default-Einstellungen, welche uns Microsoft vorschlägt, die Services QoS Network Monitor Driver. In den Properties-Einstellungen des Protokolls TCP/IP geben wir bekannte IP-Adressen bereits an: IP Address: 147.87.70.119 / 24 Gateway Address: 147.87.70.250 / 24 Als preferred DNS Server ist vorzugsweise der eigene anzugeben. Falls eventuelle andere DNS Servers bekannt sind, können diese bereits unter alternate DNS Server angegeben werden. Nach einem Neustart und Beendigung der Installation, erscheint ein Fenster, wo der Server konfiguriert werden kann. Da sich der Server Mainsmis bereits im Netzwerk befindet, muss hier die Option One or more servers already run in this network gewählt werden.
Testbericht Situationen, Seite 26 / 236 3.4.2 TCP/IP Einstellungen In den TCP/IP Einstellungen wird folgende Konfiguration vorgenommen. Als preferred DNS Server wird der eigene angegeben. Als alternate DNS Server der erste Server in unserem Netzwerk, also Mainsmis. 3.4.3 Zusammenfassung und Image Das basic Image auf Celerina beinhaltet folgende Komponenten und Konfigurationen: Windows 2000 Server Updates Anwendungssoftware TCP/IP Settings Es wurden noch keine Konfigurationen der DNS gemacht. Das Image, das wir nun von diesem System erstellen, eignet sich sehr gut für die Testreihen, bei denen von Grund auf spezielle Konfigurationen, auch im Bereich DNS und Active Directory, nötig sind.
Testbericht Situationen, Seite 27 / 236 3.5 Advanced Image des Servers Mainsmis Part 1 Da für die meisten Tests die gleichen Voraussetzungen gelten, das heisst eine Windows 2000 Server Maschine mit Active Directory, wird das System, das für das basic Image erstellt wurde, nun erweitert. Der Zustand, den wir nun erstellen wollen, soll verhindern, dass wir für jede neue Testreihe wieder von Anfang an installieren müssen. Dies ist teilweise nicht vermeidbar (deswegen das basic Image), jedoch können wir für viele Tests von einem erweiterten Zustand, das heisst mit installiertem Active Directory und konfiguriertem DNS, ausgehen. 3.5.1 DNS Vorbereitungen Es wird empfohlen, dieses Kapitel zu überspringen, da diese Konfigurationen auch von der Installationsroutine des Active Directories übernommen werden können. Falls sie jedoch eine spezielle Konfiguration wünschen, können sie diese natürlich vornehmen. Nachfolgend ist beschrieben, wie es in unserem Fall von Hand aussehen würde. Es wird im DNS Fenster eine neue forward lookup Zone mit den Eigenschaften Zone Type: Standard primary Zone Name: pkiad1.ch Zone File: pkiad1.ch.dns erstellt. Entsprechend dazu wird auch die reverse lookup Zone dazu erstellt, und zwar mit den Einstellungen: Zone Type: Standard primary Network ID: 147.87.70 Zone File: 70.87.147.in-addr.arpa.dns Als letztes wird in der forward lookup Zone ein new Host hinzugefügt. Bei diesem Host handelt es sich um den eigenen Server, deswegen werden die folgenden Angaben gemacht: Name: Mainsmis IP: 147.87.70.6 Dieser Host kann mittels eines Pointers automatisch in der reverse lookup Zone eingefügt werden. Falls dies nicht geschieht, kann dieser mit dem Befehl new Pointer in der reverse lookup Zone eingefügt werden.
Testbericht Situationen, Seite 28 / 236 3.5.2 Active Directory Nun wird das Active Directory installiert. Falls sie sich dafür entschieden haben, die DNS Konfiguration von dieser Installationsroutine durchführen zu lassen, empfiehlt es sich, allfällige DNS Einträge und TCP/IP Settings zu löschen. Dazu gehören: forward und reverse lookup zones WINS Server Preferred und alternate DNS Server haben wir im vorherigen Kapitel bereits definiert, und werden hier natürlich nicht wieder entfernt. Mit dem Befehl dcpromo, der unter Start > Run... eingegeben werden kann, wird die Installation gestartet. Bei unserer ersten Installation handelt es sich um einen Domain Controller, der für eine neue Domain zuständig sein wird. Deshalb wählen wir die Option Domain controller for a new domain.
Testbericht Situationen, Seite 29 / 236 Die zu erstellende Domain ist ein neuer Domain Tree. Das heisst, er wird nicht in einen bestehenden Domain Tree eingefügt bzw. an einen angehängt, ist später aber in der Lage, neue Subdomains bei sich aufzunehmen: Create a new domain tree
Testbericht Situationen, Seite 30 / 236 In unserer Unternehmung existiert noch keine Domain, und damit auch noch kein sogenannter Forest. Aus diesem Grund müssen wir mit Create a new Forest of domain trees einen neuen erstellen. Dieser Forest wird von der Maschine verwaltet, die ihn erstellt hat, in unserem Fall Mainsmis.
Testbericht Situationen, Seite 31 / 236 Nachdem wir nun spezifiziert haben wie die neue Domain aussehen soll, muss sie noch einen Namen haben. In unserem Fall heisst sie pkiad1.ch. Dieser Name ist zugleich auch der Name des neuen Forests. Ein NetBIOS Domain Name wird vom Active Directory Setup vorgeschlagen. Dieser kann, wie in unserem Fall PKIAD1, übernommen werden.
Testbericht Situationen, Seite 32 / 236 Database location und Log location können wie vom Setup vorgeschlagen übernommen werden. Je nach Bedürfnis können diese Angaben jedoch abgeändert werden.
Testbericht Situationen, Seite 33 / 236 Der Sysvol Folder beinhaltet eine Kopie aller public Folders dieser Domain. Der Inhalt dieses Ordners wird mit eventuell anderen existierenden Domain Controllers repliziert, das heisst, deren Inhalte werden untereinander ausgetauscht. Falls die DNS zu diesem Zeitpunkt noch nicht konfiguriert worden ist, wird dies dem User mitgeteilt. Es ist auch möglich, das die DNS zu diesem Zeitpunkt nicht richtig konfiguriert ist oder nach irgendwelchen getätigten Änderungen nicht neu gestartet wurde. Je nach Situation kann die untenstehende Meldung anders lauten.
Testbericht Situationen, Seite 34 / 236 Die Installationsroutine fragt nun nach, ob die Konfiguration des DNS automatisch erledigt werden soll. Es empfiehlt sich, hier auf Yes,... zu klicken. Wenn die Umgebung eine reine Windows 2000 Umgebung ist, sollte die Option Permissions compatible only with Windows 2000 servers gewählt werden.
Testbericht Situationen, Seite 35 / 236 Für die Administration des DNS wird ein neuer Administrator-Account eingerichtet. Dieser Account muss mit einem neuen Passwort versehen sein, welches hier definiert wird. In der Zusammenfassung vor der effektiven Installation kann überprüft werden, ob alle Angaben richtig gemacht wurden. Um ein reibungsloses Arbeiten des DNS zu garantieren, sollte der Typ des Domain Controllers auf jeden Fall richtig sein. Dies ist vor allem wichtig, wenn später andere Domain Controllers dazukommen.
Testbericht Situationen, Seite 36 / 236 Nach diesen Schritten ist das Active Directory auf der Maschine installiert. Es müssen keine weiteren Konfigurationen vorgenommen werden.
Testbericht Situationen, Seite 37 / 236 3.5.3 DNS Konfiguration Um ein reibungsloses Arbeiten der DNS zu garantieren, werden noch verschiedene Konfigurationen vorgenommen. Dies ist vor allem in Hinblick auf die Zusammenarbeit mit anderen Domain Controllern, in unserem Fall Celerina, wichtig. Für die forward und reverse lookup Zones erlauben wir dynamische updates. Im DNS Fenster unter Properties der jeweiligen Zone wird aus diesem Grund die Auswahl Allow dynamic updates? auf Yes gesetzt.
Testbericht Situationen, Seite 38 / 236 Der DNS wird danach in das Active Directory integriert. Momentan befindet sich der DNS in der forward und reverse lookup Zone wahrscheinlich noch im primary integrated Zustand. Mit Change... kann der DNS in den Typ Active Directory integrated umgeschaltet werden. Dies muss bei beiden Zonen geschehen. Mit dieser Änderung werden alle Informationen betreffend der Zone in das Active Directory integriert.
Testbericht Situationen, Seite 39 / 236 Zusätzlich sollen in den Properties des Servers (Rechtsklick auf Mainsmis) Forwarders (andere DNS Server) eingetragen werden. Dies stellt sicher, dass alle Anfragen an den DNS, die nicht lokal verarbeitet werden können, weitergeleitet werden an einen anderen DNS Server. An dieser Stelle muss nicht der zweite Server in unserem Netzwerk angegeben werden. Die hier angegeben DNS Server sollen dann zum Zuge kommen, wenn weder der preferred, noch die alternate Server die DNS Anfrage bearbeiten können. Welche DNS Server sie hier angeben können oder müssen, sollte ein Netzwerk Administrator wissen. Nach den Änderungen des DNS sollte dieser neu gestartet werden, damit die Änderungen übernommen werden.
Testbericht Situationen, Seite 40 / 236 3.6 Advanced Image des Servers Celerina Part 1 Abgesehen von den Unterschieden betreffend Namen und IP Adressen, ist der grösste Unterschied zwischen dem Mainsmis und Celerina Server die Tatsache, dass Mainsmis als erster aufgesetzt wurde und als erster eine Domain verwaltet. Das heisst auch, dass der Mainsmis Server einen Forest erstellt hat, in dem er seine Domain als erster platziert. Der Server Celerina erstellt auch eine neue Domain, platziert diese aber im bereits existierenden Forest. Aus diesem Grund gibt es gewisse Unterschiede, wenn es darum geht, das Active Directory zu installieren bzw. die DNS zu konfigurieren. 3.6.1 DNS Vorbereitungen Es wird empfohlen, dieses Kapitel zu überspringen, da diese Konfigurationen auch von der Installationsroutine des Active Directories übernommen werden können. Vor allem in Hinblick auf die Platzierung der neuen Domain in den Forest ist eine automatische Konfiguration von der Installationsroutine sicherlich sehr hilfreich. Falls sie jedoch eine spezielle Konfiguration wünschen, können sie diese natürlich vornehmen. Nachfolgend ist beschrieben, wie es in unserem Fall von Hand aussehen würde. Es wird im DNS Fenster eine neue forward lookup Zone mit den Eigenschaften Zone Type: Standard primary Zone Name: pkiad2.ch Zone File: pkiad2.ch.dns erstellt. Entsprechend dazu wird auch die reverse lookup Zone dazu erstellt, und zwar mit den Einstellungen: Zone Type: Standard primary Network ID: 147.87.70 Zone File: 70.87.147.in-addr.arpa.dns Als letztes wird in der forward lookup Zone ein new Host hinzugefügt. Bei diesem Host handelt es sich um den eigenen Server, deswegen werden die folgenden Angaben gemacht: Name: Celerina IP: 147.87.70.119 Dieser Host kann mittels eines Pointers automatisch in der reverse lookup Zone eingefügt werden. Falls dies nicht geschieht, kann dieser mit dem Befehl new Pointer in der reverse lookup Zone eingefügt werden.
Testbericht Situationen, Seite 41 / 236 3.6.2 Zonentransfer Mit diesem Zonentransfer wird sichergestellt, dass der Domain Controller Celerina die Domain pkiad1.ch, die von Mainsmis verwaltet wird, kennt. Dank dem Zonentransfer erkennt er Mainsmis als Domain Controller der Domain pkiad1.ch. Dies ist wichtig, wenn es nachher darum geht, die neue Domain in den existierenden Forest zu platzieren. Dank dem Zonentransfer erkennt Celerina den Mainsmis Server als Domain Controller der Domain pkiad1.ch und vor allem als Verwalter des Forests pkiad1.ch. Falls dies nämlich nicht der Fall ist, kann Celerina zwar als neuer Domain Controller definiert werden, kann aber nicht in den Forest platziert werden, da Celerina den Verwalter dieses Forests, nämlich Mainsmis, nicht findet. In der forward und reverse lookup Zone wird mit add new Zone... eine Standard secondary Zone erstellt. Beachten sie, dass die Option Active Directory integrated inaktiv ist. Dies ist die logische Konsequenz aus der Tatsache, dass das Active Directory noch nicht installiert wurde.
Testbericht Situationen, Seite 42 / 236 Der Name der neuen secondary Zone soll dem Namen der Zone entsprechen, die man einfügen/transferieren will. Danach muss der Domain Controller der zu transferierenden Zone gewählt werden, in unserem Fall Mainsmis (147.87.70.6).
Testbericht Situationen, Seite 43 / 236 Auch für die Reverse Lookup Zone wird eine secondary Zone eingerichtet. Dabei muss diesmal die Netzwerk ID angegeben werden. Die neuen Zonen, die nun eingefügt werden, sind nur Referenzen auf pkiad1.ch. Wird die Zone pkiad1.ch von Mainsmis verändert, ist diese Änderung auch auf Celerina sichtbar. Nach den vorgenommenen Änderungen muss der DNS neu gestartet werden.
Testbericht Situationen, Seite 44 / 236 3.6.3 Active Directory Nun wird das Active Directory installiert. Falls sie sich dafür entschieden haben, die DNS Konfiguration von dieser Installationsroutine durchführen zu lassen, empfiehlt es sich, allfällige DNS Einträge und TCP/IP Settings zu löschen. Dazu gehören: forward und reverse lookup zones WINS Server Preferred und alternate DNS Server haben wir im vorherigen Kapitel (basic Image) bereits definiert, und werden hier natürlich nicht wieder entfernt. Mit dem Befehl dcpromo, der unter Start > Run... eingegeben werden kann, wird die Installation gestartet. Bei unserer ersten Installation handelt es sich um einen Domain Controller, der für eine neue Domain zuständig sein wird. Deshalb wählen wir die Option Domain controller for a new domain.
Testbericht Situationen, Seite 45 / 236 Die zu erstellende Domain ist ein neuer Domain Tree. Das heisst, er wird nicht in einen bestehenden Domain Tree eingefügt bzw. an einen angehängt, ist später aber in der Lage, neue Subdomains bei sich aufzunehmen: Create a new Domain tree
Testbericht Situationen, Seite 46 / 236 Nun kommt der grosse Unterschied zur Installation des Active Directories auf Mainsmis. Wir erstellen auf Celerina keinen neuen Forest, sondern platzieren den neuen Domain Tree im existierenden Forest. Deswegen wählen wir die Option Place this new Domain tree in an existing forest. Trees, die sich im gleichen Forest befinden, bauen automatisch ein Vertrauen untereinander auf. Dies ist für alle kommenden Tests sehr hilfreich.
Testbericht Situationen, Seite 47 / 236 Um den neuen Domain Tree in einen Forest einzufügen, muss man einen User, der im Forest Administrator-Rechte besitzt, angeben. Dieser User ist in unserem Fall der Administrator der Domain pkiad1. Für den neuen Domain Tree ist der Name anzugeben.
Testbericht Situationen, Seite 48 / 236 Der NetBIOS Name wird vom Setup vorgeschlagen, und kann in den meisten Fällen übernommen werden. Database location und Log location können wie vom Setup vorgeschlagen übernommen werden. Je nach Bedürfnis können diese Angaben jedoch abgeändert werden. Der Sysvol Folder beinhaltet eine Kopie aller public Folders dieser Domain. Der Inhalt dieses Ordners wird mit eventuell anderen existierenden Domain Controllers repliziert, das heisst, deren Inhalte werden untereinander ausgetauscht. Falls die DNS zu diesem Zeitpunkt noch nicht konfiguriert worden ist, wird dies dem User mitgeteilt. Es ist auch möglich, das die DNS zu diesem Zeitpunkt nicht richtig konfiguriert ist oder nach den oben beschriebenen Änderungen nicht neu gestartet wurde. Je nach Situation erscheint eine anders lautende Meldung.
Testbericht Situationen, Seite 49 / 236 Die Installationsroutine fragt nun nach, ob die Konfiguration des DNS automatisch erledigt werden soll. Es empfiehlt sich, hier auf Yes,... zu klicken. Wenn die Umgebung eine reine Windows 2000 Ungebung ist, sollte die Option Permissions compatible only with Windows 2000 servers gewählt werden.
Testbericht Situationen, Seite 50 / 236 Für die Administration des DNS wird ein neuer Administrator-Account eingerichtet. Dieser Account muss mit einem neuen Passwort versehen sein, welches hier definiert wird.
Testbericht Situationen, Seite 51 / 236 Zur Kontrolle kann in der Zusammenfassung überprüft werden, ob der Typ des neuen Domain Controllers richtig gewählt wurde. Falls die Installation nun richtig abgeschlossen wird, existiert zwischen den beiden Domains bereits ein sogenannter Trust. Es wird also automatisch ein Vertrauen zwischen diesen Domains aufgebaut. Dies ist vor allem in Hinblick auf die Zusammenarbeit, auch im Bereich Exchange, sehr nützlich. Nach diesen Schritten ist das Active Directory auf der Maschine installiert. Es müssen keine weiteren Konfigurationen vorgenommen werden.
Testbericht Situationen, Seite 52 / 236 3.6.4 DNS Konfiguration Um ein reibungsloses Arbeiten der DNS zu garantieren, werden noch verschiedene Konfigurationen vorgenommen. Dies ist vor allem in Hinblick auf die Zusammenarbeit mit anderen Domain Controllern, in unserem Fall mit dem Bereits existierenden Domain Controller Mainsmis, wichtig. Für die forward und reverse lookup Zones erlauben wir dynamische updates. Im DNS Fenster unter Properties der jeweiligen Zone wird aus diesem Grund die Auswahl Allow dynamic updates? auf Yes gesetzt.
Testbericht Situationen, Seite 53 / 236 Der DNS wird danach in das Active Directory integriert. Momentan befindet sich der DNS in der forward und reverse lookup Zone wahrscheinlich noch im primary integrated Zustand. Mit Change... kann der DNS in den Typ Active Directory integrated umgeschaltet werden. Dies muss bei beiden Zonen geschehen. Mit dieser Änderung werden alle Informationen betreffend der Zone in das Active Directory integriert.
Testbericht Situationen, Seite 54 / 236 Zusätzlich sollen in den Properties des Servers (Rechtsklick auf Celerina) Forwarders (andere DNS Server) eingetragen werden. Dies stellt sicher, dass alle Anfragen an den DNS, die nicht lokal verarbeitet werden können, weitergeleitet werden an einen anderen DNS Server. An dieser Stelle muss nicht der erste Server in unserem Netzwerk angegeben werden. Die hier angegeben DNS Server sollen dann zum Zuge kommen, wenn weder der preferred, noch die alternate Server die DNS Anfrage bearbeiten können. Welche DNS Server sie hier angeben können oder müssen, sollte ein Netzwerk Administrator wissen. Nach den Änderungen des DNS sollte dieser neu gestartet werden, damit die Änderungen übernommen werden.
Testbericht Situationen, Seite 55 / 236 3.7 Advanced Image des Servers Mainsmis Part 2 3.7.1 Zonentransfer Mit einem Zonentransfer wird sichergestellt, dass die beiden Domain Controllern Mainsmis und Celerina sich gegenseitig besser kennen. Der eine Domain Controller weiss, wie die andere Domain aussieht. Dies ist zum Beispiel wichtig, wenn es darum geht, eine neue Domain in einen existierenden Forest zu platzieren. Ein Zonentransfer kann erst vorgenommen werden, wenn die Zone, die man einfügen will, bereits existiert. Aus diesem Grund musste der Server Celerina als Domain Controller konfiguriert werden und muss nun eine eigene Domain verwalten. In der forward und reverse lookup Zone wird mit add new Zone... eine Standard secondary Zone erstellt.
Testbericht Situationen, Seite 56 / 236 Der Name der neuen secondary Zone soll dem Namen der Zone entsprechen, die man einfügen will. Danach muss der Domain Controller der neuen Zone gewählt werden, in unserem Fall Celerina (147.87.70.6).
Testbericht Situationen, Seite 57 / 236 Auch für die Reverse Lookup Zone wird eine secondary Zone eingerichtet. Dabei muss diesmal die Netzwerk ID angegeben werden. Die neuen Zonen, die nun eingefügt werden, sind nur Referenzen auf pkiad2.ch. Wird die Zone pkiad2.ch von Celerina verändert, ist diese Änderung auch auf Mainsmis sichtbar. Nach den vorgenommenen Änderungen muss der DNS neu gestartet werden. 3.7.2 Zusammenfassung und Image Das advanced Image für Mainsmis beinhaltet folgende Komponenten und Konfigurationen: Windows 2000 Server Updates Anwendungssoftware Active Directory Konfiguriertes DNS Trusts (nach der Active Directory Installation auf Celerina) Global Catalog Server (standardmässig vorhanden) Der DNS wurde entweder von Hand oder von der Installationsroutine des Active Directories konfiguriert. Dieses Image, das wir nun erstellen, eignet sich besonders für die kommenden Testsituationen 1 bis 4. Beinahe alle Tests können von diesem Zustand des Systems aus gestartet werden.
Testbericht Situationen, Seite 58 / 236 3.8 Advanced Image des Servers Celerina Part 2 3.8.1 Global Catalog Server Der Global Catalog besitzt eine komplette Kopie der eigenen Domain mit allen Objekten und deren Attributen, die sich darin befinden. Zusätzlich besitzt der Global Catalog eine Kopie aller Objekte in allen anderen Domains, allerdings nicht mit allen Attributen der Objekte. Auf diese Weise existiert im Forest eine Stelle, wo alle Informationen aller Domains im Forest gespeichert werden. Damit diese Informationen auf dem neusten Stand sind, findet regelmässig eine Replikation mit allen Domains statt. Mit Objekten sind User, Clients und andere Komponenten wie zum Beispiel Netzwerkprinter gemeint. Als Attribut wird eine Eigenschaft von einem Objekt bezeichnet. Ein User namens tata ist zum Beispiel ein Objekt. Die e-mail Adresse tata@pkiad.ch könnte dann ein Attribut von dem Objekt tata sein. Für bestimmte Testsituationen ist es nun nötig, dass sich in beiden Domains ein Global Catalog Server befindet. So ein Server wird standardmässig in der ersten Domain eines Forests eingerichtet, ohne dass der Administrator bzw. derjenige, der die Domain Struktur erstellt hat, etwas unternehmen musste. In unserem Fall heisst das, dass sich dieser Global Catalog Server auf Mainsmis befindet. Wie gesagt, muss aber auch Celerina über einen Global Catalog Server verfügen, um gewisse Voraussetzungen in späteren Testsituationen zu erfüllen. Dazu werden auf Celerina in AD Sites and Services unter Sites > Default-First-Site-Name > Servers > Celerina die Properties von NTDS Settings aufgerufen.