You are viewing limited content. For full access, please sign in.

Question

Question

AD users accessing Forms via external URL

asked on April 5, 2019

Hi,
 

I'm looking to see if something should, or shouldn't be possible in relation to internal AD users being able to access Forms using SSO.
 

The scenario is that we (or the customer) has a Forms server that is accessible for both internal users and external participant users and is accessed via an external URL (i.e. https://cloudserver.com/forms). All of the URLs within the Forms config and LFDSSTS use this external URL.

If an internal AD user navigates to this site, they are challenged to login using a username/password or using the blue "Windows Authentication" button. If they click the blue button they are challenged to enter credentials again but these are not accepted, despite being correct (the prompt appears endlessly). If they then cancel that and enter their AD credentials in the form of DOMAIN\Username along with their password, they are able to access Forms as their AD user.

So the question is whether this should work at all, or is it the case that internal users must always enter their credentials in this way. I suspect that the browser is unable to pass through the credentials when using an external URL. Incidentally, the same behaviour is observed if we switch to an internal server name.  The same behaviour is observed when accessing the external URL from the same server, or via a remote web browser where the user is logged in using a valid AD account.

Thanks,

Nigel.

0 0

Replies

replied on April 5, 2019

Which browsers have you tested? This could be a configuration issue. We have two instances of Forms, one internal and one external.

For the internal site, the STS page is configured to auto-login with Windows credentials so the users do not have to click/enter anything.

For external, we don't have the Windows button at all and users with Windows credentials enter their credentials with domain\username.

Usually, if you see the browser prompt for credentials outside of the page's login fields, it means it it does not have access to the local user's identity.

 

We recently had an issue where a policy change broke internal authentication and adding a policy to make forms a trusted site with the right authentication settings resolved it.

In IE for example, under Internet Options > Security > Trusted Sites, when you click Custom level, scroll all the way to the bottom and look at the User Authentication settings.

Chrome has similar settings and (for the most part) uses what is configured in IE.

1 0
replied on May 14, 2019 Show version history

The browser needs to send some domain along with the username, and if one isn't specified the domain from the url is a reasonable default.  It has no reason to think that the client domain would work, and that would be considered a privacy leak if it sent that unnecessarily.  I doubt there's a way to change the default that it uses.  Is there a reason you can't set up a dns entry so that users can access the site via a url that matches the domain?  I would think that would work, though you would need to add a matching ssl cert.

1 0
replied on April 5, 2019

Chrome and IE/Edge so far, I did try adding the external URL to the local intranet zone but not changed the user authentication settings yet. Will try that and see how it goes...

0 0
replied on April 23, 2019

Hi Nigel,

I have a client that is facing the same issue. Were you able to get this resolved?

 

Thanks,

Molly

0 0
replied on May 14, 2019

Sorry for the late reply but no, the users accept that they have to login this way, as they do for other web apps they use so it's not a big deal for them thankfully.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.