Windows Radial Controller Sample Report Descriptors

This is source I found from another site, main source you can find in last paragraph

Azure Active Directory is the world largest enterprise cloud identity management service. It’s used by millions of organizations to access Office 365 and thousands of business applications from Microsoft and third party software as a service (SaaS) vendors. Many of the rich Windows 10 experiences for organizational users (such as store access or OS state roaming) use Azure AD as the underlying identity infrastructure. Windows 10 provides an integrated configuration experience with Azure AD, allowing devices to be registered in Azure AD and enrolled into MDM in a smooth integrated flow.

Once a device is enrolled in MDM, the MDM can enforce compliance with corporate policies, add or remove apps, and more. Additionally, the MDM can report a device’s compliance Azure AD. This enables Azure AD to allow access to corporate resources or applications secured by Azure AD only to devices that comply with policies. To support these rich experiences with their MDM product, MDM vendors can integrate with Azure AD. This topic describes the steps involved.

Connect to Azure AD

Several ways to connect your devices:

For company-owned devices:

  • Join Windows to a traditional Active Directory domain
  • Join Windows to Azure AD

For personal devices (BYOD):

  • Add a Microsoft work account to Windows

Azure AD Join

Company owned devices are traditionally joined to the on-premises Active Directory domain of the organization. These devices can be managed using Group Policy or computer management software such as System Center Configuration Manager. In Windows 10, it’s also possible to manage domain joined devices with an MDM.

Windows 10 introduces a new way to configure and deploy corporate owned Windows devices. This mechanism is called Azure AD Join. Like traditional domain join, Azure AD Join allows devices to become known and managed by an organization. However, with Azure AD Join, Windows authenticates to Azure AD instead of authenticating to a domain controller.

Azure AD Join also enables company owned devices to be automatically enrolled in, and managed by an MDM. Furthermore, Azure AD Join can be performed on a store-bought PC, in the out-of-box experience (OOBE), which helps organizations streamline their device deployment. An administrator can require that users belonging to one or more groups enroll their devices for management with an MDM. If a user is configured to require automatic enrollment during Azure AD Join, this enrollment becomes a mandatory step to configure Windows. If the MDM enrollment fails, then the device will not be joined to Azure AD.

Important Every user enabled for automatic MDM enrollment with Azure AD Join must be assigned a valid Azure Active Directory Premium license.

BYOD scenario

Windows 10 also introduces a simpler way to configure personal devices to access work apps and resources. Users can add their Microsoft work account to Windows and enjoy simpler and safer access to the apps and resources of the organization. During this process, Azure AD detects if the organization has configured an MDM. If that’s the case, Windows attempts to enroll the device in MDM as part of the “add account” flow. It’s important to note that in the BYOD case, users can reject the MDM Terms of Use—in which case the device is not enrolled in MDM and access to corporate resources is typically restricted.

Integrated MDM enrollment and UX

Two Azure AD MDM enrollment scenarios:

  • Joining a device to Azure AD for company-owned devices
  • Adding a work account to a personal device (BYOD)

In both scenarios, Azure AD is responsible for authenticating the user and the device, which provides a verified unique device identifier that can be used for MDM enrollment.

In both scenarios, the enrollment flow provides an opportunity for the MDM service to render it's own UI, using a web view. MDM vendors should use this to render the Terms of Use (TOU), which can be different for company-owned and BYOD devices. MDM vendors can also use the web view to render additional UI elements, such as asking for a one-time PIN, if this is part of the business process of the organization.

In the out-of-the-box scenario, the web view is 100% full screen, which gives the MDM vendor the ability to paint an edge-to-edge experience. With great power comes great responsibility! It is important that MDM vendors who chose to integrate with Azure AD to respect the Windows 10 design guidelines to the letter. This includes using a responsive web design and respecting the Windows accessibility guidelines, which includes the forward and back buttons that are properly wired to the navigation logic. Additional details are provided later in this topic.

For Azure AD enrollment to work for an Active Directory Federated Services (AD FS) backed Azure AD account, you must enable password authentication for the intranet on the ADFS service as described in solution #2 in this article.

Once a user has an Azure AD account added to Windows 10 and enrolled in MDM, the enrollment can be manages through

