Azure Active Directory – Teil II

Szenarien der Identitätsverwaltung

Im ersten Teil dieser Serie habe ich einen allgemeinen Überblick über das Azure Active Directory (AAD) gegeben. In diesem Teil möchte ich die Möglichkeiten beschreiben, wie sich ein Azure AD integrieren lässt.

Welche Anbindung ?

Bei der Einführung von Microsoft 365 Diensten stellen sich für alle Kunden die gleichen Fragen. Welche Art der Anbindung ist sinnvoll ? Es existieren 2 grundsätzliche Szenarien, um Benutzerkonten in Microsoft 365 zu verwalten.

Eigenständige Identitätsverwaltung

In diesem Modell sind die Benutzerkonten nur in der Microsoft 365-Umgebung vorhanden und nicht mit dem lokalen Active Directory (AD-Gesamtstruktur) des Kunden verknüpft. Dies bedeutet dann in der Praxis häufig, dass ein Anwender sowohl ein Benutzerkonto im lokalen Active Direcory des Unternehmens hat und zusätzlich ein weiteres Benutzerkonto Azure Active Directory des M365 – Tenants des Unternehmens.

Diese Konten haben unter Umständen den gleichen Benutzernamen und das gleiche Kennwort. Dies kann auch weitere Attribute betreffen, die jedoch separate und unabhängige Objekte darstellen und dementsprechend unabhängig verwaltet werden müssen. Diese bedeutet aus administrativer Sicht doppelten Verwaltungsaufwand und das Risiko eintretender Fehler (Attribut-Konflikte etc. > Teil III der Serie)

Hybride Identitätsverwaltung

In diesem Modell werden Benutzerkonten im lokalen Active Directory des Unternehmens erstellt und verwaltet und anschließend mit dem Azure Active Directory synchronisiert. Die Synchronisation wird von einem Verzeichnissynchronisationsserver (Azure AD Connect) durchgeführt.

Im hybriden Identitätsmodell ist die lokale AD-Gesamtstruktur in der Regel das „führende Verzeichnis“, wobei lokale AD-Objekte und Attribute in die Cloud repliziert werden. Da das lokale AD das führende Verzeichnis darstellt, kann ein Administrator nur begrenzt Aspekte der synchronisierten Identität in Azure AD anpassen.

Beide Methoden der Identitätsverwaltung haben Ihren eigenen Vor- und Nachteile:

In Azure AD verwaltete Identitäten sind praktisch, da Unternehmen kein lokales Active Directory benötigen. Viele kleinere Unternehmen (>299 Lizenzen), die Microsoft 365 verwenden, haben oder möchten kein lokales Active Directory. Wenn jedoch ein lokales Active Directory vorhanden ist, kann die Verwaltung von Cloud-Identitäten zeitaufwändiger sein, da für jeden Benutzer zwei separate Konten (Lokales AD-Konto & Cloud-Konto) verwaltet werden müssen.

In der Praxis lässt sich keine reine Empfehlung aussprechen, ab welcher Unternehmensgröße die Verwaltung von Benutzerobjekten durch eine Synchronisation (Azure AD Connect) der Identitäten sinnvoller ist. In der Regel kommt es darauf an, wie viel Zeit und Mühe ein Administrator in die Verwaltung doppelter Identitäten investieren muss, anstatt eine Synchronisierungsinfrastruktur zu warten.

Hybride Identitäten vereinfachen die Verwaltung, da alle Änderungen normalerweise am lokalen AD vorgenommen und dann vom Azure AD Connect mit dem Azure AD synchronisiert werden. Das hybride Identitätsmodell hindert Unternehmen nicht daran, eigenständige Identitäten zu erstellen und zu verwenden (z. B. für die von Office 365-Gruppen erstellten Gruppenobjekte oder für externe Benutzer, die nur Zugriff auf Office 365-Ressourcen benötigen).

Unternehmen können Ihrer hybriden Identitäts-Architektur optional einen Identitätsverbund (Active Directory Federation Service oder Anwendungsauthentifizierung in Azure AD)  hinzufügen. Durch die Föderation können Unternehmen steuern, wie Sicherheitsrichtlinien wie Anmeldezeiten, Multi-Faktor-Authentifizierung von Drittanbietern und Netzwerkstandorte, von denen Benutzer auf Microsoft 365-Ressourcen zugreifen können, durchgesetzt werden.

