0

I have configured the registry values mentioned everywhere in various guides for the AuthServerAllowlist and AuthNegotiateDelegateAllowlist to allow Windows auth to work seamless with an internal website.

There is an AD login button which used to then prompt for the credentials and worked if you entered them, but now we can simply click the button and the user is signed in. Great.

This works great for users in both the domain where the website is hosted and also a domain in another forest, with NTLM auth.

Someone has now implemented a policy on the network to disable NTLM auth which is understandable, so users were again prompted with a login box which did not work when they entered them.

We had to add the SPN for the website name in and this restored access but only for those on the same domain that is hosting the website. Users from the other forest still cannot sign in.

If I manually run a KLIST GET and append the target realm onto the end I can retrieve a ticket and sign into the wesbite, but if I purge the tickets and let the browser handle this, it never retrieves a ticket.

We had this same issue with a desktop app and there was a Kerberos Realm box we were able to fill in with the target realm which fixed the issue, but for browser based I cannot seem to figure out a workaround for this.

Any ideas would be appreciated. Thanks!

EDIT - This is only a problem where there is a 1 way outbound trust from the domain hosting the site.

0 Answers0