Schlagwort-Archive: DCA

Teil 27b: DirectAccess-Gruppenrichtlinienobjekte vorbereiten

Veröffentlicht am von
Antworten

Der Wizard von DirectAccess erstellt alle notwendigen Einstellungen für die erfolgreiche Verindung in Gruppenrichtlinienobjekten. Weil ich die Sicherheitsfilterung und die verknüpften OUs vorher festlegen möchte, muss ich die DirectAccess-Gruppenrichtlinienobjekte vorbereiten. Diese einfachen Schritte sind schnell erledigt.

DirectAccess-Gruppenrichtlinienobjekte vorbereiten – Schritte:

  • Sicherheitsgruppen in Active Directory erstellen
  • Gruppenrichtlinienobjekte erstellen und verknüpfen

Sicherheitsgruppen in Active Directory erstellen

Wie in Teil 27 beschrieben, werde ich drei Sicherheitsgruppen für DirectAccess erstellen. Damit auf den DirectAccess-Server keine anderen Gruppenrichtlinieneinstellungen wirken, erstelle ich eine eigene OU. Bei dieser OU werde ich dann die Vererbung deaktivieren.

  1. Als Administrator an APP1 anmelden
  2. Server Manager > Tools > Active Directory Users and Computers
  3. intern.einfaches-netzwerk.at\Einfaches-Netzwerk erweitern
  4. In der OU Sicherheitgruppen folgende Gruppen erstellen
    1. DirectAccess Computers
    2. DirectAccess Servers
    3. DirectAccess ISATAP
      DA_ADDS-001
  5. Das Computerobject CLIENT1 zur Gruppe DirectAccess Computers hinzufügen
  6. Das Computerobjekt DA1 zur Gruppe DirectAccess Servers und IIS Web Server hinzufügen
  7. In der OU Servers eine weitere OU DirectAccess erstellen
  8. Das Computerobject DA1 in die OU DirectAccess verschieben
    DA_ADDS-002
  9. Fenster schließen

Gruppenrichtlinienobjekte erstellen und verknüpfen

  1. Server Manager > Tools > Group Policy Management
  2. intern.einfaches-netzwerk.at\Group Policy Objects erweitern
  3. Folgende Gruppenrichtlinienobjekte erstellen
    1. DirectAccess Computers Custom
    2. DirectAccess Computers Wizard
    3. DirectAccess Servers
    4. DirectAccess ISATAP

    Weiterlesen →

Teil 27a: DirectAccess-Server installieren und konfigurieren

Veröffentlicht am von
4

DirectAccess-Server installieren und konfigurieren – Schritte:

  • In Hyper-V eine virtuelle Maschine erstellen und Windows Server 2012 R2 installieren
  • Empfohlene Update für Windows Server 2012 R2 DirectAccess installieren
  • Die Server-Rolle Web Server (IIS) installieren
  • Netzwerk-Adapter konfigurieren
  • Bindings konfigurieren
  • Netzwerkprofil Public für den externen Netzwerk-Adapter konfigurieren
  • Statische Route ins interne Netzwerk hinzufügen

In Hyper-V eine virtuelle Maschine erstellen und Windows Server 2012 R2 installieren

  1. Im Hyper-V-Manager folgende virtuelle Maschine erstellen:
    1. Name: DA1
    2. Generation 2
    3. zwei Netzwerk-Adapter
      1. Adapter 1 im Corpnet, Adapter 2 im Internet
      2. Single-root I/O virtualization aktiviert (benötigt spezielle Hardware, die ich nicht habe – darum deaktiviert; siehe Overview of Single Root I/O Virtualization)
        DA_SERVER-001
      3. Enable MAC address spoofing aktiviert
        DA_SERVER-002
  2. Windows Server 2012 R2 wie in Teil 19c beschrieben aufsetzen

Empfohlene Update für Windows Server 2012 R2 DirectAccess installieren

  1. Alle Updates für Windows Server 2012 R2 von folgender Webseite installieren: Recommended hotfixes and updates for Windows Server 2012 DirectAccess and Windows Server 2012 R2 DirectAccess

Die Server-Rolle Web Server (IIS) installieren

  1. Die Server-Rolle Web Server (IIS) mit Standardeinstellungen installieren (Wizard einfach durchklicken)
    DA_SERVER-023

Netzwerk-Adapter konfigurieren

  1. Als Administrator an DA1 anmelden
  2. Network and Sharing Center öffnen > Change adapter settings
  3. Den internen Adapter nach Intern1 umbenennen
  4. Den externen Adapter nach Extern1 umbenennen, damit die Netzwerk-Adapter in den Dialogfenstern leichter unterschieden werden können
    DA_SERVER-003
  5. Den internen Netzwerk-Adapter (Intern1) konfigurieren
    1. Intern1 rechts anklicken > Properties
    2. Internet Protocol Version 4 markieren > Properties
    3. Internet Protocol Version 4 Properties
      1. IP address: 192.168.150.10
      2. Subnet mask: 255.255.255.0
      3. Default gateway: KEIN GATEWAY
      4. Preffered DNS server: 192.168.150.1
        DA_SERVER-004
    4. Alle Fenster mit OK schließen
  6. Den externen Netzwerk-Adapter (Extern1) konfigurieren
    1. Extern1 rechts anklicken > Properties
    2. Extern1 Properties
      1. Client for Microsoft Network deaktivieren
      2. File and Printer Sharing for Microsoft Network deaktivieren
        DA_SERVER-005
    3. Internet Protocol Version 4 markieren > Properties
    4. Internet Protocol Version 4 Properties
      1. IP address: 131.107.0.10
      2. Subnet mask: 255.255.255.0
      3. Default gateway: 131.107.0.1
      4. Preferred DNS server: KEIN DNS SERVERDA_SERVER-006
    5. Auf Advanced… klicken
      Weiterlesen →

