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