Archiv der Kategorie: Zertifikate

CA, Zertifikate, PKI

Teil 27c: DirectAccess-Zertifikate und Web Server konfigurieren

Veröffentlicht am von
3

Die Schritte für die Konfiguration von Zertifikaten und Web Server habe ich in den Teilen Teile 6ff, Teile 26ff detailliert beschrieben. Die Vorlagen für die Computer- und Web Server-Zertifikate können wie beschrieben verwendet werden, es sind keine Änderungen notwendig. Das Hinzufügen von Host (A)- und Alias (CNAME)-Einträgen am DNS Server habe ich ebenfalls schon öfter beschrieben (siehe z.B. Teil 12b: SSL mit WSUS verwenden). Deshalb habe ich in diesem Teil das Konfigurieren der DirectAccess-Zertifikate und Web Server etwas zusammengefasst.

DirectAccess-Zertifikate und Web Server konfigurieren – Schritte:

  • CDP am Server DA1 für den Zugriff aus dem Internet konfigurieren
  • Am externen DNS Host (A oder AAAA)-Einträge für pki und da hinzufügen
  • Ein Computer- und Web Server-Zertifikat auf DA1 ausstellen und im IIS Manager hinzufügen
  • Computer-Zertifikat auf den DirectAccess-Clients
  • Webseite für den NLS (Network Location Server) konfigurieren

CDP am Server DA1 für den Zugriff aus dem Internet konfigurieren

Weil DA1 aus dem Internet erreichbar ist – Netzwerk-Adapter Extern1 mit 131.107.0.10 – muss ich die CRL hier verfügbar machen. Diese Schritte können bei einem Drittanbieter-Zertifikat übersprungen werden, weil die vorhandene Infrastruktur des Drittanbieters (z.B. StartSSL) verwendet wird.

  1. Als Administrator an DA1 anmelden
  2. Den Ordner C:\CertEnroll erstellen und freigeben
  3. Die Gruppe Cert Publishers und das Computerobjekt der SubCA1 (APP1) berechtigen (Ändern)
    DA_CERT-0001
  4. Die CA-Zertifikate nach C:\CertEnroll kopieren
    DA_CERT-0002
  5. Im IIS Manager ein virtuelles Verzeichnis CertEnroll anlegen
    DA_CERT-0003
  6. Directory Browsing und Double Escaping aktivieren (siehe Teil 6)
  7. In den Eigenschaften der SubCA1 die CDPs und AIAs hinzufügen
  8. Der CDP für http://pki.einfaches-netzwerk.at/CertEnroll und file:///da1.intern.einfaches-netzwerk.at/CertEnroll
    DA_CERT-0004
  9. Der AIA-Eintrag für http://pki.einfaches-netzwerk.at/CertEnroll
    DA_CERT-0005
  10. Den Dienst certsvc neu starten
  11. Die CRL neu veröffentlichen, diese wird sowohl auf APP1 > C:\CertEnroll als auch auf DA1 > C:\CertEnroll kopiert (für die interne Hochverfügbarkeit der CRL kann man diese zwei Server mittels Network Load Balancing zusammenführen, dazu mehr in einem späteren Teil)DA_CERT-0006
  12. Die interne Erreichbarkeit der CRL testen
    DA_CERT-0007

Am externen DNS Host (A)-Einträge für pki und da hinzufügen

  1. Am externen DNS Server (hier INET1) einen Host (A)-Eintrag für pki.einfaches-netzwerk.at / 131.107.0.10 anlegen (vom ISP anlegen lassen)
    DA_CERT-010
  2. Am externen DNS Server (hier INET1) einen Host (A)-Eintrag für da.einfaches-netzwerk.at / 131.107.0.10 anlegen (vom ISP anlegen lassen)
    DA_CERT-009
  3. Die externe Erreichbarkeit der CRL testen
    DA_CERT-011

Passt soweit! 🙂

Ein Computer- und Web Server-Zertifikat auf DA1 ausstellen und im IIS Manager hinzufügen

Wie in Teil 27 beschrieben braucht DA1 für die IPsec-Verbindung das Computer-, für die IP-HTTPS-Verbindung das Web Server-Zertifikat.

  1. Eine MMC mit dem Snap-in Certificates für den Computer account starten
  2. Das Computer- und folgendes Web Server-Zertifikat ausstellen
    DA_CERT-004

    1. Subject name
      1. Type: Common name
      2. Value: da.einfaches-netzwerk.at
    2. Alternative name
      1. Type: DNS
      2. Value: da.einfaches-netzwerk.at
        DA_CERT-002
    3. Friendly name: IP-HTTPS Web Server Certificate
      DA_CERT-003
    4. MMC mit den ZertifikatenDA_CERT-006
  3. Alle Fenster schließen
  4. Das Web Server-Zertifikat im IIS Manager unter Bindings hinzufügen
    DA_CERT-007
    DA_CERT-008
  5. Alle Fenster schließen