Settings >

Accounts >

Work access. Device management of either Azure AD Join for corporate scenarios or BYOD scenarios are similar.

Note Users cannot remove the device enrollment through the

Work access user interface because management is tied to the Azure AD or work account.

MDM endpoints involved in Azure AD integrated enrollment

Azure AD MDM enrollment is a two-step process:

  1. Display the Terms of Use and gather user consent.

    This is a passive flow where the user is redirected in a browser control (webview) to the URL of the Terms of Use of the MDM.

  2. Enroll the device.

    This is an active flow where Windows OMA DM agent calls the MDM service to enroll the device.

To support Azure AD enrollment, MDM vendors must host and expose a Terms of Use endpoint and an MDM enrollment endpoint.

Terms of Use endpoint

Use this endpoint to inform users of the ways in which their device can be controlled by their organization. The Terms of Use page is responsible for collecting user’s consent before the actual enrollment phase begins.

It’s important to understand that the Terms of Use flow is a "black box" to Windows and Azure AD. The whole web view is redirected to the Terms of Use URL, and the user is expected to be redirected back after approving (or in some cases rejecting) the Terms. This design allows the MDM vendor to customize their Terms of Use for different scenarios (e.g., different levels of control are applied on BYOD vs. company-owned devices) or implement user/group based targeting (e.g. users in certain geographies may be subject to stricter device management policies).

The Terms of Use endpoint can be used to implement additional business logic, such as collecting a one-time PIN provided by IT to control device enrollment. However, MDM vendors must not use the Terms of Use flow to collect user credentials, which could lead to a highly degraded user experience. It’s not needed, since part of the MDM integration ensures that the MDM service can understand tokens issued by Azure AD.

MDM enrollment endpoint

After the users accepts the Terms of Use, the device is registered in Azure AD and the automatic MDM enrollment begins.

The following diagram illustrates the high-level flow involved in the actual enrollment process. The device is first registered with Azure AD. This process assigns a unique device identifier to the device and presents the device with the ability to authenticate itself with Azure AD (device authentication). Subsequently, the device is enrolled for management with the MDM. This is done by calling the enrollment endpoint and requesting enrollment for the user and device. At this point, the user has been authenticated and device has been registered and authenticated with Azure AD. This information is made available to the MDM in the form of claims within an access token presented at the enrollment endpoint.

azure ad enrollment flow

The MDM is expected to use this information about the device (Device ID) when reporting device compliance back to Azure AD using the Azure AD Graph API. A sample for reporting device compliance is provided later in this topic.

Make the MDM a reliable party of Azure AD

To participate in the integrated enrollment flow outlined in the previous section, the MDM must be able to consume access tokens issued by Azure AD. To report compliance to Azure AD, the MDM must be able to authenticate itself to Azure AD and obtain authorization in the form of an access token that allows it to invoke the Azure AD Graph API.

Add a cloud-based MDM

A cloud-based MDM is a SaaS application that provides device management capabilities in the cloud. It is a multi-tenant application. This application is registered with Azure AD in the home tenant of the MDM vendor. When an IT admin decides to use this MDM solution, an instance of this application is made visible in the tenant of the customer.

The MDM vendor must first register the application in their home tenant and mark it as a multi-tenant application. Here a code sample from GitHub that explains how to add multi-tenant applications to Azure AD, WepApp-WebAPI-MultiTenant-OpenIdConnect-DotNet.

Note For the MDM provider, if you don't have an existing Azure AD tentant with an Azure AD subscription that you manage, follow the step-by-step guide in Add an Azure AD tenant and Azure AD subscription to set up a tenant, add a subscription, and manage it via the Azure Portal.

The keys used by the MDM application to request access tokens from Azure AD are managed within the tenant of the MDM vendor and not visible to individual customers. The same key is used by the multi-tenant MDM application to authenticate itself with Azure AD, regardless of the customer tenent to which the device being managed belongs.

