title: Add an Azure AD tenant and Azure AD subscription
description: Here's a step-by-step guide to adding an Azure Active Directory tenant, adding an Azure AD subscription, and registering your subscription.
ms.reviewer:
manager: aaroncz
ms.author: vinpa
ms.topic: article
ms.prod: windows-client
ms.technology: itpro-manage
author: vinaypamnani-msft
ms.date: 06/26/2017
---
# Add an Azure AD tenant and Azure AD subscription
Here's a step-by-step guide to adding an Azure Active Directory tenant, adding an Azure AD subscription, and registering your subscription.
> **Note**If you have paid subscriptions to Office 365, Microsoft Dynamics CRM Online, Enterprise Mobility Suite, or other Microsoft services, you have a free subscription to Azure AD. For step-by-step guide to register this free subscription, see [Register your free Azure Active Directory subscription.](#register-your-free-azure-active-directory-subscription)
1. Sign up for Azure AD tenant from [this website](https://account.windowsazure.com/organization) by creating an administrator account for your organization.
2. Enter the information for your organization. Select **check availability** to verify that domain name that you selected is available.
3. Complete the login and country information. Enter a valid phone number, then select **Send text message** or **Call me**.
4. Enter the code that you receive and then select **Verify code**. After the code is verified and the continue button turns green, select **continue**.
5. After you finish creating your Azure account, you can add an Azure AD subscription.
If you don't have a paid subscription to any Microsoft service, you can purchase an Azure AD premium subscription. Go to the Office 356 portal at https://portal.office.com/, and then sign in using the admin account that you created in Step 4 (for example, user1@contosoltd.onmicrosoftcom).
6. Select **Install software**.
7. In the Microsoft 365 admin center, select **Purchase Services** from the left navigation.
8. On the **Purchase services** page, scroll down until you see **Azure Active Directory Premium**, then select to purchase.
9. Continue with your purchase.
10. After the purchase is completed, you can log on to your Office 365 Admin Portal and you'll see the **Azure AD** option from the Admin drop-down menu along with other services (SharePoint and Exchange).
When you choose Azure AD, it will take you to the Azure AD portal where you can manage your Azure AD applications.
## Register your free Azure Active Directory subscription
If you have paid subscriptions to Office 365, Microsoft Dynamics CRM Online, Enterprise Mobility Suite, or other Microsoft services, you have a free subscription to Azure AD. Here's a step-by-step guide to register your free Azure AD subscription using an Office 365 Premium Business subscription.
1. Sign in to the Microsoft 365 admin center at <https://portal.office.com> using your organization's account.
2. On the **Home** page, select on the Admin tools icon.
3. On the **Admin center** page, hover your mouse over the Admin tools icon on the left and then click **Azure AD**. This option will take you to the Azure Active Directory sign-up page and brings up your existing Office 365 organization account information.
Azure Active Directory is the world's largest enterprise cloud identity management service. It’s used by organizations to access Office 365 and business applications from Microsoft and third-party software as a service (SaaS) vendors. Many of the rich Windows10 experiences for organizational users (such as store access or OS state roaming) use Azure AD as the underlying identity infrastructure. Windows integrates with Azure AD, allowing devices to be registered in Azure AD and enrolled into MDM in an integrated flow.
Azure Active Directory is the world's largest enterprise cloud identity management service. It's used by organizations to access Microsoft 365 and business applications from Microsoft and third-party software as a service (SaaS) vendors. Many of the rich Windows experiences for organizational users (such as store access or OS state roaming) use Azure AD as the underlying identity infrastructure. Windows integrates with Azure AD, allowing devices to be registered in Azure AD and enrolled into MDM in an integrated flow.
Once a device is enrolled in MDM, the MDM:
Once a device is enrolled in MDM, the MDM:
- Can enforce compliance with organization policies, add or remove apps, and more.
- Can enforce compliance with organization policies, add or remove apps, and more.
- Can report a device’s compliance in Azure AD.
- Can report a device's compliance in Azure AD.
- Azure AD can allow access to organization resources or applications secured by Azure AD to devices that comply with policies.
- Azure AD can allow access to organization resources or applications secured by Azure AD to devices that comply with policies.
To support these rich experiences with their MDM product, MDM vendors can integrate with Azure AD. This article describes the steps involved.
To support these rich experiences with their MDM product, MDM vendors can integrate with Azure AD.
## 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 Microsoft Configuration Manager. In Windows10, it’s also possible to manage domain joined devices with an MDM.
Windows10 introduces a new way to configure and deploy organization 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 won't 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](/previous-versions/azure/dn499825(v=azure.100)) license.
### BYOD scenario
Windows10 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. In the BYOD case, users can reject the MDM Terms of Use. The device isn't enrolled in MDM and access to organization resources is typically restricted.
## Integrated MDM enrollment and UX
## Integrated MDM enrollment and UX
Two Azure AD MDM enrollment scenarios:
There are several ways to connect your devices to Azure AD:
- Joining a device to Azure AD for company-owned devices
- Adding a work account to a personal device (BYOD)
In both scenarios, Azure AD authenticates the user and the device. It provides a verified unique device identifier that can be used for MDM enrollment.
- [Join device to Azure AD](/azure/active-directory/devices/concept-azure-ad-join)
- [Join device to on-premises AD and Azure AD](/azure/active-directory/devices/concept-azure-ad-join-hybrid)
- [Add a Microsoft work account to Windows](/azure/active-directory/devices/concept-azure-ad-register)
In both scenarios, the enrollment flow provides an opportunity for the MDM service to render its own UI, using a web view. MDM vendors should use the UI 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 more UI elements, such as asking for a one-time PIN.
In each scenario, Azure AD authenticates the user and the device. It provides a verified unique device identifier that can be used for MDM enrollment. The enrollment flow provides an opportunity for the MDM service to render its own UI, using a web view. MDM vendors should use the UI to render the Terms of Use (TOU), which can be different for company-owned and bring-your-own-device (BYOD) devices. MDM vendors can also use the web view to render more UI elements, such as asking for a one-time PIN.
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's important that MDM vendors who integrate with Azure AD respect the Windows design guidelines. This step includes using a responsive web design and respecting the Windows accessibility guidelines. For example, include the forward and back buttons that are properly wired to the navigation logic. More details are provided later in this article.
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's important that MDM vendors who integrate with Azure AD respect the Windows design guidelines. This step includes using a responsive web design and respecting the Windows accessibility guidelines. For example, include the forward and back buttons that are properly wired to the navigation logic. More details are provided later in this article.
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. For more information, see solution \#2 in [Configure Azure MFA as authentication provider with AD FS](/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa).
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. For more information, see [Configure Azure MFA as authentication provider with AD FS](/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa).
Once a user has an Azure AD account added to Windows and enrolled in MDM, the enrollment can be managed through **Settings** > **Accounts** > **Work access**. Device management of either Azure AD Join for organization scenarios or BYOD scenarios is similar.
Once a user has an Azure AD account added to Windows and enrolled in MDM, the enrollment can be managed through **Settings** > **Accounts** > **Access work or school**. Device management of either Azure AD Join for organization scenarios or BYOD scenarios is similar.
> [!NOTE]
> [!NOTE]
> Users can't remove the device enrollment through the **Work access** user interface because management is tied to the Azure AD or work account.
> Users can't remove the device enrollment through the **Access work or school** user interface because management is tied to the Azure AD or work account.
### MDM endpoints involved in Azure AD integrated enrollment
### MDM endpoints involved in Azure AD–integrated enrollment
Azure AD MDM enrollment is a two-step process:
Azure AD MDM enrollment is a two-step process:
1. Display the Terms of Use and gather user consent.
1. Display the Terms of Use and gather user consent: This consent 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 step is an active flow where Windows OMA DM agent calls the MDM service to enroll the device.
This consent 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.
To support Azure AD enrollment, MDM vendors must host and expose a **Terms of Use endpoint** and an **MDM enrollment endpoint**.
2. Enroll the device.
- **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.
This step is an active flow where Windows OMA DM agent calls the MDM service to enroll the device.
It's important to understand the Terms of Use flow is an "opaque box" to Windows and Azure AD. The whole web view is redirected to the Terms of Use URL. The user should be redirected back after approving or rejecting the Terms. This design allows the MDM vendor to customize their Terms of Use for different scenarios. For example, different levels of control are applied on BYOD vs. organization-owned devices. Or, implement user/group based targeting, like users in certain geographies may have stricter device management policies.
To support Azure AD enrollment, MDM vendors must host and expose a Terms of Use endpoint and an MDM enrollment endpoint.
The Terms of Use endpoint can implement more 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 can be a 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.
<ahref=""id="terms-of-use-endpoint-"></a>**Terms of Use endpoint**
- **MDM enrollment endpoint**: After the users accepts the Terms of Use, the device is registered in Azure AD. Automatic MDM enrollment begins.
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 the Terms of Use flow is an "opaque box" to Windows and Azure AD. The whole web view is redirected to the Terms of Use URL. The user should be redirected back after approving or rejecting the Terms. This design allows the MDM vendor to customize their Terms of Use for different scenarios. For example, different levels of control are applied on BYOD vs. organization-owned devices. Or, implement user/group based targeting, like users in certain geographies may have stricter device management policies.
The Terms of Use endpoint can implement more 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 can be a 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.
After the users accepts the Terms of Use, the device is registered in Azure AD. 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). Then, the device is enrolled for management with the MDM. This step calls the enrollment endpoint and requests 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 available to the MDM in the form of claims within an access token presented at the enrollment endpoint.
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). Then, the device is enrolled for management with the MDM. This step calls the enrollment endpoint and requests 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 available to the MDM in the form of claims within an access token presented at the enrollment endpoint.
@ -103,63 +68,30 @@ The following diagram illustrates the high-level flow involved in the actual enr
The MDM is expected to use this information about the device (Device ID) when reporting device compliance back to Azure AD using the [Microsoft Graph API](/azure/active-directory/develop/active-directory-graph-api). A sample for reporting device compliance is provided later in this article.
The MDM is expected to use this information about the device (Device ID) when reporting device compliance back to Azure AD using the [Microsoft Graph API](/azure/active-directory/develop/active-directory-graph-api). A sample for reporting device compliance is provided later in this article.
## Make the MDM a reliable party of Azure AD
## Make MDM a reliable party of Azure AD
To participate in the integrated enrollment flow outlined in the previous section, the MDM must consume access tokens issued by Azure AD. To report compliance with Azure AD, the MDM must authenticate itself to Azure AD and obtain authorization in the form of an access token that allows it to invoke the [Microsoft Graph API](/azure/active-directory/develop/active-directory-graph-api).
To participate in the integrated enrollment flow outlined in the previous section, the MDM must consume access tokens issued by Azure AD. To report compliance with Azure AD, the MDM must authenticate itself to Azure AD and obtain authorization in the form of an access token that allows it to invoke the [Microsoft Graph API](/azure/active-directory/develop/active-directory-graph-api).
### Add a cloud-based MDM
### Cloud-based MDM
A cloud-based MDM is a SaaS application that provides device management capabilities in the cloud. It's 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.
A cloud-based MDM is a SaaS application that provides device management capabilities in the cloud. It's 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](https://go.microsoft.com/fwlink/p/?LinkId=613661).
The MDM vendor must first register the application in their home tenant and mark it as a multi-tenant application. For more information about how to add multi-tenant applications to Azure AD, see the [Integrate an app that authenticates users and calls Microsoft Graph using the multi-tenant integration pattern (SaaS)](https://go.microsoft.com/fwlink/p/?LinkId=613661) code sample on GitHub.
> [!NOTE]
> [!NOTE]
> For the MDM provider, if you don't have an existing Azure AD tenant with an Azure AD subscription that you manage, follow the step-by-step guide in [Add an Azure AD tenant and Azure AD subscription](add-an-azure-ad-tenant-and-azure-ad-subscription.md) to set up a tenant, add a subscription, and manage it via the Azure Portal.
> For the MDM provider, if you don't have an existing Azure AD tenant with an Azure AD subscription that you manage, follow the step-by-step guides below:
>
> - [Quickstart: Create a new tenant in Azure Active Directory](/azure/active-directory/fundamentals/active-directory-access-create-new-tenant) to set up a tenant.
> - [Associate or add an Azure subscription to your Azure Active Directory tenant](/azure/active-directory/fundamentals/active-directory-how-subscriptions-associated-directory) to add a subscription, and manage it via the Azure Portal.
The MDM application uses keys to request access tokens from Azure AD. These keys are managed within the tenant of the MDM provider and not visible to individual customers. The same key is used by the multi-tenant MDM application to authenticate itself with Azure AD, whatever the customer tenant the managed device belongs.
The MDM application uses keys to request access tokens from Azure AD. These keys are managed within the tenant of the MDM provider and not visible to individual customers. The same key is used by the multi-tenant MDM application to authenticate itself with Azure AD, in the customer tenant where the managed device belongs.
> [!NOTE]
> [!NOTE]
> All MDM apps must implement Azure AD V2 tokens before we certify that integration works. Due to changes in the Azure AD app platform, using Azure AD V2 tokens is a hard requirement. For more information, see [Microsoft identity platform access tokens](/azure/active-directory/develop/access-tokens#token-formats-and-ownership).
> All MDM apps must implement Azure AD V2 tokens before we certify that integration works. Due to changes in the Azure AD app platform, using Azure AD V2 tokens is a hard requirement. For more information, see [Microsoft identity platform access tokens](/azure/active-directory/develop/access-tokens#token-formats).
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.
### On-premises MDM
1. Log on to the Azure Management Portal using an admin account in your home tenant.
An on-premises MDM application is different than a cloud MDM. It's a single-tenant application that is present uniquely within the tenant of the customer. Customers must add the application directly within their own tenant. Also, each instance of an on-premises MDM application must be registered separately and have a separate key for authentication with Azure AD.
2. In the left navigation, select **Active Directory**.
3. Select the directory tenant where you want to register the application.
Ensure you're logged into your home tenant.
4. Select the **Applications** tab.
5. In the drawer, select **Add**.
6. Select **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 select **Next**.
8. Enter the logon URL for your MDM service.
9. For the App ID, enter `https://<your_tenant_name>/ContosoMDM`, then select OK.
10. While still in the Azure portal, select the **Configure** tab of your application.
11. Mark your application as **multi-tenant**.
12. Find the client ID value and copy it.
You'll need this ID 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 need this key to call the Microsoft Graph API to report device compliance. This information is covered in the next 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](https://go.microsoft.com/fwlink/p/?LinkId=613667).
### Add an on-premises MDM
An on-premises MDM application is different than a cloud MDM. It's a single-tenant application that is present uniquely within the tenant of the customer. Customers must add the application directly within their own tenant. Also, each instance of an on-premises MDM application must be registered separately and has a separate key for authentication with Azure AD.
To add an on-premises MDM application to the tenant, use the Azure AD service, specifically under **Mobility (MDM and MAM)** > **Add application**. Administrators can configure the required URLs for enrollment and Terms of Use.
To add an on-premises MDM application to the tenant, use the Azure AD service, specifically under **Mobility (MDM and MAM)** > **Add application**. Administrators can configure the required URLs for enrollment and Terms of Use.
@ -173,19 +105,14 @@ The application keys used by your MDM service are a sensitive resource. They sho
For security best practices, see [Windows Azure Security Essentials](/dotnet/api/system.identitymodel.tokens.jwt.jwtsecuritytokenhandler).
For security best practices, see [Windows Azure Security Essentials](/dotnet/api/system.identitymodel.tokens.jwt.jwtsecuritytokenhandler).
You can roll over the application keys used by a cloud-based MDM service without requiring a customer interaction. There's a single set of keys across all customer tenants that are managed by the MDM vendor in their Azure AD tenant.
For cloud-based MDM, you can roll over the application keys without requiring a customer interaction. There's 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 Azure AD authentication keys are within the customer tenant and must be rolled over by the customer's administrator. To improve security, provide guidance to customers about rolling over and protecting the keys.
For the on-premises MDM, the Azure AD authentication keys are within the customer tenant and must be rolled over by the customer's administrator. To improve security, provide guidance to customers about rolling over and protecting the keys.
## Publish your MDM app to Azure AD app gallery
## Publish your MDM app to Azure AD app gallery
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.
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 show how MDM applications show up in the Azure app gallery.
### Add cloud-based MDM to the app gallery
### Add cloud-based MDM to the app gallery
> [!NOTE]
> [!NOTE]
@ -201,8 +128,6 @@ The following table shows the required information to create an entry in the Azu
|**Description**|A brief description of your MDM app, which must be under 255 characters.|
|**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|
|**Icons**|A set of logo icons for the MDM app. Dimensions: 45 X 45, 150 X 122, 214 X 215|
### Add on-premises MDM to the app gallery
### Add on-premises MDM to the app gallery
There are no special requirements for adding on-premises MDM to the app gallery. There's a generic entry for administrators to add an app to their tenant.
There are no special requirements for adding on-premises MDM to the app gallery. There's a generic entry for administrators to add an app to their tenant.
@ -219,7 +144,7 @@ There are three distinct scenarios:
2. MDM enrollment as part of Azure AD Join, after Windows OOBE from **Settings**.
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).
3. MDM enrollment as part of adding a Microsoft work account on a personal device (BYOD).
These scenarios support Windowsclient Pro, Enterprise, and Education.
These scenarios support Windows Pro, Enterprise, and Education.
The CSS files provided by Microsoft contain version information and we recommend that you use the latest version. There are separate CSS files for Windows client devices, OOBE, and post-OOBE experiences. [Download the Windows templates and CSS files (1.1.4)](https://download.microsoft.com/download/0/7/0/0702afe3-dc1e-48f6-943e-886a4876f6ca/MDM-ISV_1.1.4.zip).
The CSS files provided by Microsoft contain version information and we recommend that you use the latest version. There are separate CSS files for Windows client devices, OOBE, and post-OOBE experiences. [Download the Windows templates and CSS files (1.1.4)](https://download.microsoft.com/download/0/7/0/0702afe3-dc1e-48f6-943e-886a4876f6ca/MDM-ISV_1.1.4.zip).
@ -267,13 +192,12 @@ The following claims are expected in the access token passed by Windows to the T
|TID|A claim representing the tenant ID of the tenant. In the example above, it's Fabrikam.|
|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` |
|Resource|A sanitized URL representing the MDM application. Example: `https://fabrikam.contosomdm.com` |
> [!NOTE]
> [!NOTE]
> There's no device ID claim in the access token because the device may not yet be enrolled at this time.
> There's 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 [Microsoft Graph API](/azure/active-directory/develop/active-directory-graph-api).
To retrieve the list of group memberships for the user, you can use the [Microsoft Graph API](/azure/active-directory/develop/active-directory-graph-api).
@ -311,7 +235,7 @@ We recommend that you send the client-request-id parameters in the query string
### Terms Of Use Error handling
### Terms Of Use Error handling
If an error occurs 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. The URL should be encoded, and the contents of the error\_description should be in English plain text. This text isn't visible to the end-user. So, localization of the errordescription text isn't a concern.
If an error occurs 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. The URL should be encoded, and the contents of the `error_description` should be in English plain text. This text isn't visible to the end-user. So, localization of the `error_description` text isn't a concern.
Here's the URL format:
Here's the URL format:
@ -334,7 +258,6 @@ The following table shows the error codes.
|Azure AD token validation failed|302|unauthorized_client|unauthorized_client|
|Azure AD token validation failed|302|unauthorized_client|unauthorized_client|
|internal service error|302|server_error|internal service error|
|internal service error|302|server_error|internal service error|
## Enrollment protocol with Azure AD
## Enrollment protocol with Azure AD
With Azure integrated MDM enrollment, there's 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.
With Azure integrated MDM enrollment, there's 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.
@ -355,19 +278,22 @@ With Azure integrated MDM enrollment, there's no discovery phase and the discove
There are two different MDM enrollment types that integrate with Azure AD, and use Azure AD user and device identities. Depending on the enrollment type, the MDM service may need to manage a single user or multiple users.
There are two different MDM enrollment types that integrate with Azure AD, and use Azure AD user and device identities. Depending on the enrollment type, the MDM service may need to manage a single user or multiple users.
<ahref=""id="multiple-user-management-for-azure-ad-joined-devices"></a>**Multiple user management for Azure AD-joined devices**
-**Multiple user management for Azure AD-joined devices**
In this scenario the MDM enrollment applies to every Azure AD user who signs in 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, determine 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 extra 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 isn't 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 signs on to the machine, Azure AD user token isn't available to OMA-DM process. Typically, MDM enrollment completes before Azure AD user sign in to machine and the initial management session doesn't 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.
In this scenario the MDM enrollment applies to every Azure AD user who signs in 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, determine 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 extra 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 isn't 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 signs on to the machine, Azure AD user token isn't available to OMA-DM process. Typically, MDM enrollment completes before Azure AD user sign in to machine and the initial management session doesn't 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.
<ahref=""id="adding-a-work-account-and-mdm-enrollment-to-a-device"></a>**Adding a work account and MDM enrollment to a 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 their 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.
In this scenario, the MDM enrollment applies to a single user who initially added their 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.
<ahref=""id="evaluating-azure-ad-user-tokens"></a>**Evaluating Azure AD user tokens**
-**Evaluating Azure AD user tokens**:
The Azure AD token is in the HTTP Authorization header in the following format:
The Azure AD token is in the HTTP Authorization header in the following format:
```console
```console
@ -386,10 +312,9 @@ Access tokens issued by Azure AD are JSON web tokens (JWTs). A valid JWT token i
- Use the JWT Token Handler extension for WIF to validate the contents of the access token and extract claims required for use. For more information, see [JwtSecurityTokenHandler Class](/dotnet/api/system.identitymodel.tokens.jwt.jwtsecuritytokenhandler).
- Use the JWT Token Handler extension for WIF to validate the contents of the access token and extract claims required for use. For more information, see [JwtSecurityTokenHandler Class](/dotnet/api/system.identitymodel.tokens.jwt.jwtsecuritytokenhandler).
- Refer to the Azure AD authentication code samples to get a sample for working with access tokens. For an example, see [NativeClient-DotNet](https://go.microsoft.com/fwlink/p/?LinkId=613667).
- Refer to the Azure AD authentication code samples to get a sample for working with access tokens. For an example, see [NativeClient-DotNet](https://go.microsoft.com/fwlink/p/?LinkId=613667).
## Device Alert 1224 for Azure AD user token
## Device Alert 1224 for Azure AD user token
An alert is sent when the DM session starts and there's an Azure AD user logged in. The alert is sent in OMA DM pkg\#1. Here's an example:
An alert is sent when the DM session starts and there's an Azure AD user logged in. The alert is sent in OMA DM package #1. Here's an example:
- **contoso.com** – This value is the name of the Azure AD tenant to whose directory the device has been joined.
- **contoso.com** - This value is the name of the Azure AD tenant to whose directory the device has been joined.
- **db7ab579-3759-4492-a03f-655ca7f52ae1** – This value is the device identifier for the device whose compliance information is being reported to Azure AD.
- **db7ab579-3759-4492-a03f-655ca7f52ae1** - This value is the device identifier for the device whose compliance information is being reported to Azure AD.
- **eyJ0eXAiO**……… – This value is the bearer access token issued by Azure AD to the MDM that authorizes the MDM to call the Microsoft Graph API. The access token is placed in the HTTP authorization header of the request.
- **eyJ0eXAiO**……… - This value is the bearer access token issued by Azure AD to the MDM that authorizes the MDM to call the Microsoft Graph API. The access token is placed in the HTTP authorization header of the request.
- **isManaged** and **isCompliant** - These Boolean attributes indicates compliance status.
- **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.
- **api-version** - Use this parameter to specify which version of the graph API is being requested.
description: Windows 10 and Windows 11 provide an enterprise-level solution to mobile management, to help IT pros comply with security policies while avoiding compromise of user's privacy.
description: Windows 10 and Windows 11 provide an enterprise-level solution to mobile management, to help IT pros comply with security policies while avoiding compromise of user's privacy.
ms.date: 08/04/2022
ms.date: 03/24/2023
ms.technology: itpro-manage
ms.technology: itpro-manage
ms.topic: article
ms.topic: article
ms.prod: windows-client
ms.prod: windows-client
@ -9,6 +9,9 @@ ms.localizationpriority: medium
author: vinaypamnani-msft
author: vinaypamnani-msft
ms.author: vinpa
ms.author: vinpa
manager: aaroncz
manager: aaroncz
appliesto:
- ✅ <ahref="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client"target="_blank">Windows 10 and later</a>
- ✅ <ahref="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client"target="_blank">Windows 11 and later</a>
ms.collection:
ms.collection:
- highpri
- highpri
- tier2
- tier2
@ -16,22 +19,27 @@ ms.collection:
# Mobile Device Management overview
# Mobile Device Management overview
Windows 10 and Windows 11 provide an enterprise management solution to help IT pros manage company security policies and business applications, while avoiding compromise of the users' privacy on their personal devices. A built-in management component can communicate with the management server.
Windows provides an enterprise management solution to help IT pros manage company security policies and business applications, while avoiding compromise of the users' privacy on their personal devices. A built-in management component can communicate with the management server.
There are two parts to the Windows management component:
There are two parts to the Windows management component:
- The enrollment client, which enrolls and configures the device to communicate with the enterprise management server.
- The enrollment client, which enrolls and configures the device to communicate with the enterprise management server. For more information, see [Enrollment overview](mobile-device-enrollment.md).
- The management client, which periodically synchronizes with the management server to check for updates and apply the latest policies set by IT.
- The management client, which periodically synchronizes with the management server to check for updates and apply the latest policies set by IT.
Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is able to communicate with a third-party server proxy that supports the protocols outlined in this document to perform enterprise management tasks. The third-party server will have the same consistent first-party user experience for enrollment, which also provides simplicity for Windows 10 users. MDM servers don't need to create or download a client to manage Windows 10. For details about the MDM protocols, see [\[MS-MDM\]: Mobile Device Management Protocol](/openspecs/windows_protocols/ms-mdm/33769a92-ac31-47ef-ae7b-dc8501f7104f) and [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692).
Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is able to communicate with a third-party server proxy that supports the protocols outlined in this document to perform enterprise management tasks. The third-party server will have the same consistent first-party user experience for enrollment, which also provides simplicity for Windows users. MDM servers don't need to create or download a client to manage Windows 10.
For details about the MDM protocols, see
- [[MS-MDE2]: Mobile Device Enrollment Protocol Version 2](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692)
- [[MS-MDM]: Mobile Device Management Protocol](/openspecs/windows_protocols/ms-mdm/33769a92-ac31-47ef-ae7b-dc8501f7104f)
## MDM security baseline
## MDM security baseline
With Windows 10, version 1809, Microsoft is also releasing a Microsoft MDM security baseline that functions like the Microsoft GP-based security baseline. You can easily integrate this baseline into any MDM to support IT pros' operational needs, addressing security concerns for modern cloud-managed devices.
Starting with Windows 10, version 1809, Microsoft provides MDM security baselines that function like the Microsoft group policy security baseline. You can easily integrate this baseline into any MDM solution to support IT pros' operational needs, addressing security concerns for modern cloud-managed devices.
The MDM security baseline includes policies that cover the following areas:
The MDM security baseline includes policies that cover the following areas:
- Microsoft inbox security technology (not deprecated) such as BitLocker, Windows Defender SmartScreen, and Device Guard (virtual-based security), Exploit Guard, Microsoft Defender Antivirus, and Firewall
- Microsoft inbox security technologies (not deprecated) such as BitLocker, Windows Defender SmartScreen, Exploit Guard, Microsoft Defender Antivirus, and Firewall
- Restricting remote access to devices
- Restricting remote access to devices
- Setting credential requirements for passwords and PINs
- Setting credential requirements for passwords and PINs
- Restricting use of legacy technology
- Restricting use of legacy technology
@ -47,27 +55,3 @@ For more information about the MDM policies defined in the MDM security baseline
- [MDM Security baseline for Windows 10, version 1809](https://download.microsoft.com/download/2/C/4/2C418EC7-31E0-4A74-8928-6DCD512F9A46/1809-MDM-SecurityBaseLine-Document-[Preview].zip)
- [MDM Security baseline for Windows 10, version 1809](https://download.microsoft.com/download/2/C/4/2C418EC7-31E0-4A74-8928-6DCD512F9A46/1809-MDM-SecurityBaseLine-Document-[Preview].zip)
For information about the MDM policies defined in the Intune security baseline, see [Windows security baseline settings for Intune](/mem/intune/protect/security-baseline-settings-mdm-all).
For information about the MDM policies defined in the Intune security baseline, see [Windows security baseline settings for Intune](/mem/intune/protect/security-baseline-settings-mdm-all).
title: Register your free Azure Active Directory subscription
description: Paid subscribers to Office 365, Microsoft Dynamics CRM Online, Enterprise Mobility Suite, or other Microsoft services, have a free subscription to Azure AD.
ms.reviewer:
manager: aaroncz
ms.author: vinpa
ms.topic: article
ms.prod: windows-client
ms.technology: itpro-manage
author: vinaypamnani-msft
ms.date: 06/26/2017
---
# Register your free Azure Active Directory subscription
If you have paid subscriptions to Office 365, Microsoft Dynamics CRM Online, Enterprise Mobility Suite, or other Microsoft services, you have a free subscription to Azure AD. Here's a step-by-step guide to register your free Azure AD subscription using an Office 365 Premium Business subscription.
> **Note**If you don't have any Microsoft service that comes with a free Azure AD subscription, follow the step-by-step guide in [Add an Azure AD tenant and Azure AD subscription](add-an-azure-ad-tenant-and-azure-ad-subscription.md) to set up a tenant, add a subscription, and manage it via the Azure Portal.
## Register your free Azure Active Directory subscription
1. Sign in to the Microsoft 365 admin center at <https://portal.office.com> using your organization's account.
2. On the **Home** page, click on the Admin tools icon.
3. On the **Admin center** page, under Admin Centers on the left, click **Azure Active Directory**. You're taken to the Azure Active Directory portal.
- name:Push notification support for device management
- name:Push notification support for device management
href:push-notification-windows-mdm.md
href:push-notification-windows-mdm.md
- name:MAM support for device management
- name:MAM support for device management
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Vinay Pamnani