I am having the most difficult time trying to understand why some of my iOS devices attempting to SSO into Native Mail receive an Access Denied error. I have IDM configured with the iOS SSO Policy at the top of my default policy configuration. I am federated with Okta which confirms with WorkspaceOne Access if my devices have the SSO certificate installed (device trust). I'm able to resolve some of the issue by rebooting the device and I've observed if users have cookies blocked in their Safari settings, this causes the Access Denied error. I have a call with support to review device and SSO logs, but I'm not hopeful. Is anyone else experiencing this?
Thanks. We currently use WS1 Access to provide mobile SSO for the Microsoft Outlook app on both iOS and Android. So there's some sort of Exchange hybrid already in place and Azure AD.
We are now migrating our mailboxes from on-premises Exchange to O365. For the mail client on both iOS and Android, we leverage SEG to proxy traffic to our Exchange environment. Since mailboxes will soon be hosted in the cloud, we don't see a need to re-route traffic back to the SEG anymore before allowing mail sync. So we are now exploring options to leverage WS1 Access in its place.
Based on what I've read from this thread, this seems possible regardless of which IDP you use such as Okta. However, I have a hard time locating the relevant docs to walk through the setup steps. Is it something you can help with?
We had VMware professional services as well for our WS1 Access implementation. I'm hoping to accomplish this other setup without the additional cost.
Does your guide cover setup for mobile devices (iOS and Android)?
SaaS hosted. Support has updated my support request with an error he found in the log:
As per the log analysis we see the below
default 15:45:22.557414-0500 com.apple.WebKit.Networking gss-krb5: credentials expired
It looks like the kerberos ticket is expired which could be due to multiple reasons like time sync between the node and device and others.
We are still looking into this further and will notify you as soon as I have further updates.
I believe I discovered the root cause. The device time was inaccurate. I've been instructing users to toggle time setting "Set Automatically" off/on then to attempt the SSO process again. I'm still testing this, but I believe this is the cause/resolution.