Use the following steps to register a cloud-based MDM application with Azure AD. At this time, you need to work with the Azure AD engineering team to expose this application through the Azure AD app gallery.

  1. Login to the Azure Management Portal using an admin account in your home tenant.
  2. In the left navigation, click on the

    Active Directory.

  3. Click the directory tenant where you want to register the application.

    Ensure that you are logged into your home tenant.

  4. Click the

    Applications tab.

  5. In the drawer, click

    Add.

  6. Click

    Add an application my organization is developing.

  7. Enter a friendly name for the application, such as ContosoMDM, select

    Web Application and or Web API, then click

    Next.

  8. Enter the login URL for your MDM service.
  9. For the App ID, enter

    https:///ContosoMDM, then click OK.

  10. While still in the Azure portal, click the

    Configure tab of your application.

  11. Mark your application as

    multi-tenant.

  12. Find the client ID value and copy it.

    You will need this later when configuring your application. This client ID is used when obtaining access tokens and adding applications to the Azure AD app gallery.

  13. Generate a key for your application and copy it.

    You will need this to call the Azure AD Graph API to report device compliance. This is covered in the subsequent section.

For more information about how to register a sample application with Azure AD, see the steps to register the

TodoListService Web API in NativeClient-DotNet

Add an on-premises MDM

An on-premises MDM application is inherently different that a cloud MDM. It is a single-tenant application that is present uniquely within the tenant of the customer. Therefore, customers must add the application directly within their own tenant. Additionally, each instance of an on-premises MDM application must be registered separately and has a separate key for authentication with Azure AD.

The customer experience for adding an on-premises MDM to their tenant is similar to that as the cloud-based MDM. There is an entry in the Azure AD app gallery to add an on-premises MDN to the tenant and administrators can configure the required URLs for enrollment and Terms of Use.

Your on-premises MDM product must expose a configuration experience where administrators can provide the client ID, app ID, and the key configured in their directory for that MDM application. You can use this client ID and key to request tokens from Azure AD when reporting device compliance.

For more information about registering applications with Azure AD, see Basics of Registering an Application in Azure AD.

Key management and security guidelines

The application keys used by your MDM service are a sensitive resource. They should be protected and rolled over periodically for greater security. Access tokens obtained by your MDM service to call the Azure AD Graph API are bearer tokens and should be protected to avoid unauthorized disclosure.

For security best practices, see Windows Azure Security Essentials.

You can rollover the application keys used by a cloud-based MDM service without requiring a customer interaction. There is a single set of keys across all customer tenants that are managed by the MDM vendor in their Azure AD tenant.

For the on-premises MDM, the keys used to authenticate with Azure AD are within the tenant of the customer and must be rolled over by the customer's administrator. In this case, you should provide guidance to the customers about rolling over and protecting the keys to improved security.

IT administrators use the Azure AD app gallery to add an MDM for their organization to use. The app gallery is a rich store with over 2400 SaaS applications that are integrated with Azure AD.

The following image illustrates how MDM applications will show up in the Azure app gallery in a category dedicated to MDM software.

azure ad add an app for mdm

You should work with the Azure AD engineering team if your MDM application is cloud-based. The following table shows the required information to create an entry in the Azure AD app gallery.

Item Description

Application ID

The client ID of your MDM app that is configured within your tenant. This is the unique identifier for your multi-tenant app.

Publisher

A string that identifies the publisher of the app.

Application URL

A URL to the landing page of your app where your administrators can get more information about the MDM app and contains a link to the landing page of your app. This URL is not used for the actual enrollment.

Description

A brief description of your MDM app, which must be under 255 characters.

Icons

A set of logo icons for the MDM app. Dimensions: 45 X 45, 150 X 122, 214 X 215

There are no special requirements for adding on-premises MDM to the app gallery.There is a generic entry for administrator to add an app to their tenant.

However, key management is different for on-premises MDM. You must obtain the client ID (app ID) and key assigned to the MDM app within the customer's tenant. These are used to obtain authorization to access the Azure AD Graph API and for reporting device compliance.

Themes

The pages rendered by the MDM as part of the integrated enrollment process must use Windows 10 templates (Download the Windows 10 templates and CSS files). This is important for enrollment during the Azure AD Join experience in OOBE where all of the pages are edge-to-edge HTML pages. Don't try to copy the templates because you'll never get the button placement right. Using the shared Windows 10 templates ensure a seamless experience for the customers.

