Having enabled Hybrid Azure AD device join through the AD Connect Wizard (Seamless SSO and hash sync, no ADFS) and having deployed GPs I am seeing the following in the AAD event log
AAD Cloud AP plugin call Plugin initialize returned error: 0xC00484B2
Device is not cloud domain joined: 0xC00484B2
PS C:Usersoffice365test1> dsregcmd /status
+———————————————————————-+
| Device State |
+———————————————————————-+
AzureAdJoined : NO
EnterpriseJoined : NO
DeviceId : 602d02e8-e435-4c6c-bdee-affea1723aab
Thumbprint : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
KeyContainerId : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
KeySignTest: : MUST Run elevated to test.
Idp : login.windows.net
TenantId : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TenantName : My Tenant Name
AuthCodeUrl : https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxx/oauth2/authorize
AccessTokenUrl : https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxx/oauth2/token
MdmUrl : https://wip.mam.manage.microsoft.com/Enroll
MdmTouUrl :
MdmComplianceUrl :
SettingsUrl : biglongstring
JoinSrvVersion : 1.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/xxxxxxxxxxxxxxxxxxxxxxxx/
WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net
DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/xxxxxxxxxxxxxxxxxxxxxxxxx/
DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net
DomainJoined : YES
DomainName : mydomain
+———————————————————————-+
| User State |
+———————————————————————-+
NgcSet : NO
WorkplaceJoined : YES
WorkplaceDeviceId : 602d02e8-xxxxxxxxxxxxxxxxxxxxxxxxxx
WorkplaceThumbprint : xxxxxxxxxxxxxxxxxxxxxxxxxx
WorkplaceIdp : login.windows.net
WorkplaceTenantId : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
WorkplaceTenantName : my tenant name
WorkplaceMdmUrl : https://wip.mam.manage.microsoft.com/Enroll
WorkplaceSettingsUrl : biglongstring=
WamDefaultSet : NO
AzureAdPrt : NO
AzureAdPrtAuthority : NO
EnterprisePrt : NO
EnterprisePrtAuthority : NO
+———————————————————————-+
| Ngc Prerequisite Check |
+———————————————————————-+
IsUserAzureAD : NO
PolicyEnabled : NO
DeviceEligible : YES
SessionIsNotRemote : YES
CertEnrollment : none
AadRecoveryNeeded : NO
PreReqResult : WillNotProvision
Jimmy White, MCSE Consultant Gigasoft Ltd.
Today I received a question what happens if the device is already Workspace ONE joined and then the device gets joined to Azure AD. In this use case the customer had AAD Premium licenses and Intune was assigned as MDM provider to all users.
So I started to install a workgroup client and installed the Intelligent HUB + enrolled the device to my UEM environment. Then I tried to join the device to AAD without an active MDM assignment in Azure Active Directory.
First result:
Works as expected.
Next test was again a workgroup client + enrolled to workspace but with Intune assigned to the user via AAD MDM application.
Result:
Error – I expected this since you can’t enroll into two MDM solutions. If the MDM enrollment fails, the AAD join fails.
Last but not least, I tested this also with a workgroup client + Workspace ONE enrolled + the MDM application was configured to use Workspace ONE.
Result:
The same error. Even if we are using the same MDM provider, Windows is not able to detect that the device is already enrolled in the same MDM.
Conclusion:
Do not try to join an MDM managed device to AAD if you have an MDM application assigned to the user.
So, either remove the MDM assignment in AAD, or unenroll the device before joining the device to AAD.
Here are some errors, and where to find them:
In the Eventlog -> Applications and Services Logs -> Microsoft -> Windows -> AAD -> Operational
AAD Cloud AP plugin call GenericCallPkg returned error: 0xC0048512In the Eventlog -> Applications and Services Logs -> Microsoft -> Windows -> User Device Registration -> Admin
The registration status has been successfully flushed to disk.
Join type: 1 (DEVICE)As you can see, the initial device registration in AAD worked well. But then you see two errors:
The get join response operation callback failed with exit code: Unknown HResult Error code: 0x801c0058.
Activity Id: 35d87d0f-1d85-49bf-a537-6b5a33446c66
The server returned HTTP status: 400
Server response was: {"code":"directory_error","subcode":"error_deviceprotected_fromdeletion_mdmmanaged","message":"The device object with id 'd896ab43-8d16-4991-b8f3-a2cbe40fbd3c' in tenant '6d9bffcc-c515-4a9e-b37c-367e2c84279c' could not be removed from the store because it is managed by MDM application '0000000a-0000-0000-c000-000000000000'.","operation":"DeviceDelete","requestid":"35d87d0f-1d85-49bf-a537-6b5a33446c66","time":"10-13-2021 14:18:38Z"}and
Unable to delete NGC container.
User SID: S-1-5-21-2019542070-1415088465-2199772-1001
IDP domain: NULL
Tenant domain: NULL
Error: Access denied.Now the device tries to delete the entry in AAD since its already managed by an MDM application.
Last but not least you see that the device unjoins the AAD Domain again:
The registration status has been successfully cleared from the device.
Join type: 8 (DEVICE_UNJOIN)
Tenant ID: 6d9bffcc-c515-4a9e-b37c-367e2c84279c
UPN:
Empowering customers in client management since 2012.
Empowering customers in modern management since 2018.
I am doing Azure Active directory integration with my MDM solution provider. After my device is Azure AD MDM enrolled to my MDM server, the sync never works,
I get an error in event viewer that failed to get AAD token for sync. I want to understand that for sync, will I receive an AAD JWT token which I am supposed to validate. When I was doing bulk enrollment using ppkg in that case I used to receive a MDM-signature
http header which I dont get now. Assuming I will receive a AAD token, why is it failing in my case. I get the following in event viewer:
MDM Session: Failed to get AAD Token for sync session User Token: (Unknown Win32 Error code: 0xcaa10001) Device Token: (Incorrect function.).
Seeing some additional errors in event viewer:
Http request status: 400. Method: GET Endpoint Uri: https://login.microsoftonline.com/0c43f031-2bf0-47d9-bd28-a8fa74a2c017/sidtoname Correlation ID: 27F72233-3F48-4047-8F93-C542E4DF4B3D
AAD Cloud AP plugin call Lookup name name from SID returned error: 0xC000023CAAD
Cloud AP plugin call GenericCallPkg returned error: 0xC0048512
Error: 0x4AA50081 An application specific account is loading in cloud joined session.
Logged at clientcache.cpp, line: 291, method: ClientCache::LoadPrimaryAccount.
Can someone please help on what could be the problem here?
With Azure AD Conditional Access (CA) policies you can control that only managed devices can access resources protected by Azure AD – https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/require-managed-devices#managed-devices
As mentioned in the article above, you might require the devices the sign in is taking place from to be hybrid Azure AD joined.
Here is official Microsoft documentation about Azure AD PRT.
As explained in this blog – https://jairocadena.com/2016/11/08/how-sso-works-in-windows-10-devices/ the Azure AD Primary Refresh Token (Azure AD PRT) is used during Azure AD CA policies evaluation to get the information about Windows 10 device registration state.
The mentioned blog explains that the Azure AD PRT is initially obtained during user sign into the station. In simple words, if the Cloud AP plugin is able to authenticate on behalf of the user (UPN and password or Windows Hello for Business PIN) to get the Azure AD access token and device is able to authenticate to Azure AD using the device registration state (MS-Organization-Access certificate) the Azure AD PRT will be issued to the user.
If any of these two parts (user or device) didn’t pass the authentication step, no Azure AD PRT will be issued.
So when you see an Azure AD Conditional Access error stating that the device is NOT registered, it doesn’t necessary mean that the hybrid Azure AD join is not working in your environment, but might mean that the valid Azure AD PRT was not presented to Azure AD.
To check if the Azure AD PRT is present for the signed into Windows 10 device user, you can use the “dsregcmd /status” command. Windows 10 OS version 1809 the Azure AD PRT info is stored in the SSO State section:
+———————————————————————-+
| SSO State |
+———————————————————————-+
AzureAdPrt : YES
AzureAdPrtUpdateTime : 2019-04-03 17:25:24.000 UTC
AzureAdPrtExpiryTime : 2019-04-17 21:25:54.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/tenantID
By the way you can use usual /? Switch to get help for the “dsregcmd” command (Windows 1809 and newer versions).
Keep in mind that the Azure AD PRT is a per user token, so you might see AzureAdPrt:NO if you are running the “dsregcmd /state” as local or not synchronized (on-premises AD user UPN doesn’t match the Azure AD UPN) user.
Per my experience, here are examples of what might be the root of Azure AD PRT being absent for the user (will be updating the list as discover more possible root causes):
- Device indeed is not hybrid Azure AD joined;
- Local registration state of the computer doesn’t match the records in Azure AD:
- Azure AD computer object was deleted by Global Admin via portal or PowerShell;
- Computer was moved out of Azure AD Connect sync scope and was removed from Azure AD by Azure AD Connect;
- Some services modified the Azure AD computer object and deleted the AlternativeSecurityIds attribute from Azure AD Computer object);
- CloudAP plugging is not able to authenticate on behalf of the user to get Azure AD access token:
- If the user is federated, the on premises STS is not reachable or STS do not have WS-Trust endpoint enabled (yes, WS-Trust is still required for Azure AD PRT flow and optional for Windows 1803 and newer registration flow) (for AD FS the WS-Trust endpoint is – adfs/services/trust/13/usernamemixed)
- The user has recently changed the UPN and is using Windows 1709 or older OS version and can’t get new or refresh expired Azure AD PRT – this issue was resolved in 1803 and newer);
Here are the recommended troubleshooting steps for mentioned above scenarios:
- To troubleshoot why the computer can’t perform hybrid Azure AD join refer to the following post – https://s4erka.wordpress.com/2018/03/06/azure-ad-device-registration-error-codes/;
- To better understand if there is a discrepancy between local registration state and Azure AD records, collect and review following info:
- “Dsregcmd /status” output on the effected computer, make the notes of the following fields: AzureAdJoined, DeviceCertificateValidity, AzureAdPrt, AzureAdPrtUpdateTime, AzureAdPrtExpiryTime;
- Check the Azure AD Portal – Devices blade, see if the station is present in Azure AD and has a timestamp listed in the Registered column, compare with the time in the DeviceCertificateValidity from the previous step. If there is no time stamp in the Registered column, that means that the AlternativeSecurityIds attribute (contains the MS-Organization-Access certificate thumbprint. This is the certificate that was saved to the station during registration process) was removed and the station needs to be re-joined to Azure AD;
- You can check if the station has the AlternativeSecurityIds attribute by using the Get-MsolDevice Azure AD PowerShell cmdlet;
- Check if the computer object is in the sync scope of Azure AD Connect;
- To get more clues about user portion of the Azure AD PRT receive process, its recommended to review the following Windows 10 logs – Application and Services Logs – Microsoft – Windows – AAD. These logs contain Operational and Analytic logs. Analytic logs are the equivalent of the Debug logs and are disabled by default. Usually you should be able to get info just by looking at the AAD Operational logs. In the AAD Operation logs look for the events generated by AadCloudAPPlugin Operation. By readying these logs you should get an idea either the STS is not reachable because of the network or protocol issues or Cloud AP is not able to authenticate on behalf of the user due to incorrect credentials or access policies configured on STS that block the authentication attempt for this user;
You can also use the “Get-WinEvent” PowerShell cmdlet to quickly pull latest AAD logs related to Azure AD Cloud AP plugin:
Get-WinEvent -LogName "Microsoft-Windows-AAD/Operational" -MaxEvents 20 | where {$_.TaskDisplayName -like "*AadCloudAPPlugin*"} | ft TimeCreated,id,KeyWordsDisplayNames,Message -wrap -autosizeKeep in mind that Windows down-level devices do not have Azure AD PRT and they “proof” to Azure AD CA that they are registered by establishing TLS authentication channel using the MS-Organization-Access certificate saved in the User certificate store during device registration. So if the successfully registered down-level Windows device is treated by Azure AD CA policy as not registered, most likely something (firewall/proxy) is messing up with that attempt of the device authentication.
In case you have verified that the signed in user has Azure AD PRT, but still the user who attempts to sign in via Microsoft Edge or Edge Chromium is getting “Device State: Unregistered”, make sure the user is signed in the browser with his work account. More details in this official document. Some other forums/blogs have mentioned the GPO is available to force automatic sign in into Edge browser to make it easier for the users.
AadCloudAPPlugin error codes examples and possible cause
0x80072ee7 followed by 0xC000023C – as mentioned in my Device Registration post, most likely caused by network or proxy settings, AadCloudAP plugin running under System cant access the Internet;
0xC000006A that has WSTrust response error “FailedAuthentication” coming before it – have seen these errors coming from 3rd party IdPs (Ping, Okta) due to users sync issues to Identity Provider (IdP) database. Also read the error description to get more clues about other possible causes of failed authentication and check IdP logs.
Logon failure. Status: 0xC000005F Correlation ID – check the federation settings of the user domain and make sure that the Identity provider supports WS-Trust protocol as mentioned here. IdPs supporting SAML protocol as primary Authentication will cause this error.
AAD Cloud AP plugin call Lookup name name from SID returned error: 0xC00485D3 (along with the call to Azure AD sidtoname endpoint in previous AadCloudAPPlugin event)– you might see this error on Azure AD Joined machine in managed (non-federated) environment, if the user signs in the Windows machine using the certificate. Smart card sign in is not supported for such scenario.
AAD Cloud AP plugin call SignDataWithCert returned error: 0x80090016 followed by Http transport error. Status: Keyset does not exist Correlation ID followed by Logon failure. Status: 0xC0090016 Correlation ID – most likely the device has lost access to the device and transport keys (TPM corruption – check with the hardware vendor if the new firmware is available), or image used for VDI was HAADJ (not recommended by public documents)). Reregistering the device (newer versions of OS should auto recover) should address this issue and allow obtaining AAD PRT.
AAD Cloud AP plugin call GenericCallPkg returned error: 0xC0048512 – most likely you are looking at the token acquisition events for the local account, that are not related to the sign ins of the user you are trying to troubleshoot. Keep searching for relevant events. 🙂
Logon failure. Status: 0xC00484C0 with Http transport error: Status: Unknown HResult Error code: 0x80048c0 – most likely you will see this for federated with non-Microsoft STS environments. Look for the event before these two events to see what STS endpoint returned this error and using timestamp, examine the STS logs to get more details.
Logon failure. Status: 0xC004848C – most likely you will see this for federated with non-Microsoft STS environments when the user is using the SmartCard to sign in the computer and the IdP MEX endpoint doesn’t contain information about certificate authentication endpoint/URL. This needs to be fixed on IdP side.
And the final thought. In case you need to re-join the Windows current device, make sure to follow the steps in this order to make sure the station really disjoined and will try the clean join process. Also keep in mind that since the computer object is recreated, the Bitlocker recovery keys that you might be saving in Azure AD for this station will be deleted and you will need to re-save them .
- Open elevated CMD (as local Admin) and issue “dsregcmd /leave”. Elevated CMD is important part, since during the leave flow, the registration service is trying to contact Azure AD and delete the computer object and also it tries to delete the MS-Organization-Access certificate from Computer certificate store, that definitely requires elevated privileges;
- Open new CMD window and confirm that the local registration state is cleaned and the station is not Azure AD joined by issuing “dsregcmd /status”;
- Using Azure AD devices portal confirm the computer object is gone, if not, delete it manually;
- In case you are in Managed environment, you need to run delta Azure AD Connect sync to pre-sync the AD computer object to Azure AD;
- Restart the station and sign in as Azure AD synchronized user.
anatoly_neo, в логе видна задержка 20 секунд.
В стеке при этом Windows.Security.Authentication.Web.Core.dll — намекает на проблему с аутентификацией Office.
P.S. Для эксперимента удалите Касперского.
Последний раз редактировалось Petya V4sechkin, 10-02-2021 в 01:05 .
Сообщения: 52604
Благодарности: 15253
| Конфигурация компьютера | |
| Материнская плата: ASUS P8Z77-V LE PLUS | |
| HDD: Samsung SSD 850 PRO 256 Гб, WD Green WD20EZRX 2 Тб | |
| Звук: Realtek ALC889 HD Audio | |
| CD/DVD: ASUS DRW-24B5ST | |
| ОС: Windows 10 Pro x64 |
anatoly_neo, точного соответствия по симптомам нет (у вас же только Outlook тормозит), но проблема как-то связана с аутентификацией.
И это согласуется с вашей ситуацией: начиная с некоторых сборок Office 2016 и Windows 10 сменился способ аутентификации с ADAL на WAM (диспетчер учетных веб-записей).
Поищите в Журналах приложений и служб -> Microsoft -> Windows -> AAD -> события, по времени совпадающие с зависаниями.
P.S. Кстати, служба Диспетчер учетных веб-записей в Windows 10 не отключена, случайно?
Это сообщение посчитали полезным следующие участники:
P.S. Кстати, служба Диспетчер учетных веб-записей в Windows 10 не отключена, случайно? »
Поищите в Журналах приложений и служб -> Microsoft -> Windows -> AAD события, по времени соответствующие зависаниям. »
Поставил на новый ПК свежую винду и офис 2019. При попытке запустить офис в AAD 4 предупреждения:
1)
Error: 0x80070002 Не удается найти указанный файл.
Exception of type ‘class DSRegException’ at acquiretokencontext.cpp, line: 208, method: AcquireTokenContext::GetFallbackDomain.
Log: 0xcaac03f1 Failed to get the DC registration data. Cannot get the domain name.
Logged at acquiretokencontext.cpp, line: 208, method: AcquireTokenContext::GetFallbackDomain.
2)
Error: 0xCAA9004D Account type is unknown.
Exception of type ‘class Exception’ at aggregatedtokenrequest.cpp, line: 157, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.
Logged at aggregatedtokenrequest.cpp, line: 159, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.
Request: authority: https://login.microsoftonline.com/common, client: d3590ed6-52b3-4102-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c, resource: https://officeapps.live.com, correlation ID (request): 0fd253d0-d916-49bf-9161-9ebac2fce256
3)
Error: 0x80070002 Не удается найти указанный файл.
Exception of type ‘class DSRegException’ at acquiretokencontext.cpp, line: 208, method: AcquireTokenContext::GetFallbackDomain.
Log: 0xcaac03f1 Failed to get the DC registration data. Cannot get the domain name.
Logged at acquiretokencontext.cpp, line: 208, method: AcquireTokenContext::GetFallbackDomain.
4)
Error: 0xCAA9004D Account type is unknown.
Exception of type ‘class Exception’ at aggregatedtokenrequest.cpp, line: 157, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.
Logged at aggregatedtokenrequest.cpp, line: 159, method: AggregatedTokenRequest::UseWindowsIntegratedAuth.
Request: authority: https://login.microsoftonline.com/common, client: d3590ed6-52b3-4102-aeff-aad2292ab01c, redirect URI: ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c, resource: https://api.office.net, correlation ID (request): dc98b904-73d5-49ed-8e7b-38232176dfd8
И такой же симптом, Outlook повисит секунд 20-30 и открывается.
Так же в AAD есть ошибки, но они возникают при запуске ПК:
1) Device is not cloud domain joined: 0xC00484B2
2) AAD Cloud AP plugin call Plugin initialize returned error: 0xC00484B2
Источник
Aad cloud ap plugin call plugin initialize returned error 0xc00484b2
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Answered by:
Question
Having enabled Hybrid Azure AD device join through the AD Connect Wizard (Seamless SSO and hash sync, no ADFS) and having deployed GPs I am seeing the following in the AAD event log
AAD Cloud AP plugin call Plugin initialize returned error: 0xC00484B2
Device is not cloud domain joined: 0xC00484B2
PS C:Usersoffice365test1> dsregcmd /status
AzureAdJoined : NO
EnterpriseJoined : NO
DeviceId : 602d02e8-e435-4c6c-bdee-affea1723aab
Thumbprint : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
KeyContainerId : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
KeyProvider : Microsoft Platform Crypto Provider
TpmProtected : YES
KeySignTest: : MUST Run elevated to test.
Idp : login.windows.net
TenantId : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TenantName : My Tenant Name
AuthCodeUrl : https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxx/oauth2/authorize
AccessTokenUrl : https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxx/oauth2/token
MdmUrl : https://wip.mam.manage.microsoft.com/Enroll
MdmTouUrl :
MdmComplianceUrl :
SettingsUrl : biglongstring
JoinSrvVersion : 1.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/xxxxxxxxxxxxxxxxxxxxxxxx/
WebAuthNSrvId : urn:ms-drs:enterpriseregistration.windows.net
DeviceManagementSrvUrl : https://enterpriseregistration.windows.net/manage/xxxxxxxxxxxxxxxxxxxxxxxxx/
DeviceManagementSrvId : urn:ms-drs:enterpriseregistration.windows.net
DomainJoined : YES
DomainName : mydomain
NgcSet : NO
WorkplaceJoined : YES
WorkplaceDeviceId : 602d02e8-xxxxxxxxxxxxxxxxxxxxxxxxxx
WorkplaceThumbprint : xxxxxxxxxxxxxxxxxxxxxxxxxx
WorkplaceIdp : login.windows.net
WorkplaceTenantId : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
WorkplaceTenantName : my tenant name
WorkplaceMdmUrl : https://wip.mam.manage.microsoft.com/Enroll
WorkplaceSettingsUrl : biglongstring=
WamDefaultSet : NO
AzureAdPrt : NO
AzureAdPrtAuthority : NO
EnterprisePrt : NO
EnterprisePrtAuthority : NO
IsUserAzureAD : NO
PolicyEnabled : NO
DeviceEligible : YES
SessionIsNotRemote : YES
CertEnrollment : none
AadRecoveryNeeded : NO
PreReqResult : WillNotProvision
Источник
Hi,
I’m testing joining of a physical Windows 10 device (2004 19041.630) to our Azure AD. The device was previously in the On Prem AD which is using Azure AD Connect to password sync hash to our Azure AD. I removed it from the on prem AD and also deleted all instances of Azure AD registered entries from the AAD.
I’ve tried to join the device manually with an admin account allowed to join devices and with a provisioning package. In both cases I can see the audit log showing add device success, add registered owner success then delete device success. Using the provisioning package this just goes into a loop and keeps repeating the add , register, delete actions.
On the device I just get the generic «something went wrong» 80180026 error. In the AAD operational log there are always 2 errors 1104 related to «AAd Cloud AP plugin call GenericCallPkg returned error: 0xC0048512».
Anyone know why it can’t join and might automatically delete the device again? Is there something on the device causing this? I have tried renaming the device but with same result.
Thanks,
Nigel
Last Updated on July 21, 2022 by rudyooms
This blog will be about an Autopilot White Gloved device that ended up in Intune but without an Azure Ad Join even though it showed us a nice green screen before sealing it! This blog is a work in progress so it will be updated daily!!!!
I will divide this blog into multiple parts
- Introduction
- The Issue
- TRYING to solve it!
- Azure Ad and Intune Device certificate
- The Device Certificate and White Glove
- Back to the Issue
- Fixing it Manually for now
1. Introduction
When a customer orders a new device, we are making sure we wipe it first and reinstall it with the latest Windows 10 build. While doing so we are also checking if everything is good to go before we start the white glove. As an example, we need to determine if key attestation is possible.
Another possibility would be to run this command: tpmtool getdeviceinformation
As we all know, TPM attestation is required when you want to perform a white glove. Also beware, when you have a tiger lake chipset, you will need to use 21h2. But none of the normal issues that could occur during the white glove was noticed.
2. The Issue
First I need to show you the exact issue, I was trying to solve. Take a look at this nice Windows Login Screen.
The only option we had, was logging in with the local admin account that was created during the white glove? At first, I had the idea my Azure Ad Login screen went fishing?
That’s odd because normally you end up with a nice login screen to log in as a user from your company but this time…. Not! So no Azure Ad login possibility on the device for us.
3. Trying to solve it
First, let’s check out if the device ended up in the Azure Ad portal.
Okay…? Looking at the picture above, Azure and Intune are detecting the device as Azure Ad joined? As the device is not used, we can just send a remove command to perform an Autopilot reset. So we did…
If you want to know more about all the possible options you have to start wiping your device please visit this blog
But still even after an Autopilot reset, the device still ended up with only the local admin on the login screen!!. Let’s dig a little bit deeper.
Again we opened the Intune portal to check out the last time it contacted Intune. As shown below… the device last contacted Intune, while we were trying to solve the issue.
But still, it wasn’t Azure Ad joined? What happened. It’s a good thing we have an additional local admin with LAPS implemented. I guess the first thing you need to do, when you need to start troubleshooting an Azure Ad join failure would be DSREGCMD /status. So we did!
Okay… The device isn’t Azure Ad joined even while Azure and Intune think differently. And no, trying to enroll the device with the /Join switch isn’t going to work!
4. Azure Ad and Intune Device Certificate
Before we continue I need to show you what happens when you are performing a White glove deployment (Autopilot for pre-provisioned deployments). I want to show you the normal device registration flow first.
So before our device gets MDM enrolled and would receive the Microsoft Intune MDM device CA, it will receive the Azure Ad Device Certificate. Let’s take a look at the device hardware information in Intune first.
Also, open the Certificate Manager and take a look at the Azure Device Certificate first before we continue
1. Device Certificate
You will probably have noticed 2 things:
- Granted to : a bunche of numbers –-> Your DeviceID which corresponds with the Azure Device ID in Azure
2. Granted by: MS-Organization-Access –> Azure AD –> So this is your Azure AD Device Certificate
2. Intune MDM certificate
As shown below the Intune MDM Device certificate. As expected on a working Intune device, this certificate is valid and available. This Certificate will arrive at the device after the Device certificate.
Again you will notice 2 things:
- Granted to: a bunche of numbers –> Your Intune Device ad which corrosponds with the Intune Device ID in Azure and Intune
- Granted by: Microsoft Intune MDM Device CA –> Intune –> So this is your Intune Device Certificate
If you want to read about my experience with an invalid certificate please read my blog about it.
5. Device Certificate and White Glove
Now we know when the Azure and Intune device certificates will be delivered to our devices, we need to take a look at how this process works with White Glove. First the Microsoft flow and then my part…
(I am telling you this because I didn’t know it at first 🙂 )
When pre-provisioning a new device with White Glove, please take a look at the Certificate Manager. When the device is performing the first step “Device Preparation” the TPM 2.0 will make sure the device is authenticated to your Azure Ad tenant. (Attestation)
While refreshing the Certificate manager you will notice the MS-Organization-Access device certificate arrives at the device for just a few seconds. After a few seconds, it disappears again! I was in the understanding it would stay there :). But I guess not.
Of course, the Device Object is pre-created successfully in Azure Ad itself!
So let’s reboot the device and see what happens when the device arrives at the first login screen.
Okay? So no Azure Device Certificate and the device is still not Azure Ad Joined. So enter your Office 365 credentials and start logging in. When logging in you will notice that within a few seconds the Device certificate arrives and the device will be Azure Ad Joined.
To resume: When using White Glove pre-provisioning the Azure Ad Device Certificate will come back and stays there during the first User Login and dsregcmd will show you, that your device is Azure Ad Joined
6. Back to the Issue
So the issue is totally Azure Ad related and nothing more. Intune was working like expected. Of course, we checked out the Settings page to determine if there was a school or work account attached. But I guess you already know the outcome. No account was configured
So the AAD event log should be your next step to investigate.
We were only noticing one error… and nothing more…. “AAD Cloud AP plugin call GenericCallPkg returned error” and 0xc0048512
When looking at this event, you are probably looking at an error while acquiring the Token for the local user and not the user you have issues with so you can skip this one…. (unfortunately for me)
Of course, when you are not blocking enrollment of personal devices and don’t have conditional access for requiring compliant devices configured you could do it manually but this time I wanted to know if I could do the same with the AAdinternals module. So I installed the module and tried to emulate the Azure Ad join.
(The device isn’t going to be Azure Ad joined with this action! but I wanted to know if any other errors could popup)
No weird, red errors…
7. Fixing it manually (for now)
Okay, screw it… I can’t find any errors which could point me to the real problem, so let’s fix it.
We changed the possibility to enroll private-owned devices to Allow… because we normally restrict it…
Now, let’s join the device manually. Maybe a new nice error could pop up?
Duh… Of course, the device was already present in Azure Ad and we got the 8018000a error. This device is already Registered
So we removed the device in Azure… And now I need to repeat myself, we removed the device in azure.
Did you ever try to remove an autopilot device in Azure? You will be prompted with a notification you can’t delete a windows autopilot device here.
Another funny fact, normally you only have 1 device in your Azure portal with a nice autopilot icon attached to it
But this time we noticed another exact same device but with a normal icon? Maybe it was because we tried the AADInternal solution first? I am not sure but we choose to remove the device to see what happened.
After the device was removed in the Azure Portal and only the Autopilot device was present we tried to perform a manually Azure Ad join again. Within a few minutes, the device was Azure Ad Joined and also dsregcmd /status finally showed us, it was AzureAdjoined
And pretty please with sugar on top… don’t forget to block the intune enrollment of personal devices again.
Conclusion
I now know what happened… I only need to reproduce it!. Let me explain what “could” have happened. After the device turned green, My colleagues sealed it as you should do. But after it turned green they turned it back on again only to perform some last-minute updates from the OOBE screen which was still running in the defaultuser0 context. I guess rebooting from there, really broke the Microsoft Sign-in page!
Again still need to reproduce it but it very much looks like this was the issue!
But as a quick note: Users are identified based on their credentials, Devices are identified by certificates!
I’m done…….(for now)
