In a previous post we discussed about the three ways to setup Windows 10 devices for work with Azure AD. I later covered in detail how Windows 10 domain joined devices are registered in Azure AD. In this post I want to provide some insight about what happens behind the scenes when users join devices to Azure AD (Azure AD Join).
Users can join devices to Azure AD in two ways: 1) through the out-of-box experience (OOBE) the very first time a device is configured (or after a device reset to factory settings) or 2) through Settings after configuring the device with a Microsoft account (e.g. Hotmail) or local account.
In both cases what happens behind the scenes is fundamentally the same:
- User chooses to join device to Azure AD.
- User authenticates and provides an MFA proof (if configured).
- User accepts terms from MDM system (if applicable).
- Device registers with Azure AD.
- Device enrolls into MDM system and gets sign-in policy (if applicable).
- User signs into Windows.
- User provisions Microsoft Passport for Work.
- Device encryption is enabled and BitLocker key is escrowed to Azure AD.
- User enterprise settings are applied.
Let’s take a look at the details of what happens at each phase.
(1) User chooses to join device to Azure AD
When a user turns a device for the first time the user will see the OOBE. Once the user has gone through the initial pages like choosing language/region, accepting legal terms and connecting to the WiFi, the user sees the experience that allows the user to configure the device with a particular account.
The first detail to know is that this experience is web driven and runs under a particular “temporal” user that is created just before the experience shows. This differs from Windows 7/8.1 where all pages are local and run as SYSTEM up to the point of user logon.
Web pages are rendered in a special host called the Cloud eXperience Host (CXH) which has access to particular WinRT APIs needed for setting up the device.
Once the CXH is launched it navigates to a web app that will orchestrate the setup process. If the device runs Windows Professional the user will see a page presenting the option to configure the device as work-owned (using a work account) or personal (using a Microsoft account). If the device runs Windows Enterprise or Windows Home this page won’t show but instead will default to work-owned or personal respectively.
Once the user has chosen to configure the device as work-owned, the user will have the option to join the device to Azure AD or to create a local account. The current experience shows the option to join the device to a domain (traditional Domain Join) however this option will guide the user to setup a local account for the user to run Domain Join via Settings afterwards.
Please note that we are working on improving this experience on a future update of Windows based on feedback we have received from you.
If the user runs Azure AD Join from Settings (after setting up the device as personal or with a local account) the user will see the experience described from this point on.
After choosing Azure AD Join the CXH will navigate to the Azure AD Join web app that is hosted in the following location:
https://login.microsoftonline.com/WebApp/CloudDomainJoin/4
This web app is mainly “client” code in the form of HTML and JavaScript that calls particular WinRT APIs in the system via the CXH.
(2) User authenticates and provides an MFA proof if configured
Now, the web app will reach out to Azure AD to discover auth end-points by retrieving the OpenID configuration:
GET https://login.microsoftonline.com/common/.well-known/openid-configuration
Configuration is retrieved by obtaining the following JSON document:
{
"authorization_endpoint":"https://login.microsoftonline.com/common/oauth2/authorize",
"token_endpoint":"https://login.microsoftonline.com/common/oauth2/token",
"token_endpoint_auth_methods_supported":["client_secret_post","private_key_jwt"],
"jwks_uri":"https://login.microsoftonline.com/common/discovery/keys",
"response_modes_supported":["query","fragment","form_post"],
"subject_types_supported":["pairwise"],
"id_token_signing_alg_values_supported":["RS256"],
"http_logout_supported":true,
"response_types_supported":["code","id_token","code id_token","token id_token","token"],
"scopes_supported":["openid"],
"issuer":"https://sts.windows.net/{tenantid}/",
"claims_supported":["sub","iss","aud","exp","iat","auth_time","acr","amr","nonce","email","given_name","family_name","nickname"],
"microsoft_multi_refresh_token":true,
"check_session_iframe":"https://login.microsoftonline.com/common/oauth2/checksession",
"end_session_endpoint":"https://login.microsoftonline.com/common/oauth2/logout",
"userinfo_endpoint":"https://login.microsoftonline.com/common/openid/userinfo"
}
The web app will build a sign-in request using the discovered authorization endpoint to obtain a token to Azure DRS:
GET https://login.microsoftonline.com/common/oauth2/authorize ?client_id=01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 &msafed=0 &nonce=5724294428562708 &prompt=login &redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2FWebApp%2FCloudDomainJoin%2F4 &response_type=id_token &scope=openid+sid &uxoptin=true &windows_api_version=2.0
A few things to note:
- The value of the parameter client_id corresponds to the one of Azure DRS. This is interesting because the redirect URI is not the Azure DRS end-point but the Azure AD Join web app. In this special case the Azure AD Join web app is considered a client of Azure DRS.
- The token requested is an ID token. This is because the Azure AD Join web app needs to get claims from the token that need to pass to APIs for discovery, registration and MDM enrollment. Remember that the Azure AD Join web app is considered a client of Azure DRS.
- There is a parameter particular to Windows to specify the API version. The value of 2.0 allows obtaining MDM related URLs (for later use) as claims in the ID token.
The user will see the sign-in page where to enter credentials:
Once the user types the username the page will discover the corresponding realm information. This will determine whether the user needs to be redirected to a different STS (Secure Token Service) like an AD FS on-premises. This is done by retrieving realm information about the user’s domain name:
GET https://login.microsoftonline.com/common/userrealm/ ?user=jairoc@microsoft.com &api-version=2.1
The following is an example of a JSON object for the realm information for a federated tenant:
{
"IsDomainVerified":0,
"NameSpaceType":"Federated",
"federation_protocol":"WSTrust",
"Login":"jairoc@microsoft.com",
"AuthURL":"https://msft.sts.microsoft.com/adfs/ls/?username=jairoc%40microsoft.com&wa=wsignin1.0&wtrealm=urn%3afederation%3aMicrosoftOnline&wctx=",
"DomainName":"microsoft.com",
"FederationBrandName":"Microsoft"
}
If the tenant is federated the user will see the on-premises STS sign-in page where user can enter credentials . If the tenant is managed the user will be able to enter the password directly in the same page. In either case, if MFA has been configured the user will be challenged for additional factors of auth before proceeding.
For managed tenants only, an authentication buffer is created locally and temporary cached for automatic sign-in of the user to Windows at the end of OOBE (this doesn’t happen if run from Settings which will require a sign-out and a manual sign-in by the user). Federated tenant users will need to authenticate to the Windows logon UI after OOBE has completed.
Credentials are posted to Azure AD for authentication to the login end-point along with a few parameters indicating that this is a CXH driven authentication. This is useful to tweak some behaviors on the service side:
https://login.microsoftonline.com/common/login ?cxhflow=MOSET &cxhver=1.0 &cxhplatform=Desktop
Note that it indicates where the join is run from (Settings or OOBE), the version of the host (to accommodate for future behaviors) and the platform (Desktop or Mobile).
After authentication succeeds, an ID token is generated and posted back to the Azure AD Join web app. The following is an example of the contents of the token:
{
upn : "jairoc@microsoft.com"
instance : "NA"
amr : ["pwd","mfa"]
tid : "df5be8b1-f322-456c-acff-b13066d72402"
sid : "S-1-12-1-1875800440-1278975369-1393086615-305892544"
nbf : 1453828246
ver : "1.0"
mdm_enrollment_url : "https://manage-beta.microsoft.com/EnrollmentServer/Discovery.svc"
family_name : "Cadena"
sub : "4ySzMn-D18vwlmB4lWNipSg7Y5-qDVg9g41XVyoRvF4"
user_setting_sync_url : "Discovery:https://kailani.one.microsoft.com"
onprem_sid : "S-1-5-21-1515794938-1370939529-2107639213-1112"
oid : "6fce7178-9d89-4c3b-97d0-0853c08c3b12"
exp : 1453832146
given_name : "Jairo"
iat : 1453828246
iss : "https://sts.windows.net/df5be8b1-f322-456c-acff-b13066d72402/"
aud : "dd762716-544d-4aeb-a526-687b73838a22"
name : "Jairo Cadena"
unique_name : "jairoc@microsoft.com"
tenant_display_name : "Microsoft"
primary_sid : "S-1-5-21-1515794938-1370939529-2107639213-1112"
}
Please note that this information is cached locally in the device and is accessible after device registration completes through the following APIs in dsreg.dll:
DsrGetJoinInfo or DsrGetJoinInfoEx
The following claims in particular contain URLs which are used later on to complete configuration of the device.
mdm_tou_url mdm_enrollment_url user_setting_sync_url
To know how, please keep reading :).
(3) User accepts terms from MDM (if applicable)
The next step is for the user to accept the terms from the MDM. If there is a corresponding URL configured in Azure AD for the MDM app for this user, the ID token will contain a claim mdm_tou_url. For more information about how these URLs are setup see the post in the Active Directory blog about Windows 10 Azure AD and Microsoft Intune MDM enrollment.
If present the web app will navigate to the URL and the user will be presented with the terms of acceptance.
Upon acceptance the page posts back an acceptance buffer that the web app will use later when calling the MDM enrollment API.
(4) Device registers with Azure AD
Via JavaScript the web app calls a WinRT worker API that in turn calls APIs for discovery of the registration service, device registration and MDM enrollment:
CloudDomainJoin.DataModel.CloudDomainJoinWorker
This API first calls a “discovery” API to obtain information about the registration service (i.e. Azure DRS). This API is an internal Win32 API implemented in dsreg.dll which retrieves the discovery data document from:
https://enterpriseregistration.windows.net/microsoft.com/enrollmentserver/contract?api-version=1.2
This document contains information about Azure DRS registration and authentication end-points including the federation STS end-point (if configuration is federated), the Azure DRS URI, the end-point for Microsoft Passport provisioning, etc. One example of this document is shown below:
https://enterpriseregistration.windows.net/EnrollmentServer/DeviceEnrollmentWebService.svc urn:ms-drs:enterpriseregistration.windows.net1.0 https://login.microsoftonline.com/microsoft.com/oauth2/authorize https://login.microsoftonline.com/microsoft.com/oauth2/token https://msft.sts.microsoft.com/adfs/ls/ https://enterpriseregistration.windows.net/EnrollmentServer/device/ urn:ms-drs:enterpriseregistration.windows.net1.0 https://msft.sts.microsoft.com/ https://device.login.microsoftonline.com/ https://enterpriseregistration.windows.net/ https://enterpriseregistration.windows.net/EnrollmentServer/key/ urn:ms-drs:enterpriseregistration.windows.net1.0
Please note that some of these URLs/URIs are added to the cache data accessible by the DsrGetJoinInfoEx API after device registration completes (not the DsrGetJoinInfo).
With the discovery data and the ID token obtained during authentication the worker API then calls another API to perform device registration. This is another internal Win32 API in dsreg.dll which does the following:
- Generates a key pair for the device certificate.
- Generates a certificate signing request (CSR) using the key pair above (signs CSR data with private key plus includes public key in request).
- Generates a second key pair that will be used to bind SSO tokens physically to the device when authenticating to Azure AD later on. This key is typically called the storage/transport key (Kstk) and is derived from the SRK (Storage Root Key) of the device TPM. The way the binding of the SSO token to the device is achieved is by storing into the TPM a corresponding symmetric session key (encrypted to the storage/transport key) issued along with the SSO token upon auth to Azure AD. Along with the key pair, obtains attestation data in the form of a blob. For more details about how this please look for a couple of future posts where I will talk about SSO in Windows 10 devices and Internals of Microsoft Passport for Work.
- Sends a device registration request to Azure DRS (to end-point obtained from discovery document) passing along the ID token, the generated CSR and the public portion of the storage/transport key along with its attestation data.
Once the request comes to Azure DRS, the service will validate the token, will create a corresponding device object in Azure AD and will generate and send back a certificate to the device. The API in turn will install the certificate into the LocalMachine\MY store.
Using Windows PowerShell you can easily spot this certificate checking for the CN=MS-Organization-Access particular issuer:
PS C:\> dir Cert:\LocalMachine\My\ | where { $_.Issuer -match "CN=MS-Organization-Access" } | fl
Subject : CN=fbfcc7db-3b31-4818-aaf0-15aeb1ab1875
Issuer : DC=net + DC=windows + CN=MS-Organization-Access + OU=82dbaca4-3e81-46ca-9c73-0950c1eaca97
Thumbprint : A948413B32FA0A6435275693D4136BE10DFB4E97
FriendlyName :
NotBefore : 1/30/2016 10:27:39 AM
NotAfter : 1/27/2026 10:57:39 AM
Extensions : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
System.Security.Cryptography.Oid...}
Also using MSOL Devices cmdlets you can query the device object in Azure AD:
PS C:\> Get-MsolDevice -DeviceId fbfcc7db-3b31-4818-aaf0-15aeb1ab1875
Enabled : True
ObjectId : 3772980f-8553-402f-b092-7bd35395a6bd
DeviceId : fbfcc7db-3b31-4818-aaf0-15aeb1ab1875
DisplayName : DESKTOP-51PBLPR
DeviceObjectVersion : 2
DeviceOsType : Windows
DeviceOsVersion : Windows 10
DeviceTrustType : Azure AD Joined
DeviceTrustLevel : Compliant
DevicePhysicalIds : {}
ApproximateLastLogonTimestamp : 1/30/2016 6:57:39 PM
AlternativeSecurityIds : {X509:<SHA1-TP-PUBKEY>A948413B32FA0A6435275693D4136BE10DFB4E97aOQeN/3X9Ak0C6mIWQSOeM17t
wLhlA2UXOYTHLJutFw=}
DirSyncEnabled :
LastDirSyncTime :
RegisteredOwners : {jairoc@ntdev.microsoft.com}
GraphDeviceObject : Microsoft.Azure.ActiveDirectory.GraphClient.Device
A few things to highlight:
- DeviceId is a GUID generated by Azure DRS. Note that this is the same value in the Subject field of the certificate.
- AlternativeSecurityIds contains the certificate thumbprint with a specific scheme format (i.e. “X509:<SHA1-TP-PUBKEY>:” + thumbprint). This is how Azure AD will find the device object when the device presents the certificate upon authentication.
- The storage/transport key is stored in the device object in an attribute non-visible through Graph API.
(5) Device enrolls into MDM system and gets policy
Upon successful registration the worker API calls the MDM enrollment API passing along the following:
- An access token to the MDM enrollment service (MDM application in Azure AD).
- The acceptance of terms blob obtained from the corresponding MDM page (if present).
To obtain the MDM access token it first obtains an auth code by authenticating to the MDM enrollment service application silently relying on SSO cookies obtained previously during authentication to Azure DRS:
GET https://login.microsoftonline.com/common/oauth2/authorize ?client_id=29d9ed98-a469-4536-ade2-f981bc1d605e &msafed=0 &nonce=7912667160858957 &redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2FWebApp%2FCloudDomainJoin%2F4 &response_type=code &resource=https://manage-beta.microsoft.com/
A few things to note:
- Client ID corresponds to the one of the MDM app in Azure AD.
- The response type requested is a code.
- The resource is the value for the mdm_enrollment_url claim in the ID token.
The worker API will then use the code to obtain an access token for enrollment to happen. It does so by posting the code to the token end-point:
POST https://login.microsoftonline.com/common/oauth2/token
grant_type=authorization_code &code=AAABAAAAiL9Kn2Z27UubvWFPbm0gLViFwdiaP_FoKfldoPoZ6-o_aBfB1H8nQJgkWzbD1W1J8F3hCrO7aTO69QAib-PfvEFZTC3BwK53vNfuZ576-HunV5qGup1Pbf5N8p3Dv-HcZ tMIUpgvmqwTCJ1mS4e4M-0cPaCejrV4imOrVOocm92F9TS5ME-d44PQ2aQVXqLSKfGsvUEnbnzN1InYTmkk_sHaxZOiAYPofFR4AeuM5EmaNCK3e5lQVqHaBIXmGJnRRpKxOqQAAPxXtPrh 5089NjNhEOgdkywyqCOSmV7FEejcSycZmpPHuvzxuUq85V_g0XS2a0y6OSgoh8lqSIBVXerds7etsC6USg4HMnCKxmZHrhxTjAp0citwUoGV3Ch6uOOgVpOKt7D4AZIfTYVEhz9p-7371EG ZaIkC6jKdfg3SwxJj4gfC_WfeJc6NGCJE2iWcIQpFmywHEBAnNrQv_2ZmyTq3TEnycijLpK8IUU5ZwtqAqAFoi7qRKb0R6GlRSnqCS9WKQaRbGkzF17IENorhD01MYwWCOrtcMW4oKfy7Qw Ehn5oPEIoaoQzLsbwjL5Wor90sbmltHCXN5KECSkMnMaa5Yz0YPsdh4ULaOZDwXrJrJxau4_DCxHss_0ENu2mjfH3tumTjG-s3A-qoHiUHjxUXbls_BdQ0X8SVLjECz1mLVsOe_rNc_bsUl PTdAzLSyQkeRTWFYb19X3CwPCAA &client_id=29d9ed98-a469-4536-ade2-f981bc1d605e &redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2FWebApp%2FCloudDomainJoin%2F4 &resource=https://manage-beta.microsoft.com/
The worker API will get back a bearer token with an access token, an ID token and a refresh token. It extracts the access token and passes it to the MDM API.
MDM enrollment occurs and sign-in policy is obtained as part of the payload coming from enrollment.
(6) User signs into Windows
Once MDM enrollment completes it is time for the user to sign in. The user is automatically signed in if the tenant is managed (i.e. no federation with an on-premises STS). This is accomplished by taking the authentication buffer obtained during authentication to Azure DRS (step #2 above) and passing it to the LSA to the Cloud Authentication Provider which in turn authenticates both the user and the device with Azure AD. For more information about how this works in detail look for a future post on SSO in Windows 10 devices.
Please note that for a future update of Windows we have plans to extend the user’s automatic sign-in behavior to federated tenants as well.
(7) User provisions Microsoft Passport for Work
User provisions Microsoft Passport for Work for a secure and convenient sign-in to Windows using Windows Hello, a user’s gesture that includes a PIN, finger-print, iris or facial recognition.
I won’t delve into this today as this subject deserves a full post. Please look for a future post about Internals of Microsoft Passport for Work for complete details on what happens behind the scenes.
(8) Device encryption is enabled and BitLocker key is escrowed to Azure AD
If the device is InstantGo capable (always on, always connected, like the Surface or Surface Pro), device disk encryption is enabled and the key is sent to Azure AD to be registered in the corresponding device object.
This is done by the BitLocker Drive Encryption Service (BDESVC) which uses the following end-point discoverable through the DsrGetJoinInfoEx API to write the key in Azure AD:
POST https://enterpriseregistration.windows.net/EnrollmentService/Key
The way the service authenticates the device to the end-point is by relying on the SSO capabilities of Windows 10. For more information about this please look for a future post about SSO in Windows 10 devices.
(9) User enterprise settings are applied.
One last point to mention the Enterprise Roaming of Settings capability. As of the date of this post it is a capability that is still on Private Preview (soon will be available for Public Preview). This component will authenticate to the Enterprise Roaming of Settings service using the SSO capabilities of Windows 10.
Once authenticated settings are retrieved and applied to the local device. It will rely on information returned by DsrGetJoinInfo to reach out to the service (i.e. user_setting_sync_url claim of ID token initially obtained, accessible through the DsrGetJoinInfo API).
Final thoughts
I hope this detail gives you a good idea about how Azure AD Join works. Please also let me know what you would like to see posted in future entries.
Again thanks for reading this far :).
See you soon,
Jairo (Twitter: JairoC_AzureAD)
Devices, Security and Identity in #Microsoft365 by Jairo Cadena 
Pingback: Azure AD Join: What happens behind the scenes? – Thoughts about Windows
Pingback: Windows 10 Conditional Access with Intune MDM and AAD Join
Pingback: Asserting domain joined state for Conditional Access in Intune - A Cloud Above the Rest
Pingback: Azure AD and Microsoft Passport for Work in Windows 10 | [Azure] Active Directory by Jairo Cadena
Hy Jairo,
Thanks for your article.
I have trouble understanding the process with a federated tenant (step 2) after entering my credentials in my company’s sign-in page. What happens next ?
You said that “credentials are posted to Azure AD” but who did it ?
In advance, thanks
Todd
LikeLike
Hi Todd, this just referred to what happens when the user clicks the ‘Sign in’ button in the page where the credentials are entered. The credentials are submitted directly to the login end-point in Azure AD if the page is the Azure AD login page. In the federated case the credentials are posted to AD FS (or on-prem STS) and it is AD FS who will provide the token resulting of authentication to Azure AD. Azure AD will take the token and issue a final one to the device for registration a few steps after.
LikeLike
Hi Jairo,
is it possible to change the DisplayName after joining a device to Azure AD ? If I change the computer name of a joined device this change is not reflected in Azure AD it stays the old one. This is a little bit confusing because if you startup/install a new Windows 10 Device the device name is normally something like “DESKT-ZGZF”.
Best regards
Jens
LikeLike
Jens, you are right that we don’t rename the device object upon renaming the device in Windows. This is something that we want to provide on a future update of Windows.
Renaming the device manually is not straightforward. You can manually rename the device by using the Graph API for the device entity using the PATCH method (https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/entity-and-complex-type-reference#DeviceEntity). You can achieve this using Windows PowerShell using the Invoke-RestMethod cmdlet.
If you want to try this out and need help with a script that does it please feel free to reach me via Twitter or email.
LikeLike
Jairo, could you provide a sample script using the Graph API to rename a device object, because I don’t have very much experience with this API ? I sent you an email some days ago but I’m not sure if it has reached you, because I don’t know if it was your correct email address.
Thanks and regards
Jens
LikeLike
Hi Jens, I went back and spot your email. Let me paste my response for the sake of friends following the blog.
To invoke a specific REST API you can use the Invoke-RestMethod cmdlet like the following:
$result = Invoke-RestMethod `
-Method Patch `
-Uri $uri `
-ContentType “application/json” `
-Body $json `
-Headers @{“Authorization”= $token;”Content-Length”=$json.Length};
$uri is the Graph API URI as follows, where {1} is your tenant domain name and {2} is the device ID of the device that you want to change the display name. The device ID you can obtain using the regular Get-MsolDevice cmdlet:
$uri = “https://graph.windows.net/{1}/devices/deviceId_{2}?api-version=1.5”;
$json is a JSON object that contains the properties to change. So for the case of display name it would be as follows where $newName is the new display name for the device:
$json = @{ displayName=$newName } | ConvertTo-Json;
Now, finally the trickiest part is to get the value for $token. For this you can use the AcquireToken method of the AuthenticationContext class:
$ctx = New-Object Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext( `
“https://login.microsoftonline.com/{1}”, `
$true);
$userCred = Get-Credential;
$cred = New-Object Microsoft.IdentityModel.Clients.ActiveDirectory.UserCredential( `
$userCred.UserName,
$userCred.Password);
$token = $ctx.AcquireToken($GRAPH_RESOURCE_ID, $CLIENT_ID, $cred);
Please note that {1} is your tenant domain name. Also note the values for the graph resource and client IDs below:
$GRAPH_RESOURCE_ID = “00000002-0000-0000-c000-000000000000”;
$CLIENT_ID = “dd762716-544d-4aeb-a526-687b73838a22”;
I hope that can give you an idea on what is needed. Let me know if you have trouble putting the pieces together.
LikeLike
We have Intune but the users (even the new ones that never accepted terms and conditions) are not prompted for terms acceptance during the OOBE. Is it a known bug?
LikeLike
Clark,
The ToU page for Intune is expected to show upon Azure AD Join. Can you please check the setting in the Azure Portal by going to the Intune application in the directory applications page and looking at the ‘configure’ section. You should be able to see the ToU URL if set.
For detailed information about MDM integration with Azure AD please see https://msdn.microsoft.com/en-us/library/windows/hardware/mt158260(v=vs.85).aspx.
LikeLike
I had an error in the URL, thank you!
LikeLike
exceptional post by the way, I had to read it several times to digest it! 🙂
LikeLiked by 1 person
Great Stuff! Is it possible to retrieve the bitlocker recovery from AzureAD with Powershell?
LikeLike
Hi there, thanks!
It is not possible today. We will be looking into this for a future update of the MSOL device cmdlets.
I would be interested in the use case you have in mind. As you may know we have an admin UI and a self-service UI. I would love to learn from you (and others) about when retrieving the BitLocker key via PowerShell would be useful.
LikeLike
We are very interested in having a PowerShell API to read the Bitlocker key from Azure AD and much more important an API to write Bitlocker keys to Azure AD for devices that do not support InstantGo. The reason is to have a single store for all bitlocker keys.
LikeLike
Hi Tobi, thanks for your feedback. It is inline with feedback we have received from a few customers. We are looking into this to see whether we can have a way to enable this scenario in a secure way. I’ll keep the blog audience updated as we make progress on this front.
LikeLike
One more question Jairo, do you have a list of urls that we should allow without authentication on the proxy?
LikeLike
Clark,
You would need the following.
For device registration:
enterpriseregistration.windows.net
For authentication to Windows:
login.microsoftonline.com
For MS Passport for Work provisioning, besides the URL for device registration which is needed for the provisioning of the credential you would need:
account.live.com
Jairo
enterpriseregistration.windows.net
login.microsoftonline.com
LikeLike
This article was a savior. I have been scratching my head entire day to understand Azure AD Join.
I am working on a task to do this entire process of AD domain join through a PowerShell script.
I reached upto a point where I was able to autenticate to Azure AD, and have got the access token
Will be great if you can guide further as I am not sure how do I proceed.
LikeLike
Shrikant, I would be curious to know why you want to do this.
There are public APIs for device registration and enrollment with MDM but these are not exposed as PowerShell cmdlets. You could try and expose these in PowerShell and in theory implement the orchestration that I explain in the blog post.
LikeLike
Hi Jairo,
again, thanks for this great article. It’s an incredible asset to get the missing details of joining Azure AD.
But, like Shrikant says, it seems there is currently absolutely no way to automate the Azure AD Join. It was easy with on premise domains, and to be honest I can’t understand why it wasn’t a must have on the list when designing the AzureAD Join.
You asked for ‘why’ – I am sure there are plenty of answers, I would like to describe our case: We implement large scale Azure AD projects with thousands of clients. Because with Win10/EMS Intune/OMA policies and app deployment ‘politely said’ there are often some ‘issues’ and we need to do intensive testing to find them all. That’s why we designed an Azure based automated Win10 test infrastructure which runs ‘fresh-install to final desktop’ with dozens of parallel scenarios (jon.doe.01 to jon.doe.99) to check for problems.
Well – currently there is a manual ‘join’ step. You can imagine how boring this job is…
Any idea to automate the Azure AD join? No problem to code, we just need a hint…
Thanks,
Christian
LikeLike
Christian, Shrikant, thanks for that feedback and the explanation on the scenario you want to enable. There is a feature that is coming to allow ‘bulk’ provisioning of Azure AD joined devices. There are no concrete dates as of when it will be available, but this will allow you to author a provisioning package with a special credential that will be used to bootstrap the join of the device where the provisioning package runs. I believe this will help with the scenario you describe.
LikeLike
Shrikant, can you detail how you were able to autenticate to Azure AD, and have get the access token? I am working on a similar process and this would be helpful.
LikeLike
The device that is registred in Azure get a display name same as the device name. If the user change de device name de display name does not change with Azure. Is that bij design?
LikeLike
Thanks for the detailed explanation Jairo. I’m working on a solution to automate the process of migrating users that are not joined to any on-premise AD to Azure AD. I found solutions for domain joined devices but not for workgroup machines. Could you give any guidance as to how I could script the Azure AD join?
LikeLike
Hey Michael, unfortunately there is no simple way to automate Azure AD Join with the current update of Windows. This function might come in a future update.
LikeLike
Too bad, we’ll wait for the next version with that then. In the meantime, we’ll instruct the user to do this by hand. Is there any way to call the window that comes up after clicking “join azure AD” by script? Just to try and streamline the user experience as opposed to having them click through the settings.
LikeLike
Michael, probably the best you can do to help these users is to take them to the Settings page where they can do Azure AD Join. From the browser you can get to the About page (if 1511 version of Windows) with ms-settings:about (you can have a link for users to click with this value in a web page for example) or you can get to the Workplace page (if 1607 version) using ms-settings:workplace. I am not sure if that is sufficient but maybe worth to consider. After they are in the page they can click on ‘Join Azure AD’ (1511) or ‘Connect’ (1607) and then authenticate and follow the flow.
LikeLike
Jairo, I am in the same boat, i am also trying to automate the process of Azure AD Join as part of the deployment of a machine. I’ve looked into the process that is provided by the W(I)CD tool for 1703, but it’s really not what we’re looking for. Have you heard of a solution that would allow for full scripted Azure AD Join yet?
LikeLike
Reblogged this on DeployWindows•Info and commented:
If you are looking for some deeper information how Azure AD join work, have a look at this post!
LikeLike
Hi Jairo, We have couple of BYOD machines in our Org. We are planning to allow either the machine should always require a password to open the device (No PIN, Only Email password) or set the No. of times login allowed using cached credentials when the device is offline (like CachedLogonsCount 10). Is it possible to achieve the above scenario?
LikeLike
Hi. Any smooth suggestion on how to automate encryption with Bitlocker on Windows 10 without InstantGo? We are hoping to have some kind of automation on our Lenovo laptops which we joins into Azure AD (not hybrid).
LikeLike
I’m interested in that too!
LikeLike
Hi Herms, we’re looking for the same solution. Did you already get this to work?
LikeLike
Hi Herms, we’re looking for the same solution. Did you get this to work?
LikeLike
Unfortunately this is not possible today. The Windows client team is looking into expanding the scope of devices that can escrow the BitLocker key to Azure AD. There are not concrete plans yet but I will keep you informed as this functionality comes available.
LikeLike
Hi Jairoacadena and everyone else
We are experiencing SSO issues with Domain Joined Windows 7 PCs that’s registered to Azure AD with Azure DRS.
This happens when a client tries to login to an Azure AD or ADFS App after they have been registered to Azure AD:
1. Clients get prompted to choose a Certificate to login to AzureAD and ADFS Apps. (Cert issued by ADFS it seems)
2. Clients then must enter their username (username@domain.com) in the login page to login.
Before the device was registered with Azure DRS the device got SSO with reduced logins to all ADFS apps and SSO (without reduced logins) to Azure AD Apps.
By Implementing this we were looking to get SSO reduced logins to Azure AD Apps for all domain joined computers *, but it appears to make the situation worse.
Do you have any idea why this is happening?
(*https://blogs.technet.microsoft.com/trejo/2016/04/09/azure-ad-join-vs-azure-ad-device-registration/ )
LikeLike
Hi Bjoervik, you can remove the certificate prompt by adding https://device.login.microsoftonline.com to the Intranet zone. Are you doing device authentication in AD FS, meaning you have enabled device write-back?
LikeLike
Hello Jairo, thank you very much for these excellent blog posts – they have been extremely helpful so far! Apart from that, I wanted to let you know that I (and most likely lots of other people) am eagerly awaiting those further blog posts you announced 🙂 such as “SSO in Windows 10 devices”… Kind regards, Alex
LikeLike
Thanks Alex! There are a couple coming soon. Stay tuned!
LikeLike
Hi Jairo, We are running a Hybrid setup of Azure AD/AD on Premise, The domained joined computer is successfully joined to Azure AD if i run dsregcmd /status, but I don’t recieve a AzureAD PRT after sign-In. The error I see in the AAD eventlog say’s
Get token user names don’t match. Correlation ID:
What can it be?
Another question regarding the Two certificates that are provisioned to the computer after Azure AD join, Which one does the computer use for authentication to Azure DRS during device registration? They are so shortlived.
Kind regards Mikael
LikeLike
Running the /leave command should work. As registration is by default enabled in 1607, the device will attempt registration on next sign-in of the user.
Regarding the certificate for authentication of the device, upon registration there is one certificate that is deployed in the computer MY store. You can identify it using PowerShell using the following command:
dir Cert:\LocalMachine\My\ | where { $_.Issuer -match “CN=MS-Organization-Access” } | fl
LikeLike
Thanks Jairo, A follow question…
Can give me some example scenarios when the device will need to authenticate to Azure AD? For the user to obtain an SSO token(PRT), I can’t see where the device authenticaion fits in. Please explain Jairo.
LikeLike
Pingback: How SSO works in Windows 10 devices | [Azure] Active Directory by Jairo Cadena
Pingback: (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail « Jorge's Quest For Knowledge!
Pingback: (2016-12-28) Joining Devices To Azure AD – The Options And The Differences « Jorge's Quest For Knowledge!
Hello Jairo, I have implemented AD FS (WIN2012R2), on-premise Identity SSO, with Azure AD. Published applications on Azure with CA. The Automatic Device Registration works fine, but unfortunately from standard clients (deployed with several policies, for example proxy configuration, endpoint protection, etc.) Azure DRS is not reached. We have defined CNAME on internal DNS, but after login the Automatic Device Registration fails, reported error “Failed to discover the Azure DRS service. Exit code: Unknown HResult Error code: 0x801c0021.”. There is a kind of list that contains all necessary Azure DRS endpoints (URLs, URI), we have to define some exceptions on endpoint protection and internal internet proxy.
LikeLike
Thanks Jairo. This was educational.
Question : Sends a device registration request to Azure DRS (to end-point obtained from discovery document) passing along the ID token, the generated CSR and the public portion of the storage/transport key along with its attestation data.The public portion of the CSR is sent in the request, Is it signed or any mechanism that Azure AD has to validate if the CSR was tampered or it just has HTTPS security since it is happening over SSL?
Thanks
LikeLike
Can the Azure AD user that joined the device to the AAD be removed from the local admin group after the join? Or does this cause some issues?
Thanks for a quick reply.
LikeLike
In step 4 when the device registers to Azure you mention that it stores information to the TPM chip on the machine if this is the case what do you use to backup the TPM information in the case the Motherboard is replaced on the machine or the user is migrating to a new machine.
LikeLike
Azure AD join apparently has a per-user limit of 20 devices. Could you offer a brief explanation of this, and comment on whether it is permanent or not? Our use case pertains to 100’s of shared virtual desktops in a pool where they are randomly assigned to users at logon.
…and I plan to be at your Ignite session on Wednesday afternoon.
LikeLike
Hi Kevin, we initially set this quota as a default value. You can certainly change this value, and even set it to unlimited if you have MFA properly for device registration.
For virtual desktops, certainly Windows Server 2016/Windows 10 will be what you want to move to if you are not already. As registration in Win10/Server 2016 is per machine, unlike Win7/Server 2008R2/2012/2012R2 which is per user, you won’t have a problem of proliferation of devices.
LikeLike
Great read Jairo! One piece I am looking to clarify is the difference between the MS-Organization-Access certificate and the MS-Organization-P2P-Access certificates in a workstations personal store?
I ‘believe’ the P2P cert is an access token as the expiration date is 24hrs. so it only makes sense that is what its for but how do I know for sure?
LikeLiked by 1 person
Hi Susan, the P2P certificate is one that is pushed down by Azure AD during authentication of the user in the device, for the purpose of supporting remote desktop connectivity to another Azure AD joined device (peer-to-peer). The target device will authenticate this certificate against Azure AD, before the remote connection is established.
LikeLike
Pingback: #AzureAD device-based conditional access and #Windows 7/8.1 | [Azure] Active Directory by Jairo Cadena
Hello and thanks for this great article.
Here we are facing an issue of ADFS login loop when joining Azure AD with on premise STS.
We found that the timezone is not set correctly during Windows 10 OOBE which then prevents the Join Azure AD process.
Any idea ?
Help ?
LikeLike
Hi LFR, is it the issue that if the user doesn’t choose the right time zone authentication loops on AD FS sign-in, but if the user chooses it right it won’t?
LikeLike
Hi,
Can a user logs in to the PC without internet connectivity ? In my scenario, A windows 10 devices enrolled through Autopilot and registered via Azure AD. After login in the first time the user goes on offline and wants to re login to the PC. Is this possible ?
LikeLike
How can I retrieve the Azure AD token that is stored by win10? So that I can reuse the Azure AD token to sign into my Apps automatically.
LikeLike
Hi Kewang, if you are developing your application that trusts in Azure AD for auth, and want to make use of the SSO state of the device (PRT) you can use the Web Account Manager APIs. Take a look a this article where you can find a code sample: https://docs.microsoft.com/en-us/windows/uwp/security/web-account-manager. On the other hand, if your application is a browser app then it will leverage SSO automatically as long as it trusts in Azure AD for authentication.
LikeLike
Where does the SID come from? On a Windows 10 Azure AD Joined device the local Administrators group includes:
AzureAD\Admin (S-1-12-1-38678509…)
S-1-12-1-3346315821-114…
S-1-12-1-445845933-119…
Note that this join was performed via Settings on a machine that included only a local admin account.
That list would include the Azure AD user that performed the join and I assume the Azure AD global administrator role and Azure AD device administrator role. (based on info here https://docs.microsoft.com/en-us/azure/active-directory/devices/assign-local-admin)
Users lists that show only SIDs are not overly helpful. Is there any way to match those SIDs to the entities they represent?
LikeLike
Hey Jairo,
What about Virtual Machines?
LikeLike
This set of posts has been invaluable. We battled a Citrix env that was having a number of issues tied to hybrid join and no support organization had been able to determine root cause. This has allowed us to peel back the onion and get back on track. Very much appreciated
LikeLike
This set of posts has been invaluable. We battled a Citrix env that was having a number of issues tied to hybrid join and no support organization had been able to determine root cause. This has allowed us to peel back the onion and get back on track. Very much appreciated
LikeLike
Using the DSREGCMD on the client I see the URL’s are pointing to Microsoft online. The Hello for Business is not coming up.I had taken the client off the domain and added it back in. The URL’s were pointing to on premises AD FS The Hello for business asking to setup the pin would come up but I would get an error when selecting the type of MFA. How do I point it back to the on-prem?
I have a hybrid configuration. I first tried the certificate trust setup. Then Azure told me I should be using Key trust.
LikeLike
Pingback: KeySignTest Failure & Device Registration – Modern Workplace Configuration with Intune
Has anyone found a way to pull the SID for the Azure AD user from the cloud side?
LikeLike
Pingback: Azure AD Hybrid Device Join Error (0x801c03f2) – Sam's Corner
Pingback: Azure AD Device based Authentication - Workplace Ninja's