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 MDM registriert werden können.

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

  • Kann die Konformität mit organization-Richtlinien erzwingen, Apps hinzufügen oder entfernen und vieles mehr.
  • Kann die Konformität eines Geräts in Microsoft Entra ID melden.
  • Microsoft Entra ID können den Zugriff auf organization Ressourcen oder Anwendungen zulassen, die durch Microsoft Entra ID auf Geräten geschützt sind, 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:

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 erstellen können. In Windows 11 wird die Webansicht jedoch innerhalb eines iframes gerendert. Es ist wichtig, dass MDM-Anbieter, die mit Microsoft Entra ID integrieren, 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 Microsoft Entra Registrierung für ein Microsoft Entra Konto gesichertes Active Directory-Verbunddienste (AD FS) funktioniert, müssen Sie die Kennwortauthentifizierung für das Intranet im AD FS-Dienst aktivieren. Weitere Informationen finden Sie unter Konfigurieren von Azure MFA 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 organization- oder BYOD-Szenarien ist ähnlich.

Hinweis

Benutzer können die Geräteregistrierung nicht über die Access-Benutzeroberfläche für Geschäfts-, Schul- oder Unikonten entfernen, da die Verwaltung an das Microsoft Entra ID- oder Geschäftskonto gebunden ist.

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

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 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 organization ihr Gerät steuern können. 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 organization-Geräten 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 ausgestellt wurden.

  • 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 bei 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 bei 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.

    Microsoft Entra Registrierungsflow

    Es wird erwartet, dass mdm diese Informationen über das Gerät (Geräte-ID) verwendet, wenn die Gerätekonformität mithilfe des 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 Microsoft Entra ID zu melden, muss sich die MDM bei Microsoft Entra ID authentifizieren und die Autorisierung in Form eines Zugriffstokens erhalten, das es ihr ermöglicht, die Microsoft-Graph-API aufzurufen.

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 bei Microsoft Entra ID im Basismandanten des MDM-Anbieters registriert. Wenn sich ein IT-Administrator entscheidet, diese MDM-Lösung zu verwenden, wird eine instance 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 Mehrinstanzenintegrationsmusters (SaaS) auf GitHub aufruft.

Hinweis

Wenn Sie für den MDM-Anbieter keinen vorhandenen Microsoft Entra Mandanten mit einem von Ihnen verwalteten Microsoft Entra-Abonnement haben, befolgen Sie die folgenden schrittweisen Anleitungen:

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 bei Microsoft Entra ID in dem Kundenmandanten zu authentifizieren, zu dem das verwaltete Gerät gehört.

Hinweis

Alle MDM-Apps müssen Microsoft Entra v2-Token implementieren, bevor wir zertifizieren, dass die Integration funktioniert. Aufgrund von Änderungen an der Microsoft Entra App-Plattform ist die Verwendung von Microsoft Entra v2-Token eine harte Anforderung. Weitere Informationen finden Sie unter Microsoft Identity Platform Zugriffstoken.

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 instance einer lokalen MDM-Anwendung separat registriert werden und über einen separaten Schlüssel für die Authentifizierung mit 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 bei 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 unbefugte 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.

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

Hinweis

Sie sollten mit dem Microsoft Entra Engineering-Team zusammenarbeiten, wenn Ihre MDM-Anwendung cloudbasiert ist und als mehrinstanzenfähige MDM-Anwendung aktiviert werden muss.

Senden Sie zum Veröffentlichen Ihrer Anwendung eine Anforderung zum Veröffentlichen Ihrer Anwendung in Microsoft Entra Anwendungskatalog.

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