There are 3 distinct scenarios:

  1. MDM enrollment as part of Azure AD Join in Windows OOBE.
  2. MDM enrollment as part of Azure AD Join, after Windows OOBE from

    Settings.

  3. MDM enrollment as part of adding a Microsoft work account on a personal device (BYOD).

Scenarios 1, 2, and 3 are available in Windows 10 Pro, Windows 10 Enterprise, and Windows 10 Education. Scenarios 1 and 3 are available in Windows 10 Mobile. Support for scenario 1 was added in Windows 10 Mobile, version 1511.

The CSS files provided by Microsoft contains version information and we recommend that you use the latest version. There are separate CSS files for desktop and mobile devices, OOBE, and post-OOBE experiences. Download the Windows 10 templates and CSS files.

Using themes

An MDM page must adhere to a predefined theme depending on the scenario that is displayed. For example, if the CXH-HOSTHTTP header is FRX, which is the OOBE scenario, the page must support a dark theme with blue background color, which uses WinJS file Ui-dark.css ver 4.0 and oobe-desktop.css ver 1.0.4.

CXH-HOST (HTTP HEADER) Senario Background Theme WinJS Scenario CSS
FRX OOBE Dark theme + blue background color Filename: Ui-dark.css Filename: oobe-dekstop.css
MOSET Settings/

Post OOBE

Light theme Filename: Ui-light.css Filename: settings-desktop.css

Terms of Use protocol semantics

The Terms of Use endpoint is hosted by the MDM server. During the Azure AD Join protocol flow, Windows performs a full-page redirect to this endpoint. This enables the MDM to display the terms and conditions that apply and allows the user to accept or reject the terms associated with enrollment. After the user accepts the terms, the MDM redirects back to Windows for the enrollment process to continue.

Redirect to the Terms of Use endpoint

This is a full page redirect to the Terms of User endpoint hosted by the MDM. Here is an example URL, https://fabrikam.contosomdm.com/TermsOfUse.

The following parameters are passed in the query string:

Item Description

redirect_uri

After the user accepts or rejects the Terms of Use, the user is redirected to this URL.

client-request-id

A GUID that is used to correlate logs for diagnostic and debugging purposes. You use this parameter to log or trace the state of the enrollment request to help find the root cause in case of failures.

api-version

Specifies the version of the protocol requested by the client. This provides a mechanism to support version revisions of the protocol.

mode

Specifies that the device is corporate owned when mode=azureadjoin. This parameter is not present for BYOD devices.

Access token

A bearer access token is issued by Azure AD is passed in the authorization header of the HTTP request. Here is a typical format:

Authorization: Bearer CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw…

The following claims are expected in the access token passed by Windows to the Terms of Use endpoint:

Item Description

Object ID

Identifier of the user object corresponding to the authenticated user.

UPN

A claim containing the user principal name (UPN) of the authenticated user.

TID

A claim representing the tenant ID of the tenant. In the example above, it's Fabrikam.

Resource

A sanitized URL representing the MDM application. Example, https://fabrikam.contosomdm.com.

Note There is no device ID claim in the access token because the device may not yet be enrolled at this time.

To retrieve the list of group memberships for the user, you can use the Azure AD Graph API.

Here's an example 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

The MDM is expected to validate the signature of the access token to ensure it was issued by Azure AD and ensure that recipient is appropriate.

Terms of Use content

The MDM may perform other additional redirects as necessary before displaying the Terms of Use content to the user. The appropriate Terms of Use content should be returned to the caller (Windows) so it can be displayed to the end user in the browser control.

The Terms of Use content should contain the following buttons:

  • Accept - the user accepts the Terms of Use and proceeds with enrollment.

  • Decline - the user declines and stops the enrollment process.

The Terms of Use content must be consistent with the theme used for the other pages rendered during this process.

Terms of Use endpoint processing logic

