Azure AD Conditional Access policies troubleshooting – Device State: Unregistered

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.

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):

1. Device indeed is not hybrid Azure AD joined;
2. 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);
3. 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:

1. 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/;
2. To better understand if there is a discrepancy between local registration state and Azure AD records, collect and review following info:
   1. “Dsregcmd /status” output on the effected computer, make the notes of the following fields: AzureAdJoined, DeviceCertificateValidity, AzureAdPrt, AzureAdPrtUpdateTime, AzureAdPrtExpiryTime;
   2. 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;
   3. You can check if the station has the AlternativeSecurityIds attribute by using the Get-MsolDevice Azure AD PowerShell cmdlet;
   4. Check if the computer object is in the sync scope of Azure AD Connect;
3. 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 -autosize

Keep 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.

And 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 .

1. 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;
2. 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”;
3. Using Azure AD devices portal confirm the computer object is gone, if not, delete it manually;
4. 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;
5. Restart the station.

AD FS 2016 Access Control Policies troubleshooting

The Access Control (AC) policies were introduced in AD FS 2016.

See this official documentation to get familiar with AD FS Access Control policies concept and settings.

Recently had to troubleshoot the following scenario.

Customer has Hybrid Exchange environment with email boxes located in on premises Exchange 2010 and archives located in Exchange Online.

Exchange on premises did not have Modern Authentication enabled.

Office 365 domain federated with AD FS 2016.

AD FS was configured to use Azure MFA.

The goal was to require MFA for all external users using Outlook 2016 and accessing their mailboxes and archives and skip MFA if the user is located inside corporate network.

At the beginning the following AD FS AC policy was configured for Office 365 Relying Party Trust (RPT).

{
Permit users
	and when authentication includes MFA
except
	from 'intranet' location;

Permit everyone
}

The issue with this policy is the “Permit everyone” at the second part, since this rule will allow anybody who didn’t meet requirement in first policy, to authenticate.

So the AD FS AC policy was modified the following way and applied to O365 RPT.

{
Permit users
	and when authentication includes MFA
except
	from 'intranet' location
}

And that’s where the unexpected authentication pop-up windows and MFA prompts started to happen when users inside corporate network were opening Outlook to access their email.

User continuously was receiving the Windows Security pop-up window that didn’t except correct user credentials and there was a second pop-up asking to authenticate again and that was triggering the MFA call to the user’s phone.

Analyzing the authentication flow based on the Exchange layout mentioned above, it was confirmed that its expected to have following authentication events to happen:

1. User accessing email box located in on premises Exchange must authenticate via AD FS using legacy authentication from Intranet.
2. When accessing email archive, Exchange Online has to authenticate user as well and since the legacy authentication was used, Exchange Online was authenticating on behalf of the user from outside of the corporate network.

By the way, due to the fact of legacy authentication flow we were not able to use Microsoft Claims X-Ray service.

To reduce the impact to production users, it was recommended to change the Access Control policy to contain these settings:
1. Permit users from the security group with MFA and exclude Intranet
2. Permit users from the security group with MFA and exclude Internet if the client IP (public IP of the office) matches the regex.
3. Permit all.

AD FS Access Control policy now looked like this.

{
Permit users
	from 'TEST' group
	and when authentication includes MFA
except
	from 'intranet' location;

Permit users
	from 'TEST' group
	and when authentication includes MFA
except
	from 'extranet' location
	and with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit everyone
}

Applied this AD FS AC policy to Office 365 RPT and still there were two prompts when the Outlook 2016 is opened – basic authentication window when accessing on premises email box and Modern Authentication prompt with MFA when accessing EXO archive.

In the AD FS Admin logs we saw the error: “MSIS5007: The caller authorization failed for caller identity XXX for relying party trust urn:federation:MicrosoftOnline.”

And in the AD FS Debug logs see the MFA is still required regardless the fact that the authentication attempt is coming from Intranet.

After multiple additional tests and getting better understanding how the Access Control policies are applied the following AD FS AC Policy was crafted that has addressed the issue completely.

{
Permit users 
	from 'extranet' location
	and from ‘TEST’' group
	and with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit users 
	from 'extranet' location
	and from 'TEST' group
	and when authentication includes MFA
except 
	with 'http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip' claim regex matches 'regex_for_public_IP_of_the_office' in the request;

Permit users 
	from 'intranet' location
	and from 'TEST' group;

Permit everyone
} 

The AD FS Access Control polices above work the following way:
1. Permits authentication coming from Internet if its EXO legacy authentication protocol on behalf of the user in the test security group coming from office public IP address;
2. Permits any other authentication for the test group coming from Internet if the MFA completed, but excludes office public IP from this rule (to make sure the first rule works as expected);
3. Permits authentication from the Intranet with no MFA for the test group (authentication to on premises Exchange)
4. And the last one catch Permit All group to make sure prod users are not affected during testing.

When the AD FS AC policy was successfully tested with the users added to the TEST group, the policy was applied to the rest of the production users by removing the TEST group condition from the first three policies and removing “Permit everyone”.