AzureAD P1

Auf dieser Seite lesen Sie, warum Office 365 E3 und E5-Pläne zwar umfangreich aber meist für einen sicheren Betrieb nicht ausreichend sind. Sie sollten auf jeden Fall die Funktionen von Azure P1 kennen und in ihre Kalkulation mit aufnehmen. Hier steht warum:

Weckruf: Jedes Gerät ist ein Client!

Stellen Sie sich vor, Sie haben gerade Office 365-Lizenzen gekauft. Das kann E3, E5, aber auch E1 oder die einzelnen Pläne für Exchange o.ä., sein. Sie nutzen das Office 365 Identity Management um die Benutzer im AzureAD und damit auch Office 365 anzulegen und über die Authentifizierung erlauben Sie den Zugriff auf die bereits nach Office 365 migrierten oder dort z.B. in Teams oder OneDrive angelegten Daten.

Irgendwann wird ihnen aber bewusst, dass die Anwender mit ihrem bekannten Benutzernamen und Kennwort diese Daten jederzeit und überall erreichen können. Überspitzt ausgedrückt: Jeder Mitarbeiter kann auf seinem privaten Consumer-Notebook oder Tablet nun das Postfach der Firma einbinden und die Daten per OneDrive nutzen und auch Word, Excel, PowerPoint einfach installieren, wenn Sie keine Vorkehrungen treffen. Es ist dabei erst mal egal, ob sich die Anwender per Cloud Kennwort, Pass-Through Authentifizierung (PTA) oder Office 365 - ADFS Anmeldung gegenüber der Cloud authentifizieren.

Spätestens jetzt habe ich die Aufmerksamkeit der Kunden und die Fragestellung, wie der Zugriff auf die Daten z.B. auf Firmengeräte oder generell auf "Compliant Devices" beschränkt werden kann.

Sofern der Kunde eine Anmeldung per On-Premises-ADFS nutzt, gibt es tatsächlich auch ohne AzureAD P1 Möglichkeiten zur Kontrolle. Alle Cloud-Dienste lassen nämlich nur authentifizierte Zugriffe durch, und dazu benötigt der Anwender zwingend ein OAUTH-Token, welches vom lokalen ADFS-Server oder in den anderen Fällen von der Cloud ausgestellt wird. Beim lokalen ADFS-Server können Sie natürlich steuern, wer so eine Token bekommt. Der On-Premises-ADFS-Server kann z.B. für Anwender nur über VPN erreichbar gemacht werden, so dass firmenfremde Geräte ohne VPN den Service gar nicht erreichen. Denkbar sind auch die eingebauten ADFS-Funktionen wie einem zweiten Faktor oder eine Beschränkung auf "Intranet" oder gleich die Nutzung von Benutzerzertifikaten. Sie steuern dann über das Rollout von Zertifikaten zu Anmeldung, und bitte "nur" zur Anmeldung, um SMIME, EFS u.a. Dinge damit nicht auch zuzulassen, wer ein Ticket vom ADFS-Server bekommt und damit auf Dienste in der Cloud zugreifen kann. In der Vollausbaustufe ist sogar eine "Device Registration" möglich, bei dem sich die Endgeräte registrieren und damit der Zugriff beschränkt wird.

Andere Firmen schalten vor ihren On-Premises ADFS-Service einen eigenen Reverse-Proxy mit entsprechender Pre-Authentication u so leistungsfähige Filter umzusetzen. Auch das ist möglich und habe ich auf ADFS Proxy beschrieben.

Sobald ich diese große Frage angesprochen habe, muss ich natürlich auch AzureAD P1 Conditional Access als Option mit aufführen. Azure AD P1 ist aber nicht kostenfrei, sondern pro Benutzer und pro Monat zu lizenzieren. Aber es gibt durchaus Gründe, sich das Paket genauer anzuschauen.

Ich würde heute fast behaupten wollen, dass AzureAD P1 zu jedem E3 oder E5-Vertrag dazu gebucht werden müsste, denn die Basis-Versionen sind nicht ausreichend. Vielleicht ändert Microsoft noch mal die Inhalte oder verbilligt oder integrierte P1, aber das ist nur ein Wunsch.

