![]() ![]() So root cause investigation on that is still on going with Jamf and Microsoft.Įxamples: info 11:43:07.723875 -0500 JamfAAD TID=6332128 MSAL 1.1.2 Mac 10.15.7 Silent flow finished. Being more rare ~15% or less of the cases it has been hard to get logs (where we have known good then the token disappearing they all start well after that point so far). Note: MSAL will not jettison a token after that failed auth. That is more concerning as there is not a reason for that. ![]() We have seen some cases where the token is missing. Result (null), error: -1009 error domain: NSURLErrorDomainįault 07:51:39.153078 -0400 JamfAAD The Internet connection appears to be offline. Also, as we found some end user clients that are work from home on high latency networks (satellite internet) seem more affected.Įxamples: info 20:09:02.570714 -0400 JamfAAD TID=3027791 MSAL 1.1.2 Mac 10.15.7 Silent flow finished. The new WebKit based authentication must just be more temperamental than the previous style in old MSAL and ADAL. The catch being that now with the new ASWebAuthenticationSession that has to be launched (the prompt that macOS is giving to redirect to Microsoft for login) and is very in the users face.įrom the several dozen sets of logs from devices I have looked at ~85% of the time it is down to a network failure. When the MSAL silent token authentication in the background fails jamfAAD is taking that MSAL exit error and falling back to an interactive authentication the same as it would for a missing token or expired session before. The large majority are NSURL error of network failures ranging from timeout to DNS name resolution. We have been working with Microsoft's MSAL team on these errors we are seeing. Info 20:09:02.654443 -0400 JamfAAD TID=3027778 MSAL 1.1.2 Mac 10.15.7 Beginning interactive, , and if you have examples that you can pull a full sudo sysdiagnose -f ~/Desktop archive from if you want to open a Support case and upload the logs with a rough time (to speed up Console filtering) of when the prompt came up they could be helpful in the investigation.Īn update for anyone following this thread. Result (null), error: -1200 error domain: NSURLErrorDomain Info 18:08:57.394824 -0400 JamfAAD Sending AAD ID to jamf daemonĪ bad auth. Result (not-null), error: 0 error domain: (null)ĭefault 18:08:57.394774 -0400 JamfAAD AAD ID acquired for macOS user account bob.lutz In a number of logs I have been looking over we can see examples of this.Ī good auth. that MSAL does on daily checks (that the jamfAAD Launch Agent does ( more on that here)) fail to stay silent when it should be. What I am working to determine is why for some macOS clients does the silent token auth. In all other scenarios (EX: Monday the 4th to Tuesday the 4th where the Mac was on and the user used it both days and did not change their password and the session was not expired) it should not prompt. The pop ups ARE expected in the case of say a new registration where a token does not already exist for authentication, and they would be expected in the case of a password change or session expiration (Global default from AAD is 14 days out of box but can be changed). On Jamf Pro v10.21 - v10.23 MSAL v1.0.7 was in use and it did not require the ASWebAuthenticationSession to be launched (the prompt that macOS is giving to redirect to Microsoft for login). In Jamf Pro v10.24 and up the library was updated to v1.1.2. That is a separate set of Enterprise Apps that do the server side (Graph API) and client side (Authenticator app) call is correct that the reason this is taking place is due to the change in the MSAL library that is used for authentication. ![]() It does not have anything to do with iOS Device Compliance.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |