Microsoft Entra-Integration mit MDM

Microsoft Entra ID ist der weltweit größte Cloud-Identitätsverwaltungsdienst für Unternehmen. Es wird von Organisationen verwendet, um auf Microsoft 365 und Geschäftsanwendungen von Microsoft und SaaS-Anbietern (Software-as-a-Service) von Drittanbietern zuzugreifen. Viele der umfangreichen Windows-Umgebungen für Organisationsbenutzer (z. B. Speicherzugriff oder Roaming des Betriebssystemstatus) verwenden Microsoft Entra ID als zugrunde liegende Identitätsinfrastruktur. Windows ist in Microsoft Entra ID integriert, sodass Geräte in Microsoft Entra ID registriert und in einem integrierten Flow bei der Verwaltung mobiler Geräte (Mobile Device Management, MDM) registriert werden können.

Sobald ein Gerät bei MDM registriert ist, gilt die MDM:

• Kann die Einhaltung von Organisationsrichtlinien erzwingen, Apps hinzufügen oder entfernen und vieles mehr.
• Kann die Konformität eines Geräts in Microsoft Entra ID melden.
• Kann den Zugriff auf Organisationsressourcen oder Anwendungen zulassen, die durch die Microsoft Entra-ID geschützt sind, auf Geräten, die richtlinienkonform sind.

Um diese umfassenden Erfahrungen mit ihrem MDM-Produkt zu unterstützen, können MDM-Anbieter in Microsoft Entra ID integrieren.

Integrierte MDM-Registrierung und UX

Es gibt mehrere Möglichkeiten, Ihre Geräte mit Microsoft Entra ID zu verbinden:

• Gerät mit Microsoft Entra ID verbinden
• Verbinden eines Geräts mit einer lokalen AD- und Microsoft Entra-ID
• Hinzufügen eines Microsoft-Geschäftskontos zu Windows

In jedem Szenario authentifiziert Microsoft Entra den Benutzer und das Gerät. Es stellt einen verifizierten eindeutigen Gerätebezeichner bereit, der für die MDM-Registrierung verwendet werden kann. Der Registrierungsflow bietet dem MDM-Dienst die Möglichkeit, seine eigene Benutzeroberfläche mithilfe einer Webansicht zu rendern. MDM-Anbieter sollten die Benutzeroberfläche verwenden, um die Nutzungsbedingungen (TOU) zu rendern, die sich für unternehmenseigene und BYOD-Geräte (Bring Your Own Device) unterscheiden können. MDM-Anbieter können die Webansicht auch verwenden, um weitere Benutzeroberflächenelemente zu rendern, z. B. um eine einmalige PIN zu verlangen.

In Windows 10 wird die Webansicht während des standardmäßigen Szenarios standardmäßig als Vollbild angezeigt, sodass MDM-Anbieter eine nahtlose Edge-to-Edge-Benutzeroberfläche schaffen können. In Windows 11 wird die Webansicht jedoch innerhalb eines iframes gerendert. Es ist wichtig, dass MDM-Anbieter, die mit Microsoft Entra ID integriert sind, die Windows-Entwurfsrichtlinien einhalten. Dieser Schritt umfasst die Verwendung eines reaktionsfähigen Webdesigns und die Einhaltung der Windows-Richtlinien für die Barrierefreiheit. Schließen Sie beispielsweise die Vorwärts- und Zurück-Schaltflächen ein, die ordnungsgemäß mit der Navigationslogik verkabelt sind. Weitere Informationen finden Sie weiter unten in diesem Artikel.

Damit die Microsoft Entra-Registrierung für ein von Active Directory Federated Services (AD FS) gesichertes Microsoft Entra-Konto funktioniert, müssen Sie die Kennwortauthentifizierung für das Intranet im AD FS-Dienst aktivieren. Weitere Informationen finden Sie unter Konfigurieren der mehrstufigen Authentifizierung von Microsoft Entra als Authentifizierungsanbieter mit AD FS.

Sobald ein Benutzer ein Microsoft Entra-Konto zu Windows hinzugefügt und bei MDM registriert hat, kann die Registrierung über Einstellungen>Konten>Auf Geschäfts-, Schul- oder Unikonto zugreifen verwaltet werden. Die Geräteverwaltung von Microsoft Entra Join für Organisationsszenarien oder BYOD-Szenarien ist ähnlich.

