ThamaraiK.06888 (Customer) asked a question.
When using Agentless DSSO with standard domain, end-users land on the custom domain after authentication with 404 error
We have a custom domain configured in the Preview environment. I am trying to enable Agentless desktop SSO, but the custom name(Ex: https://customdomain.com/logn/agentslessDsso) is name appearing on the configuration page instead of standard domain name. I have completed all the SPN registration and other required steps for agentless desktop SSO, but the error message I am seeing as Page not found with custom domain name. Can someone please guide if we need to update any Okta settings to use standard domain for desktop less SSO?
Hi, @ThamaraiK.06888 (Customer)
Thank you for posting on our Community page!
I have done some research and found this article that might help with configuring your use case:
https://support.okta.com/help/s/article/When-using-DSSO-with-custom-domain-end-users-land-on-the-default-domain-after-authentication?language=en_US
Hope this helps!
Thank you for reaching out to our Community and have a great day!
_____________________________________________________________________________
The Okta Community Catalysts Program is now live. Collect online badges when you participate in the Okta Help Center Questions community. Learn more here.
_____________________________________________________________________________
Hi, Thank you for your reply. I have gone through this article already and this is applicable for Desktop agent based SSO(i.e IWA). I have verified the web config and its configured with the default domain. Here, I am seeing this issue on agentless desktop SSO.
My issue here is, the user will go to https://**.oktapreview.com and they will land on https://oktapreview.customdomain.com and get Page not found error.
Hello, @ThamaraiK.06888 (Customer)
My name is Norbert and I am a Technical Engineer working for Okta. I am happy to provide assistance in regards to this issue!
Generally speaking, when an HTTP 404 error code is returned, the browser or application you are trying to use, attempted to connect to a resource on a server that could not be found. I couldn't notice that the link provided contains a typo, which could explain the issue in the context of testing ADSSO.( https://customdomain.com/logn/agentslessDsso )
I had the chance to replicate the behavior presented with a tenant that had a custom domain associated with it. Also, I was able to collect some information from an environment that uses ADSSO without involving a custom domain. I would like to highlight the following information:
When a custom domain is associated with your Okta tenant:
Okta will automatically associate the custom login during the configuration process of ADSSO.
However, this should not influence authentication from the default endpoint. When reproducing this matter, I am redirected to HTTP/ostrichmedia.kerberos.okta.com , nevertheless from which domain I have tried accessing the tenant. After ADSSO verification is successful, I am redirected to https:// https://login.ostrichmedia.eu/login/agentlessDsso.
When a custom domain is no associated with the tenant:
Okta uses the default domain for ADSSO.
Given the information mentioned above, I would suggest verifying that your SPN is set correctly. In this regards, we have to consider the following:
Where HTTP/<myorg>.kerberos.okta.com is the SPN. <ServiceAccountName> is the value you used when configuring the Early Access version of Agentless DSSO and <oktaorg> is your Okta org (either oktapreview, okta-emea or okta). For example,
setspn -S HTTP/atko.kerberos.oktapreview.com atkospnadmin
Also, please confirm the username and password are correct for the SPN account, both in AD and as stored in the Okta configuration.
This is a transcript from this public facing documentation and it is part of this integration whitepaper.
If all of the above are verified and determined to be correct and still receiving errors, then this would point to a kerberos ticket validation issue. I can see that you have already engaged Okta support on a ticket and provided a trace for analysis. We are always eager to contribute to your success, but for the purpose having a centralized lead in regards to this issue, we will continue troubleshooting on the support ticket dedicated for this issue.
Thank you!