There are few things to look for, when you have problems in the implementation phase of conditional access or if you want to solve problems that end-users are reporting.
If you can’t solve the problem yourself and you have to make a support case for Microsoft, I’ll tell you also what you should take out when you open the case. Usually you open the support ticket through the portal, but not necessary always.
Pre-requirements
When you start troubleshooting, note next things before you open Azure AD Portal. If you have many rows of failed logs, these will help you on the way to find the right logon failure row:
- User Principal Name
- User’s display name
- Operating system name
- Time stamp (about)
- Application that you are troubleshooting
- Client application type (Client App / Browser)
Find the log
Open your Azure AD Portal, when starting the troubleshooting and ensure that you have at least Report Reader permission to the your Azure AD directory with the account you sign in. Select Azure Active Directory and Sign-Ins.
Use search tools to find the specific authentication session from all logs. I usually start with a specific username and Status.
Use noted pre-requirement values to find your failed login that you are going to inspect and click it open.
Analyzing the log
You can find here all the information about the sign-in. Also you can find the Failure reason.
When you click different tabs in the details pane, you can find the Device information, MFA information (was it required, did the user pass it and with what authentication method). One of the cool features of the Sign-in -log is the Conditional Access tab. You can see here which conditional access policies have been applied and what was the result. From this example I can see that the logon was failed to the CA policy called Desktop Devices – Browsers and grant control that the policy has is require domain-joined device and the result is Failure.
Now you know why the device didn’t pass the conditional access. Still you don’t know the root cause, why the device is not domain joined. Here are couple of first ideas in this case that I would suggest to look for:
- Double check from the workstation that it is domain joined
- Check the Join type from the Device info tab that it is Hybrid Azure AD joined
- Ensure that you have only Hybrid Azure AD joined type of device in Azure AD (some times users have also Azure AD registered the device and you find it two times with the same name; then just remove the registration from the workstation side)
- Ensure that the user is not using incognito-mode in the browser
- If using 3rd party browser e.g. Chrome, ensure that there is Windows 10 accounts add-on installed
There might be several other reasons also, why this happens but these are the first steps where to start.
Deeper troubleshooting
If you just don’t know why the problem occurs for example in the domain joined case above, go to the workstation and open a command prompt with administrative privileges. You can find status of Azure AD registration or join with a command:
dsregcmd /status
Read the result of command out and ensure that you don’t find anything weird. If you are still in the corner, leave the Azure AD by typing:
dsregcmd /debug /leave
After the command, log off from the computer, ensure that you don’t have any device accounts with the name of problematic workstation in the Azure AD and sign-in again to the workstation (Azure AD join occurs in sign-in process). If this doesn’t help either you can troubleshoot more and more from event logs and from AD FS or Azure AD Connect side (depending how is your Hybrid Azure AD join configured). If you still can’t find the solution, open the support case to the Microsoft.
Opening a case for Microsoft
You can contact Microsoft Customer Support through the Azure portal. Just open the detail pane of your sign-in log and select Troubleshooting and support tab.
Open the case for Microsoft by clicking the Create a new support request -link on the right side of the screen. This is the preferred way to open the request. If you are using a separate account to create a support case (e.g. Microsoft Premier Support with different credentials that you have signed in to the Azure AD portal), you have to note few items to the support case opening post for quicker analysis. Copy next information to the ticket.
- Requiest Id, from Troubleshooting and support tab
- Date (UTC), from Troubleshooting and support tab
- Correlation Id , from Basic info tab
- Username, from Basic info tab
- Azure AD Directory name and Directory ID from Azure AD Properties pane
After gathering the information, open the case and try to solve the problem with Microsoft’s support together.
Summary and required permissions
As you can see, the conditional access troubleshooting is not a rocket science. Give Reports reader directory role to your first level support and teach them, how to solve basic conditional access problems or give the link to this blog post.
Find other Conditional access related blogs from Bloggerz.cloud
2 Comments
Hal · 07.01.2020 at 11.24
Hi this is really useful. When a device is both registered and Hybrid joined, is it OK to remove it from Azure AD by deleting, leaving just the hybrid device? It is not so easy to do this at the workstation. I know usually this would result in the device being blocked, but should be OK if the device is hybrid joined no?
Markus Lintuala · 23.01.2020 at 19.55
It depends a lot of your Windows client version. Under the official documentation there is clearly stated that you have to remove it manually from workstation if you have pre-1803 Windows OS. If you have 1803 or above OS with update KB4489894 installed, the removal should be automatic if you don’t have Intune managed devices. Either or.. at the end, if you have both registered and Hybrid joined devices in AAD, the correct way to remove it is from workstation side.