Today’s quick post is about the effect of System Board replacement for a device that is managed by Intune.
This is the draft version that I sent out to Rudy for his review, because of the fact that recently he has been doing some wonderful posts on things related to TPM and Autopilot. He not only helped to review this but also put in his efforts and you can see his version posted here.
Table of Contents
Introduction to the problem – Effects of SYSTEM Board replacement on a MEM Intune managed device
When a TPM 2.0 enabled MEM Intune managed device undergoes a major hardware change like a System Board replacement, post-change, it results in the device becoming unrecognizable to the management service – Azure AD, Intune, and the Autopilot service.
Consider you have a Windows 10/Windows 11 device that is
- TPM 2.0 enabled,
- Registered to Autopilot service,
- Autopilot provisioned, Azure AD Join with auto-enrollment to Intune,
- Bitlocker enabled with TPM protection.
Device State |
+----------------------------------------------------------------------+
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : NO
Device Name : DESKTOP-LR80PVF
+----------------------------------------------------------------------+
| Device Details |
+----------------------------------------------------------------------+
DeviceId : d1a5f064-641e-4c40-a7fa-7f0273c6fa71
Thumbprint : 2FBF85F05E9C40242EDD94AE4EE96B77D10C0F1C
DeviceCertificateValidity : [ 2021-12-10 17:08:41.000 UTC -- 2031-12-10 17:38:41.000 UTC ]
KeyContainerId : 8de5992f-2a63-4246-8b3c-eb6e15f8480c
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
DeviceAuthStatus : SUCCESS
For any reason whatsoever, it required a SYSTEM board replacement.
Note #1: If Bitlocker Device/Drive encryption was enabled on the device and was not suspended prior to the System Board replacement, post-change, as you try to boot, the device will always enter Bitlocker Recovery mode. The explanation is given in the latter part of this post.
Note #2: Before the SYSTEM Board replacement, either make sure to turn Bitlocker protection off or save the working Recovery key. Post the replacement procedure, if Bitlocker protection was not disabled prior to the change, the device is guaranteed to boot to the Recovery screen and you can guess what will happen if you do not happen to have the recovery key for the same.
Post the MOBO change, considering that there are no issues with the system drive and the system can boot the OS, when the device is handed over to the user and they perform Windows sign-in to get to the desktop, the problem starts from there.
The user gets the below prompts stating that there is a problem with the work or school account, asking for a sign-in.
Clicking on the Sign-in button and performing the auth operation thereafter triggers a process that is equivalent to performing a dsregcmd /forcerecovery which will resolve the issue for which this blog post is all about.
Technically, the device goes through a registration recovery operation bolstering its new identity with Azure AD.
If you have taken care to note down the Azure AD device ID of the device, you will see the value getting changed before and after this process.
Initial values before Sign-in and recovery operation.
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : NO
Device Name : DESKTOP-LR80PVF
+----------------------------------------------------------------------+
| Device Details |
+----------------------------------------------------------------------+
DeviceId : d1a5f064-641e-4c40-a7fa-7f0273c6fa71
Thumbprint : 2FBF85F05E9C40242EDD94AE4EE96B77D10C0F1C
DeviceCertificateValidity : [ 2021-12-10 17:08:41.000 UTC -- 2031-12-10 17:38:41.000 UTC ]
KeyContainerId : 8de5992f-2a63-4246-8b3c-eb6e15f8480c
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
DeviceAuthStatus : SUCCESS
Values post Sign-in and recovery operation
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : NO
Device Name : DESKTOP-LR80PVF
+----------------------------------------------------------------------+
| Device Details |
+----------------------------------------------------------------------+
DeviceId : 27fee40b-f644-4b3f-905b-b6bd65f6b0ca
Thumbprint : 23BEAA1D1FDE745803CB9620DD72CC0CC368EBFB
DeviceCertificateValidity : [ 2021-12-11 16:38:00.000 UTC -- 2031-12-11 17:08:00.000 UTC ]
KeyContainerId : fb50b800-1fb3-447d-abc5-29330c888a6b
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
DeviceAuthStatus : SUCCESS
But this is not what this blog post is about.
This blog post is about why, in the first place, the device shows the error with the Work or School account after the user gets to the Desktop for the first time after SYSTEM Board replacement.
As such, let us ignore the Sign in and continue with the Not now option to see what all issues are in wait for us and the most important question – Why?
We will find out shortly.
Issues that arise on a MEM Intune managed device post SYSTEM Board replacement
As said above, when we continue with the Not now option on the Work or School account problem warning prompt, below are the errors the user is expected to experience on the device.
- If the device has the Company Portal app installed, it will fail to recognize the device (in some case might even fail to sign-in)
- Opening any of the Office apps from the M365 Enterprise App suite will prompt user for sign-in. The seamless SSO functionality (due to the Azure AD PRT) that the user enjoyed before the System board replacement takes a hit.
- OneDrive sync client will fail to sign-in the logged in user and will give the below error.
- And finally, if the organization has device based CA policy applied, the device will get blocked from accessing the CA policy protected corporate resources.
If System Board replacement causes the device to become unrecognizable by Azure services, how does the Windows login works? I will not answer this now, but it will get explained automatically as you read below.
However, if there occurs any issue with the system drive in itself, like system partition corrupted, etc. and the system fails to boot, it would then require a re-image (or recovery if WinRE is present ) which will mean starting afresh, negating the above problems as highlighted.
But then you will face the next issue that is the device will not be recognized by the Autopilot service and as such will start the consumer OOBE flow during provisioning.
Are there any changes to the device join state?
Before the SYSTEM Board replacement, this is the DSREGCMD command output.
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : NO
Device Name : DESKTOP-LR80PVF
+----------------------------------------------------------------------+
| Device Details |
+----------------------------------------------------------------------+
DeviceId : d1a5f064-641e-4c40-a7fa-7f0273c6fa71
Thumbprint : 2FBF85F05E9C40242EDD94AE4EE96B77D10C0F1C
DeviceCertificateValidity : [ 2021-12-10 17:08:41.000 UTC -- 2031-12-10 17:38:41.000 UTC ]
KeyContainerId : 8de5992f-2a63-4246-8b3c-eb6e15f8480c
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
DeviceAuthStatus : SUCCESS
+----------------------------------------------------------------------+
| Tenant Details |
+----------------------------------------------------------------------+
TenantName : LearnIntuneWithJoy
TenantId : 13b9b587-b500-49e8-a36f-c34aa188c4db
Idp : login.windows.net
AuthCodeUrl : https://login.microsoftonline.com/13b9b587-b500-49e8-a36f-c34aa188c4db/oauth2/authorize
AccessTokenUrl : https://login.microsoftonline.com/13b9b587-b500-49e8-a36f-c34aa188c4db/oauth2/token
MdmUrl : https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
MdmTouUrl : https://portal.manage.microsoft.com/TermsofUse.aspx
MdmComplianceUrl : https://portal.manage.microsoft.com/?portalAction=Compliance
SettingsUrl :
JoinSrvVersion : 2.0
JoinSrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/device/
JoinSrvId : urn:ms-drs:enterpriseregistration.windows.net
KeySrvVersion : 1.0
KeySrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/key/
KeySrvId : urn:ms-drs:enterpriseregistration.windows.net
WebAuthNSrvVersion : 1.0
WebAuthNSrvUrl : https://enterpriseregistration.windows.net/webauthn/13b9b587-b500-49e8-a36f-c34aa188c4db/
WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net
DeviceManagementSrvVer : 1.0
DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/13b9b587-b500-49e8-a36f-c34aa188c4db/
DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet : NO
WorkplaceJoined : NO
WamDefaultSet : YES
WamDefaultAuthority : organizations
WamDefaultId : https://login.microsoft.com
WamDefaultGUID : {B16898C6-A148-4967-9171-64D755DA8520} (AzureAd)
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : YES
AzureAdPrtUpdateTime : 2021-12-10 17:49:12.000 UTC
AzureAdPrtExpiryTime : 2021-12-24 17:54:48.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/13b9b587-b500-49e8-a36f-c34aa188c4db
EnterprisePrt : NO
EnterprisePrtAuthority :
+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+
AadRecoveryEnabled : NO
Executing Account Name : AzureAD\JoymalyaBasuRoy, joymalya@intunewithjoy.in
KeySignTest : PASSED
+----------------------------------------------------------------------+
| IE Proxy Config for Current User |
+----------------------------------------------------------------------+
Auto Detect Settings : YES
Auto-Configuration URL :
Proxy Server List :
Proxy Bypass List :
+----------------------------------------------------------------------+
| WinHttp Default Proxy Config |
+----------------------------------------------------------------------+
Access Type : DIRECT
+----------------------------------------------------------------------+
| Ngc Prerequisite Check |
+----------------------------------------------------------------------+
IsDeviceJoined : YES
IsUserAzureAD : YES
PolicyEnabled : YES
PostLogonEnabled : YES
DeviceEligible : NO
SessionIsNotRemote : NO
CertEnrollment : none
PreReqResult : WillNotProvision
Surprisingly, post changing MOBO, the DSREGCMD command output still shows the device as Azure AD joined with the exact same identifier.
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : NO
Device Name : DESKTOP-LR80PVF
+----------------------------------------------------------------------+
| Device Details |
+----------------------------------------------------------------------+
DeviceId : d1a5f064-641e-4c40-a7fa-7f0273c6fa71
Thumbprint : 2FBF85F05E9C40242EDD94AE4EE96B77D10C0F1C
DeviceCertificateValidity : [ 2021-12-10 17:08:41.000 UTC -- 2031-12-10 17:38:41.000 UTC ]
KeyContainerId : 8de5992f-2a63-4246-8b3c-eb6e15f8480c
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
DeviceAuthStatus : FAILED. Error:8007013d
+----------------------------------------------------------------------+
| Tenant Details |
+----------------------------------------------------------------------+
TenantName : LearnIntuneWithJoy
TenantId : 13b9b587-b500-49e8-a36f-c34aa188c4db
Idp : login.windows.net
AuthCodeUrl : https://login.microsoftonline.com/13b9b587-b500-49e8-a36f-c34aa188c4db/oauth2/authorize
AccessTokenUrl : https://login.microsoftonline.com/13b9b587-b500-49e8-a36f-c34aa188c4db/oauth2/token
MdmUrl : https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
MdmTouUrl : https://portal.manage.microsoft.com/TermsofUse.aspx
MdmComplianceUrl : https://portal.manage.microsoft.com/?portalAction=Compliance
SettingsUrl :
JoinSrvVersion : 2.0
JoinSrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/device/
JoinSrvId : urn:ms-drs:enterpriseregistration.windows.net
KeySrvVersion : 1.0
KeySrvUrl : https://enterpriseregistration.windows.net/EnrollmentServer/key/
KeySrvId : urn:ms-drs:enterpriseregistration.windows.net
WebAuthNSrvVersion : 1.0
WebAuthNSrvUrl : https://enterpriseregistration.windows.net/webauthn/13b9b587-b500-49e8-a36f-c34aa188c4db/
WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net
DeviceManagementSrvVer : 1.0
DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/13b9b587-b500-49e8-a36f-c34aa188c4db/
DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net
+----------------------------------------------------------------------+
| User State |
+----------------------------------------------------------------------+
NgcSet : NO
WorkplaceJoined : NO
WamDefaultSet : YES
WamDefaultAuthority : organizations
WamDefaultId : https://login.microsoft.com
WamDefaultGUID : {B16898C6-A148-4967-9171-64D755DA8520} (AzureAd)
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : YES
AzureAdPrtUpdateTime : 2021-12-10 17:49:12.000 UTC
AzureAdPrtExpiryTime : 2021-12-24 17:54:48.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/13b9b587-b500-49e8-a36f-c34aa188c4db
EnterprisePrt : NO
EnterprisePrtAuthority :
+----------------------------------------------------------------------+
| Diagnostic Data |
+----------------------------------------------------------------------+
AadRecoveryEnabled : YES
Executing Account Name : AzureAD\JoymalyaBasuRoy, joymalya@intunewithjoy.in
KeySignTest : FAILED (device key)
+----------------------------------------------------------------------+
| IE Proxy Config for Current User |
+----------------------------------------------------------------------+
Auto Detect Settings : YES
Auto-Configuration URL :
Proxy Server List :
Proxy Bypass List :
+----------------------------------------------------------------------+
| WinHttp Default Proxy Config |
+----------------------------------------------------------------------+
Access Type : DIRECT
+----------------------------------------------------------------------+
| Ngc Prerequisite Check |
+----------------------------------------------------------------------+
IsDeviceJoined : YES
IsUserAzureAD : YES
PolicyEnabled : YES
PostLogonEnabled : YES
DeviceEligible : NO
SessionIsNotRemote : NO
CertEnrollment : none
PreReqResult : WillNotProvision
Did you notice all the errors that have crept in?
Even though the device still has the all-important MS-Organization-Access certificate which gives the device its identity to Azure AD (and thus to all of Microsoft cloud), we can see that there is some issue with the device key for which everything breaks loose.
How does this relate to TPM? Read on.
Decoding the cause of issue…
To understand the cause for the issues as highlighted above, we need to have an insight into how a Windows 10 device gets managed. For the purpose of simplicity, I will try to explain w.r.t Azure AD join and MDM auto-enrollment, Azure AD Authentication service (AADSTS) being the auth endpoint.
Revisiting Azure DRS
For successful join/registration, Azure DRS drops a certificate to the device, which is the MS-Organization-Access cert installed to the Computer Account Personal store. The Subject Name (CN) of this cert is the Azure AD Device ID.
Now if you check Graph Explorer to see the properties of the same Azure device object, you would come across another parameter
"alternativeSecurityIds": [
{
"type": ,
"identityProvider": ,
"key":
}
A better view of this property obtained using the Get-MsolDevice cmdlet
What is this alternativeSecurityIds key?
The alternativeSecurityIds is an x509 cert which is Azure AD internal. This is used to identify the device when it checks back with service.
As can be seen, it is composed of the SHA Hash of the Transport Key (TP_Pub) and the thumbprint of the MS-Organization-Access cert.
This is where we need to get a look into the Azure DRS process for the AADJ behind-the-scenes knowledge and I have already talked about it in my previous autopilot blogs.
AAD Join activity sequence in a nutshell
AAD Join activity is done within the host process called CloudExperienceHost via the CloudDomainJoin web app
The process begins with
- Home Realm discovery to negotiate the auth endpoint (For autopilot, this is pre-negotiated with information retrieved from the autopilot profile)
- User credentials sent to the auth endpoint.
- For successful auth, auth endpoint sends an Id_token (JWT) back to the CloudDomainJoin webapp.
If MDM Auto Enrollment scope is defined, the Id_token will also contain the MDM related URLs (Discovery, TOU, Compliance)
- CloudDomainJoin webapp makes a WinRT worker API call which in turn makes internal Win32 API calls to discover registration service, device registration and MDM enrollment endpoints(functions exported through dsreg.dll)
At this point, the CloudDomainJoin web app has
- Id_token to be passed to Azure DRS
- Discovery data of registration service, device registration endpoint and MDM enrollment endpoint
With this, the CloudDomainJoin web app makes another internal Win32 API call to process the device registration (function exported via dsreg.dll) The activities that get performed at the device level are
- dsreg component generates two cryptographic key sets – Device Key (DK_Pub/DK_Priv) and Transport Key (TP_Pub/TP_Priv)
For a TPM 2.0 enabled device, the private key of the above public-private key pairs is secured by the TPM.
- dsreg then uses public part of Device Key (DK_Pub) to create a Certificate Signing Request (CSR).
CloudDomainJoin web app sends the CSR and public part of the Transport Key (TP_Pub) to Azure DRS registration endpoint (as obtained from discovery data) along with the Id_token (obtained during auth)
- Azure DRS verifies the Id_token and creates a device object in Azure AD.
As part of the device object creation, Azure DRS creates a certificate, encrypts it with the Device Key (DK_Pub) received via the CSR, and sends it back to the device.
This is the MS-Organization-Access certificate stored on the Local Machine Personal cert store (protected by TPM since DK_priv is bound to TPM) and serves as the primary device identity to the service.
Since this cert is encrypted with the DK_Pub, it can only be decrypted using the DK_Priv which is TPM protected.
This completes the Azure DRS process but there’s more to the story…
Post Azure DRS as the device completes enrollment to the MDM and provisioning
- (for a managed tenant) CloudDomainJoin webapp completes the user sign-in process (Winlogon) to present the Desktop screen as a seamless experience, using the temporary cache buffer created during the Azure DRS auth process.
- (for a federated tenant or for hybrid Azure AD join) CloudDomainJoin webapp does not creates the user credential cache buffer, as such user is presented with the Winlogon screen to perform the manual sign-in to get to the Desktop.
The Winlogon process is of importance, as it is during this 1st sign-in, that the device receives the PRT from the Azure AD auth endpoint.
This is the reason why, for performing AAD Join from the Windows Settings menu, post-completion, till the time you have not signed out from the local/Microsoft account and sign-in using the Azure AD account, if you run dsregcmd /status you will see that the AzureAdPrt status shows as NO.
PRT is the reason behind the SSO capabilities that Azure AD offers. The content of PRT is opaque and cannot be viewed externally.
But does it only serves the purpose of SSO?
The PRT, in addition to the claims that are usually found in a normal refresh token, contains an additional claim – Device ID and as such forms the basis for CA evaluation.
Understanding Winlogon for Azure AD join
Microsoft already has this documented here, as such I will not repeat it. But will only highlight the important parts.
- The CSR as sent to Azure DRS is used by the Azure AD Authentication service (AADSTS) to create the PRT, which is delivered to the device encrypted using the public part of the Transport Key (TK_Pub)
- AADSTS also creates a Session Key (encrypted opaque blob which can only be viewed by the AADSTS) which is also delivered to the device along with the PRT, protected using the public part of Transport Key (TK_Pub).
Since, this can be only decrypted by the private part of the Transport Key (TK_priv), which is protected by the TPM, it serves as the Proof-of-Possession for any request being sent to Azure AD.
Any token request or PRT renewal request made to Azure AD gets signed by the Session Key via TPM thereby resisting tampering attempts. Any request for token renewal without the Session Key is rejected.
The public part of the Transport Key (TK_pub) is used by Azure DRS to create another important property of the device object – alternativeSecurityIds as I already told above, which is used by Azure to identify and verify the device.
Did we get an Answer?
For a system enabled with TPM 2.0, the TPM chip stores the necessary keys required for everything as explained above.
When the SYSTEM Board is replaced, since the new System Board will come with a new TPM, it will not have the old keys (DK_priv and TK_priv) that were stored in the TPM chip of the old SYSTEM board.
Thus without the TPM that started the device certificate generation, the device loses access to the device-bound keys and as such cannot prove its identity to the service.
Note: Azure AD join/registration does not support FIPS compliant TPM 1.2 and as such for such devices, it will consider the device to be without TPM and resort to using Software Key Storage Provider (KSP) to secure the private keys of the public-private keys pairs as mentioned above. Thus, for a device with no TPM or TPM 1.2, since it will be using a Software KSP, SYSTEM board change will break nothing. See how TPM enhances the security of an Azure AD joined device!
But why do we need to re-register device to Autopilot post major hardware change?
For an Autopilot provisioned device, hardware hash forms the basis of identity validation, when a device reaches out to the service endpoint to check if it is autopilot enabled.
Revisiting Autopilot in a nutshell, the CSV we upload (output of the Get-WindowsAutopilotInfo PS script) to register the device to Autopilot contains the hardware hash against which the device gets registered to Autopilot, resulting generation of ZTDID which gets stamped to the blank Azure AD device object, also created by Azure DRS as part of the Autopilot registration.
You can use the oa3tool.exe (part of Windows 10 ADK) with the switch /DecodeHwHash to decode the hardware hash and see the details being submitted
Sample command: .\oa3tool.exe /DecodeHwHash=<hardware hash copied from the csv>
Of all the properties that you will see in the Decoded Hash, the below are the minimum properties that help to uniquely identify a device from the rest.
<p n="SmbiosSystemManufacturer" v="" />
<p n="SmbiosSystemProductName" v="" />
<p n="SmbiosSystemSerialNumber" v="" />
<p n="SmbiosUuid" v="" />
<p n="OSType" v="" />
<p n="DiskSerialNumber" v="" />
<p n="MacAddress" v="" />
<p n="TPMVersion" v="" />
<p n="TPM EkPub" v="" />
Change of SYSTEM board will cause a change of values for these parameters resulting in a new hash and as such when the device will reach out to Autopilot service to check if it is Autopilot enabled, it will fail.
The device will not undergo Autopilot provisioning but will go through the normal OOBE setup experience.
End of the day…
Replacing the SYSTEM board of a TPM-enabled managed device breaks the trust between the device and the management service because of the simple reason – post the MOBO change, the device TPM is new and as such, it does not contain the necessary keys that are required.