Endpoint Manager (Intune) Compliance & Conditional Access für MTR on Android (MTRoA) Poly Devices

Hey, Da es speziell zu diesem Thema immer wieder viele Fragen gibt, erkläre ich Ihnen in diesem Beitrag an einem Beispiel wie Sie Ihre Poly MTRoA Devices konform in Ihre M365 Umgebung integrieren. Viel Spass

Hinweis:
Das folgende Beispiel stellt kein“Best Practice“ dar, basiert lediglich auf meinen Erfahrungen mit MTRoA Systemen und wurde auf einem Demo Tenant ausgeführt.
Wie bei allen Security-relevanten Themen rate ich Ihnen dazu, jegliche Änderung an Ihrer Produktiv-/Demo-Umgebung sehr gut zu planen und mögliche Folgen zu bedenken.

Wenn Sie in Ihrem Unternehmen Conditional Access Regeln (z.B. MFA „Multi Factor Authentication“) für Teams nutzen, müssen Android Devices (wie CCX Phones, Studio X Series usw.) bei Intune registiert sein (Lizenz erforderlich) und den definierten Regeln entsprechen. Ist dies nicht der Fall, so können sich die Geräte nicht anmelden und / oder funktionieren gegebenenfalls nicht korrekt. Nachfolgend finden Sie eine entsprechende Grafik zur besseren Veranschaulichung.

Gretchenfrage: Wie finde ich überhaupt heraus, ob Intune (MDM) auf meinem Tenant aktiviert ist ?

Das ist einfach. Loggen Sie sich unter https://portal.azure.com mit ihren M365 Admin Credentials ein. Geben Sie oben im Suchfeld „Azure ad“ oder einen vergleichbaren String ein und klicken Sie auf „Azure Active Directory“.

Klicken Sie links in der Navigation auf „Mobility (MDM and MAM)“.

Klicken Sie nun auf „Microsoft Intune“.

Sollte Intune bereits aktiviert sein, stehen MDM und MAM User scope auf „All“ oder „Some“.

„Best Practice“ ist hier ganz klar „Some“ zu verwenden, nur die benötigten Gruppe oder Accounts zu inkludieren und den / die Admin Accounts von der Richtlinie auszuschliessen.

Los geht´s …

Wir wissen nun, dass Intune MDM auf unserem Tenant aktiv ist. Um also möglichen Problemen bei der Installation der MTRoA Systeme vor Ort vorzubeugen, Nehmen wir nachfolgend einige Konfigurationen vor.

Wir werden eine Policy aufsetzen, die MTRoA Geräten, in Abhängigkeit von Standort, Useraccount und Device Typ, den Zugriff auf Unternehmensressourcen gestattet.

Schritt 1: „Korrekte Lizenzierung prüfen“

Als Erstes sollten wir sicherstellen, dass Ihre Poly Android Devices korrekt lizensiert sind und wir uns nicht im Vorfeld durch falsche Einstellungen direkt Probleme bereiten.

Mögliche Lizenz-Varianten sind:

• Microsoft Teams Room Standard License (beinhaltet bereits Intune / Endpoint Manager) + Azure Active Directory Premium 1 für Conditional Access
• E3 License (beinhaltet bereits Intune / Endpoint Manager und Azure Active Directory Premium 1)
• E5 License (beinhaltet bereits Intune / Endpoint Manager und Azure Active Directory Premium 2)
• … eventuell gibt es noch mehr Möglichkeiten (separate Intune license etc., aber das hier sollten die gängigsten Varianten sein)

Schritt 2: „Dynamische Gruppen erstellen“

Als Nächstes erstellen wir zwei dynamische Gruppen, in denen alle unsere MTR on Android Accounts und Devices Mitglied sind.

Warum 2 Gruppen ?

Sicherlich lässt sich unser Vorhaben auch mit der Erstellung einer einzelnen Gruppe (z.B. der MTRoA Devices) erreichen. Aus Gründen der Übersichtlichkeit und Flexibilität nutze ich allerdings meist 2. Sie können hier natürlich nach Ihren eigenen Präferenzen agieren und müssen meinem Beispiel nicht zwingend folgen.

