Oft werde ich gefragt, was ist eigentlich dieses Azure-AD? Ich dachte mir, der Frage kann ich eigentlich auch mal eine Blogreihe widmen, schließlich wird es immer wichtiger. In dieser Reihe werde ich neben den Themen auch auf die Authentifizierungsmethoden, Arten von Identitäten und Objekten, auch über Lizenzen und Kompatible Dienste schreiben. Kurz um, über alles rund um Azure Active Directory.
Was ist Azure-AD?
Das Microsoft Azure-AD (Auch AAD abgekürzt) ist ein Authentifizierungsdienst in der Microsoft Cloud. Dieser wird Global betrieben und ist Hochverfügbar. Eine Unterscheidung nach geographischen Regionen findet bei diesem Dienst im Vergleich zu anderen Microsoft Clouddiensten nicht statt. Dieser Dienst wird als Primäre Authentifizierungsmöglichkeit für die geschäftlichen Microsoft Cloud Anwendungen genutzt. Eine Besonderheit ist, dass er mit dem Lokalen Active Directory partiell synchronisiert werden kann. Synchronisierte und nicht Synchronisierte Objekte werden unterschiedlich behandelt. Das bringt uns zum nächsten Thema:
Arten von Objekten
Die wichtigsten Objekte im Azure-AD sind dieselben wie in einem Aktive Directory im Unternehmen: Benutzer, Gruppen und Computer. Der Fokus liegt beim Azure AD klar auf Identität, für andere Funktionen sieht Microsoft alternative Lösungen in der Cloud.
Was fehlt an Funktionen und Objekten?
Da es sich bei Azure-AD um ein Identitätsbasiertes Produkt handelt, fehlen hier manche Funktionen, die es in einem Active Directory im Unternehmen zusätzlich gibt. Für diese Funktionen gibt es teilweise alternative Produkte in Azure, diese sind aber in den seltensten Fällen identisch. Hier ein paar Beispiele:
DNS
Es gibt einen AzureDNS Dienst, dieser richtet sich aber an öffentliche DNS Zonen und ist nicht für Private Zonen geeignet. Nach der Idee von Microsoft gibt es aber auch in einem Azure-AD keine privaten Netze mehr, sondern alle sind im Internet.
Gruppenrichtlinien
Was den GPO am nächsten kommt in der Azure Welt sind Richtlinien in der MDM Lösung Intune. Diese enthalten als Vorschau auch eine Funktion die den Administrativen Vorlagen nachempfunden ist, aber sehr rudimentär.
Arten von Objekten
Die Synchronisierten Objekte
Objekte die vom Lokalen Active Directory im Unternehmen, man spricht auch von On-Premise, existieren, können in das Azure-AD synchronisiert werden. Dabei können die Objekte eingegrenzt werden, zum Beispiel nur die Mitglieder einer Gruppe werden synchronisiert. Aber es ist auch möglich die Replizierten Attribute der Objekte einzuschränken. Dies ermöglicht auch Datensparsamkeit, in dem nur die benötigten Attribute und Objekte synchronisiert werden. Die einzige Schwierigkeit bei dieser Idee ist, dass es keine Liste gibt, welcher Dienst welche Attribute nutzt. Zu Mindestens kenne ich die nicht, wenn ihr eine solche Liste gefunden habt, lasst es mich bitte wissen.
Eine weitere Besonderheit ist, dass diese Objekte im lokalen AD gepflegt werden müssen, zu Mindestens die synchronisierten Attribute. Ein Beispiel hierfür ist zum Beispiel das Attribut „ProxyAddresses“ welches vom Exchange auch für die E-Mail Adressen und Aliase genutzt wird. Die Exchange spezifischen Attribute werden bei Office365 aber in der Cloud gepflegt.
Dies kann die Administration vor ein paar Herausforderungen stellen. Deshalb empfehle ich bei hybrid Szenarien immer die PowerShell zu nutzen. Ein Beispiel ist das Anlegen von neuen Benutzern, dies habe ich bereits im Artikel „Benutzer einfachen anlegen mit PowerShell“ beschrieben.
Es gibt aber auch Attribute, die von der Cloud zurückgeschrieben werden können, wenn es vom Administrator eingerichtet wurde. Ein Beispiel ist das Kennwort, wodurch eine Möglichkeit geschaffen werden kann, dass die Benutzer ihr Kennwort selbst zurücksetzten können.
Was die Anmeldemöglichkeiten betrifft, komme ich später darauf zu sprechen.
Die Cloudbasierten Objekte
Neben den Synchronisierten Objekten kann ich auch rein Cloudbasierte anlegen. Diese werden vollständig in Azure-AD verwaltet. Die Verwendungsmöglichkeiten entsprechen den Synchronisierten. Es ist nur kein SSO mit Unternehmenslokalen-Konten möglich, da die Verknüpfung mit den lokalen Konten fehlt. Mehr zu diesem Thema, wenn es um Authentifizierung geht.
Typische Szenarien sind externe Mitarbeiter die bestimmte Online Ressourcen, aber keine Ressourcen in der lokalen Infrastruktur nutzen sollen. Es gibt auch erste Firmen die vollkommen ohne lokale IT arbeiten und alles in der Cloud haben. Zugegeben, erst wenige, denn für die meisten ist dieser Weg technisch aufgrund von Abhängigkeiten noch nicht möglich.
Ein weiteres Beispiel für Cloudbasierte Objekte sind Azure-AD Gruppen. Diese werden zum Beispiel für Teams oder Office365-Groups genutzt. Auch gibt es Dynamische Gruppen in Azure-AD die zum Beispiel für Intune oder Autopilot genutzt werden, die nicht ins Lokale AD synchronisiert werden. Hier kann manchmal die richtige Verschachtelung mit Lokalen Gruppen eine der Herausforderungen sein. Eine Nutzung aber im Lokalen AD ist für diese Gruppen nicht möglich.
Schreibe einen Kommentar