Domain Tenant Move and Device Join Issues

I discovered recently an issue following a tenant to tenant Microsoft 365/Azure AD migration. The issue was that devices would not enroll with Intune in the old tenant because the settings the device was getting was mixed up between the old and new tenants.

In the case I had, the new tenant was not yet ready for device enrolment, but new users are still joining the company and need a new device but with the settings from the legacy tenant Intune.

The process should work like this:

• Login on the device, in my case with a username still in the old tenant – we used enrol@tenantname.onmicrosoft.com. If you login with a user with a domain name that has migrated you will not get a Persistent Refresh Token (PRT) and therefore not auto-enroll in Intune.
• The device is Active Directory joined, and should be aiming for Hybrid AAD Join.
• The device at first login should generate a certificate and store it in the UserCertificate field in Active Directory – this should happen 5 minutes after login.
• The device should now sync successfully to the old tenant. This should happen, Active Directory replication delays pending, within 30 minutes. You can speed this up by forcing replication and running a manual sync
• The device should appear in Azure AD as Pending.
• Wait an hour, as the scheduled task that does all this work runs hourly on the device, or log off and back on again. Within five minutes the post login scheduled task will run, find its device in Azure AD and authenticate to it (Pending becomes a date/time)

In my case this was not happening correctly. The dsregcmd /status cmd that shows the state of Azure AD Join was reporting:

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES
          EnterpriseJoined : NO
              DomainJoined : YES
                DomainName : DOMAIN
               Device Name : PC1.domain.local

+----------------------------------------------------------------------+
| Device Details                                                       |
+----------------------------------------------------------------------+

                  DeviceId : 24ffdc75-xxxx-xxxx-xxxx-a6a5c8c638a0
                Thumbprint : XX93XX71XX04XXB4XXE0XX8FXX03XX7FX48XX7D
 DeviceCertificateValidity : [ 2023-06-20 18:50:53.000 UTC -- 2033-06-20 19:20:53.000 UTC ]
            KeyContainerId : GUID
               KeyProvider : Microsoft Platform Crypto Provider
              TpmProtected : YES
          DeviceAuthStatus : SUCCESS

+----------------------------------------------------------------------+
| Tenant Details                                                       |
+----------------------------------------------------------------------+

                TenantName : Old tenant name
                  TenantId : Old tenant GUID
                       Idp : login.windows.net
               AuthCodeUrl : https://login.microsoftonline.com/new-tenant-guid/oauth2/authorize
            AccessTokenUrl : https://login.microsoftonline.com/new-tenant-guid/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 :

If you look carefully in the above, you will see that AuthCodeUrl and AccessTokenUrl are both wrong – the device is joined to the old tenant, but the persistent refresh token (PRT) comes from the new tenant!

This meant that the device would never auto-enroll in Intune in the old tenant.

Eventually we noticed this following – the SCP at the top of the Active Directory forest, under CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=domain,DC=local had a “keyword” value of the old tenant primary domain that had already been migrated to the new tenant:

And in here, Keywords showing (redacted) the old domain:

The domain has already moved to the new tenant and so is now incorrect though it used to be correct. The AzureADId is the guid of the old tenant and remains correct.

To fix, update the AzureADName to the onmicrosoft.com domain that does not move in a tenant to tenant migration as shown:

The domain originally in the SCP is often the primary domain of a tenant and therefore could be a domain that is migrated leaving a broken configuration between Azure AD, Active Directory, devices and SCPs!

Photo by Athena: https://www.pexels.com/photo/black-and-gray-motherboard-2582937/