Element Beschreibung
Anwendungs-ID Die Client-ID Ihrer MDM-App, die in Ihrem Mandanten konfiguriert ist. Diese ID ist der eindeutige Bezeichner für Ihre mehrinstanzenfähige App.
Herausgeber Eine Zeichenfolge, die den Herausgeber der App identifiziert.
Anwendungs-URL Eine URL zur Landing Page Ihrer App, auf der Ihre Administratoren weitere Informationen zur MDM-App erhalten und einen Link zur Landing Page Ihrer App enthält. Diese URL wird nicht für die tatsächliche Registrierung verwendet.
Beschreibung Eine kurze Beschreibung Ihrer MDM-App, die maximal 255 Zeichen lang sein muss.
Symbole Ein Satz von Logosymbolen für die MDM-App. Abmessungen: 45 x 45, 150 x 122, 214 x 215

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 Join-Erfahrung 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 im Rahmen von Microsoft Entra Teilnahme an Windows OOBE.
  2. MDM-Registrierung im Rahmen Microsoft Entra Joins nach Windows OOBE über 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.

CXH-HOST (HTTP-HEADER) Szenario Hintergrunddesign WinJS Szenario-CSS
FRX OOBE Dunkles Design + blaue Hintergrundfarbe Dateiname: Ui-dark.css Dateiname: oobe-dekstop.css
MOSET Einstellungen/Post OOBE Helles Design Dateiname: Ui-light.css Dateiname: settings-desktop.css

Semantik des Nutzungsbedingungenprotokolls

Der MDM-Server hostet den Endpunkt der Nutzungsbedingungen . Während des Microsoft Entra Joinprotokollflows 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:

Element Beschreibung
redirect_uri Nachdem der Benutzer die Nutzungsbedingungen akzeptiert oder abgelehnt hat, wird er zu dieser URL umgeleitet.
client-request-id Eine GUID, die zum Korrelieren von Protokollen zu Diagnose- und Debugzwecken verwendet wird. Verwenden Sie diesen Parameter, um den Status der Registrierungsanforderung zu protokollieren oder nachzuverfolgen, um die Grundursache von Fehlern zu ermitteln.
API-Version Gibt die Version des vom Client angeforderten Protokolls an. Dieser Wert bietet einen Mechanismus zur Unterstützung von Versionsrevisionen des Protokolls.
mode Gibt an, dass sich das Gerät organization im Besitz von mode=azureadjoin befindet. Dieser Parameter ist für BYOD-Geräte nicht vorhanden.

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:

Element Beschreibung
Objekt-ID Bezeichner des Benutzerobjekts, das dem authentifizierten Benutzer entspricht.
UPN Ein Anspruch, der den Benutzerprinzipalnamen (UPN) des authentifizierten Benutzers enthält.
TID Ein Anspruch, der die Mandanten-ID des Mandanten darstellt. Im obigen Beispiel ist dies Fabrikam.
Ressource Eine bereinigungs-URL, die die MDM-Anwendung darstellt. Beispiel: https://fabrikam.contosomdm.com

Hinweis

Das Zugriffstoken enthält keinen Geräte-ID-Anspruch, da das Gerät zu diesem Zeitpunkt möglicherweise noch nicht registriert ist.

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 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 Joinprozesses nicht überspringen. Zeigen Sie die Schaltfläche "Ablehnen" nicht im Microsoft Entra Join-Prozess an. Der Benutzer kann die MDM-Registrierung nicht ablehnen, wenn er vom Administrator für den Microsoft Entra-Beitritt 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.

Ursache HTTP-status Fehler Beschreibung
API-Version 302 invalid_request Nicht unterstützte Version
Mandanten- oder Benutzerdaten fehlen, oder andere erforderliche Voraussetzungen für die Geräteregistrierung sind nicht erfüllt. 302 unauthorized_client Nicht autorisierter Benutzer oder Mandant
Fehler bei Microsoft Entra Tokenüberprüfung 302 unauthorized_client unauthorized_client
Interner Dienstfehler 302 server_error Interner Dienstfehler

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.