At this point, the user is on the Terms of Use page shown during the OOBE or from the Setting experiences. The user has the following options on the page:

  • User clicks on the Accept button - The MDM must redirect to the URI specified by the redirect_uri parameter in the incoming request. The following query string parameters are expected:

    • IsAccepted - This mandatory Boolean must be set to true.

    • OpaqueBlob - Required parameter if the user accepts. The MDM may use this make some information available to the enrollment endpoint. The value persisted here is made available unchanged at the enrollment endpoint. The MDM may use this parameter for correlation purposes.

    • Here is an example redirect - ms-appx-web://MyApp1/ToUResponse?OpaqueBlob=value&IsAccepted=true
  • User clicks on the Decline button - The MDM must redirect to the URI specified in redirect_uri in the incoming request. The following query string parameters are expected:

    • IsAccepted - This mandatory Boolean must be set to false. This also applies if the user skipped the Terms of Use.

    • OpaqueBlob - This parameter is not expected to be used because the enrollment is stopped with an error message displayed to the user.

Users skip the Terms of Use when they are adding a Microsoft work account to their device. However, then cannot skip it during the Azure AD Join process. The decline button must not be shown in the Azure AD Join process because MDM enrollment cannot be declined by the user if configured by the administrator for the Azure AD Join.

We recommend that you send the client-request-id parameters in the query string as part of this redirect response.

Terms Of Use Error handling

If an error was encountered during the terms of use processing, the MDM can return two parameters – an error and error_description parameter in its redirect request back to Windows. Note that the URL should be encoded and the contents of the error_description should be in English plain text. This text is not visible to the end-user and therefore localization of the error description text is not a concern.

Here is the URL format:

HTTP/1.1 302
Location:
?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=Acess%20is%20denied%2E

The following table shows the error codes.

Cause HTTP status Error Description

api-version

302

invalid_request

unsupported version

Tenant or user data are missingor other required prerequisites for device enrollment are not met

302

unauthorized_client

unauthorized user or tenant

Azure AD token validation failed

302

unauthorized_client

unauthorized_client

internal service error

302

server_error

internal service error

Enrollment protocol with Azure AD

With Azure integrated MDM enrollment, there is no discovery phase and the discovery URL is directly passed down to the system from Azure. The following table shows the comparison between the traditional and Azure enrollments.

Detail Traditional MDM enrollment Azure AD Join (corporate-owned device) Azure AD add a work account (user-owned device)

MDM auto-discovery using email address to retrieve MDM discovery URL

Enrollment

Not applicable

Discovery URL provisioned in Azure

Uses MDM discovery URL

Enrollment

Enrollment renewal

ROBO

Enrollment

Enrollment renewal

ROBO

Enrollment

Enrollment renewal

ROBO

Is MDM enrollment required?

Yes

Yes

No

User can decline.

Authentication type

OnPremise

Federated

Certificate

Federated

Federated

EnrollmentPolicyServiceURL

Optional (all auth)

Optional (all auth)

Optional (all auth)

EnrollmentServiceURL

Required (all auth)

Used (all auth)

Used (all auth)

EnrollmentServiceURL includes OS Version, OS Platform, and other attributes provided by MDM discovery URL

Highly recommended

Highly recommended

Highly recommended

AuthenticationServiceURL used

Used (Federated auth)

Skipped

Skipped

BinarySecurityToken

Custom per MDM

Azure AD issued token

Azure AD issued token

EnrollmentType

Full

Device

Full

Enrolled certificate type

User certificate

Device certificate

User certificate

Enrolled certificate store

My/User

My/System

My/User

CSR subject name

User Principal Name

Device ID

User Principal Name

EnrollmentData Terms of Use binary blob as AdditionalContext for EnrollmentServiceURL

Not supported

Supported

Supported

CSPs accessible during enrollment

Windows 10 support:

  • DMClient
  • CertificateStore
  • RootCATrustedCertificates
  • ClientCertificateInstall
  • EnterpriseModernAppManagement
  • PassportForWork
  • Policy
  • w7 APPLICATION

Legacy support:

  • EnterpriseAppManagement (Windows Phone 8.1)

same as traditional MDM enrollment

same as traditional MDM enrollment

Management protocol with Azure AD

There are two different MDM enrollment types that take advantage of integration with Azure AD and therefore make use of Azure AD user and device identities. Depending on the enrollment type, the MDM service may need to manage a single user or multiple users.