MDM-Endpunkte, die an der integrierten Registrierung von Microsoft Entra beteiligt sind

Die Microsoft Entra MDM-Registrierung ist ein zweistufiger Prozess:

1. Anzeigen der Nutzungsbedingungen und Einholen der Benutzerzustimmung: Diese Zustimmung ist ein passiver Ablauf, bei dem der Benutzer in einem Browsersteuerelement (Webview) zur URL der Nutzungsbedingungen der MDM umgeleitet wird.
2. Registrieren des Geräts: Dieser Schritt ist ein aktiver Flow, bei dem der Windows OMA DM-Agent den MDM-Dienst aufruft, um das Gerät zu registrieren.

Zur Unterstützung der Microsoft Entra-Registrierung müssen MDM-Anbieter einen Nutzungsbedingungen-Endpunkt und einen MDM-Registrierungsendpunkt hosten und verfügbar machen.

• Nutzungsbedingungen-Endpunkt: Verwenden Sie diesen Endpunkt, um Benutzer darüber zu informieren, wie ihre Organisation ihr Gerät steuern kann. Die Seite Nutzungsbedingungen ist dafür verantwortlich, die Zustimmung des Benutzers einzuholen, bevor die eigentliche Registrierungsphase beginnt.

  Es ist wichtig zu verstehen, dass der Ablauf der Nutzungsbedingungen eine "undurchsichtige Box" für Windows und Microsoft Entra ID ist. Die gesamte Webansicht wird zur URL der Nutzungsbedingungen umgeleitet. Der Benutzer sollte zurückgeleitet werden, nachdem er die Bedingungen genehmigt oder abgelehnt hat. Dieses Design ermöglicht es dem MDM-Anbieter, seine Nutzungsbedingungen für verschiedene Szenarien anzupassen. Beispielsweise werden verschiedene Steuerungsebenen auf BYOD- und organisationseigene Geräte angewendet. Oder implementieren Sie benutzer-/gruppenbasierte Zielgruppenadressierung, wie Benutzer in bestimmten Geografischen Regionen möglicherweise strengere Geräteverwaltungsrichtlinien haben.

  Der Endpunkt für Nutzungsbedingungen kann weitere Geschäftslogik implementieren, z. B. das Erfassen einer einmaligen PIN, die von der IT bereitgestellt wird, um die Geräteregistrierung zu steuern. MDM-Anbieter dürfen jedoch nicht den Ablauf der Nutzungsbedingungen verwenden, um Benutzeranmeldeinformationen zu sammeln, was zu einer beeinträchtigten Benutzererfahrung führen kann. Dies ist nicht erforderlich, da ein Teil der MDM-Integration sicherstellt, dass der MDM-Dienst Token verstehen kann, die von Microsoft Entra ID ausgegeben werden.

• MDM-Registrierungsendpunkt: Nachdem die Benutzer die Nutzungsbedingungen akzeptiert haben, wird das Gerät in microsoft Entra ID registriert. Die automatische MDM-Registrierung beginnt.

  Das folgende Diagramm veranschaulicht den allgemeinen Ablauf, der am tatsächlichen Registrierungsprozess beteiligt ist. Das Gerät wird zuerst mit der Microsoft Entra-ID registriert. Dieser Prozess weist dem Gerät einen eindeutigen Gerätebezeichner zu und gibt dem Gerät die Möglichkeit, sich mit microsoft Entra ID (Geräteauthentifizierung) zu authentifizieren. Anschließend wird das Gerät für die Verwaltung mit der MDM registriert. Dieser Schritt ruft den Registrierungsendpunkt auf und fordert die Registrierung für den Benutzer und das Gerät an. An diesem Punkt wurde der Benutzer authentifiziert, und das Gerät wurde mit der Microsoft Entra-ID registriert und authentifiziert. Diese Informationen stehen der MDM in Form von Ansprüchen innerhalb eines Zugriffstokens zur Verfügung, das am Registrierungsendpunkt angezeigt wird.

  

  Es wird erwartet, dass mdm diese Informationen über das Gerät (Geräte-ID) verwendet, wenn die Gerätekonformität mithilfe der Microsoft Graph-API an Microsoft Entra ID gemeldet wird. Ein Beispiel für die Meldung der Gerätekonformität wird weiter unten in diesem Artikel bereitgestellt.

