Ich bin ein großer Freund von dynamischen Azure Active Directory (AAD) Gruppen. Viele Dinge lassen sich damit automatisieren und lösen sich quasi von selbst.
Dynamische Gruppen werden immer auf Basis einer Abfrage und Werten mit Mitgliedern gefüllt. Mitglieder können Geräte oder auch Benutzer sein und die Regelsyntax ist grundsätzlich recht einfach, kann jedoch bei Verknüpfung mit „und/oder“ sehr komplex aussehen. Hier mal ein Beispiel:
Die zur Verfügung stehenden Eigenschaften sind in den Microsoft Docs nachzulesen.
Nun kommt das große ABER! Gerade wenn man die Gruppen mit Informationen aus dem Microsoft Endpoint Manager (Intune) automatisch befüllen lassen will, wird man sehr schnell feststellen, dass diese nicht zur Verfügung stehen. Genauer habe ich nach einer Möglichkeit gesucht, in einer Gruppe alle Notebooks zu sammeln, um an diese Gruppe später das VPN Profil über Intune zu verteilen.
Umständlich geht das natürlich mit dem SCCM und einer Collection Synchronisation – fehleranfällig, nicht immer erfolgreich und der SCCM steht auch nicht regelmäßig zur Verfügung.
Ich habe den Microsoft Graph Explorer genommen und mir die Unterschiede zwischen den Geräteinformationen aus dem Azure AD und Intune angeschaut:
Query: https://graph.microsoft.com/beta/devices
Query: https://graph.microsoft.com/beta/deviceManagement/managedDevices
Was sofort auffällt ist, dass die IDs 1 und 2 verschieden sind und die Intune Informationen schon auf den ersten Blick viel zielführender für mein Problem sind. Wir erinnern uns, alle Notebooks sollen in einer Gruppe gesammelt werden. Auf den zweiten Blick sehen wir bei den Intune Informationen einen Wert, der sich „wifiMacAddress“ (3) nennt – Perfekt! Im hier gezeigten Beispiel ist das Feld leer, weil es sich um eine VM handelt. Eine Prüfung an einem weiteren Gerät zeigt anderes 🙂
Mit der Azure AD Device ID das Gerät der Gruppe hinzufügen
Soweit so gut. Jetzt müssen wir es nur noch schaffen, wenn das Feld „wifiMacAddress“ gefüllt ist, die Azure AD Device ID herzunehmen und das Gerät der Gruppe hinzufügen.
Leichter gesagt als getan, denn die Randbedingungen müssen noch enger werden. So will ich zum Beispiel keine persönlichen Geräte haben. Sicherlich kennt ihr das Problem mit den Azure AD Registrierten Geräten, die plötzlich auch in Intune auftauchen. Dazu hilft die Eigenschaft „managedDeviceOwnerType“ (4) mit dem Wert „company“. Außerdem will ich keine MacOS Geräte in der Gruppe sondern nur Windows 10 Enterprise Geräte. Dazu helfen mir die Eigenschaften „operatingSystem“ (5) und „skuFamily“ (nicht mit im Screenshot).
Nach der Theorie die Praxis
Die Theorie steht – jetzt geht es an die Umsetzung. Da die Verwaltung der Gruppen über reine Powershellbefehle nicht möglich ist, musste ich auf die Verwaltung mit Graph ausweichen. Sich da reinzudenken war schwerer als gedacht.
Ich hatte mir vorgenommen, das Ganze so automatisiert wie möglich stattfinden zu lassen. Also kein Anmeldefenster und am besten in regelmäßigen Abständen ausführen – versteht sich. Und alles am besten nicht auf einem Server OnPremises.
Die Anmeldung lässt sich mit einer Azure App Registration machen. Das ist so ähnlich wie ein Dienstkonto in einer Domäne. Dazu an späterer Stelle mehr.
Für die regelmäßige Ausführung habe ich mich an Azure Functions erinnert. Hier können Runbooks (Powershell) zeitlich oder Event-gesteuert ausgeführt werden.
Dazu kommt natürlich noch die ganze Skriptlogik. Hier war sehr viel trial and error angesagt, um aus vielen Einzelteilen ein großes Ganzes zu machen.
Neue Gruppe im Azure AD anlegen
Fangen wir damit an, dass wir uns eine neue Gruppe im Azure AD anlegen und uns den Namen und die Object ID der Gruppe notieren. Ja, es ist keine dynamische Gruppe. Die Dynamik kommt in diesem Fall aus dem späteren Skript.
App Registration
Machen wir mit der App Registration weiter. Im Azure AD Portal auf App Registrations klicken. Im Anschluss auf New Registration.
Im nächsten Schritt vergeben wir vorerst nur den Namen und klicken anschließend auf Register.
Aus der Übersicht der neuen App notieren wir uns für später die Application ID & Directory ID.
Des Weiteren brauchen wir noch ein Secret, über das sich das Skript dann später selbst anmelden kann. Dieses kann unter dem Menü Certificates & Secrets angelegt werden.
Wichtig ist, dass der Schlüssel nach dem Erstellen direkt notiert wird. Denn später ist dieser nicht mehr vollumfänglich lesbar!
Als nächstes müssen wir der App noch die Rechte geben, um die Mitglieder der Gruppe hinzuzufügen. Dazu gehen wir auf API Permissions und fügen neue Microsoft Graph Berechtigungen hinzu.
Für unser Beispiel brauchen wir folgende Berechtigungen vom Typ Application:
- Read all devices
- Read Microsoft Intune devices
- Read all groups
- Read and write all groups
- Sign in and read user profile
Wichtig ist, dass wir nach dem Hinzufügen auch noch den Admin Consent erteilen.
Das war es mit der Vorbereitung im Azure AD.
Einrichtung der Azure Function
Kommen wir zur Einrichtung der Azure Function. Dazu benötigen wir als erstes einen Automation Account. Das Anlegen geht schnell von der Hand und braucht nur einen Namen, eine Region und eine Azure Subscription.
Nachdem auch diese Hürde überwunden ist, hinterlegen wir in dem Automation Account ein paar Variablen und die Credentials für die App.
Für die spätere Verwendung sind die folgenden Variablen notwendig (alle vom Typ String):
- AADGroupID
- AADGroupName
- tenantID
Im Menü Credentials hinterlegen wir für die App die Anmeldeinformationen.
Jetzt erstellen wir das Runbook, welches alle Geräte mit den wifiMacAddresses findet und in der Gruppe hinzufügen soll.
Im nächsten Schritt können wir den Code des Powershell-Skriptes hinzufügen. Das Skript findet ihr in meinem Github Repo.
Für einen Test habe ich in Zeile 440 vorerst nur ein Gerät benannt. Wenn es später produktiv läuft, muss
-and $_.deviceName -eq ‚WAP-abcdefgh‘
am Ende entfernt werden! Anschließend können wir das Skript im Test Pane testen.
Nachdem wir den Test gestartet haben, sollte als Ausgabe so etwas ähnliches rauskommen.
Und auch die Gruppe hat nun einen Member.
Für einen produktiven Einsatz fehlt nur noch die Zeitplanung. Der Zeitplan kann unter Schedules hinterlegt werden.
Ganz kostenfrei sind die Runbooks unter Azure Automation nicht. Aber die ersten 500 Minuten pro Monat pro Subscription sind kostenfrei. Die Ausführung des Skriptes dauert je nach Komplexität maximal 2 Minuten. Das heißt das Skript kann aller 8 Stunden laufen, wenn die Ausführungsdauer 2 Minuten beträgt.
Mit etwas Anpassung lässt sich das Skript natürlich auch von einem OnPremises System ausführen, oder andere Werte und Eigenschaften abfragen.
Ich hoffe ich konnte eine kleine Inspiration geben 🙂
Mehr Unterstützung durch SoftEd Consulting
Wir bieten technische Trainings und Beratungsleistungen rund um den Digital Workplace. Alle Angebote im Überblick