Multiple user management for Azure AD joined devices

In this scenario the MDM enrollment applies to every Azure AD user who logs on to the Azure AD joined device - call this enrollment type a device enrollment or a multi-user enrollment. The management server can determine the user identity, conclude what policies are targeted for this user, and send corresponding policies to the device. To allow management server to identify current user that is logged on to the device, the OMA DM client uses the Azure AD user tokens. Each management session contains an additional HTTP header that contains an Azure AD user token. This information is provided in the DM package sent to the management server. However, in some circumstances Azure AD user token is not sent over to the management server. One such scenario happens immediately after MDM enrollments completes during Azure AD join process. Until Azure AD join process is finished and Azure AD user logs on to the machine, Azure AD user token is not available to OMA-DM process. Typically MDM enrollment completes before Azure AD user logs on to machine and the initial management session does not contain an Azure AD user token. The management server should check if the token is missing and only send device policies in such case. Another possible reason for a missing Azure AD token in the OMA-DM payload is when a guest user is logged on to the device.

Adding a work account and MDM enrollment to a device

In this scenario, the MDM enrollment applies to a single user who initially added his work account and enrolled the device. In this enrollment type the management server can ignore Azure AD tokens that may be sent over during management session. Whether Azure AD token is present or missing, the management server sends both user and device policies to the device.

Evaluating Azure AD user tokens

The Azure AD token is in the HTTP Authorization header in the following format:

Authorization:Bearer 
>

Additional claims may be present in the Azure AD token, such as:

  • User - user currently logged in
  • Device compliance - value set the the MDM service into Azure
  • Device ID - identifies the device that is checking in
  • Tenant ID

Access token issued by Azure AD are JSON web tokens (JWTs). A valid JWT token is presented by Windows at the MDM enrollment endpoint to initiate the enrollment process. There are a couple of options to evaluate the tokens:

Device Alert 1224 for Azure AD user token

An alert is sent when the DM session starts and there is an Azure AD user logged in. The alert is sent in OMA DM pkg#1. Here's an example:

Alert Type: com.microsoft/MDM/AADUserToken

Alert sample: 
 
  
  >1 
  1224 
   
    
    com.microsoft/MDM/AADUserToken 
    
   UserToken inserted here 
   
  
 … other xml tags … 
 

Determine when a user is logged in through polling

An alert is send to the MDM server in DM package#1.

  • Alert type - com.microsoft/MDM/LoginStatus
  • Alert format - chr
  • Alert data - provide login status information for the current active logged in user.
    • Logged in user who has an Azure AD account - predefined text: user.
    • Logged in user without an Azure AD account- predefined text: others.
    • No active user - predefined text:none

Here's an example.

 
  
  >1 
  1224 
   
    
    com.microsoft/MDM/LoginStatus 
    
   user 
   
  
 … other xml tags … 

Report device compliance to Azure AD

Once a device is enrolled with the MDM for management, corporate policies configured by the IT administrator are enforced on the device. The device compliance with configured policies is evaluated by the MDM and then reported to Azure AD. This section covers the Graph API call you can use to report a device compliance status to Azure AD.

For a sample that illustrates how an MDM can obtain an access token using OAuth 2.0 client_credentials grant type, see Daemon_CertificateCredential-DotNet.

  • Cloud-based MDM - If your product is a cloud-based multi-tenant MDM service, you have a single key configured for your service within your tenant. Use this key to authenticate the MDM service with Azure AD, in order to obtain authorization.

  • On-premises MDM - If your product is an on-premises MDM, customers must configure your product with the key used to authenticate with Azure AD. This is because each on-premises instance of your MDM product has a different tenant-specific key. For this purpose, you may need to expose a configuration experience in your MDM product that enables administrators to specify the key to be used to authenticate with Azure AD.

Use Azure AD Graph API

The following sample REST API call illustrates how an MDM can use the Azure AD Graph API to report compliance status of a device currently being managed by it.

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 
} 