Machen Sie MDM zu einer zuverlässigen Partei von Microsoft Entra ID

Um am im vorherigen Abschnitt beschriebenen integrierten Registrierungsflow teilzunehmen, muss die MDM Zugriffstoken nutzen, die von Microsoft Entra ID ausgestellt wurden. Um die Konformität mit der Microsoft Entra-ID zu melden, muss sich die MDM bei der Microsoft Entra-ID authentifizieren und die Autorisierung in Form eines Zugriffstokens erhalten, mit dem die Microsoft Graph-API aufgerufen werden kann.

Cloudbasierte MDM

Eine cloudbasierte MDM ist eine SaaS-Anwendung, die Geräteverwaltungsfunktionen in der Cloud bereitstellt. Es handelt sich um eine mehrinstanzenfähige Anwendung. Diese Anwendung ist mit der Microsoft Entra ID im Basismandanten des MDM-Anbieters registriert. Wenn sich ein IT-Administrator entscheidet, diese MDM-Lösung zu verwenden, wird eine Instanz dieser Anwendung im Mandanten des Kunden sichtbar gemacht.

Der MDM-Anbieter muss die Anwendung zuerst in ihrem Basismandanten registrieren und als mehrinstanzenfähige Anwendung kennzeichnen. Weitere Informationen zum Hinzufügen von mehrinstanzenfähigen Anwendungen zu Microsoft Entra ID finden Sie im Codebeispiel Integrieren einer App, die Benutzer authentifiziert und Microsoft Graph mithilfe des Mehrinstanzenfähigen Integrationsmusters (SaaS) auf GitHub aufruft.

Die MDM-Anwendung verwendet Schlüssel, um Zugriffstoken von Microsoft Entra ID anzufordern. Diese Schlüssel werden innerhalb des Mandanten des MDM-Anbieters verwaltet und für einzelne Kunden nicht sichtbar. Derselbe Schlüssel wird von der mehrinstanzenfähigen MDM-Anwendung verwendet, um sich mit der Microsoft Entra-ID in dem Kundenmandanten zu authentifizieren, zu dem das verwaltete Gerät gehört.

Lokales MDM

Eine lokale MDM-Anwendung unterscheidet sich von einer Cloud-MDM. Es handelt sich um eine Einzelmandantenanwendung, die eindeutig innerhalb des Mandanten des Kunden vorhanden ist. Kunden müssen die Anwendung direkt in ihrem eigenen Mandanten hinzufügen. Außerdem muss jede Instanz einer lokalen MDM-Anwendung separat registriert werden und über einen separaten Schlüssel für die Authentifizierung mit der Microsoft Entra-ID verfügen.

Um dem Mandanten eine lokale MDM-Anwendung hinzuzufügen, verwenden Sie den Microsoft Entra-Dienst, insbesondere unter Mobilität (MDM und MAM)>Anwendung> hinzufügenEigene Anwendung erstellen. Administratoren können die erforderlichen URLs für die Registrierung und die Nutzungsbedingungen konfigurieren.

Ihr lokales MDM-Produkt muss eine Konfigurationsumgebung verfügbar machen, in der Administratoren die Client-ID, die App-ID und den Schlüssel angeben können, die in ihrem Verzeichnis für diese MDM-Anwendung konfiguriert sind. Sie können diese Client-ID und diesen Schlüssel verwenden, um Token von Microsoft Entra ID anzufordern, wenn Sie die Gerätekonformität melden.

Weitere Informationen zum Registrieren von Anwendungen mit Microsoft Entra ID finden Sie unter Grundlagen zum Registrieren einer Anwendung in Microsoft Entra ID.

Schlüsselverwaltungs- und Sicherheitsrichtlinien

Die von Ihrem MDM-Dienst verwendeten Anwendungsschlüssel sind eine sensible Ressource. Sie sollten aus Sicherheitsgründen in regelmäßigen Abständen geschützt und rollovert werden. Zugriffstoken, die von Ihrem MDM-Dienst zum Aufrufen der Microsoft Graph-API abgerufen werden, sind Bearertoken und sollten geschützt werden, um eine nicht autorisierte Offenlegung zu vermeiden.

Bewährte Sicherheitsmethoden finden Sie unter Microsoft Azure Security Essentials.