Schauen Sie sich aber auf jeden Fall schon mal die folgende Übersicht an

In jeder E1, E3, E5-Lizenz ist "Azure Basic" mit enthalten und dann verstehen Sie, was die verschiedenen Zusatzfunktionen von AzureAD P1 für ihren täglichen Betrieb bedeuten können.

Von den 16 hier allein in AzureAD P1 aufgeführten Komponenten beschreibe ich eine Teilmenge.

Conditional Access

Wenn die Forderung "Zugriff nur von Firmengeräten" lautet, dann ist natürlich "Conditional Access" interessant. Diese Funktion von Azure erlaubt es dem Administrator, ganz gezielt den Zugriff zu steuern, d.h. abhängig von verschiedenen Kriterien zu erlauben oder zu unterbinden. Dazu gehören

  • IP-Adresse
    Dieses Kriterium ist ideal, um z.B. Anwender aus dem Firmennetzwerk, die alle über die gleichen bekannten statischen IP-Adressen bei Office 365 ankommen, zuzulassen. Beachten Sie dabei aber, dass das Gäste-LAN nicht die gleichen Adressen nutzt. Sonst kann ein Anwender auch von hier sein Privatgerät einbinden.
  • Geräteklasse
    Damit lassen sich Windows PC und verschiedene Smartphones unterscheiden. Sie können z.B.: den Zugriff auf ActiveSync auf bestimmte Smartphone-Versionen beschränken und damit die "Mail Kachelapp" auf Windows 10 aussperren.
  • Geräte
    Wenn Sie die Geräte im AzureAD verwalten, dann können Sie den Zugriff auch auf einzelne Geräte oder über Gruppen zusammengefasste Geräte steuern

Beim Conditional Access in der Cloud können Sie diese Regeln auch für jede Applikation getrennt verwalten. So können Geräte z.B. ActiveSync nutzen aber kein OWA. Sie könnten z.B. auch den Zugang zum Admin-Portal für Administratoren  auf bestimmte Endgeräte, Standorte oder mit einem weiteren Faktor absichern.

Es gibt hier also sehr viele Möglichkeiten und Kombinationen: Ohne eine saubere Planung und Testphase sollten Sie nicht mal eben an den Einstellungen etwas drehen. Es soll durchaus schon passiert sein, dass sich ein Administrator selbst ausgesperrt hat. Diese Regel zu entfernen geht dann nur noch über den Microsoft Support. Daher am besten immer erst eine "Allow"-Regel für ein besonderes Konto hinterlegen.

GroupBased Licensing

Auf der Seite Office 365 Lizenzen mit Azure Groups habe ich umfangreich beschrieben, wie sie Azure Gruppen nutzen können, um die entsprechenden Lizenzen für die Clients zuzuweisen. Diese nützliche Funktion erfordert aber ebenfalle Azure AD Premium Plan 1. Allein für diese Funktion würde ich natürlich kein P1 lizenzieren. Die Vergabe der Lizenzen können Sie nämlich auch per PowerShell als Skript (siehe Office 365 Lizenzverwaltung) oder eine Provisioning-Lösung machen.


Quelle: What is group-based licensing in Azure Active Directory?
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-licensing-whatis-azure-portal

Wenn Sie aber kein E3 oder höher haben, sondern nur E1 oder F1/F3, dann benötigen Sie AzureAD P1 für diese Benutzer, wenn sie in LIzenzgruppen Mitglied sind.

Outlook Message Encryption und AIP

Das Thema RMS hat mittlerweile den Name "Azure Information Protection (AIP)" bekommen und ist durchaus für Firmen interessant, die die Information selbst sichern und klassifizieren wollen. Sie müssen dann nicht jeden Übertragungsweg (USB-Stick, Netzwerk, VPN) und jeden Speicherplatz (USB-Stick, lokale Disk, OneDrive etc.) gesondert absichern. Die Information selbst nur nur den berechtigten Personen zugänglich und dieser Schutz basiert nicht aus ACLs sondern eben auf der Verschlüsselung der Information