Loggen Sie sich im Azure Portal (https://portal.azure.com/) mit Ihrem M365 Admin Account ein.

Geben Sie oben im Suchfeld „Azure ad“ oder einen vergleichbaren String ein und klicken Sie auf „Azure Active Directory“.

Klicken Sie links in der Navigation auf „Groups“.

Klicken Sie auf „New Group“.

Vergeben Sie die folgenden Werte und klicken Sie anschliessend auf „Add dynamic query“.

• Group Type: „Security“
• Group Name: „frei zu vergeben“
• Group Description: „frei zu vergeben“
• Azure AD roles can be assigned to the group: „No“
• Membership Type: „Dynamic User“

Wir legen nun eine dynamische Gruppe an, die in Abhängigkeit von den von uns angebenen Werten, neue User automatisch aufnimmt.
Ich werde mich in diesem Beispiel auf den „User Principal Name“ konzentrieren und als Bedingung festlegen.

Meine gesamten MTRoA Account Namen beginnen mit „Conf-„. Ich wähle also die folgenden Werte für meine Gruppe aus und klicke anschliessend auf „Save“.

• Property: „UserPrincipalName“
• Operator: „Starts with“
• Value: „Conf“

Klicken Sie abschliessend auf „Create“ um die Gruppe zu erstellen.

Nach kurzer Zeit sollten die entsprechenden Accounts auch schon automatisch der Gruppe zugeordnet sein. Sie können dies kontrollieren, indem Sie die Gruppe anklicken und anschliessend, in der Navigation links, auf „Members“ klicken.

Sollten die User nicht direkt sichtbar sein – Don´t panic. Es kann einen Moment dauern.

Wir werden nun die zweite dynamische Gruppe anlegen, der die MTRoA Devices zugeordnet werden sollen.

Wir klicken dazu wieder auf „Groups“ und „New Group“.

Vergeben Sie die folgenden Werte und klicken Sie anschliessend auf „Add dynamic query“.

• Group Type: „Security“
• Group Name: frei zu vergeben
• Group Description: frei zu vergeben
• Azure AD roles can be assigned to the group: „No“
• Membership Type: „Dynamic Device“

Wir wollen nun alle Devices, die auf Android als OS basieren und eins der folgenden Modelle repräsentieren, – Studio X30, Studio X50, G7500 oder TC8 – automatisch in diese Gruppe aufnehmen lassen. Dazu erstellen wir die folgende Regel:

Property: „deviceOSType“
Operator: „Equals“
Value: „Android“
und der Device Typ ist eins der oben genannten, s. nachfolgender Screenshot.

Wenn Sie es sich einfach machen wollen, klicken Sie links neben „Rule syntax“ auf „Edit“, kopieren Sie den nachfolgenden Code und fügen Sie ihn dort ein 🙂

(device.deviceOSType -eq "Android") and (device.deviceModel -eq "PolyTC8") or (device.deviceModel -eq "PolyStudioX30") or (device.deviceModel -eq "PolyStudioX50") or (device.deviceModel -eq "PolyG7500")

TIP:
Alternativ können Sie auch den Studio X Part genereller gestalten um eventuelle weitere Geräte dieser Familie später ebenfalls inkludiert zu haben. Der Code würde dann folgendermassen aussehen:

(device.deviceOSType -eq "Android") and (device.deviceModel -eq "PolyTC8") or (device.deviceModel -contains "StudioX") or (device.deviceModel -eq "PolyG7500")

Klicken Sie auf „Save“ und anschliessend auf „Create“ um die Gruppe final zu erstellen. Wir sollten nun also beide erstellen Gruppen in unserer Übersicht sehen und können nun weitermachen.

Schritt 3: „Named (trusted) Location erstellen“ (optional)

Klicken Sie links in der Navigation auf „Security“ und anschliessend auf „Named Locations“.

Sie haben nun mehrere Möglichkeiten eine Lokation auf vertrauenswürdig zu hinterlegen.
1 – als Land oder
2- als IP Range
In meinem Beispiel entscheide ich mich für die IP Range und klicke auf „IP ranges location“

Vergeben Sie nun einen Namen für Ihren Standort (ich gebe hier mein HomeOffice an), aktiveren Sie die Checkbox „Mark as trusted location“ und klicken Sie auf das „+“ Zeichen um eine IP Range anzugeben.

Hinweis:
Es können hier nur Public IPs verwendet werden. Bitte tragen Sie also hier keine LAN internen Ranges ein.
Klicken Sie auf „Add“ um die IP Range zu übernehmen und auf „Create“ um den Standort abzuspeichern.

Der neu erstellte Standort sollte nun in der Liste der Named Locations erscheinen und wir können mit dem nächsten Schritt fortfahren.

Schritt 4: „Device Administrator aktivieren.“

Öffnen Sie den Endpoint Manager (Intune) unter https://endpoint.microsoft.com/,

Wir werden nun den „Android Device Administrator“ aktivieren, den wir für die MTRoA „Verwaltung“ benötigen. Das Android Device Administrator Management stellt die Device Administration auf System Level für Android-basierte Geräte bereit.

Klicken Sie links in der Navigation auf „Devices“.

Klicken Sie unter „Device Enrollment“ auf „Enroll Devices“.

Klicken Sie auf „Android Enrollment“ und, am Ende der Seite, auf „Personal and corporate-owned devices with device administrator privileges“.

Aktivieren Sie die Checkbox und klicken Sie auf „Ok“.

Schritt 5: „Device Filter erstellen“

Klicken Sie links unten auf „Tenant Administration“.

Klicken Sie auf „Filters (Preview)“.

Hinweis:
Da es sich um ein Preview Feature handelt, kann es sein, dass Sie diese Funktion erst noch aktivieren müssen.Klicken Sie dazu auf den Banner, aktivieren Sie die Checkbox und klicken Sie „Apply“.

Klicken Sie auf „Create“.

Vergeben Sie die folgenden Werte und klicken Sie auf „Next“.

• Filter name: „frei wählbar“
• Description: „frei wählbar“
• Platform: „Android Device Administrator“

Im nächsten Fenster vergeben Sie die folgenden Werte, klicken dann auf „Add expression“ und dann auf „Next“:

• Property: „model“
• Operator: „ln“
• Value: [„polystudiox30″,“polystudiox50″,“polyg7500″,“polytc8“]

TIP:

Alternativ können Sie auch den Studio X Part genereller gestalten um eventuelle weitere Geräte dieser Familie später ebenfalls inkludiert zu haben. Der Code würde dann folgendermassen aussehen:

(device.model -eq "polyg7500") or (device.model -eq "polytc8") or (device.model -startsWith "polystudiox")

Sie bekommen nun noch einmal alle Werte in der Übersicht angezeigt. Sofern alles ok ist, klicken Sie auf „Create“.

Schritt 6: „Ist Android überhaupt erlaubt?“

Klicken Sie auf „Devices“ -> „Enroll Devices“ -> „Enrollment restrictions“

Klicken Sie auf „All Users“.

Klicken Sie auf „Properties“.

Stellen Sie sicher, dass „Android Device Administrator“ für Corporate- und Personal Devices auf „Allowed“ steht.

Ist dies nicht der Fall, so ändern Sie die Einstellungen entsprechend, wenn dies nicht gegen Ihre Security Policies ist. Alternativ erstellen Sie eine neue Restriction, die Android explizit für unsere erstellten Gruppen freigibt.

Klicken Sie dazu oben auf „Create Restriction“.

Wählen Sie „Device type restriction“.

Vergeben Sie einen Namen + eine Beschreibung und klicken Sie auf „Next“.

In meinem Beispiel aktiviere ich alle Android Optionen und deaktiviere die restlichen Punkte. Klicken Sie auf „Next“.

Auf der nächsten Seite klicken Sie auf „Next“ ohne Änderungen vorzunehmen.

Unter „Assignments“ klicken Sie auf „Add Group“.

Wählen Sie die beiden zuvor erstellten Gruppen aus, fügen Sie diese hinzu und klicken Sie auf „Select“. Klicken Sie anschliessend auf „Next“.

Überprüfen Sie die Einstellungen noch einmal in der Übersicht und klicken Sie auf „Create“.

Schritt 7: „Compliance Policy definieren“

Wir erstellen nun, aus Gründen der Übersichtlichkeit, 2 Policies.
Policy 1 markiert Geräte, die nicht unseren Anforderungen entsprechen, direkt und umgehend als „non-compliant“.
Policy 2 entfernt / blockiert diese Geräte nach 10 Tagen aus unserem System.

Weitere Informationen zu den jeweiligen Actions können Sie hier auf den Microsoft Webseiten nachlesen:
https://docs.microsoft.com/de-de/mem/intune/protect/actions-for-noncompliance

Policy 1

Klicken Sie auf „Devices“ und auf „Compliance Policies“.

Klicken Sie auf „Create Policy“.

Unter „Platform“ wählen Sie „Android Device Administrator“ aus den verfügbaren Optionen und klicken Sie auf „Create“.

Vergeben Sie einen Namen, sowie eine Beschreibung und klicken Sie auf „Next“.

Unter „Device Health“ wähle ich in meinem Beispiel aus, dass rooted Devices nicht zugelassen werden sollen. Zusätzlich wähle ich unter „Device Properties“ die Minimum Android Version aus. Da das TC8 auf Android 9 basiert und die Studio X Series auf 8.1, wähle ich 8.1 als niedrigsten Wert. Klicken Sie auf „Next“.

Unter „Locations“ klicken Sie auf „Next“.

Unter „Actions for noncompliance“ belasse ich den Standardwert, der besagt, dass Geräte, die diesen Richtlinien nicht entsprechen, direkt und ohne Verzögerung als non-compliant markiert werden. Klicken Sie auf „Next“.

Unter „Assignments“ klicken Sie auf „Add Group“. Wählen Sie die beiden zuvor erstellen Gruppen aus und klicken Sie „Select“. Klicken Sie auf „Next“.

Überprüfen Sie die eingestellten Optionen in der Übersicht und klicken Sie abschliessend auf „Create“.

Policy 2

Hier verfahren Sie bei den ersten Schritten analog zu Policy 1.
Unter dem Reiter „Actions for noncompliance“ legen Sie allerdings eine weitere Aktion an.

Action: „Retire the noncompliant device“
Schedule: „10 Days“

Ordnen Sie wieder unsere beiden erstellten Gruppen zu und erstellen Sie die Regel final.

Schritt 8: „Conditional Access aktivieren“

Aus Security Gründen sollten Sie IMMER mit der Erstellung einer „Block“- anstelle einer „Allow“ Regel beginnen. In meinem Beispiel, ich arbeite in einer nicht produktiven Demo Umgebung, ist die Reihenfolge andersherum. Bitte beachten Sie dies.

Klicken Sie auf „Devices“ und anschliessend auf „Conditional Access“.

Wir werden nun in diesem Beispiel 2 Regeln erstellen:
Eine Regel, die den Zugriff auf bestimmte Apps für Android Devices aus einer Trusted Location gestattet und eine Regel, die den Zugriff für Android Devices aus Untrusted Locations auf Cloud Apps blockiert.

Klicken Sie dazu auf „New Policy“.

Vergeben Sie einen Namen für die neue Policy und klicken Sie anschliessend, unter „Users and Groups“ auf „0 users and groups selected“.
Unter „Include“ wählen Sie „Select Users and Groups“ und nachfolgend „Users and Groups“.
Wählen Sie im Fenster rechts die beiden zuvor erstellen Gruppen aus und klicken Sie auf „Select“.

Unter „Cloud Apps or Actions“ klicken Sie auf „No cloud apps, actions, or authentication contexts selected“. Unter „Include“ wählen Sie „Select Apps“. Suchen Sie die folgenden Apps heraus,fügen Sie sie hinzu und klicken Sie auf „Select“:

• Microsoft Teams
• Office 365 Exchange Online
• Office 365 SharePoint Online

Unter „Conditions“ klicken Sie auf „0 Conditions selected“ und dann rechts unter „Device Platforms“ auf „not configured“.

Wählen Sie unter „Configure“ -> „Yes“ und unter „Include“- -> „Select Device Platform“ -> „Android“ aus. Klicken Sie auf „Done“.

Klicken Sie unter „Locations“ auf „0 included“. Wählen Sie unter „Configure“ -> „Yes“ und unter „Include“- -> „Selected locations“ -> „<Ihre erstellte Location>“ aus.
Klicken Sie auf „Select“.

Klicken Sie unter „Grant“ auf „0 Controls selected“.

Wählen Sie „Grant“ -> „Require Device to be marked as compliant“ und klicken Sie „Select“.

Unter „Enable Policy“ klicken Sie auf „On“ und abschliessend auf „Create“.

Verfahren Sie bei der Erstellung analog zur vorherigen Regel, allerdings mit folgenden Werten:

Name: „Frei wählbar“
User and Groups: „<Unsere beiden erstellten Gruppen>“
Cloud Apps or Actions: „All Cloud Apps“
Conditions:
„Device Platforms“ -> „Android“
„Locations“ -> „Include“ -> „All Locations“ / „Exclude“ -> „Selected Locations“ -> unsere Location.
Grant: „Block“

Diese Regel sperrt den Zugriff auf alle Cloud Apps für alle Android Devices unserer beiden Gruppen. die nicht compliant sind und sich nicht aus einer Trusted Location anmelden.

Unter „Enable Policy“ wählen Sie „On“ und klicken Sie auf „Create“.

Es sollten nun beide erstellten Regeln in der Übersicht erscheinen.

Jetzt ist es an der Zeit die Funktion unserer erstellten Regeln zu testen.

Nach dem Login auf beiden Devices werden diese als Compliant und Intune gemanaged in unserem Azure AD angezeigt – PERFEKT.

Sollten Sie trotzdem Probleme bei der Anmeldung Ihrer Devices haben, helfen Ihnen vielleicht diese beiden Posts weiter:

MTRoA Anmeldeprobleme (AADSTS50199)
MTR on Android Troubleshooting – Die häufigsten Probleme

Fertig 🙂

Kudos an meinen Kollegen Vincent Dal (Poly Solution Architect Manager EMEA) für seine Tipps.

Microsoft hat seine Websites ebenfalls mit weitergehenden Infos versorgt. Nachfolgend finden Sie 2 nützliche Links:

Authentication best practices for Teams shared device management on Android devices
Supported Conditional Access and Intune device compliance policies for Microsoft Teams Rooms