Bei cloudbasiertem MDM können Sie ein Rollover für die Anwendungsschlüssel ausführen, ohne dass eine Kundeninteraktion erforderlich ist. Es gibt einen einzelnen Satz von Schlüsseln für alle Kundenmandanten, die vom MDM-Anbieter in seinem Microsoft Entra-Mandanten verwaltet werden.

Für die lokale MDM befinden sich die Microsoft Entra-Authentifizierungsschlüssel im Kundenmandanten, und der Administrator des Kunden muss ein Rollover für die Schlüssel ausführen. Um die Sicherheit zu verbessern, bieten Sie Kunden Anleitungen zum Rollover und Schutz der Schlüssel.

Veröffentlichen Ihrer MDM-App im Microsoft Entra-App-Katalog

IT-Administratoren verwenden den Microsoft Entra-App-Katalog, um eine MDM für ihre Organisation hinzuzufügen. Der App-Katalog ist ein umfangreicher Store mit über 2400 SaaS-Anwendungen, die in Microsoft Entra ID integriert sind.

Hinzufügen von cloudbasierter MDM zum App-Katalog

Um Ihre Anwendung zu veröffentlichen, senden Sie eine Anforderung zum Veröffentlichen Ihrer Anwendung im Microsoft Entra-Anwendungskatalog.

Die folgende Tabelle enthält die erforderlichen Informationen zum Erstellen eines Eintrags im Microsoft Entra-App-Katalog.

Hinzufügen einer lokalen MDM-Instanz zum App-Katalog

Es gibt keine besonderen Anforderungen für das Hinzufügen einer lokalen MDM-Instanz zum App-Katalog. Es gibt einen generischen Eintrag für Administratoren, um ihrem Mandanten eine App hinzuzufügen.

Die Schlüsselverwaltung unterscheidet sich jedoch bei der lokalen MDM. Sie müssen die Client-ID (App-ID) und den Schlüssel abrufen, die der MDM-App innerhalb des Mandanten des Kunden zugewiesen sind. Die ID und der Schlüssel erhalten die Autorisierung für den Zugriff auf die Microsoft Graph-API und melden die Gerätekonformität.

Designs

Die seiten, die vom MDM im integrierten Registrierungsprozess gerendert werden, müssen Windows-Vorlagen verwenden (Herunterladen der Windows-Vorlagen und CSS-Dateien (1.1.4)). Diese Vorlagen sind wichtig für die Registrierung während der Microsoft Entra-Einbindungserfahrung in OOBE, bei der alle Seiten Edge-to-Edge-HTML-Seiten sind. Vermeiden Sie das Kopieren der Vorlagen, da es schwierig ist, die Richtige Platzierung der Schaltfläche zu erhalten.

Es gibt drei verschiedene Szenarien:

1. MDM-Registrierung als Teil von Microsoft Entra join in Windows OOBE.
2. MDM-Registrierung als Teil der Microsoft Entra-Einbindung nach Windows OOBE aus Den Einstellungen.
3. MDM-Registrierung im Rahmen des Hinzufügens eines Microsoft-Geschäftskontos auf einem persönlichen Gerät (BYOD).

Diese Szenarien unterstützen Windows Pro, Enterprise und Education.

Die von Microsoft bereitgestellten CSS-Dateien enthalten Versionsinformationen, und es wird empfohlen, die neueste Version zu verwenden. Es gibt separate CSS-Dateien für Windows-Clientgeräte, OOBE- und Post-OOBE-Umgebungen. Laden Sie die Windows-Vorlagen und CSS-Dateien (1.1.4) herunter.

• Verwenden Sie für Windows 10 oobe-desktop.css
• Verwenden Sie für Windows 11 oobe-light.css

Verwenden von Designs

Eine MDM-Seite muss abhängig vom angezeigten Szenario einem vordefinierten Design entsprechen. Wenn der CXH-HOSTHTTP-Header beispielsweise FRX ist, was das OOBE-Szenario ist, muss die Seite ein dunkles Design mit blauer Hintergrundfarbe unterstützen, das winJS-Datei Ui-dark.css Ver 4.0 und oobe-desktop.css Ver 1.0.4 verwendet.

Semantik des Nutzungsbedingungenprotokolls