Detail Herkömmliche MDM-Registrierung Microsoft Entra Join (organization gerät im Besitz) Microsoft Entra ID fügt ein Geschäftskonto (benutzereigenes Gerät) hinzu.
Automatische MDM-Ermittlung mithilfe der E-Mail-Adresse zum Abrufen der MDM-Ermittlungs-URL Anmeldung Nicht zutreffend
In Azure bereitgestellte Ermittlungs-URL
Verwendet die MDM-Ermittlungs-URL. Anmeldung
Registrierungserneuerung
ROBO		 Anmeldung
Registrierungserneuerung
ROBO		 Anmeldung
Registrierungserneuerung
ROBO
Ist eine MDM-Registrierung erforderlich? Ja Ja Nein
Der Benutzer kann ablehnen.
Authentifizierungstyp OnPremise
Federated
Zertifikat		 Federated Federated
EnrollmentPolicyServiceURL Optional (alle Authentifizierung) Optional (alle Authentifizierung) Optional (alle Authentifizierung)
EnrollmentServiceURL Erforderlich (alle Authentifizierung) Verwendet (alle Authentifizierung) Verwendet (alle Authentifizierung)
EnrollmentServiceURL enthält die Betriebssystemversion, die Betriebssystemplattform und andere Attribute, die von der MDM-Ermittlungs-URL bereitgestellt werden. Sehr empfehlenswert Sehr empfehlenswert Sehr empfehlenswert
Verwendeter AuthenticationServiceURL Verwendet (Verbundauthentifizierung) Übersprungen Übersprungen
BinarySecurityToken Benutzerdefiniert pro MDM Microsoft Entra ID ausgestelltes Token Microsoft Entra ID ausgestelltes Token
EnrollmentType Vollständig Gerät Vollständig
Registrierter Zertifikattyp Benutzerzertifikat Gerätezertifikat Benutzerzertifikat
Registrierter Zertifikatspeicher Mein/Benutzer My/System Mein/Benutzer
CSR-Antragstellername Benutzerprinzipalname Geräte-ID Benutzerprinzipalname
EnrollmentData Nutzungsbedingungen für binäres Blob als AdditionalContext für EnrollmentServiceURL Nicht unterstützt. Unterstützt Unterstützt
Zugriff auf CSPs während der Registrierung Windows 10 Unterstützung:
– DMClient
– CertificateStore
– RootCATrustedCertificates
– ClientCertificateInstall
– EnterpriseModernAppManagement
– PassportForWork
-Politik
- w7 APPLICATION

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 Microsoft Entra verbundene Geräte

    In diesem Szenario gilt die MDM-Registrierung für jeden Microsoft Entra Benutzer, der sich beim Microsoft Entra verbundenen 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 Microsoft Entra Benutzertoken jedoch nicht an den Verwaltungsserver gesendet. Ein solches Szenario tritt unmittelbar nach Abschluss der MDM-Registrierungen während Microsoft Entra Joinprozesses auf. Bis Microsoft Entra Joinprozess abgeschlossen ist und sich Microsoft Entra Benutzer beim Computer anmeldet, ist Microsoft Entra Benutzertoken für den OMA-DM-Prozess nicht verfügbar. In der Regel wird die MDM-Registrierung abgeschlossen, bevor sich 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, wenn 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 während der Verwaltungssitzung gesendet werden können. Unabhängig davon, ob 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>

    Im Microsoft Entra Token können weitere Ansprüche vorhanden sein, 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

    Von Microsoft Entra ID ausgestellte Zugriffstoken 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.
    • Ein Beispiel für die Arbeit mit Zugriffstoken finden Sie in den Microsoft Entra Authentifizierungscodebeispielen. 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: Stellen Sie Anmeldeinformationen status für den aktuell aktiven angemeldeten Benutzer bereit.
    • 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 mdm für die Verwaltung registriert ist, werden organization Richtlinien, die vom IT-Administrator konfiguriert wurden, 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 Anruf behandelt, mit dem Sie eine Gerätekonformität status 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 bei 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 bei Microsoft Entra ID verwendet wird. Diese Schlüsselkonfiguration liegt daran, dass jede lokale instance Ihres MDM-Produkts über einen anderen mandantenspezifischen Schlüssel verfügt. Daher müssen Sie möglicherweise eine Konfigurationsoberfläche in Ihrem MDM-Produkt verfügbar machen, mit der Administratoren den Schlüssel angeben können, der für die Authentifizierung bei Microsoft Entra ID verwendet werden soll.

