The Cloud Brew Conference is a great conference in the hearth of Belgium in Mechelen 30km north of Bruessel. The conference first start in 2013 with a great location, in a old brewery and still takes place there today.
With two full days of Azure experience with many international speakers from around the globe, it’s a must for Belgians and cloud folks with Azure focus. The agenda looks pretty good.
DIe Microsoft Inspire fand letzte Woche statt und bereits im Vorfeld gab es einige Neuigkeiten zu verschiedenen Services. So wurde u.a. Azure Migrate als Public Preview vorgestellt, ein Assessment Tool für virtuelle Umgebungen (Hyper-V und VMware). Außerdem gab es ein neues Release zu Web Application Firewall/Gateway. Und natürlich einige Neuigkeiten zu Azure File Sync, die gerade im Hinblick auf Enterprise Unternehmen interessant sind. Diese werden in diesem Artikel vorgestellt.
Für Azure File Sync ist eine neue Agent Version verfügbar, die einige Interessante Funktionen mitbringt. Insbesondere der lang erwartete Support für Azure Fileshares <= 5TB wird nun integriert. Die Aktualisierung erfolgt Schrittweise, daher kann es etwas dauern, bis ihr von den Verbesserungen profitiert. Allerdings gibt es auch eine Möglichkeit, das ganze zu beschleunigen.
Microsoft has changed the #AzureBastion minimum subnet size from /27 to /26. Installed #Azure Bastion are unaffected, but new deployments require the new subnet size. Please remember this.
Azure Bastion ist ein ganz neuer Service im Azure Universum, der den Remote Zugriff auf eure Azure VMs via RDP/SSH deutlich vereinfacht und absichert.
Azure Bastion Architecture by Microsoft Docs
Bisher gab es zwei Möglichkeiten, um sich zu Azure VMs via RDP oder SSH zu verbinden.
Es besteht Zugriff auf das VNET, in dem die Azure VM liegt. Dazu war eine VPN Verbindung zum VNET notwendig oder ein Jump Host der in Azure ausgerollt wurde.
Oder die Azure VM erhielt eine öffentliche IP-Adresse, um RDP oder SSH nach außen zu veröffentlichen. Damit einhergehend öffneten sich eine Menge Sicherheitslücken.
Mit Azure Bastion gibt es nun eine 3. Möglichkeit.
Azure Bastion wird als Platform-as-a-Service bereitgestellt und ermöglicht eine nahtlose Verbindung über das Azure Portal zur entsprechenden Azure VM. Durch diese Funktion sind beide oben genannten Möglichkeiten obsolet und ein direkter Zugriff auf Azure VMs, ohne Public IP, ist immer möglich. Azure Bastion stellt auf seine Art einen entsprechenden Jump Host im jeweiligen VNET bereit und benötigt seinerseits eine Public IP für die entsprechende Funktionalität.
Gestern Vormittag durfte ich zum ersten Mal auf der Cloud and Datacenter Conference (CDC-Germany) in Hanau eine Session halten. Die CDC ist eine der wenigen Konferenzen in Deutschland, die den Fokus auf On-Prem und Hybrid Cloud Szenarien legt und dadurch viele Kunden erreicht. Carsten und seine Frau haben eine tolle Konferenz gegründet, die jedes Jahr mehr Teilnehmer zählt. Dies liegt auch an den vielen hochkarätigen Sprechern, die Carsten für die Konferenz gewinnt.
Soeben wurde Server Management Blog das Update 1802 von Project Honolulu freigegeben, “The Nextgen Serverconsole” wie das Tool auch gern bezeichnet wird.
Die Neuerungen beziehen sich vor allem auf Performance Verbesserungen und Unterstützung von HA-Umgebungen, sind also zunächst unter der Haube zu finden.
Seit heute ist die Preview von Project Honolulu – Next Server Manager Console zum Download verfügbar. In diesem Blog Beitrag gehe ich auf die Installation und Konfiguration von dem Tool ein.
Vorwort
Bei Project Honolulu handelt es sich um eine vollständig, webbasierte Oberfläche für das zentrale Server Management von Windows Servern (ab 2012). Bedeutet das Tool ist nur über ein Webbrowser erreichbar und kann auch nur von hier verwaltet werden, dies ist für die spätere Installation von Relevanz.
Da ich, aufgrund der freundlichen Unterstützung von ppedv, noch einen Gutschein für die Serverprüfung 70-659 hatte, habe ich diesen heute eingelöst.
Wenn man ein wenig Erfahrung im Bereich Hyper-V und der Verwaltung von Hyper-V mit dem SCVMM 2008 R2 hat, dann ist diese für viele sicherlich kein Hindernis.
Allerdings passten die Fragen zum Remotedesktop Service nicht so recht zu dieser Prüfung. Davon waren einige vorhanden die sich auf die Themen Verbindung, Lizenzierung und Broker bezogen.
Ansonsten bin ich ganz froh, dass ich den Gutschein erfolgreich nutzen konnte und die Prüfung bestanden habe. Wer noch weitere gehende Informationen sucht, sollte sich den folgenden Beitrag anschauen, besser hätte ich es nicht zusammenfassen können: Virtualboy Blog
Aufgrund eines Fehlers und wahrscheinlich, weil ich nicht aufgepasst habe, habe ich bei der Migration von ESXi auf Hyper-V eine VM gelöscht, auf der meine Offline CA gespeichert war. Natürlich hatte ich ausgerechnet von diesem Zertifikat keine Datensicherung des privaten Schlüssels. Da in der Root CA auch noch ein Designfehler vorhanden war bzgl. der CRL, habe ich mich dazu entschieden, ein neues Root Zertifikat zu erstellen und die vorhandenen Designfehler zu korrigieren.
Da sieht man mal wieder, wie wichtig eine vernünftige Planung, auch in einer Testumgebung ist und das man natürlich die Datensicherung, gerade von kritischen Geräten nicht vergessen sollte 😉
Die Grundkonfiguration lässt sich mit folgenden Schritten schnell erledigen:
1. Standard-Installation von Windows Server 2008 R2 Enterprise Edition (Aktivierung auch gleich erledigen)
Primären DNS-Suffix eintragen
Unter C: ein Verzeichnis ADCS mit zwei Unterverzeichnissen “Database” und “Logs” anlegen
Serverrolle Active Directory Zertifikatsdienste (Active Directory Certificate Services) installieren
Bei Rollendiesten “Zertifizierungsstelle” auswählen
Allgemeiner Name dieser Zertifizierungsstelle “F1NaLByte Root Authority” (denkt euch euren eigenen aus 😉 )
Gültigkeitsdauer, da es sich um eine Offline Root CA handelt, kann diese zwischen 20 und 30 Jahren liegen. Wenn dieses Zertifikat kompromitiert werden sollte, verliert es ohnehin seine Gültigkeit.
Zertifikatdatenbank, auswählen des im Vorfeld angelegenten Database-Verzeichnis für die Datenbank und Logs-Verzeichnis für die Logs.
Restliche Abfragen mit Standardwerten bestätigen. Daraufhin ist die Rolle installiert.
Konfiguration Sperrlistenverteilungspunkt
Nun müssen die Sperrlisteninformationen angepasst werden, dass ist wichtig! Hier sind zunächst alle Einträge mit “ldap” und “file” zu löschen, siehe Bild.
Das ganze sollte, nach geänderter Konfiguration, folgendermaßen aussehen:
Konfiguration Stelleninformationen
Zuletzt sollte ebenfalls der Zugriff auf die Stelleninformationen angepasst werden.
Veröffentlichung der Sperrliste
Nächster Schritt ist die Konfiguration für das Veröffentlichungsintervall der Sperrliste. Da ich mit dieser Root CA nur meine Sub CA autorisiere, kann das Intervall ziemlich hoch eingestellt werden. Dies sollte aber im Einzelfall betrachtet werden. Bei Ausstellung von mehrere SubCA, sollte man das Intervall entsprechend der Anforderungen anpassen. In meinem Fall habe ich mich für 2 Jahre entschieden.
Zertifikatssperrliste Konfiguration
Nun muss noch die Zertifikatssperrliste veröffentlicht werden:
Ist der “File-Pfad” nicht verändert worden, so befindet sich die veröffentlichte Sperrliste nun an folgendem Ort: “C:WindowsSystem32CertSrvCertEnroll”
Diese beiden Dateien können nun mit dem Root- Zertifikat exportiert werden. Die beiden Dateien müssen unter der konfigurierten URL auf dem Webserver zur Verfügung gestellt werden.
Damit ist die Konfiguration der Offline Root CA abgeschlossen und alle notwendigen Dateien stehen zur Verfügung. Der nächste Schritt wäre die Erstellung einer untergeordneten Online CA (SubCA) die, beispielsweise, im Active-Directory veröffentlicht ist.
Mit dem Webservern kann man auf Port 80 mehrere Domänen auf einer IP-Adresse, anhand des Hostnamen, hosten. Dies ist allerdings bei HTTPS-Verbindungen schwierig, da der Hostname ja durch das Zertifikat bereits ausgestellt wird und mehrere Hostnamen nicht zusammen mit einem Port und einer IP laufen können.
Es gibt allerdings einen Weg, wie man mehrere SSL-Verbindungen mit einem Webserver und einer IP realisieren kann.
Vorraussetzungen:
Ein Wildcard-Zertifikat (*.domain.de)
IP-Adresse für das Hosting mehrere Webseiten
Min. 2 Webseiten auf Port 80 mit Hostnamen (SSL-Hostname wird nachgetragen)
Um das ganze nun zu realisieren:
Eine Commando-Zeile mit administrativen Rechten aufrufen
Ins Verzeichnis C:WindowsSystem32inetsrv wechseln
Folgendes Kommando eingeben (ersetzen von {Sitename}, {IP} und {Hostheader} mit den gewünschten Werten)
appcmd set site /site.name:”Default Web Site” /bindings.[protocol=’https’,bindingInformation=’10.0.1.100:443:web1.f1nalbyte.de’].bindingInformation:*:443:web1.f1nalbyte.de