Der MDM-Server hostet den Endpunkt der Nutzungsbedingungen . Während des Ablaufs des Microsoft Entra-Joinprotokolls führt Windows eine ganzseitige Umleitung zu diesem Endpunkt durch. Diese Umleitung ermöglicht es der MDM, die geltenden Geschäftsbedingungen anzuzeigen. Es ermöglicht dem Benutzer, die mit der Registrierung verbundenen Bedingungen zu akzeptieren oder abzulehnen. Nachdem der Benutzer die Bedingungen akzeptiert hat, leitet die MDM zurück zu Windows um, damit der Registrierungsprozess fortgesetzt werden kann.

Umleiten zum Endpunkt der Nutzungsbedingungen

Bei dieser Umleitung handelt es sich um eine vollständige Umleitung auf den Endpunkt der Benutzerbedingungen, der von der MDM gehostet wird. Hier sehen Sie eine Beispiel-URL, https://fabrikam.contosomdm.com/TermsOfUse.

Die folgenden Parameter werden in der Abfragezeichenfolge übergeben:

Zugriffstoken

Microsoft Entra ID gibt ein Bearerzugriffstoken aus. Das Token wird im Autorisierungsheader der HTTP-Anforderung übergeben. Hier ist ein typisches Format:

Autorisierung: Bearer CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw...

Die folgenden Ansprüche werden im Zugriffstoken erwartet, das von Windows an den Endpunkt der Nutzungsbedingungen übergeben wird:

Um die Liste der Gruppenmitgliedschaften für den Benutzer abzurufen, können Sie die Microsoft Graph-API verwenden.

Hier sehen Sie eine Beispiel-URL:

https://fabrikam.contosomdm.com/TermsOfUse?redirect_uri=ms-appx-web://ContosoMdm/ToUResponse&client-request-id=34be581c-6ebd-49d6-a4e1-150eff4b7213&api-version=1.0
Authorization: Bearer eyJ0eXAiOi

Es wird erwartet, dass die MDM die Signatur des Zugriffstokens überprüft, um sicherzustellen, dass es von der Microsoft Entra-ID ausgestellt wird und dass der Empfänger geeignet ist.

Inhalt der Nutzungsbedingungen

Die MDM kann bei Bedarf weitere Umleitungen durchführen, bevor dem Benutzer die Inhalte der Nutzungsbedingungen angezeigt werden. Die entsprechenden Inhalte der Nutzungsbedingungen sollten an den Aufrufer (Windows) zurückgegeben werden, damit er dem Endbenutzer im Browsersteuerelement angezeigt werden kann.

Die Inhalte der Nutzungsbedingungen sollten die folgenden Schaltflächen enthalten:

• Akzeptieren : Der Benutzer akzeptiert die Nutzungsbedingungen und fährt mit der Registrierung fort.
• Ablehnen : Der Benutzer lehnt den Registrierungsprozess ab und beendet sie.

Die Inhalte der Nutzungsbedingungen müssen mit dem Design übereinstimmen, das für die anderen Seiten verwendet wird, die während dieses Prozesses gerendert werden.

Endpunktverarbeitungslogik für Nutzungsbedingungen

An diesem Punkt befindet sich der Benutzer auf der Seite mit den Nutzungsbedingungen, die während der OOBE oder in den Einstellungen angezeigt wird. Der Benutzer hat die folgenden Optionen auf der Seite:

• Benutzer klickt auf die Schaltfläche Akzeptieren : Die MDM muss an den URI umgeleitet werden, der durch den parameter redirect_uri in der eingehenden Anforderung angegeben wird. Die folgenden Abfragezeichenfolgenparameter werden erwartet:
  • IsAccepted: Dieser boolesche Wert ist erforderlich und muss auf true festgelegt werden.
  • OpaqueBlob : Erforderlicher Parameter, wenn der Benutzer dies akzeptiert. Die MDM kann dieses Blob verwenden, um dem Registrierungsendpunkt einige Informationen zur Verfügung zu stellen. Der hier beibehaltene Wert wird unverändert am Registrierungsendpunkt verfügbar gemacht. Die MDM kann diesen Parameter zu Korrelationszwecken verwenden.
  • Hier ist eine Beispielumleitung: ms-appx-web://MyApp1/ToUResponse?OpaqueBlob=value&IsAccepted=true
