Archiv

Posts Tagged ‘DNS’

Work Folders | Zertifikate ausrollen

14. Januar 2014 4 Kommentare

der 4. Teil der Implementierung der Work Folders geht es um den DNS Einträge und der Implementierung des Zertifikates, damit wir mit allen Geräten nicht nur innerhalb unseres Firmennetzwerkes Zugriff haben, sondern auch über das Internet von jeder beliebigen Stelle. Dabei gehe ich auch auf die Problematik eines bestehenden Exchange Servers und der mittlerweile von Microsoft abgekündigten Firewall Thread  Management Gateway (TMG 2010) einNetzwerk-Diagramm  für Work Folders

Wenn in einer Firma sowohl ein Sync-Server als auch ein Mail Server eingesetzt werden sollen, so ergibt sich auf Grund des verwendeten Protokolls (hppts= Port 443) ein Problem. Der Datenstrom muss an der Firewall getrennt werden. Die nachfolgende Beschreibung hier gilt für folgende Komponenten:

  • Proxy-Server: TMG 2010 auf Windows Server 2008 R2
  • Mail-Server: Exchange Server
  • Sync-Server: Windows Server 2012 R2
  • Es ist nur eine externe IP Adresse vorhanden
    Exchange Server verlangt beim Protokoll Outlook Web Access (OWA) SSL Verschlüsselung. Für den Zugriff muss öffentlich ein DNS Eintrag beim Provider eingerichtet werden. Der Sync- Server benötigt für die Work Folders ebenfalls einen öffentlichen DNS Eintrag
  • mail.contoso.com
  • workfolders.contoso.com
    ich habe im DNS Manger der Domäne auch noch einen Host-Eintrag workfolders erzeugt, dessen  IP auf den Sync-Server (Fileserver) zeigt:

DNS Eintrag für Workfolders

 

Und natürlich benötigen wir in SAN-Zertifikat (Multi-Domain Zertifikat), bei dem beide Einträge vorhanden sind. Dann kann auf der TMG mittels Bridging der SSL Datenstrom je nach Anforderung zum Mail-Server also auch zum Sync-Server weitergeleitet werden.

Dieses Zertifikat muss sowohl auf dem Mail-Server (Exchange) als auch auf dem Sync-Server und natürlich auf dem Proxy-Server (TMG) ausgerollt werden.

Exchange-Server

Es gibt genügend Beschreibungen im Internet, wie ein Zertifikat auf dem Exchange Server aus zu rollen ist, das ist auch abhängig von der Version des Exchange Servers. Hier ein paar Links:

 

Sync-Server (File Server)

hier ist eine Besonderheit zu beachten, weil eine SSL-Bindung ans den Web-Server IIS nicht über die Oberfläche funktionierten kann, weil der Web-Server (IIS) gar nicht installiert werden muss und auch gar nicht installiert wurde.

Besonderheiten bei den Rollen: Workfolders und Web Server

Es wurde aber (automatisch) mit den Work Folders die IIS Hostable Web Core installiert, die aber keine graphische Oberfläche hat.

PowerShell Abfrage: welche Komponenten sind installiert?

Das Powershell-Kommando hierfür: get-windowsfeature | where {$_.installed -eq $True}

Ist die Rolle Web Server (IIS) installiert, dann gibt es hier eine Beschreibung, wie Sie da Zertifikat an die Website binden können.

und hier der Weg, bei dem wir mit  Powershell und der CMD die Bindung vornehmen können.

1- Zuerst muss das Zertifikat importiert werden: (Powershell)

PS C:\>Import-PfxCertificate –FilePath <certFile.pfx> -CertStoreLocation cert:LocalMachine\My

natürlich können wir das ganze auch über das über das Zertifikats Snap-in der MMC erledigen. Dann sollte nach dem Import die Einstellung so aussehen:

MMC: installierte Zertifikate

 

2– Danach müssen den thumbprint des soeben importierten ermitteln:

PS C:\>Get-ChildItem –Path cert:\LocalMachine\My

Powersehll Abfrage: Thumbprint der installierte Zertifikate ermitteln

3- Das SSL Zertifikat muss nun mittel einer CMD-Konsole (!!!) gebunden werden.

netsh http add sslcert ipport=0.0.0.0:443 certhash=<Cert thumbprint> appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=MY

Nachdem die Zeile in die CMD Konsole eingegeben (kopiert) wurde, wechseln wir wieder in die Powershell und kopieren den richtigen Thumprint des weiter oben installierten Zertifikates. und ersetzen in der Kommando-Zeile (CMD) <Cert thumbprint> durch die Zeichenfolge und dann erst wird das Kommando mit Return abgesetzt.

CMD: Zertifikat an WebServer binden 

Das  Kommando bindet das Zertifikat an das Root (alle Hostnamen dieses Servers) dieses Servers mit Port 443


