Users from primary domain are able to be authenticated without issue. Users from Domain B, which is in a different forest and is trusted via 2-way trust, can authenticate with the storefront without issue. However, when launching a resource the CWA eventually loads a small window indicating the the "username or password is incorrect" and will leave an unauthenticated session in "pre-logon" state on the VDA.

Findings:

• They have two forests with two way forest trust
• CAs, VDAs and FAS servers are in one forest and the users are in the other forest
• SSO is not working
• They have not done the configuration correctly
• The certs are getting issued as they have LDAP referrals correctly enabled but, they are not getting validated
• The user domain's domain controller was not able to build the chain of certs
• Checked and found that they have not made the root and the issuing CA certs trusted in the user's domain and have not put the issuing CA cert in the NTAuth container in the user domain
• On top of this, they do not have a valid domain controller certificate on the user domain DC
• We manually imported the root and intermediate CAs on one of the domain controllers and we were able to get past the username and password is incorrect error and got the request is not supported error as there is no valid DC cert
• We shared the certutil commands to push the certs in the configuration partition of active directory using the certs from each domain and told them to make these CAs trusted by using those certs in the other domain/forest

Commands:-

certutil -dspublish -f filename NTAuthCA
certutil -dspublish -f filename RootCA"
certutil -dspublish -f filename SubCA

The issue was that the Domain Controller for domain B did not have the correct type of certificate that allowed for Kerberos authentication. 

Once we replaced the wildcard certificate on that Domain Controller with one that allowed Kerberos - the issue was fully resolved.

Problem Cause

The issue was that the Domain Controller for domain B did not have the correct type of certificate that allowed for kerberos authentication. 

Once we replaced the wildcard certificate on that Domain Controller with one that allowed Kerberos - the issue was fully resolved.