• Benutzer klickt auf die Schaltfläche Ablehnen : Die MDM muss zu dem in redirect_uri in der eingehenden Anforderung angegebenen URI umgeleitet werden. Die folgenden Abfragezeichenfolgenparameter werden erwartet:
  • IsAccepted: Dieser boolesche Wert ist erforderlich und muss auf false festgelegt werden. Diese Option gilt auch, wenn der Benutzer die Nutzungsbedingungen übersprungen hat.
  • OpaqueBlob : Es wird nicht erwartet, dass dieser Parameter verwendet wird. Die Registrierung wird beendet, und dem Benutzer wird eine Fehlermeldung angezeigt.

Benutzer überspringen die Nutzungsbedingungen, wenn sie ihrem Gerät ein Microsoft-Geschäftskonto hinzufügen. Sie können es jedoch während des Microsoft Entra-Einbindungsprozesses nicht überspringen. Zeigen Sie die Schaltfläche "Ablehnen" nicht im Microsoft Entra-Beitrittsprozess an. Der Benutzer kann die MDM-Registrierung nicht ablehnen, wenn er vom Administrator für die Microsoft Entra-Einbindung konfiguriert wurde.

Es wird empfohlen, die Parameter client-request-id in der Abfragezeichenfolge als Teil dieser Umleitungsantwort zu senden.

Fehlerbehandlung bei Nutzungsbedingungen

Wenn während der Verarbeitung der Nutzungsbedingungen ein Fehler auftritt, kann die MDM zwei Parameter zurückgeben : einen - und error_description -errorParameter in seiner Umleitungsanforderung zurück an Windows. Die URL sollte codiert sein, und der Inhalt des error_description sollte im englischen Nur-Text enthalten sein. Dieser Text ist für den Endbenutzer nicht sichtbar. Die Lokalisierung des error_description Texts ist also kein Problem.

Hier sehen Sie das URL-Format:

HTTP/1.1 302
Location:
<redirect_uri>?error=access_denied&error_description=Access%20is%20denied%2E

Example:
HTTP/1.1 302
Location: ms-appx-web://App1/ToUResponse?error=access_denied&error_description=Access%20is%20denied%2E

In der folgenden Tabelle sind die Fehlercodes aufgeführt.

Registrierungsprotokoll mit Microsoft Entra ID

Bei der in Azure integrierten MDM-Registrierung gibt es keine Ermittlungsphase, und die Ermittlungs-URL wird direkt von Azure an das System übergeben. Die folgende Tabelle zeigt den Vergleich zwischen den herkömmlichen und Azure-Registrierungen.

Verwaltungsprotokoll mit Microsoft Entra ID

Es gibt zwei verschiedene MDM-Registrierungstypen, die in Microsoft Entra ID integriert werden und Microsoft Entra-Benutzer- und Geräteidentitäten verwenden. Je nach Registrierungstyp muss der MDM-Dienst möglicherweise einen einzelnen oder mehrere Benutzer verwalten.

• Verwaltung mehrerer Benutzer für in Microsoft Entra eingebundene Geräte

  In diesem Szenario gilt die MDM-Registrierung für jeden Microsoft Entra-Benutzer, der sich beim in Microsoft Entra eingebundenen Gerät anmeldet. Nennen Sie diesen Registrierungstyp eine Geräteregistrierung oder eine Registrierung mit mehreren Benutzern. Der Verwaltungsserver kann die Benutzeridentität bestimmen, welche Richtlinien für diesen Benutzer vorgesehen sind, und entsprechende Richtlinien an das Gerät senden. Damit der Verwaltungsserver den aktuellen Benutzer identifizieren kann, der am Gerät angemeldet ist, verwendet der OMA DM-Client die Microsoft Entra-Benutzertoken. Jede Verwaltungssitzung enthält einen zusätzlichen HTTP-Header, der ein Microsoft Entra-Benutzertoken enthält. Diese Informationen werden im DM-Paket bereitgestellt, das an den Verwaltungsserver gesendet wird. Unter bestimmten Umständen wird das Microsoft Entra-Benutzertoken jedoch nicht an den Verwaltungsserver gesendet. Ein solches Szenario tritt unmittelbar nach Abschluss der MDM-Registrierungen während des Microsoft Entra-Einbindungsprozesses auf. Bis der Microsoft Entra-Einbindungsprozess abgeschlossen ist und sich der Microsoft Entra-Benutzer beim Computer anmeldet, ist das Microsoft Entra-Benutzertoken für den OMA-DM-Prozess nicht verfügbar. In der Regel wird die MDM-Registrierung abgeschlossen, bevor sich der Microsoft Entra-Benutzer beim Computer anmeldet, und die erste Verwaltungssitzung enthält kein Microsoft Entra-Benutzertoken. Der Verwaltungsserver sollte überprüfen, ob das Token fehlt, und nur in diesem Fall Geräterichtlinien senden. Ein weiterer möglicher Grund für ein fehlendes Microsoft Entra-Token in der OMA-DM-Nutzlast ist, dass ein Gast am Gerät angemeldet ist.