Computer-Zertifikat auf den DirectAccess-Clients

Weil ich die Computer-Zertifikate mittels Gruppenrichtlinen automatisch ausrolle (siehe Teil 6i), ist auf den Clients alles erledigt. 🙂
DA_CERT-012

Webseite für den NLS (Network Location Server) konfigurieren

Für die Webseite des NLS gilt als Best Practice nicht die IIS Standard Webseite zu verwenden. Aus diesem Grund erstelle ich eine einfache html-Datei.

  1. Als Administrator an APP1 anmelden
  2. Die Datei index.html mit folgendem Inhalt in C:\inetpub\wwwroot erstellen 
    <html>
    <body>
        <a href="http://app1.intern.einfaches-netzwerk.at">www.einfaches-netzwerk.at</a>
    </body>
</html>
  3. Am DNS Server einen neuen Host (A)-Eintrag für nls.intern.einfaches-netzwerk.at anlegen
    DA_SERVER-024
  4. Folgendes Web Server-Zertifikat ausstellen
    1. Subject name
      1. Type: Common name
      2. Value: nls.intern.einfaches-netzwerk.at
    2. Alternative name
      1. Type: DNS
      2. Value: nls.intern.einfaches-netzwerk.at
        DA_CERT-016
    3. Friendly name: NLS Web Server Certificate
      DA_CERT-017
  5. Fenster schließen
  6. Das Web Server-Zertifikat im IIS Manager unter Bindings hinzufügen
    DA_CERT-018
  7. Der Aufruf mittels https://nls.intern.einfaches-netzwerk.at/DA_CERT-019

In diesem Teil ist viel geschehen: Ich habe die CRL für die DirectAccess-Clients aus dem Internet erreichbar gemacht. Außerdem habe ich für IP-HTTPS, IPsec und den NLS alle notwendigen Zertifikate installiert und die Web Server konfiguriert. Schon ist es soweit: Im nächsten Teil werde ich auf DA1 die Server-Rolle für DirectAccess installieren und konfigurieren.

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 →

Java Deployment Rule Set mit Microsoft CA digital signieren

Veröffentlicht am von
Antworten

Mit Java 7 Update 40 hat Oracle das Feature Java Deployment Rule Set eingeführt, um die Sicherheit und Kompatibilität der Browser-Applets zu erhöhen. Für Desktop Administratoren ermöglicht es die zentrale Verwaltung der Sicherheitseinstellungen auf den Clients. Im folgenden Beispiel verwende ich meine bestehende PKI (Ein einfaches Netzwerk, Teil 6ff) um ein Code Signging Zertifikat auszustellen.

Java Deployment Rule Set mit Microsoft CA digital signieren – Schritte:

  • Die Rolle Certification Authority Web Enrollment auf SERVER01 installieren
  • Zertifikatsvorlage für Code Signing erstellen und veröffentlichen
  • Web Server Zertifikat für SERVER01 anfordern und IIS zur Verwendung von https konfigurieren
  • Java 7 Developmentkit herunterladen und installieren
  • Java Deployment Rule Set erstellen und digital signieren
  • Verteilen der Datei DeploymentRuleSet.jar auf die Clients

Die Rolle Certification Authority Web Enrollment auf SERVER01 installieren

  1. Als Administrator an SERVER01 anmelden
  2. Server Manager > Manage > Add Roles and Features
  3. Add Roles and Features Wizard
    1. Before You Begin > Next
    2. Installation Type: Role-based or feature-based installation > Next
    3. Server Selection: SERVER01.haimann.local > Next
    4. Server Roles
      1. Active Directory Certificate Services
        1. Certification Authority Web Enrollment > Next
          JAVA-013
    5. Features > Next
    6. Confirmation > Install
    7. Results > Configure Active Directory Certificate Services on the destination server
      JAVA-014
  4. AD CS Configuration
    1. Credentials > Next
      JAVA-016
    2. Role Services: Certification Authority Web Enrollment > Next
      JAVA-017
    3. Confirmation > Configure
      JAVA-018
      Weiterlesen →