Problem:

When the Access Policies are configured incorrectly, authentication may fail for some or all users.  This can cause even your local accounts to be unable to login to the tenant to resolve the issue.

Solution:

To login to the tenant and bypass the configured Access Policies causing the authentication issue, append ?login to your default login URL:

https://<tenantURL>/SAAS/auth/login?login

Problem:

While adding or editing an Identity Provider and attempting to add or update an authentication method, you see the error “Cannot update Identity Provider”.  This prevents you from adding or editing authentication methods when you click save.

Solution:

The SAML context name must be unique in your Workspace ONE Access tenant, including names used by the default authentication methods.  Rename your SAML context name for the chosen authentication method and click save.

Problem:

When attempting to login to Workspace ONE Access, an error message is displayed with "404.idp.not.found", "federationArtifact.not.found Federation Artifact not found", or another error that indicates that an Identity Provider or Federation Artifact could not be found to authenticate the users .  This occurs when no Access Policies are setup to handle authenticating the network range, device type, user group, or attempted authentication methods or if the Claim Rules for the relying party are misconfigured.

Solution:

• In the access policy rules, create an access policy that includes the network range, device type, user group and authentication method you are attempting to login with.  Ensure these authentication methods are enabled and active for your Identity Providers and that they are applying to the network range and user group you are expecting.
• Ensure your Relying Party Trust claim rules were properly configured based on the examples provided. The claim values are case sensitive.  Also ensure you properly replaced your spnamequalifier in the custom claims rule with your Workspace ONE Access tenant.

Problem:

When users attempt to authenticate using claims-based authentication to AD FS, they see a login page that says "Error: Contact your administrator".  This occurs because AD FS cannot properly authenticate the claim.

Problem:

• Ensure you properly established trust between AD FS as the Identity Provider and Workspace ONE Access as the Service Provider.  Re-export the FederationMetadata.xml files or URLs and ensure you uploaded the correct metadata for each component.
• Ensure your Relying Party Trust claim rules were properly configured based on the examples provided. The claim values are case sensitive, and ensure you properly replaced your spnamequalifier in the custom claims rule with your Workspace ONE Access tenant.
• Ensure your authentication methods configured for the access policies applied to your domain users are correctly using the authentication methods setup for the AD FS Identity Provider.
• Ensure you are not attempting to authenticate local users from Workspace ONE Access that do not exist within your Active Directory.  Local users should be authenticated using the Password (Local Directory) authentication method, not authentication methods configured for AD FS since AD FS will fail to find these local user accounts in AD.

Problem:

When users attempt to authenticate using claims-based authentication to AD FS from Workspace ONE Access, they are being redirected to AD FS for their credentials appropriately but then receive an error that they could not be authenticated.  AD FS may be configured incorrectly, causing issues with consuming incoming claims, generating outgoing claims, or other issues that would cause authentication to fail.

Solution:

• After installing and configuring AD FS, Server Manager will contain an AD FS Dashboard from the left menu.  From here, an Events view is available which can be configured to log events of different severities (Informational, Warning, Error, or Critical) within a certain time period.  This view can be configured by clicking Tasks > Configure Event Data, which is next to the Events view from this AD FS Dashboard.
• Alternatively, you can use Event Viewer to view the AD FS logs as well.  From Event Viewer, you can find the logs by navigating to Applications and Services Logs > AD FS Tracing > Debug.  To begin receiving logs, you will need to right-click the Debug file and select Enable Log.  If you wish to stop tracking events this way, you can right click the Debug file and select Disable Log to return it to the original state.

Both solutions will allow you to see traces of your authentication attempts.  Failures and issues are typically noted with the severity levels of Error or Critical, so try inspecting your logs to see what is causing your authentication to fail.  Typical authenticate issues could be:

• The Third Party IDP configuration in Workspace ONE Access is not sending a Name ID Format that the Identity Provider (AD FS) is expecting to query a user from the Attribute Store with.
• The Third Party IDP and/or Access Policies in Workspace ONE Access are using Authentication Methods that the Identity Provider (AD FS) is not handling or cannot handle due to the authentication methods allowed for Intranet vs. Extranet.  These Intranet vs. Extranet authentication methods can be viewed in AD FS by going to AD FS Management > AD FS > Authentication Policies > Primary Authentication.  By default, Extranet authentication uses Forms authentication while Intranet uses Windows authentication, so if you are attempting to authenticate users in your Intranet by using Forms authentication, this will fail until you update the Primary Authentication settings to also allow Forms authentication for Intranet requests.
• The Relying Party Trust was misconfigured in AD FS.  If you imported the Service Provider Metadata from Workspace ONE Access, this shouldn't be an issue.
• The Relying Party Claim Rules were misconfigured.  The exact configuration issues would depend on what Claim Rule templates you utilized, but double check that you have access to the attributes you're expecting in the claim as well as your Attribute Store.  If you are using Custom Claim Rules, double check that your claim engine logic is correct and without syntax issues and that it is returning an outgoing claim that your Service Provider is expecting.  Service Providers will require different configurations, so it's best to find documentation for that service (ie: Workspace ONE Access, Okta, Ping) and see what they are expecting in their claims from AD FS to properly authenticate users.