• Hinzufügen eines Geschäftskontos und einer MDM-Registrierung zu einem Gerät:

  In diesem Szenario gilt die MDM-Registrierung für einen einzelnen Benutzer, der zunächst sein Geschäftskonto hinzugefügt und das Gerät registriert hat. Bei diesem Registrierungstyp kann der Verwaltungsserver Microsoft Entra-Token ignorieren, die möglicherweise während der Verwaltungssitzung gesendet werden. Unabhängig davon, ob das Microsoft Entra-Token vorhanden ist oder fehlt, sendet der Verwaltungsserver sowohl Benutzer- als auch Geräterichtlinien an das Gerät.

• Auswerten von Microsoft Entra-Benutzertoken:

  Das Microsoft Entra-Token weist den HTTP-Autorisierungsheader im folgenden Format auf:

  Authorization:Bearer <Azure AD User Token Inserted here>
  

  Möglicherweise sind im Microsoft Entra-Token weitere Ansprüche vorhanden, z. B.:

  • Benutzer : Aktuell angemeldeter Benutzer
  • Gerätekonformität: Festlegen des Werts für den MDM-Dienst in Azure
  • Geräte-ID: Identifiziert das Gerät, das eingecheckt wird.
  • Mandanten-ID

  Zugriffstoken, die von Microsoft Entra ID ausgestellt werden, sind JSON-Webtoken (JWTs). Windows stellt dem MDM-Registrierungsendpunkt ein gültiges JWT-Token vor, um den Registrierungsprozess zu starten. Es gibt eine Reihe von Optionen zum Auswerten der Token:

  • Verwenden Sie die JWT-Tokenhandlererweiterung für WIF, um den Inhalt des Zugriffstokens zu überprüfen und die für die Verwendung erforderlichen Ansprüche zu extrahieren. Weitere Informationen finden Sie unter JwtSecurityTokenHandler-Klasse.
  • In den Codebeispielen für die Microsoft Entra-Authentifizierung finden Sie ein Beispiel für die Arbeit mit Zugriffstoken. Ein Beispiel finden Sie unter NativeClient-DotNet.

Gerätewarnung 1224 für Microsoft Entra-Benutzertoken

Eine Warnung wird gesendet, wenn die DM-Sitzung gestartet wird und ein Microsoft Entra-Benutzer angemeldet ist. Die Warnung wird im OMA DM-Paket Nr. 1 gesendet. Beispiel:

Alert Type: com.microsoft/MDM/AADUserToken

Alert sample:
<SyncBody>
 <Alert>
  <CmdID>1</CmdID>
  <Data>1224</Data>
  <Item>
   <Meta>
    <Type xmlns= "syncml:metinf ">com.microsoft/MDM/AADUserToken</Type>
   </Meta>
   <Data>UserToken inserted here</Data>
  </Item>
 </Alert>
 ... other XML tags ...
</SyncBody>

Bestimmen, wann ein Benutzer über Abrufe angemeldet ist

Eine Warnung wird an den MDM-Server im DM-Paket Nr. 1 gesendet.

• Warnungstyp: com.microsoft/MDM/LoginStatus
• Warnungsformat : chr
• Warnungsdaten: Geben Sie Anmeldestatusinformationen für den aktuell aktiven angemeldeten Benutzer an.
  • Angemeldeter Benutzer, der über ein Microsoft Entra-Konto verfügt – vordefinierter Text: Benutzer.
  • Angemeldeter Benutzer ohne Microsoft Entra-Konto: vordefinierter Text: andere.
  • Kein aktiver Benutzer – vordefinierter Text:none

Beispiel:

<SyncBody>
 <Alert>
  <CmdID>1</CmdID>
  <Data>1224</Data>
  <Item>
   <Meta>
    <Type xmlns= "syncml:metinf ">com.microsoft/MDM/LoginStatus</Type>
   </Meta>
   <Data>user</Data>
  </Item>
 </Alert>
 ... other XML tags ...