Where:

  • contoso.com – This is the name of the Azure AD tenant to whose directory the device has been joined.

  • db7ab579-3759-4492-a03f-655ca7f52ae1 – This is the device identifier for the device whose compliance information is being reported to Azure AD.

  • eyJ0eXAiO……… – This is the bearer access token issued by Azure AD to the MDM that authorizes the MDM to call the Azure AD Graph API. The access token is placed in the HTTP authorization header of the request.

  • isManaged and

    isCompliant - These Boolean attributes indicates compliance status.

  • api-version - Use this parameter to specify which version of the graph API is being requested.

Response:

  • Success - HTTP 204 with No Content.
  • Failure/Error - HTTP 404 Not Found. This error may be returned if the specified device or tenant cannot be found.

Data loss during unenrollment from Azure Active Directory Join

When a user is enrolled into MDM through Azure Active Directory Join and then disconnects the enrollment, there is no warning that the user will lose Windows Information Protection (WIP) data. The disconnection message does not indicate the loss of WIP data.

aadj unenerollment

Error codes

Code ID Error message
0x80180001 "idErrorServerConnectivity", // MENROLL_E_DEVICE_MESSAGE_FORMAT_ERROR

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x80180002 "idErrorAuthenticationFailure", // MENROLL_E_DEVICE_AUTHENTICATION_ERROR

There was a problem authenticating your account or device. You can try to do this again or contact your system administrator with the error code {0}.

0x80180003 "idErrorAuthorizationFailure", // MENROLL_E_DEVICE_AUTHORIZATION_ERROR

This user is not authorized to enroll. You can try to do this again or contact your system administrator with the error code {0}.

0x80180004 "idErrorMDMCertificateError", // MENROLL_E_DEVICE_CERTIFCATEREQUEST_ERROR

There was a certificate error. You can try to do this again or contact your system administrator with the error code {0}.

0x80180005 "idErrorServerConnectivity", // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x80180006 "idErrorServerConnectivity", // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x80180007 "idErrorAuthenticationFailure", // MENROLL_E_DEVICE_INVALIDSECURITY_ERROR

There was a problem authenticating your account or device. You can try to do this again or contact your system administrator with the error code {0}.

0x80180008 "idErrorServerConnectivity", // MENROLL_E_DEVICE_UNKNOWN_ERROR

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x80180009 "idErrorAlreadyInProgress", // MENROLL_E_ENROLLMENT_IN_PROGRESS

Another enrollment is in progress. You can try to do this again or contact your system administrator with the error code {0}.

0x8018000A "idErrorMDMAlreadyEnrolled", // MENROLL_E_DEVICE_ALREADY_ENROLLED

This device is already enrolled. You can contact your system administrator with the error code {0}.

0x8018000D "idErrorMDMCertificateError", // MENROLL_E_DISCOVERY_SEC_CERT_DATE_INVALID

There was a certificate error. You can try to do this again or contact your system administrator with the error code {0}.

0x8018000E "idErrorAuthenticationFailure", // MENROLL_E_PASSWORD_NEEDED

There was a problem authenticating your account or device. You can try to do this again or contact your system administrator with the error code {0}.

0x8018000F "idErrorAuthenticationFailure", // MENROLL_E_WAB_ERROR

There was a problem authenticating your account or device. You can try to do this again or contact your system administrator with the error code {0}.

0x80180010 "idErrorServerConnectivity", // MENROLL_E_CONNECTIVITY

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x80180012 "idErrorMDMCertificateError", // MENROLL_E_INVALIDSSLCERT

There was a certificate error. You can try to do this again or contact your system administrator with the error code {0}.

0x80180013 "idErrorDeviceLimit", // MENROLL_E_DEVICECAPREACHED

Looks like there are too many devices or users for this account. Contact your system administrator with the error code {0}.

0x80180014 "idErrorMDMNotSupported", // MENROLL_E_DEVICENOTSUPPORTED

This feature is not supported. Contact your system administrator with the error code {0}.

0x80180015 "idErrorMDMNotSupported", // MENROLL_E_NOTSUPPORTED

This feature is not supported. Contact your system administrator with the error code {0}.

0x80180016 "idErrorMDMRenewalRejected", // MENROLL_E_NOTELIGIBLETORENEW

The server did not accept the request. You can try to do this again or contact your system administrator with the error code {0}.