Verwenden von Microsoft Graph-API

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

Hinweis

Diese API gilt nur für genehmigte MDM-Apps auf Windows-Geräten.

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 Microsoft Entra ID an die MDM ausgestellt wird, die die MDM zum Aufrufen des Microsoft-Graph-API autorisiert. Das Zugriffstoken wird im HTTP-Autorisierungsheader der Anforderung platziert.
  • isManaged und isCompliant: Diese booleschen Attribute geben die Konformität status 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 Beitritt 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.

aadj-Registrierung aufheben.

Fehlercodes

Code ID Fehlermeldung
0x80180001 "idErrorServerConnectivity", // MENROLL_E_DEVICE_MESSAGE_FORMAT_ERROR Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x80180002 "idErrorAuthenticationFailure", // MENROLL_E_DEVICE_AUTHENTICATION_ERROR Bei der Authentifizierung Ihres Kontos oder Geräts ist ein Problem aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180003 "idErrorAuthorizationFailure", // MENROLL_E_DEVICE_AUTHORIZATION_ERROR Dieser Benutzer ist nicht zur Registrierung autorisiert. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180004 "idErrorMDMCertificateError", // MENROLL_E_DEVICE_CERTIFCATEREQUEST_ERROR Es ist ein Zertifikatfehler aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180005 "idErrorServerConnectivity", // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x80180006 "idErrorServerConnectivity", // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x80180007 "idErrorAuthenticationFailure", // MENROLL_E_DEVICE_INVALIDSECURITY_ERROR Bei der Authentifizierung Ihres Kontos oder Geräts ist ein Problem aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180008 "idErrorServerConnectivity", // MENROLL_E_DEVICE_UNKNOWN_ERROR Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x80180009 "idErrorAlreadyInProgress", // MENROLL_E_ENROLLMENT_IN_PROGRESS Eine weitere Registrierung wird ausgeführt. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x8018000A "idErrorMDMAlreadyEnrolled", // MENROLL_E_DEVICE_ALREADY_ENROLLED Dieses Gerät ist bereits registriert. Sie können sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x8018000D "idErrorMDMCertificateError", // MENROLL_E_DISCOVERY_SEC_CERT_DATE_INVALID Es ist ein Zertifikatfehler aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x8018000E "idErrorAuthenticationFailure", // MENROLL_E_PASSWORD_NEEDED Bei der Authentifizierung Ihres Kontos oder Geräts ist ein Problem aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x8018000F "idErrorAuthenticationFailure", // MENROLL_E_WAB_ERROR Bei der Authentifizierung Ihres Kontos oder Geräts ist ein Problem aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180010 "idErrorServerConnectivity", // MENROLL_E_CONNECTIVITY Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x80180012 "idErrorMDMCertificateError", // MENROLL_E_INVALIDSSLCERT Es ist ein Zertifikatfehler aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180013 "idErrorDeviceLimit", // MENROLL_E_DEVICECAPREACHED Anscheinend gibt es zu viele Geräte oder Benutzer für dieses Konto. Wenden Sie sich mit dem Fehlercode {0}an Ihren Systemadministrator.
0x80180014 "idErrorMDMNotSupported", // MENROLL_E_DEVICENOTSUPPORTED Dieses Feature wird nicht unterstützt. Wenden Sie sich mit dem Fehlercode {0}an Ihren Systemadministrator.
0x80180015 "idErrorMDMNotSupported", // MENROLL_E_NOTSUPPORTED Dieses Feature wird nicht unterstützt. Wenden Sie sich mit dem Fehlercode {0}an Ihren Systemadministrator.
0x80180016 "idErrorMDMRenewalRejected", // MENROLL_E_NOTELIGIBLETORENEW Der Server hat die Anforderung nicht akzeptiert. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180017 "idErrorMDMAccountMaintenance", // MENROLL_E_INMAINTENANCE Der Dienst befindet sich in der Wartung. Sie können dies später erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180018 "idErrorMDMLicenseError", // MENROLL_E_USERLICENSE Es ist ein Fehler mit Ihrer Lizenz aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x80180019 "idErrorInvalidServerConfig", // MENROLL_E_ENROLLMENTDATAINVALID Der Server ist anscheinend nicht ordnungsgemäß konfiguriert. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
"rejectedTermsOfUse" "idErrorRejectedTermsOfUse" Ihre organization setzt voraus, dass Sie den Nutzungsbedingungen zustimmen. Versuchen Sie es erneut, oder bitten Sie Ihren Support um weitere Informationen.
0x801c0001 "idErrorServerConnectivity", // DSREG_E_DEVICE_MESSAGE_FORMAT_ERROR Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x801c0002 "idErrorAuthenticationFailure", // DSREG_E_DEVICE_AUTHENTICATION_ERROR Bei der Authentifizierung Ihres Kontos oder Geräts ist ein Problem aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x801c0003 "idErrorAuthorizationFailure", // DSREG_E_DEVICE_AUTHORIZATION_ERROR Dieser Benutzer ist nicht zur Registrierung autorisiert. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x801c0006 "idErrorServerConnectivity", // DSREG_E_DEVICE_INTERNALSERVICE_ERROR Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x801c000B "idErrorUntrustedServer", // DSREG_E_DISCOVERY_REDIRECTION_NOT_TRUSTED Der Server, der kontaktiert wird, ist nicht vertrauenswürdig. Wenden Sie sich mit dem Fehlercode {0}an Ihren Systemadministrator.
0x801c000C "idErrorServerConnectivity", // DSREG_E_DISCOVERY_FAILED Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x801c000E "idErrorDeviceLimit", // DSREG_E_DEVICE_REGISTRATION_QUOTA_EXCCEEDED Anscheinend gibt es zu viele Geräte oder Benutzer für dieses Konto. Wenden Sie sich mit dem Fehlercode {0}an Ihren Systemadministrator.
0x801c000F "idErrorDeviceRequiresReboot", // DSREG_E_DEVICE_REQUIRES_REBOOT Ein Neustart ist erforderlich, um die Geräteregistrierung abzuschließen.
0x801c0010 "idErrorInvalidCertificate", // DSREG_E_DEVICE_AIK_VALIDATION_ERROR Anscheinend verfügen Sie über ein ungültiges Zertifikat. Wenden Sie sich mit dem Fehlercode {0}an Ihren Systemadministrator.
0x801c0011 "idErrorAuthenticationFailure", // DSREG_E_DEVICE_ATTESTATION_ERROR Bei der Authentifizierung Ihres Kontos oder Geräts ist ein Problem aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x801c0012 "idErrorServerConnectivity", // DSREG_E_DISCOVERY_BAD_MESSAGE_ERROR Fehler bei der Kommunikation mit dem Server. Sie können dies erneut versuchen oder sich mit dem Fehlercode an Ihren Systemadministrator wenden. {0}
0x801c0013 "idErrorAuthenticationFailure", // DSREG_E_TENANTID_NOT_FOUND Bei der Authentifizierung Ihres Kontos oder Geräts ist ein Problem aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.
0x801c0014 "idErrorAuthenticationFailure", // DSREG_E_USERSID_NOT_FOUND Bei der Authentifizierung Ihres Kontos oder Geräts ist ein Problem aufgetreten. Sie können dies erneut versuchen oder sich mit dem Fehlercode {0}an Ihren Systemadministrator wenden.