Teil 27: Vorbereitung von DirectAccess

Veröffentlicht am von
Antworten

Vorbereitung von DirectAccess: Systeme und Protokolle

Für die Vorbereitung von DirectAccess ist es wichtig, einige wenige Begriffe zu kennen. Im folgenden Abschnitt möchte ich die Konfiguration der Systeme und Protokolle für mein einfaches Netzwerk so kurz wie möglich beschreiben. Nachdem ich alle notwendigen Informationen zusammengetragen habe, werde ich DirectAccess installieren und konfigurieren.

Als Referenz für die Vorbereitung von DirectAccess verwende ich DirectAccess in Windows Server. Für die Kapazitätsplanung hilft DirectAccess Capacity Planning.

IPv6 / IPv4 Übergangstechnologien

  • 6to4: Wird verwendet, wenn der DirectAccess-Client eine öffentliche IPv4-Adresse bezieht. Der Client darf sich nicht hinter einem NAT-Gerät befinden. Das dabei verwendete Protokoll 41 ist häufig durch die Internet Provider blockiert. Ich werde 6to4 nicht verwenden und mittels Gruppenrichtlinie deaktivieren.
  • Teredo: Funktioniert 6to4 nicht, wird der Verbindungsaufbau mittels Teredo versucht. Teredo überprüft zuerst hinter welchem NAT-Gerät sich der DirectAccess-Client befindet, verpackt dann den IPv6-Verkehr und startet die Kommunikation. Teredo verwendet den UDP-Port 3544.
    • Vorteil: Ermöglicht DirectAccess hinter einem NAT-Gerät (Router)
    • Nachteil: zwei öffentliche IP-Adressen am externen Netzwerk-Adapter des DirectAccess-Servers notwendig
  • IP-HTTPS: IPv6-Pakete werden in HTTPS eingekapselt. IP-HTTPS verwendet den TCP-Port 443. Weil der Port 443 (jede https-Webseite) eigentlich überall erlaubt ist, funktioniert IP-HTTPS in den meisten Fällen. Wird das Häkchen bei „Use force tunneling“ aktiviert, wird ausschließlich IP-HTTPS verwendet. In diesem Fall kann 6to4 und Teredo deaktiviert werden.
    • Vorteil: Funktioniert (fast) immer
    • Nachteil: IPsec und HTTPS-Verschlüsselt (nur bei Windows 7) und dadurch etwas langsamer als Teredo, weil die Pakete doppelt ver- und entschlüsselt werden müssen; Verwaltung von Zertifikaten
  • ISATAP: Um aus dem IPv4-Intranet DirectAccess-Clients verwalten zu können, ist ISATAP notwendig. Dafür wird am internen Computer ein ISATAP-Adapter mit einer auf der IPv4-Adresse basierenden IPv6-Adresse erstellt (mehr Informationen später).
    • Vorteil: Zugriff auf die DirectAccess-Clients (z.B. durch den Helpdesk)
    • Nachteil: Konfigurationsaufwand; von Microsoft nicht empfohlen
  • DNS64: DNS64 wird am DirectAccess-Server ausgeführt und löst für die DirectAccess-Clients interne Namen in IPv4-Adressen auf. Dafür verwendet er seine eigene DNS-Konfiguration. Es ist keine Konfiguration notwendig.
  • NAT64: NAT64 übersetzt den Verkehr von öffentlichen IP-Adressen zu privaten und zurück. NAT64 übersetzt den Verkehr von IPv6 zu IPv4 und zurück. Es ist auch für NAT64 keine Konfiguration notwendig.

Verwendete Systeme:

  • Active Directory Domain Services: Es können nur Domänen-Computer DirectAccess-Clients sein. Für die Konfiguration der Clients werden ausschließlich Gruppenrichtlinien verwendet. Für die Zielgruppenfilterung werde ich Sicherheitsgruppen für Server und Clients erstellen. Der DirectAccess-Server kommt in eine eigene OU, damit dieser Server keine anderen Gruppenrichtlinien erhält.
  • Active Directory Certificate Services: Für die Kommunikation mittels IP-HTTPS und für die Webseite des NLS (Network Location Server) sind Zertifikate notwendig. Weil für IP-HTTPS die CRL extern erreichbar und hochverfügbar sein muss, empfiehlt sich ein Zertifikat von einem Drittanbieter, um dessen bestehende Infrastruktur nutzen zu können. Ich werde meine PKI für den NLS und IP-HTTPS verwenden, weil ich keinen „echten“ Internetzugang in der Laborumgebung habe. (Siehe Hosting the Windows Server 2012 Base Configuration Test Lab with Windows Server 2012 Hyper-V)
    Weiterlesen →