Seit Mitter 2018 bietet Exchange Online aber mit der Funktion Outlook Message Encryption eine durchaus interessante Funktion zur sicheren Übertragung von E-Mails an. Die Mails werden dabei ebenfalls mit AIP gesichert. Der Empfänger muss aber nun kein Office 365-Teilnehmer in einem beliebigen Tenant sein. Microsoft hat das System auf andere Identity Provider ausgedehnt und erlaubt auch die Zusendung von Tokens per Mail. Der Empfänger muss so einfach nachweisen, dass er der Inhaber der Mailadresse ist um dann auf die Information zuzugreifen.

Auch wenn es hier noch die ein oder andere Einschränkung gibt, ist es immer noch besser als gar keine Verschlüsselung. Für die Nutzung von Outlook Message Encryption ist natürlich auch wieder Azure AD Premium Plan 1 für den Absender erforderlich. Wenn er diese Lizenz aber hat, dann kann er auch mit RMS arbeiten.

Dynamische Gruppen

Der On-Premises-Administrator kennt schon länger in Exchange die Abfragebasierte Verteiler - Querybased distribution Groups. Damit konnten Sie Exchange Mailverteiler dynamisch anhand von LDAP-Feldern zusammenstellen. Häufig genutzt wurden dabei Abteilungsbezeichnungen oder Standorte. Denkbar ist aber fast jedes AD-Feld.

Auch im AzureAD gibt es natürlich Benutzer mit Feldbeschreibungen und Gruppen. Sobald Sie AzureAD P1 lizenziert haben, können Sie auch im AzureAD neue Gruppen anlegen, deren Mitglieder sich anhand von Feldinhalten im AzureAD zusammensetzen. Diese Gruppen können auch dort als Mailverteiler aber auch für Berechtigungen., Lizenzvergabe und andere Anforderungen genutzt werden.

MFA - auch On-Premises

Die Funktion "Conditional Access" ist schon der erste schnelle "Quick Win" mit Azure AD P1. Ein legitimer Faktor bei der Zugriffssteuerung ist natürlich die Nutzung von zusätzlichen Kriterien. Das kann ein Einmal-Token oder ein Telefonanruf sein. Eine grundlegende MFA-Funktion ist natürlich auch in Azure AD Basic enthalten und Sie sollten diese Funktion auch nutzen, um privilegierte Konten zu schützen.

Aber wenn Sie eh schon AzureAD P1 haben, dann können Sie diese Funktion auch auf "On-Premises-Server" ausweiten. Über einen passenden Agenten können Zugriffe auf lokale Dienste mit dem Schutz versehen werden.

Eigene Unternehmensapps

Mit P1 können Sie in Azure auch eigene Unternehmensapps eintragen. Ohne P1 sind sie auf die vorgefertigten Apps der Dritthersteller beschränkt.

DeviceWriteBack/Computer Join

Bislang kennen die meisten Administratoren natürlich die Funktion, dass Computer in das lokale AD aufgenommen werden und letztlich AADConnect diese Partnerschaft auch in Office 365 bekannt macht. Hierfür ist natürlich der Betrieb eines lokalen Active Directory erforderlich. Allerdings können sich Computer auch direkt im AzureAD registrieren. Allerdings haben Sie als lokaler Administrator davon nichts, wenn es die gleichen Objekte dann auch nicht im lokalen AD irgendwo gibt. Genau das kann AADConnect für Sie übernehmen. Die Funktion "Device Writeback" schreibt solche Objekte auch in das lokale AD. Allerdings auch hier nur, wenn Sie Azure AD P1 lizenziert haben

Kennwort Self Service / User WriteBack

Jeder Benutzer hat in der Cloud nicht nur eine Identität zur Anmeldung sondern auch ein Profil mit vom Administrator gepflegten Stammdaten. Meist kommen diese Daten auch aus dem lokalen Active Directory.