Die meisten zusätzlichen Steuerelemente, die der Verbund anbietet, sind auch nativ in Azure AD verfügbar, wenn Kunden über Azure AD Premium (Pläne P1 oder P2) verfügen.

Es ist wichtig, sich daran zu erinnern, dass die Infrastruktur des Identitätsverbunds skaliert werden muss, um die Leistungs- und Workload-Anforderungen zu erfüllen. Es muss außerdem hoch verfügbar und ausfallsicher (Redundante ADFS-Server, Web Application Proxys, SQL-Datenbanken) sein, da Office 365 Benutzeranmeldungen möglicherweise nicht authentifizieren kann, wenn der Verbunddienst nicht verfügbar ist.

Unternehmen können eine Mischung dieser beiden Modelle bereitstellen. Obwohl es üblicher ist, sich auf ein einziges Identitätsmodell zu einigen, können Unternehmen verschiedene Identitätslösungen kombinieren, um ihren spezifischen Anforderungen gerecht zu werden. Letztendlich hängt die Entscheidung, welches Identitätsmodell verwendet werden soll, von den geschäftlichen und technischen Anforderungen der Organisation ab.

Ausnahme bei Dienstkonten

Nicht alle im Unternehmen verwendete Konten gehören Benutzern. Für einige Anwendungen von Drittherstellern (z. B. Backup– oder Archivierungslösungen, Monitoring/ SIEM) benötigen in der Regel im Azure AD spezielle Dienstkonten, die ausschließlich für Verwaltungszwecke verwendet werden. Diese Konten benötigen normalerweise kein Postfach oder keine Lizenz, benötigen jedoch möglicherweise die Zuweisung von Administratorrechten, um Daten im Namen des Tenants anzeigen und darauf zugreifen zu können.

In den meisten Fällen werden Die Dienstkonten so erstellt, dass ihre Kennwörter niemals ablaufen. Dies erfolgt auf der Grundlage, dass die Verwaltung des Kennwortablaufs für Dienstkonten häufig komplex und zeitaufwändig ist. Während das Festlegen von Dienstkontokennwörtern so, dass sie niemals ablaufen, der Weg des geringsten Widerstands ist, sollten Administratoren Dienstkontokennwörter regelmäßig auf dieselbe Weise ändern, wie die Passwörter lokaler administrativer Konten.

Die Konfiguration eines Kennworts, das niemals ablaufen soll, lässt sich mit Unterstützung von PowerShell recht simpel umsetzen. Im ersten Beispiel unten wird das Flag „Kennwort läuft nie ab“ für ein Dienstkonto gesetzt.

PS] C:\> Get-AzureADUser -ObjectID SVC_AvePoint-BackupAgent@torbenritter.com –PasswordPolicies „DisablePasswordExpiration“

Im zweiten Beispiel werden die Benutzerkonten gescannt und diejenigen gemeldet, für die dieses Flag gesetzt ist.

[PS] C:\> Get-AzureADUser | Where {$_.PasswordPolicies –eq „DisablePasswordExpiration“} | Format-Table DisplayName, UserPrincipalName

HINWEIS:

Dies betrifft ausschließlich Konten im Azure AD. Wenn Administratoren ein Konto über das lokale AD synchronisieren und die Kennwortsynchronisierung aktiviert ist, wird das Kennwort des entsprechenden Cloud-Kontos automatisch so festgelegt, dass es nicht abläuft. Das Passwort des lokalen Kontos läuft nicht ab.

Es muss beachtet werden, dass ein Administrator bei einer erfolgreichen Aktualisierung der Kennwortrichtlinie keine Benachrichtigung erhalten wird. Wenn jedoch ein Fehler auftritt, wird eine Meldung angezeigt.

Im Teil III dieser Serie beschreibe ich die möglichen Synchronisationsmöglichkeiten über das kostenfreie Tool „Azure AD-Connect“ Richtung Azure Active Directory.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.