</SyncBody>

Melden der Gerätekonformität an Microsoft Entra ID

Sobald ein Gerät bei der MDM für die Verwaltung registriert ist, werden vom IT-Administrator konfigurierte Organisationsrichtlinien auf dem Gerät erzwungen. MDM wertet die Gerätekonformität mit konfigurierten Richtlinien aus und meldet sie dann an Microsoft Entra ID. In diesem Abschnitt wird der Graph-API-Aufruf behandelt, mit dem Sie einen Gerätekonformitätsstatus an Microsoft Entra ID melden können.

Ein Beispiel, das veranschaulicht, wie eine MDM ein Zugriffstoken mit OAuth 2.0 client_credentials Gewährungstyp abrufen kann, finden Sie unter Daemon_CertificateCredential-DotNet.

• Cloudbasierte MDM : Wenn Es sich bei Ihrem Produkt um einen cloudbasierten mehrinstanzenfähigen MDM-Dienst handelt, haben Sie einen einzelnen Schlüssel für Ihren Dienst in Ihrem Mandanten konfiguriert. Verwenden Sie diesen Schlüssel, um die Autorisierung zu erhalten, um den MDM-Dienst mit der Microsoft Entra-ID zu authentifizieren.
• Lokale MDM- Wenn Es sich bei Ihrem Produkt um eine lokale MDM handelt, müssen Kunden Ihr Produkt mit dem Schlüssel konfigurieren, der für die Authentifizierung mit der Microsoft Entra-ID verwendet wird. Diese Schlüsselkonfiguration liegt daran, dass jede lokale Instanz Ihres MDM-Produkts über einen anderen mandantenspezifischen Schlüssel verfügt. Daher müssen Sie möglicherweise eine Konfigurationsumgebung in Ihrem MDM-Produkt verfügbar machen, mit der Administratoren den Schlüssel angeben können, der für die Authentifizierung mit der Microsoft Entra-ID verwendet werden soll.

Verwenden der Microsoft Graph-API

Der folgende Rest-API-Beispielaufruf veranschaulicht, wie eine MDM die Microsoft Graph-API verwenden kann, um den Konformitätsstatus eines verwalteten Geräts zu melden.

Sample Graph API Request:

PATCH https://graph.windows.net/contoso.com/devices/db7ab579-3759-4492-a03f-655ca7f52ae1?api-version=beta HTTP/1.1
Authorization: Bearer eyJ0eXAiO.........
Accept: application/json
Content-Type: application/json
{  "isManaged":true,
   "isCompliant":true
}

Es gilt Folgendes:

• contoso.com : Dieser Wert ist der Name des Microsoft Entra-Mandanten, in dessen Verzeichnis das Gerät eingebunden wurde.
• db7ab579-3759-4492-a03f-655ca7f52ae1 : Dieser Wert ist der Gerätebezeichner für das Gerät, dessen Konformitätsinformationen an microsoft Entra ID gemeldet werden.
• eyJ0eXAiO......... : Dieser Wert ist das Bearerzugriffstoken, das von der Microsoft Entra-ID für die MDM ausgestellt wird, die mdm zum Aufrufen der Microsoft Graph-API autorisiert. Das Zugriffstoken wird im HTTP-Autorisierungsheader der Anforderung platziert.
• isManaged und isCompliant : Diese booleschen Attribute geben den Konformitätsstatus an.
• api-version : Verwenden Sie diesen Parameter, um anzugeben, welche Version der Graph-API angefordert wird.

Antwort:

• Erfolg: HTTP 204 ohne Inhalt.
• Fehler/Fehler: HTTP 404 nicht gefunden. Dieser Fehler wird möglicherweise zurückgegeben, wenn das angegebene Gerät oder der angegebene Mandant nicht gefunden werden kann.

Datenverlust während der Aufhebung der Registrierung von Microsoft Entra Join

Wenn ein Benutzer über microsoft Entra join bei MDM registriert wird und dann die Registrierung trennt, gibt es keine Warnung, dass der Benutzer Windows Information Protection-Daten (WIP) verliert. Die Trennungsmeldung weist nicht auf den Verlust von WIP-Daten hin.

Fehlercodes