Der Benutzer kann aber in Office 365 recht einfach auch seine Stammdaten selbst pflegen, wenn dies der Administrator erlaubt. Das Office 365 Web-Portal ist in Grenzen eine Plattform zur Selbstverwaltung. Solche Änderungen sollten natürlich nicht nur in der Cloud zur Verfügung stehen. Mit AzureAD P1 kann der AADConnect solche Änderungen in Office 365 auch wieder zurück schreiben.

Es geht sogar noch mehr: Anwender können bei einem vergessenen Kennwort auch das Office 365 Portal nutzen, um ihr Kennwort selbst wieder zu setzen. Natürlich prüft Office 365 über einen zweiten Faktor, dass hier der legitime Anwender die Kennwortrücksetzung anfordert. Dafür hat Office 365 ja die Infrastruktur über Token, Mails an eine andere Adresse und Telefonanrufe.

Azure AD Connect Health, ADFS in der Cloud

Früher war die Installation von ADFS-Systemen immer erforderlich, wenn Anwender sich per "SingleSignOn" anmelden wollen. Das ist dank Pass-Through Authentifizierung (PTA) und Seamless Single Sign On heute nicht mehr erforderlich und ich bin sicher, dass immer mehr mittlere und kleine Firmen den ADFS-Server sogar zurückbauen. Mit Azure AD P1 können Sie aber dennoch die Funktion von ADFS nutzen. Office 365 betreibt einen großen Authentication Service und mit Azure AD P1 können Sie auch diesen Service nutzen.

Selbst wenn Sie weiter ihren lokalen ADFS-Service betreiben, können Sie dann die Office 365 Funktion "Azure AD Connect Health" nutzen, um ihre On-Premises-Umgebung mit zu überwachen:

Azure AD Application Proxy

Dieser sehr interessanten Komponente habe ich eine eigene Seite gewidmet:

Microsoft Identity Manager (MIM) CAL

In AzureAD P1 ist auch die Nutzer-CAL für den Microsoft Identity Manager enthalten, d.h. die "Vollversion" des AADConnect, mit dem Sie Identitäten zwischen verschiedenen Verzeichnisdiensten abgleichen können. Das ist natürlich nur ein Teil, denn die Lizenz für den MIM-Server und darunter liegenden SQL-Instanzen benötigen sie zusätzlich. Nicht vergessen werden dürfen auch die Aufwände für Installation, Konfiguration, Entwicklung und Betrieb.

Azure AD Premium Plan 2

Wenn Sie die Liste der Azure AD Pläne anschauen, dann finden Sie auch noch Plan 2.

Da kommen noch ein paar Features dazu, von denen ich persönlich erst mal "Privileged Identity Management " (PIM) am interessantesten finde. Damit können administrative Rechte im Tenant dynamische verwaltet werden. Ein Benutzer ist also nicht dauernd z.B. Exchange Online Administrator sondern muss die Rechte anfordern. Eine andere hinterlegte Person (Vier-Augen Prinzip) bekommt dann die Anfrage z.B. per Mail und kann die Rechte damit für eine beschränkte Zeit gewähren. Nach Ablauf der Zeit werden die Rechte wieder entzogen. All diese Aktionen werden protokolliert.

Zusammenfassung

Es gibt nicht das eine große Feature, welche bei einer Firma den Einsatz von AzureAD Pi1 rechnet. Vielleicht ist es tatsächlich "Conditional Access", welches den größten Leidensdruck erzeugt und mit AzureAD P1 oder einer komplexen lokalen ADFS-Installation zu lösen ist. Aber werden dann doch mehrere Bausteine in die Betrachtung einbezogen und dann lässt sich die Lizenz sehr schnell argumentieren.

Für mich gehören die Funktionen von AzureAD P1 eigentlich zu jedem E3/E5-Paket dazu. Schade, dass Microsoft viele Funktionen in der AzureAD Basic-Stufe noch nicht oder nur sehr eingeschränkt integriert hat.

Warum aber aber gerade die Schutzfunktion PIM (Privileged Access Management) erst im Paket "Azure AD Premium Plan 2" enthalten ist, verstehe ich nicht wirklich. Diese Funktion finde ich sehr interessant aber wird für viele Firmen wohl nicht erreichbar sein.

Weitere Links