Eine Besonderheit ist noch zu beachten, wenn sich ein Exchange Server in der Domäne befindet.Diese Beschreibung hier setzte aber auf bestimmte Gegebenheiten auf:

  • Es ist nur eine feste IP Adresse vorhanden
  • Benutzer nutzen auch OWA um auf Ihre Mail-Daten des Exchange Servers zuzugreifen
  • Als Firewall wird ein Thread Management Server 2010 (TMG) eingesetzt
    Das Problem ist, das sowohl OWA als auch Work Folders SSL (Port 443) benutzen und wir auf an der Firewall Bridging einsetzen müssen, um die SSL Daten entweder zum Exchange Server oder aber zum Sync-Server weiter zu leiten.
    1- Zertifikat importieren
    Das Zertifikat ist mit der MMC (Zertifikats Snap in)  auf der der TMG zu importieren. Danach sieht der persönliche Zertifikatsspeicher so ausSmiley mit geöffnetem Mund:

MMC: welche Zertifikate sind installiert

        Der rote Pfeil zeigt auf das “alte” OWA Zertifikat, der blaue auf das neue Zertifikat
          2- Web Listener erstellen bzw. umstellen
          Der existierende Web-Listener muss nun umgestellt werden:
      TMG Weblistener für SSL Ich habe nicht nur den Namen, sondern auch die Beschreibung geändert.
      TMG Weblistener : für welche IP er muss zwingend auf die externe Adressen “lauschen”
      TMG Weblistener : für SSL Traffic es geht um SSL Verkehr an Port 443
      TMG Weblistener : SAN Zertifikat zuweisen im Kartenreiter Certifikate müssen wir jetzt das neue Zertifikat zuweisen

      Hier noch einmal der Hinweis, dass auch der Exchange Server natürlich mit dem neuen Zertifikat versehen wurde!

      Der Weblistener lauscht ja auf Port 443 und weil in dieser Konfiguration nur eine externer IP Adresse vorhanden ist, gilt dieser Web Listener sowohl für OWA als auch für WEorkfolders und erst im Bridging wird unterschieden …

      Klick auf Select Certificate…

      TMG Weblistener : SAN Zertifikkat auswählen Das Bild zeigt jetzt das ich bereits auf das neue Zertifikat (Blau) geklickt habe.

      Anschließend auf “Select” klicken

      TMG Weblistener : Authentifizierung Im Kartenreiter Authentication habe ich “no Authentication” eingestellt (gehabt).

      Wir reichen ja nur durch und authentifizieren im Exchange Server bzw. im Sync Server

    Damit haben wir die Änderung des Web Listeners an der TMG abgeschlossen und klicken auf OK

    3- Regel OWA ändern
    TMG Regel für OWA: Weblistener auswählen Alle Einstellungen bleiben, nur der Weblistener muss richtig ausgewählt werden.
    4- Work Folder Regeln erstellen
    Der Einfachheit habe ich die “OWA” Regel in der TM kopiert , den Namen dann geändert und dann die Änderungen durchgeführt.
    TMG Regel für Work Folders: Name und Beschreibung Name und Beschreibung geändert
    TMG Regel für Work Folders: Erlaubnis  
    TMG Regel für Work Folders: für welche Quelle?  
    TMG Regel für Work Folders: Webserver eintragen Der Client kennt den externen oder internen DNS Namen (publish Sites) und als Computer habe wird der Namen des Sync-Servers eingetragen
    TMG Regel für Work Folders: Protokoll https eintragen Es geht um HTTPS (Port 443)
    TMG Regel für Work Folders: Weblistener auswählen hier wieder den Web-Listener eintragen.

    TMG Regel für Work Folders: DNS eintragen hier wird der öffentliche DNS Name eingetragen

    (beim der OWA Regel steht hier der öffentliche DNS Name für OWA)

    TMG Regel für Work Folders: Pfad umsetzen bei dem internen Pfad tragen wir ein:

    /sync/1.0/*

    Danke an meinen MVP Kollegen Christian Gröbner, der mich bei den Zertifikaten unterstützt hat und der diesen Eintrag aus dem Live-Logging ausgelesen hat.

    TMG Regel für Work Folders: keine Authentifizierung an der Firewall wird nicht authentifiziert, sondern nur weitergereicht…
    TMG Regel für Work Folders: WebServer und Protokoll 443 Traffic wird an den Web-Server weitergeleitet.
    TMG Regel für Work Folders: Benutzer auswählen und eintragen Ich habe hier “alle Benutzer” eingetragen…
    TMG Regel für Work Folders: Regel testen Ein Klick auf “Test Rue” zeigt, dass die Weiterleitung korrekt ist.
    Damit ist die Konfiguration an der TMG 2010 abgeschlossen. Im nächsten Blog Post werde ich dann den Abschluss dieser Work Folders Serie beschreiben, nämlich die Implementierung der Work Folders unter Windows 8.1, und zwar für ein Gerät in der Domäne als auch ein BYOD Gerät.
  1. Work Folders | Überblick
  2. Work Folders | Einrichtung Server und Konfiguration
  3. Work Folders | Quota und SMB
  4. Work Folders | Zertifikate ausrollen
  5. Work Folders | Client Konfiguration

        Windows Server 2012 | DC Update


        Vor kurzem stand ich vor der Herausforderung, eine bestehende Windows Server 2008 R2 Domäne mit 2 DC’s auf Windows Server 2012 upzugraden. Normalerweise steht einem Implace-Upgrade laut Technet nichts im Wege, aber natürlich wollte ich mich von dem alten “Müll” befreien.

        2 DC's auf Basis Windows Server 2008 R2 81x OnPremise, 1x virtuelll) Hier die bestehende Konfiguration:
        1x Windows Server 2008 R2 (onPremise)
        1x Windows Server 2008 R2 (virtuell)

        installiert:
        AD
        DHCP
        DNS
        File & Print
        DFS

        neuer 3. DC hinzugefügt: Windows Server 2012 (virtuell)

        DFS Replikation

        Replikationsfolder 1: 
        1047 Ordner, 34.443 Dateien, 25,8 GByte
        Replikationsfolder 2:
        8643 Ordner, 82.374 Dateien, 88,1 GByte

        Als erstes habe ich einen 3. DC in der vorhandenen Hyper-V Umgebung installiert. Allerdings mit dem Betriebssystem Windows Server 2012.
        Als Rollen und Features wurden installiert:
        AD
        DHCP
        DNS
        File & Storage Services

        Der neue Server wurde der bestehenden Domäne hinzugefügt und mit allen Updates versorgt.

        Dann wurde er als 3. DC zu den Domain-Controllern hinzugefügt.
        Anschließend wurden alle FSMO Rollen auf den neuen Server verschoben.

        Der Kunde nutzt intensiv DFS, ausschließlich wegen den Möglichkeiten der Links

        Also wurden die 2 bestehenden Replikationsfolder um einen 3. Member (neuer DC) erweitert.

        Anschließend war Warten angesagt, bis beide Replikationen komplett abgeschlossen waren.

        im nächsten Schritt wurden dann vom vorhandenen aktivem DHCP ein Backup erstellt, dieses im neuen Server importiert und dann dort aktiviert und beim alten Server deaktiviert.

        Der nächste Schritt war DCPROMO auf dem bestehenden Windows Server 2008 R2 DC1. Leider schlug DCPROMO fehl, weil sich im AD noch alter Müll (seit dem Jahr 2000!) angesammelt hatte. Nun bin ich im AD nicht zu Hause, aber nach einigen Recherchen im Internet habe ich dann doch die Lösung gefunden und dann mit ADSI “manuell” korrigiert.

        2 DC's und ein Member Server Erneuer Aufruf und dann waren es nur mehr 2 DC’s.

        Dann wurden die Replikate im DFS aufgelöst, und anschließend konnte der Server mit neuer Software bestückt werden.

            Festplatten-Konfiguration des Servers

        Die interne Bestückung des Servers besteht aus einem INTEL-RAID System(Raid 1) mit 2 Festplatten für das Betriebssystem und einer Datenfestplatte (DFS)

        Mit der DVD des Microsoft Betriebssystems Windows Server 2012 gebootet, KEY eingetragen, und dann auf den nächsten Fehler gestoßen, Windows Server 2012 mag diese Konfiguration des RAID-Systems nicht.

        Die Recherche im Internet gab leider nichts her. Also mal wieder von vorne. Identifizierung auf den Intel Seiten nach dem neusten BIOS, Memory-Stick mit MS-DOS bootbar erstellt, das von den Intel Seiten heruntergeladene BISO draufgespielt, Server-Schrank geöffnet, Server geöffnet, BIOS identifiziert, umgestellt und dann mit dem Stick gebootet. BIOS des Servers upgedatet., wieder zurückgewechselt und dann neu gebootet.

        Dies ist die Kurzversion von doch einigen Schritten, die etwas länger dauern. Danach das RAID-System aufgelöst und ein neues Array erzeugt. Erneut mit der DVD gebootet, und siehe da, Windows Server 2012 ließ sich auf dem neuen Festplatten (Raid 1) installieren.

        2x Windows Server 2012 DC, 1x Windows Server 2008 R2 DC Auf dem OnPremise-System wurden dann folgende Rollen /Feature installiert:
        AD
        DHCP
        DNS
        File & Storage Services

        und alles Updates eingespielt und danach der Server als 3. DC dem AD hinzugefügt.

        Danach wurde das Backup des DHCP Servers wieder importiert und der DC1 als erstes System eingestellt.  (DHCP auf dem DC3 natürlich disabled)

        der letzte Schritt war natürlich die Konfiguration von DFS und das Anstoßen der Replikate.

         

        2 DC's, mit Windows Server 2012 So sieht jetzt die Konfiguration aus. 2 neue, nicht nur im AD aufgeräumte DC’s und ein voll funktionsfähigens DHCP, DNS und DFS-System auf Basis Windows Server 2012 .

        Als nächstes kann ich mich an die Verbesserungen von Windows Server 2012 machen, aber das ist eine andere Geschichte

        So nebenbei, es gab natürlich ein kleines Problem: Exchange Server 2010 (die Mailboxrolle) hatte ein Problem: SACL… aber das ist ein anderer Beitrag

        %d Bloggern gefällt das: