Office 365 Lizenzen mit Azure Groups

Durch einen Artikel auf einem Blog wurde ich drauf aufmerksam, dass ich Lizenzen in Office 365 gar nicht mehr mühsam manuell oder per PowerShell vergeben muss. Das kann ADSync und Azure alleine. So wird es eingerichtet.

Achtung:
Voraussetzung für diese Funktion ist eine kostenpflichtige AzureAD Subscription. Es reicht nicht einfach nur ein Office 365 Tenant mit E1,E3,E5-Lizenzen zu haben. Azure AD Premium oder Enterprise Mobility Suite sind solche Pakete.

Die Quelle

Natürlich ist das nicht direkt auf meinem eigenen Mist gewachsen aber das HowTo auf dem Blog war so falsch, dass ich meine etwas abgewandelte Umsetzung hier dokumentiere. Hier erst mal das originale Blog:

Zumindest bei der ersten Veröffentlichung waren Bilder falsch und auf diverse Bugs des ADSync wurde nicht eingegangen, so dass schon an den Kommentaren sichtbar wird, dass hier noch Bedarf zur Nachbesserung besteht. Zudem bin ich sicher, dass nicht viele deutsche Administratoren diesen kleinen Blog-Eintrag finden und dann auch umsetzen können.

Voraussetzungen und Schritte

Diese gesamte Beschreibung macht natürlich nur Sinn, wenn Sie einen Office 365 Tenant und ein lokale Active Directory haben, die zudem per ADSync miteinander gekoppelt sind Denn nur so werden die relevanten Informationen von ihrem lokalen Active Directory auch automatisiert in Office 365 angelegt. Die Schritte sind dann

  • Lizenzgruppen anlegen
    Unser Ziel ist es ja Office 365 Lizenzen anhand von Gruppenmitgliedschaften zu vergeben. Bitte nehmen Sie dazu nicht die "Domain Benutzer", die in der Regel eh nicht zu Office 365 repliziert werden. Bei den meisten Firmen wird es aber immer eine Gruppe "Office 365 User" oder "Alle Mittarbeiter" o.ä. geben oder sie legen entsprechende Gruppen an, die natürlich auch von ADSync in die Cloud repliziert werden müssen. Eine Gruppe, die sie als Filter für ADSync angelegt haben, ist vielleicht nicht optimal, da dort vielleicht auch andere Objekte (Kontakte etc.) enthalten sind, die keine Lizenz benötigen.
  • Mitarbeiter in Lizenzgruppen aufnehmen
    Addieren Sie dann die Mitarbeiter in die entsprechende Lizenzgruppe. Achten Sie bitte darauf, dass ein Anwender möglichst nur in einer Lizenzgruppe ist, nicht dass es zu unklaren Verhältnissen für Azure AD kommt.
  • "Usage Location" und ADSync
    Um eine Lizenz in Office 365 fehlerfrei zuzuweisen muss der "Ort" beim Benutzer hinterlegt werden. Das entsprechende Feld im AzureAD lautet "Usage Location" und ist per Default erst einmal leer. Wenn Sie eine Lizenz zuweisen, dann erzwingt Office 365 auch, dass Sie hier eine Auswahl vornehmen. Das Feld wird per Default auch nicht von ADSync repliziert. Das wollen wir nun nachholen, indem der Inhalt von "C" (Country) über ADSync in die Cloud repliziert wird.
  • Azure Gruppen mit Lizenzen versehen
    Der letzte Schritt ist dann die Zuweisung von Lizenzen anhand der von ADSync gepflegten Gruppen und "Usage Location"

Die ersten beiden Schritte schaffen Sie sicher auch ohne Anleitung, so dass ich mich hier auf die Anpassung von ADSync und spätere Konfiguration in Azure beschränken kann.

Analyse vorab

Dieser Schritt ist nicht erforderlich aber manchmal aufschlussreicht. Sie können nämlich über den Synchronization Service Manager einfach die aktuellen Objekte im Metaverse anzeigen lassen

Sie sehen hier schon, dass das Feld "c", welcher per Default aus dem lokalen AD schon in das Metaverse übertragen ist, auch nicht bei allen Benutzern gepflegt ist. In der Liste erscheinen aber auch Gruppen, die natürlich kein "c" haben. Aber auch aus dem AzureAD kommt schon das Feld "usageLocation" herein, und es ist bei einigen Benutzer sicher auch schon gefüllt. Das sind schon mal alle Benutzer die eine Lizenz in Office 365 zugewiesen bekommen haben. Das wollen wir nun aber automatisieren.

ADSync pausieren

Ein gültiger Wert im Feld "Usage Location" ist in AzureAD für die Lizenzzuweisung wichtig. Wir passen also ADSync derart an, dass die Information aus dem lokale Active Directory nach AzureAD repliziert wird. Wie jede Anpassung an den Regeln ist es ratsam zu verhindern, dass ADSync gerade "aktiv" wird während wir an der Konfiguration schrauben. Daher halten wir den eingebauten Scheduler an.

Set-ADSyncScheduler -SyncCycleEnabled $false

Die AzureAD Connect Konsole macht dies auch aber der Rule-Editor, den wir nun brauchen macht dies nicht.

ADSync Inbound Rule anlegen

Wenn Sie den "Synchronization Rule Editor" noch nicht genutzt haben, finden Sie ihn im Startmenü

Direkt ohne Willkommensschirm werden alle vorhanden Regeln angezeigt aber der erste Filter steht schon auf "Inbound", d.h. Regel mit denen ADSync Daten aus anderen Verzeichnissen in sein Medadirectory einliest

Hier brauchen wir nun eine neue Regeln um das Feld "c" erst mal in das Metaverse zu übertragen. Sie drücken als rechts auf "Add new Rule" und füllen das erste Fenster des Assistenten aus.

Die Felder bedeuten:

  • Name: Eine Beschreibung der Regel
  • Description: Noch mehr Platz für Dokumentation
  • Connected System: Die Quelle ist hier das lokale Active Directory
  • Connected System Objekt Type: Uns interessieren nur "User"
  • Metaverse Object Type: Das Objekt im Metaverse, auf das die Änderungen angewendet werden.
  • Link Type: Join bedeutet, dass die Daten zu einem bestehenden Objekte zusammengeführt werden.
  • Precedence: Die Priorität in der sich diese Regel in andere Regeln einfügt. Die Regel sollte eine niedrige Nummer haben als andere Regeln.
  • Tag:

Die beiden nächsten Eingabemasken für "Scoping Filter" und "Join Rules" werden nicht genutzt. Weiter geht es dann auf "Transformations", auf der die Zuordnung der Felder addiert wird. Über "Add Transformation" addiere ich eine neue Zeile, in der ich dann eingeben:

  • Flowtype: Expression
  • Target Attribute: UsageLocation
  • Source : IIF(IsNullOrEmpty([c]),"DE",[c])
    Achten Sie beim kopieren darauf, dass "Computer Anführungszeichen" im Ziel laden, Es gibt je nach Zeichensatz ja durch aus mehrere wie " und ”. Der Code kopiert den Inhalt von "c", wenn er nicht leer ist. Ansonsten schreibt er ein "DE" als Default rein, was für deutsche Anwender natürlich passender ist. Am Anfang steht wirklich ein "IIF" mit zwei "I"

Mit einem "ADD" wird die Regel addiert und wir landen wieder auf dem Startfenster.

Wenn beim "Add" ein Fehler kommt, das ein Objekt nicht referenziert ist, dann gehen Sie noch mal zur erste Seite zurück und addieren im Feld "Tag" einfach einen beliebigen String. Das war wohl ein Problem von früheren Versionen in der Fixliste ist der Fehler ab Version 1.1.614.0 vom 5. Sep 2017 als gefixt aufgelistet

ADSync Inbound Rule anlegen

Nun müssen wir natürlich noch eine zweite Regel anlegen, um das Feld auch ins AzureAD zu übertragen. Dazu müssen Sie im Rule Editor erst einmal die Einstellung auf "Outbound" umstellen

Wenn Sie dann auf "Add new Rule" klicken, sieht das Fenster fast genauso aus. Links oben sollte aber nun "Create outbound synchronization rule" stehen. Auch hier füllen Sie die erste Seite wieder aus mit

Auch hier sollte die Precedence niedriger sein als der niedrigste Eintrag. Bei mir war der bei 145 so dass ich den Vorgaben des Blog-Artikels gefolgt bin. Die zwei folgenden Eingabemasken für "Scoping Filter" und "Join Rules" bleiben ungenutzt und es geht auf "Transformations" weiter., auf der die Zuordnung der Felder addiert wird. Über "Add Transformation" addiere ich eine neue Zeile, in der ich dann folgendes eingeben.

Meine Eingabe unterscheidet sich auch hier vom US-Blog, der Werte anzeigt, die bei mir gar nicht möglich sind. Ich habe z.B. gar kein Targetattribute "c" in AzureAD. Die obige Zeile macht aber genau, was ich will.

Damit die Änderungen schnell aktiv werden, wir manuell ein Lauf gestartet

Start-ADSyncSyncCycle -PolicyType Delta

Nach all den Änderungen lassen wir ADSync wieder "geplant" laufen. Dieser Hinweise fehlte im englischen Post

Set-ADSyncScheduler -SyncCycleEnabled $true

Denken Sie aber nun immer daran, dass Sie hier manuell einen Abgleich addiert haben und die UsageLocation in der Cloud quasi immer von dem Feld "c" im lokalen On-Prem Active Directory bestimmt wird.

Das wird aber auch von Microsoft nicht wirklich kritisch gesehen

Group license assignment will never modify an existing usage location value on a user. We recommend that you always set usage location as part of your user creation flow in Azure AD (e.g. via AAD Connect configuration) - that will ensure the result of license assignment is always correct, and users do not receive services in locations that are not allowed.
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-licensing-group-advanced

Azure Gruppen für Lizenzvergabe einrichten

Nachdem die UsageLocation nun gesetzt ist, erfolgt die Konfiguration der Lizenzgruppen über das Azure-Portal. Viele reine Office 365 Administratoren, die bislang nur mit https://portal.office365.com gearbeitet haben, könnten nun erstmalig manage.windowsazure.com sehen. Keine Sorge, ihre Anmeldedaten funktionieren auch hier. Über den Punkte "Azure Active Directory" und "Lienzierung" können Sie auf "All Products" klicken und das jeweilige Produkt auswählen:

Mit einem Druck auf "Assigned" sehen Sie die aktuell zugewiesenen Lizenzen für dieses Produkt pro Benutzer. Mit einem Klick auf "Licensed Groups" sehen Sie dann in der Regel erst mal nichts. Diese Funktion haben Sie ja noch nicht genutzt.

Hier können Sie dann wieder über "Assign" eine Gruppe auswählen. Wohl dem, der ein gutes Namenskonzept hat, damit Sie in der Gesamtliste aller Gruppen und Benutzer ihre Lizenzgruppe finden

Sie können hier immer nur genau eine Gruppe auswählen der sie dann im nächsten Reiter die Lizenz zuweisen:

Ich finde die Farbgebung hier aber etwas unglücklich da nicht sofort klar ist, welche Teillizenz nur auf "On" oder auf "Off" steht. Im Bild ist "Exchange P2" und "Microsoft Planner" gerade auf "OFF". Mitglieder der entsprechenden Gruppe bekommen also alle anderen Lizenzen außer diese beiden Einträge.

Konflikte

Wie sich AzureAD und die Lizenzen verhalten ist am besten zu verstehen, wenn Sie folgendes sich merken.

  • Lizenzen sind immer additiv
    Wenn also jemand über eine Gruppe oder manuell eine Lizenz hat, dann kann eine andere Zuweisung diese nicht "wegnehmen"
  • Per Gruppen verwaltete Lizenzen sind vererbt
    Alle Lizenzen aller Gruppen und manuell zugewiesene Lizenzen werden quasi übereinander gelegt

Alle Konflikte, z.B. User in mehreren Gruppen oder Entfernen aus einer Gruppe oder abweichende manuelle Zuweisungen führen nicht zu einem Konflikt da eine Lizenz nie verweigert sondern einfach nicht mehr über diesen Weg zugewiesen wird.

Weitere Links