Nun ist das auch noch passiert 😉 Vor einigen Jahren hat uns Microsoft noch versprochen, das die Azure Cloud niemals ein lokales Active Directory ersetzen wird bzw. kann.

Doch mit der Veröffentlichung des jĂŒngsten Preview Mitglieds, der “Azure Active Directory Domain Services” hat sich das nun geĂ€ndert. Auf dem letzten MVP Summit 2014 in Redmond noch als “Streng Geheim” mit NDA sehr wage angekĂŒndigt, nun seit ein paar Tagen als Preview verfĂŒgbar.

Ich konnte es mir nicht nehmen, dieses gleich zu testen. Nachdem aufgrund eines Softwarefehlers die Azure Admin OberflÀche 24 Stunden spÀter auch die entsprechenden Links angezeigt hat, konnte ich gleich loslegen.

Hier nun meine “Walk Through” How-To Anleitung fĂŒr die ersten Gehversuche:

Da aber in den momentanen Anleitungen gewisse Anforderungen nur spÀrlich zu finden sind, hier noch einmal zusammen gefasst.
Folgende Aufgaben sollten vorher erledigt sein:

  • Erstellen eines virtuellen Netzwerks in den unterstĂŒtzen Regionen (seit spĂ€testens heute auch in Europa! Alle Dienste sind hier zu finden regions page (momentan der letzte Azure AD Eintrag)
  • Optional Erstellung eines neuen ADs (Domain.onmicrosoft.com) es sollte aber auch mit einer Benutzerdefinierten DomĂ€ne gehen.
  • Erstellung einer Benutzergruppe mit dem Namen “AAD DC Administrators” (WICHTIG! Die Gruppe muss GENAU SO geschrieben sein!! Sonst werden die Benutzer nicht als Administratoren repliziert 🙂 )
  • Die Einrichtung der DNS Server kann erst spĂ€ter erfolgen.

In einer beliebigen Azure DomĂ€ne in den TAB “Konfiguration” gehen und ein wenig nach unten scrollen. Dort erscheint der neue Optionspunkt “Domain Services”.

16-10-_2015_01-33-11_AzureADDomainService

Hier nun auf “Yes” klicken, um die Funktion zu aktivieren. Anschließend die vorhandene DomĂ€ne auswĂ€hlen und das vorher erstellte virtuelle Netzwerk. Letzte Woche war nur USA und Asien möglich, in der heutigen Übersicht steht auch Europa als unterstĂŒtzte Region in der Liste.

16-10-_2015_01-36-40_AzureADDomainService

 

16-10-_2015_01-36-50_AzureADDomainService

Die Erstellung der DomĂ€ne dauert eine ganze Weile… Zwei Zigaretten und ein Kaffee 🙂

Im Hintergrund werden bis zu drei virtuelle Maschinen erstellt und automatisch als DomÀnen Controller konfiguriert.

16-10-_2015_01-37-10_AzureADDomainService

Hier ist die Erstellung der Gruppe zu sehen. Man sollte vorher neue Benutzer hinzufĂŒgen, da sonst nur der angemeldete Azure Portal Admin (Globaladmin) zur VerfĂŒgung steht. In meinem Fall ist das eine LiveID, das wird so spĂ€ter nicht wirklich funktionieren 😉

 

16-10-_2015_01-39-15_AzureADDomainService 16-10-_2015_01-40-15_AzureADDomainService 16-10-_2015_01-57-30_AzureADDomainService

Irgendwann ist nun auch die DomÀne fertig und es wird eine IP Adresse angezeigt. Diese ruhig so eintragen, wie es in der Azure Doku beschrieben ist (https://azure.microsoft.com/de-de/documentation/articles/active-directory-ds-getting-started-dns/ )

Ich hatte nebenbei eine neue VM in dem neuen VN eingerichtet, so dass ich gleich loslegen konnte…

Normaler Domain-Join, damit ich auch die Ergebnisse sehe…. Aber naja… Das ist genau wie bei einem eigenem AD 🙂 Sollte es zu Fehler kommen, von wegen “Falscher Benutzer” oder so… Bitte kontrollieren, ob der Gruppenname korrekt geschrieben ist oder die Replikation des hier genutzten AD Admins ist noch nicht fertig)

16-10-_2015_02-43-44_AzureADDomainService

Reboot tut gut 🙂
NachtrĂ€gliche Kontrolle der Servereigenschaften zeigen das gewĂŒnschte Ergebnis. Mein erster Server im neuen Azure Dienst.

 

16-10-_2015_02-44-13_AzureADDomainService

Nach einer Weile kommen im ĂŒbrigen auch weitere IPs… Das sind dann die weiteren DomĂ€nen Controller.

16-10-_2015_02-46-00_AzureADDomainService 16-10-_2015_02-48-47_AzureADDomainService 16-10-_2015_02-51-18_AzureADDomainService

 

Als nÀchstes die Remote Admin Tools installieren und schauen, wie die Umgebung aussieht.

Dort finden wir zwei Benutzerdefinierte OUs “AADDC Users” und AADDC Computers”. Diese sind die zukĂŒnftigen Speicherorte von neuen Benutzer- und Computerkonten.

16-10-_2015_02-53-07_AzureADDomainService 16-10-_2015_02-53-49_AzureADDomainService

 

Hier sind nur “meine” 3 DomĂ€nencontroller aufgelistet.

16-10-_2015_02-54-32_AzureADDomainService 16-10-_2015_02-55-00_AzureADDomainService

Und hier sind die Gruppenrichtlinien dargestellt.

20-10-_2015_22-26-31_AzureADDomainService

 

Nutzen des neuen Dienstes

Und nun?
In den ersten Beschreibungen werden einige Szenarien dargestellt. (Overview )
Nach meinen persönlichen Erfahrungen könnte die Option fĂŒr “Cloud Only” Kunden interessant sein. Denn bisher blieb immer noch ein DomĂ€nen Controller lokal stehen, um die jahrzehntelang gepflegte GPOs weiter zu nutzen. Mal abgesehen davon, dass ein persönlicher Cloudspeicher wie “OneDrive for Business” auch nichts anderes wĂ€re, ist nun aber damit eine Abhilfe geschaffen worden.

Hier meine persönliche Empfehlung zur Vorgehensweise, unter der Voraussetzung, das ein Fileshare auf Basis SMB unbedingt beibehalten werden muss.

  • Erstellung einer wie oben beschrieben AD Domain Service Konfiguration
  • Erstellung einer neuen VM
  • HinzufĂŒgen einer zusĂ€tzlichen virtuellen Festplatte zur VM
  • Erstellen der notwendigen Ordnerstruktur
  • Erstellen der notwendigen Benutzergruppen
  • Bereitstellung einer HTTPS oder SFTP Anwendung auf der VM fĂŒr einen “Internet basierten Upload” oder
  • Bereitstellung eines dynamischen Gateways zur VPN Anbindung an den Client oder an das lokale Netzwerk (meine bevorzugte Variante) – Hier kann dann dieser Share im internen Netzwerk direkt von weiteren Clients genutzt werden

Sicherheitsfunktionen

Wie sagte doch ein bekannter ehemaliger DatenschĂŒtzer aus Schleswig Holstein? “.. Notfalls mĂŒssen halt technische Massnahmen zum Schutze des Zugriffs umgesetzt werden…”

Nicht das mein Kollege Raphael Köllner und ich dies schon seit bald 4 Jahren auf den verschiedensten Konferenzen zeigen… Aber hier noch einmal eine Shortliste, welche Sicherheitsfunktionen auch mit so einem Netzlaufwerk möglich sind bzw. umgesetzt wurden:

Implementiert und umgesetzt (Auszug):

  • physikalische VerschlĂŒsselung aller Festplattenlaufwerke
  • physikalische und organisatorische Gewaltentrennung der Hardwareadministration und Softwareadministration und Kundensupport sowie des eigentlichen Kunden
  • VerschlĂŒsselung aller Dateien und Daten – “Encryption at Rest” – (das sind z.B. temporĂ€re Daten) durch aufteilen der Daten in 64KB große / kleine Teilchen, welche alle einzeln verschlĂŒsselt sind. (Der MasterschlĂŒssel fĂŒr jede einzelne Gesamtdatei liegt physikalisch in einem anderen Netzwerk)
  • Über die Liste der weiteren technischen und organisatorischen Maßnahmen kann man sich im Trustcenter informieren bzw. auch ĂŒber den Rechenzentrumsbetreiber (Rechenzentrum Sicherheit )

Maßnahmen durch den Kunden (unabhĂ€ngig ob Cloud oder lokal) – (ebenfalls nur als Auszug)

  • VerschlĂŒsselung von Dateninhalten mit Azure RMS
  • dedizierte Berechtigungsgruppen und Rollenkonzepte (aber wer macht das schon…?)
  • Einsatz von Bitlocker (FestplattenverschlĂŒsselung)
  • Einsatz von SMB 3.0 Clients (Microsoft Azure Blob Share unterstĂŒtzt SMB 3.0 !) zur VerschlĂŒsselung der DatenĂŒbertragung
  • Einsatz von Gruppenrichtlinien
  • Einsatz von “Revisionsicherem” Storage in der Cloud (hierzu kommt demnĂ€chst ein Artikel von mir als Managed Service Lösung)

INHO (als persönlicher Beitrag): Solange die eigene Umgebung oder die eigenen Prozesse keine Sicherheit und / oder keine Konzepte kennen, ist der Speicherort so ziemlich egal. Denn der Speicherort eine Datei alleine ergibt keine ausreichende Sicherheit. Und ich möchte behaupten, dass wenn nur 50% der lokalen Daten mit sauberen Prozessen und Konzepten in Azure gespeichert werden, diese 99% sicherer sind, als da, wo sie heute lagern.

Aber nun ja. ich hoffe, ich konnte mit dem Artikel wieder dem einen einem oder anderem weiterhelfen.

Gruss

Michael

Ach… hier ist noch ein kleines Video

 

The short URL of the present article is: http://wp.me/p1MQAv-16w

Tagged with:

Filed under: AzureCloudInfrastructureManaged ServicesSecurity