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

Question

Question

windows authentication is not available

Forms Directory Server Version 11
Updated July 10, 2024
asked on June 21, 2024

Hi everyone,

A customer is having an issue that prevents them from using LFDS to log into Forms using their Windows credentials. Has anyone seen this before? I found an instance from March 30, 2020 but my scenario is using a single STS site, situated on on the LFDS server. For the record, I have Repo and Web Client on their own servers within the same domain.

Clicking on the Windows Auth button just generates an error to remind me there's a problem. 

   

0 0

Replies

replied on June 23, 2024

Hi Ben,

Could you directly contact the support team for more help? This sounds like a configuration error, so our support team can help you figure it out.

1 0
View 5 previous replies
replied on June 24, 2024

The first thing I'd check is whether this STS instance was configured to use the "Alternate Service" even though it's on the same machine as LFDS (where it's unnecessary). STS does not support WinAuth in the Alternate Service configuration.

0 0
replied on June 24, 2024 • Show version history

Hi Zhiyong: Yep, good idea.

Hi Samuel: I considered that but when I configure the "Alternate Service" the "Windows Auth" button isn't visible. Also, Windows Auth gets disabled in lfdssts/configuration

1 0
replied on June 24, 2024

Okay, I didn't think the Win Auth option showed up in the UI when the Alternate Service was enabled but figured it was worth checking. Definitely file a support case.

1 0
replied on June 25, 2024

You can also check IIS and ensure Windows Authentication is enabled under the site. 

1 0
replied on June 26, 2024 • Show version history

The Authentication was set to Windows. After chatting with support, I've requested an updated certificate because the SAN of the cert didn't list both FQDNs of the A-Record and CName of the server.  The SAN isn't wrong it's just incomplete.

2 0
replied on July 8, 2024

So I have a resolution but only partial answer so far.

Putting the FQDNs of the a-record and CNAME in the SAN didn't resolve the issue. 

Setting up the LFDS and LFDSSTS endpoints to use the FQDN of the a-record and not the CNAME did work and fixed the problem... but I still don't know why using the FQDN of the CNAME didn't work.

0 0
replied on July 8, 2024

Almost certainly a Kerberos issue that resulted in a blocking failure due to NTLM being disabled so it couldn't be a fallback.

A DNS CNAME alone does not set the necessary Kerberos SPNs for Win Auth to work with an alias. Try removing the CNAME record and then setting a Computer Name Alias instead, which will handle both the DNS and Kerberos side of things.

1 0
replied on July 10, 2024

Thanks. I'll report back once I've had a chance to test this. 

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

Sign in to reply to this post.

Details
Related Posts
Loading ...