Das Microsoft Entra Admin Center ist der Zusammenschluss mehrerer Microsoft Cloud Identitätsdienste, welche Euch ermöglichen eine zentrale Verwaltung Eurer - ob rein in der Cloud oder innerhalb einer hybriden Bereitstellung - Benutzer, Gruppen und der allgemeinen Identity Governance durchzuführen.
In diesem Beitrag möchte ich Euch gerne die unterschiedlichen Bestandteile und Möglichkeit des Entra Admin Centers aufzeigen. Hierbei lege ich besonders einen Fokus auf die Security-Funktionalitäten, die uns das Entra Admin Center bietet.
Woraus besteht das Entra Admin Center?
Das Microsoft Entra Admin Center ist nicht so sehr ein eigenes Produkt oder eine Lösung an sich, sondern eine Kombination verschiedener Lösungen, die zusammen dazu beitragen Identitäten innerhalb der Microsoft Cloud und auch in lokalen IT-Infrastrukturen durch Microsoft-Lösungen zu schützen.
Nach aktuellem Stand besteht die Microsoft Entra-Produktfamilie aus folgenden Produkten:
Das Azure Active Directory
Azure Active Directory ist Microsofts cloudbasierte Identity- und Access-Management (IAM, )-Lösung.
Es bildet die zentrale Grundlage für mehrere Microsoft Online-Dienste wie Microsoft 365, Dynamics und Azure. Das Azure Active Directory kann in andere Cloud-Lösungen und Plattformen integriert werden. Es kann ebenfalls Anwendungen und Plattformen unterstützen, die lokal betrieben werden - hierzu ist eine entsprechend starke Lizenzierung erforderlich. Einen Überblick zu den Lizenzen in der Enterprise Mobility & Security-Suite findet Ihr hier.
Zusammen mit den anderen Lösungen aus der Microsoft Entra Produktfamilie deckt Azure Active Directory nahezu alle Aspekte ab, die man von einer modernen Identity- und Access-Management-Lösung erwarten würde.
Cloud, Hybrid oder lokal?
Identity-Modelle und Authentifizierung
Bei der Betrachtung des Azure Active Directory und seinem Identity-Management stellen wir fest:
Es stehen in Summe zwei (mitunter auch in drei aufgeteilt) Identitätsmodelle zur Verfügung: Cloud-only-Identitäten und Hybrid-Identitäten.
Welches Identitäts-Modell man wählt, hängt von mehreren Elementen ab, wie z.B. ob und wie bestehende Systeme ins Azure Active Directory integriert werden können.
Darüber hinaus können auch rechtliche oder regulatorische Anforderungen (z.B.: Ablageort des Password-Hashes oder GDPR-Vorgaben) die Wahl für das eine oder andere Modell beeinflussen.
In den Anfängen von Office 365 haben die meisten Organisationen ein Hybrid-Identitätsmodell angenommen, bei dem das lokale Active Directory zur Authentifizierung über Active Directory Federation Services (AD FS) genutzt wurde. Obwohl das auch heute noch eine Option ist, ist die Verwendung von Cloud-only-Identitäten, selbst in hybriden Szenarien mit einem starken On-Premises-Footprint durch zusätzliche Optionen, wie die Pass-Through-Authentication, einfacher geworden.
Cloud-Only Identitäten
Cloud-only-Identitäten nur in der Cloud. Sie werden in und durch das Azure Active Directory verwaltet.
Dies ist das Standard-Identitätsmodell beim Erstellen eines neuen Cloud-Mandanten. Wenn wir uns in einer Hybridumgebung befinden und wir uns für cloud-only-Identitäten entscheiden, besteht zunächst keine Beziehung zwischen den lokalen Identitäten und denen in der Cloud.
Würde man diesen Stand so beibehalten, wäre das Ergebnis das alle Aktivitäten im Zusammenhang mit diesen Identitäten separat durchgeführt werden müssen, einschließlich der Erstellung von Identitäten, der Passwortverwaltung, der Zuweisung von Gruppenmitgliedschaften usw. Dies versucht man normalerweise durch die Herstellung einer Verbindung mit dem Azure AD Connect zu verhindern
Antworten auf diese und Fragen beeinflussen die Entscheidung, ob wir auf cloud-only-Identitäten setzen sollten oder nicht. Eine kleine grobe Faustregel, die man anwenden kann ist:
Für Organisationen mit begrenzter Infrastruktur vor Ort sind Cloud-only-Identitäten die beste Wahl. Nicht nur aus funktioneller und kostentechnischer Sicht, sondern auch aus Security-Perspektive: Es müssen keine Vor-Ort-Server verwaltet und gehärtet werden, um dieses Identitätsmodell zu unterstützen.
Hybride Identitäten
Organisationen mit einer On-Premises-Infrastruktur nutzen in der Regel Active Directory als ihre primäre Identitäts- und Zugriffsmanagementlösung.
Dadurch kontrollieren sie den Zugriff auf Server, Anwendungen und andere Ressourcen, die mit dem Verzeichnis verbunden sind. Solche Unternehmen neigen eher dazu, ein hybrides Identitätsmodell in Betracht zu ziehen, wenn sie Microsoft 365 als Cloud-Lösung implementieren, da es bedeutet, dass Objekte lokal verwaltet und mit den Azure Active Directory synchronisiert werden - dies ermöglicht die Erweiterung der lokalen Infrastruktur um die Möglichkeiten der Benutzerverwaltung in der Cloud. Obwohl am Ende Identitäten in beiden Systemen vorhanden sind, bleibt das lokale Verzeichnis die primäre Verwaltungsplattform.
Synchronisierung des lokalen Passworts
Wenn Passwort-Hash-Synchronisierung (PHS) aktiviert ist, werden Passwort-Hashes aus dem lokalen Active Directory auch in Azure Active Directory synchronisiert.
Dies bedeutet, dass Benutzer dasselbe Passwort in der Cloud wie im lokalen Verzeichnis verwenden. Ohne PHS wäre das Passwort, das im Azure Active Directory verwendet wird, nicht nur unterschiedlich von dem im lokalen Verzeichnis, sondern müsste auch entsprechend unabhängig voneinander verwaltet werden, was nicht nur administrativ für einen höheren Aufwand sorgt, als auch erwartungsgemäß bei den Benutzern für potenzielle Verwirrung in der täglichen Nutzung sorgen könnte.
Neben der Synchronisierung von Passwörtern aus der lokalen Organisation ins Azure AD können auch weitere Funktionen, wie z.B.: das Zurückschreiben von Passwörtern aktiviert werden.
Ist PHS unsicher?
Viele Unternehmen verstehen nicht vollends, wie die Synchronisation von Passwort-Hashes funktioniert, und halten PHS daher für unsicher. Überprüfen wir einmal wie eine Synchronisierung der Passwörter funktioniert:
- Der Passwortsynchronisations-Agent, der auf dem Azure AD Connect-Server installiert ist, fordert alle zwei Minuten die Passwort-Hashes aus der lokalen Active Directory an. Diese Anfrage erfolgt über das Standard-MS-DRSR-Protokoll, das zur Synchronisation zwischen Domain Controllern verwendet wird. Das die Azure AD Connect verwendeten Dienstkonten in der lokalen Organisation über die entsprechende Berechtigungen verfügen müssen - diese werden dann auch bei der Installation des Azure AD Connect gesetzt - , um die Passwort-Hashes zu erhalten.
- Bevor die Hashes an Azure AD Connect gesendet werden, verschlüsselt der Domain Controller die MD4 Passwort-Hashes mit einem Schlüssel, der mit dem MD5-Hash des RPC-Sitzungsschlüssels und einem zusätzliche String erstellt wird. Um sicherzustellen, dass das Azure AD Connect den Inhalt entschlüsseln kann, wird der String zusammen mit den verschlüsselten Passwort-Hashes gesendet.
- Sobald der Azure AD Connect-Server die Passwort-Hashes empfangen hat, generiert er einen Schlüssel, um die empfangenen Daten wieder in ihr ursprüngliches MD4-Format zu entschlüsseln. Hierbei verwendet er den String, den er zusammen mit den verschlüsselten Hashes erhalten hat. Wichtig ist hierbei zu beachten, dass der Azure AD Connect-Server keinen Zugriff auf Klartext-Passwörter hat; alle Passwörter sind in ihrem ursprünglichen MD4-Format.
- Bevor Passwörter mit dem Azure Active Directory synchronisiert werden, werden zuerst einige Schritte durchgeführt:
- Alle Passwort-Hashes werden auf 64 Byte erweitert. Zunächst wird der Hash in eine 32-Byte-Hexadezimalzeichenfolge umgewandelt. Dann wird die Zeichenfolge unter Verwendung von UTF-16-Kodierung wieder in binäre Form umgewandelt.
- Der Synchronisations-Agent fügt jedem 64-Byte-Binärpasswort-Hash einen String von 10 Byte pro Benutzer hinzu. Dies geschieht, um den ursprünglichen Hash weiter zu schützen.
- Der MD4-Hash und der Benutzer-spezifische String werden kombiniert und als Eingabe an die PBKDF2-Funktion, eine kryptografische Funktion zur Derivation von Schlüsseln, bereitgestellt. Die Funktion wird 1000-mal mit dem HMAC-SHA256-Schlüsselhashing-Algorithmus iteriert. Das Ergebnis davon wird mit dem Benutzer-spezifischen String und der Anzahl der SHA256-Iterationen verkettet.
- Schließlich wird das Ergebnis der oben beschriebenen Aktionen mit dem Azure Active Directory synchronisiert. Dies erfolgt über eine sichere Verbindung (TLS).
Wenn sich ein Benutzer mit einem synchronisierten Passworthash bein Azure Active Directory anmeldet, wird das eingegebene Passwort durch denselben Prozess wie oben beschrieben ausgeführt. Wenn das Ergebnis der Eingabe mit dem Hash übereinstimmt, der im Azure Active Directory gespeichert ist, ist das Passwort des Benutzers korrekt und wird anschließend erfolgreich authentifiziert. Andernfalls wird der Zugriff blockiert.
Pass-Through Authentication (PTA)
Einige Unternehmen haben interne und externen Anforderungen die voraussetzen, dass die Authentifizierung zu den Unternehmensressourcen in der haus-internen Kontrolle bleiben muss.
Das bedeutet im Wesentlichen, dass diese Organisationen die Authentifizierung vor Ort durchführen müssen, anstatt diese Rolle an Azure Active Directory zu übertragen, wie es bei Cloud-Konten oder synchronisierten Identitäten der Fall ist.
In Vor-PTA-Zeiten griffen Unternehmen in der Regel auf Active Directory Federation Services (AD FS) zurück. Jedoch haben nicht viele Organisationen das interne Wissen und somit auch die Ressourcen, um AD FS ordnungsgemäß zu installieren, zu warten und abzusichern.
Da es sich um eine Authentifizierungsplattform handelt, ist die Sicherheit des Dienstes und der Server, auf denen er läuft, äußerst wichtig. Die Einführung von AD FS in eine neue lokale IT-Umgebung, erhöht daher zunächst die Komplexität der Umgebung sowie deren Angriffsfläche. Dies gilt es dann auch in der IT-Sicherheitsstrategie zu berücksichtigen.
Um somit dieses Risiko zu reduzieren, die Komplexität zu verringern und dennoch die Möglichkeit zu bieten, die gesetzten Anforderungen zu erfüllen, hat Microsoft die Pass-Through-Authentifizierung eingeführt.
PTA als Funktion stellt sicher, dass Authentifizierungsanfragen für das Azure AD an die lokale Organisation "weitergeleitet" werden. Erst wenn die lokale AD die Anfrage erfolgreich authentifiziert hat, werden die Verbindungen zum Azure AD geöffnet.
Um zu vermeiden, dass eingehender Traffic in die Umgebung geöffnet werden muss, nutzt die Pass-Through-Authentifizierung eine ausgehende Verbindung vom lokalen Agenten zu Azure AD.
Seamless Single Sign-On (SSO)
Bei Verwendung von PTA können Benutzer eine Single-Sign-On-Erfahrung erhalten:
Dies bedeutet, dass Benutzer ihr Passwort nicht erneut eingeben müssen, um auf Microsoft 365-Dienste zuzugreifen. Dies gilt für neuere Clients wie Windows 10 und Windows 11. Ältere Betriebssystemversionen wie Windows 7 oder Windows 8 haben diese Funktion nicht, selbst wenn PTA aktiviert ist.
Absicherung vom Azure Active Directory
Das Entra Admin Center bietet uns zahlreiche Möglichkeiten, um das Azure Active Directory abzusichern und somit die Sicherheit unserer Identitäten zu erhöhen - anbei einige der Möglichkeiten aufgelistet:
Weitere Möglichkeiten zur Absicherung der Microsoft 365 Umgebung habe ich in meinem Beitrag zur Microsoft Security hinterlegt.
Microsoft Entra Identity Governance
Identitätsmanagement ist ein Satz von Prozessen und Technologien gemeint, der verwendet wird, um den Zugang und die Kontrolle zu digitalen Ressourcen einer Organisation zu verwalten und zu kontrollieren.
Dies beinhaltet in der Regel die Definition und Durchsetzung von Richtlinien für die Benutzerauthentifizierung, Autorisierung und den Zugang zu Systemen und Daten.
Identitätsmanagement hilft Organisationen, sich gegen unbefugten Zugriff zu schützen und sicherzustellen, dass nur autorisierte Benutzer Zugriff auf die Ressourcen haben, die sie für ihre Arbeit benötigen.
Entitlement Management
Die Verwaltung von Zugriffsrechten ist ein wichtiger Bestandteil des Identitätsmanagements, da es dazu beiträgt, sicherzustellen, dass nur autorisierte Benutzer Zugriff auf die Ressourcen haben, die sie für ihre Aufgaben benötigen.
Historisch gesehen war das Gewähren von Zugriff auf Ressourcen, in der Regel durch Zuweisen von Berechtigungen, eine Aufgabe, die den Administratoren vorbehalten war. Mit dem Wachstum des digitalen Bestands – und damit auch der Anzahl der Zugriffsrechte – kann das Verfolgen von Berechtigungen jedoch schnell zu einer Überlastung der Administratoren führen.
Um die Arbeit in Bezug auf die Zuweisung granularer Berechtigungen zu reduzieren, könnte man versucht sein, den Umfang der Berechtigungen zu erhöhen, damit jeder Zuweisung Zugriff auf mehr Ressourcen gewährt, was die Anzahl der Male verringert, in denen Berechtigungen erteilt werden müssen. Dies mag aus Effizienzgründen sinnvoll sein, aber absolut nicht aus Sicherheitssicht!
Oft werden Berechtigungen auf der Grundlage von Gruppenmitgliedschaften erteilt, und der Besitz dieser Gruppen wird dann an die Geschäfts- oder Anwendungsinhaber delegiert. Diese Art der Delegation wird manchmal auch als "Shift-Left" in Bezug auf Verantwortlichkeiten bezeichnet. Die Delegation, wer Gruppenmitgliedschaften kontrollieren kann, ist ein guter erster Schritt, bietet jedoch nicht immer ausreichende Flexibilität.
Es gibt keinen User-Self-Service, und die Benutzer müssen immer noch (manuell) mit denjenigen in Kontakt treten, der für die Verwaltung zuständig ist. Die Microsofts Lösung "Entitlement Management" zielt darauf ab, vordefinierte Berechtigungssätze, auch Access Packages genannt, zu bestimmen.
Benutzer können dann Zugriff auf diese Pakete beantragen, wonach ein Workflow gestartet wird, der eine Genehmigung sucht. Sobald die Genehmigung erteilt wurde, gewährt das System – in diesem Fall das Azure AD – dem Benutzer die zugehörigen Berechtigungen.
Privileged Identity Management
Privileged Identity Management ist ein Service in Azure AD, der es Unternehmen ermöglicht, den Zugriff auf Azure AD-Rollen und Azure-Ressourcen zu verwalten.
Das Konzept baut darauf auf, nicht mehr 24/7-Admin-Zugriff zu gewähren, sondern diese bei Bedarf und nur die jeweils maximal erforderlichen Rechte zu vergeben.
Im Kern kann man dies wie folgt widerspiegeln:
Microsoft Entra Permissions Management
Entra Permissions Management ist eine Lösung, die aus Microsofts Übernahme von CloudKnox im Jahr 2021 hervorgeht.
Es handelt sich um eine Cloud-Infrastruktur-Berechtigungsverwaltungslösung (CIEM), die Sichtbarkeit und Kontrolle über Berechtigungen in Cloud-Infrastrukturplattformen wie Microsoft Azure, Google Cloud Platform und Amazon Web Services bietet.
Es hat im Kern einen ähnlichen Ansatz, wie wir ihn auch von einem SIEM her kennen, jedoch ist hier der Cloud-Aspekt noch mehr im Fokus und nicht so sehr die lokale Integration.
Entra Admin Center - Login und Portal
Den Login zum Entra Admin Center finden wir über das Microsoft 365 Admin Center.
Alternativ habe ich den Link zum Portal auch direkt hier hinterlegt.
Microsoft Entra Workload Identities
Workload-Identitäten sind nicht unbedingt ein separater Identitätstyp, sondern vielmehr ein Begriff, den Microsoft geprägt hat, um auf Anwendungen, Dienstprinzipale und verwaltete Identitäten zu verweisen.
Diese Objekte werden häufig verwendet, um Anwendungen den Zugriff auf Ressourcen wie Postfächer oder SharePoint-Websites in Microsoft 365 sowie auf Key Vaults oder virtuelle Maschinen in Azure zu ermöglichen.
Microsoft Entra Applikationen
Eine Anwendung, die durch eine App-Registrierung in Azure AD dargestellt wird, ist die Definition (virtuelle Darstellung) einer Anwendung innerhalb des Entra Admin Centers.
Die Applikation als Objekt definiert dabei mehrere Aspekte:
Die App-Registrierung dient auch als Blaupause für die Erstellung von Dienstprinzipalen, die auf die Anwendung verweisen, entweder im eigenen Tenant bzw. Mandanten oder in Drittanbieter-Mandanten, in denen die Anwendung verwendet wird. .
Microsoft Entra Dienstprinzipal
Bevor jemand oder etwas auf Ressourcen zugreifen kann, die vom Azure AD gesichert sind, muss diese erfolgreich authentifiziert und autorisiert werden.
Dazu müssen die dazu erforderlichen Entitäten durch ein Objekt im Mandanten dargestellt werden - hier kommen unsere Dienstprinzipale ins Spiel.
Beispielsweise werden Benutzer durch ein Benutzerobjekt (auch Benutzerprinzipal genannt) und Anwendungen durch ein entsprechendes Anwendungsobjekt, als auch Dienstprinzipal dargestellt.
Innerhalb des Azure Active Directory gibt es verschiedene Arten von Dienstprinzipalen:
Entra Admin Center: Fazit und Blog
Ich hoffe Dir in dem Beitrag gezeigt zu haben, welche Möglichkeiten uns das Entra Admin Center bietet.
Schau Dir doch auch die anderen Tutorials und Tipps an, die ich bereits auf meinem Blog geteilt habe. Ich bin stehts bemüht, die aktuellsten Themen und Fragestellungen meiner Kunden zu beantworten, um Dich bei der Arbeit mit der Microsoft Cloud Security und anderen Microsoft 365 Produkten zu unterstützen!