0x80180017 "idErrorMDMAccountMaintenance", // MENROLL_E_INMAINTENANCE

The service is in maintenance. You can try to do this again later or contact your system administrator with the error code {0}.

0x80180018 "idErrorMDMLicenseError", // MENROLL_E_USERLICENSE

There was an error with your license. You can try to do this again or contact your system administrator with the error code {0}.

0x80180019 "idErrorInvalidServerConfig", // MENROLL_E_ENROLLMENTDATAINVALID

Looks like the server is not correctly configured. You can try to do this again or contact your system administrator with the error code {0}.

"rejectedTermsOfUse" "idErrorRejectedTermsOfUse"

Your organization requires that you agree to the Terms of Use. Please try again or ask your support person for more information.

0x801c0001 "idErrorServerConnectivity", // DSREG_E_DEVICE_MESSAGE_FORMAT_ERROR

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x801c0002 "idErrorAuthenticationFailure", // DSREG_E_DEVICE_AUTHENTICATION_ERROR

There was a problem authenticating your account or device. You can try to do this again or contact your system administrator with the error code {0}.

0x801c0003 "idErrorAuthorizationFailure", // DSREG_E_DEVICE_AUTHORIZATION_ERROR

This user is not authorized to enroll. You can try to do this again or contact your system administrator with the error code {0}.

0x801c0006 "idErrorServerConnectivity", // DSREG_E_DEVICE_INTERNALSERVICE_ERROR

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x801c000B "idErrorUntrustedServer", // DSREG_E_DISCOVERY_REDIRECTION_NOT_TRUSTED The server being contacted is not trusted. Contact your system administrator with the error code {0}.
0x801c000C "idErrorServerConnectivity", // DSREG_E_DISCOVERY_FAILED

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x801c000E "idErrorDeviceLimit", // DSREG_E_DEVICE_REGISTRATION_QUOTA_EXCCEEDED

Looks like there are too many devices or users for this account. Contact your system administrator with the error code {0}.

0x801c000F "idErrorDeviceRequiresReboot", // DSREG_E_DEVICE_REQUIRES_REBOOT

A reboot is required to complete device registration.

0x801c0010 "idErrorInvalidCertificate", // DSREG_E_DEVICE_AIK_VALIDATION_ERROR

Looks like you have an invalid certificate. Contact your system administrator with the error code {0}.

0x801c0011 "idErrorAuthenticationFailure", // DSREG_E_DEVICE_ATTESTATION_ERROR

There was a problem authenticating your account or device. You can try to do this again or contact your system administrator with the error code {0}.

0x801c0012 "idErrorServerConnectivity", // DSREG_E_DISCOVERY_BAD_MESSAGE_ERROR

There was an error communicating with the server. You can try to do this again or contact your system administrator with the error code {0}

0x801c0013 "idErrorAuthenticationFailure", // DSREG_E_TENANTID_NOT_FOUND

There was a problem authenticating your account or device. You can try to do this again or contact your system administrator with the error code {0}.

0x801c0014 "idErrorAuthenticationFailure", // DSREG_E_USERSID_NOT_FOUND

There was a problem authenticating your account or device. You can try to do this again or contact your system administrator with the error code {0}.

This is source I found from another site, main source you can find in last paragraph

Source : https://docs.microsoft.com/en-us/windows/client-management/mdm/azure-active-directory-integration-with-mdm

advise

playing

Azure Active Directory integration with MDM
Using the HID class eases the job of writing USB device drivers
Lock IT Down: Make sure your network is secure with the Microsoft Baseline Security Analyzer
The Post-Harvey Mosquito Invasion Seems Like Hell
How to Keep Your Social Media Creeping Private
Habbo Hotel Kids Social Network Reopens For Business Post Pedophile Scandal: Spain, Brazil, Finland First Up
New FIAT 500. New VW Passat. Which Is More Reliable?
Getting Started with OpenHAB Home Automation on Raspberry Pi
Considerations for SphygmoCor radial artery pulse wave analysis: side selection and peripheral arterial blood pressure calibration
Verifone and ATIO Group Partner on Comprehensive Forecourt and mPOS Solution for Petroleum Retailers in Mexico