Hi all
I try to explain the situation i'm facing as detailed as possible - but i'm using non real domain names:
Facts:
DomainA has an NPS and AzureMFA server (yes, the onpremises one) (we have a Connection Request Policy in place that matches against the UPN Suffix with regex to forward the request to DomainB NPS servers)
DomainA and DomainB has a Two-Way (not selective) Trust with each other.
DomainB also has an NPS server
DomainA contains the Citrix StoreFront Servers
DomainB contains the Citrix Worker Nodes (Terminal Servers)
Storefront can be accessed internaly (through a load balancer)
Storefront can be accessed externaly (throug an F5 - which is basically referring to the NPS of DomainA for pre authentication and MFA)
MFA Authentication works for DomainA and DomainB users as expected.
- So no issues with the configuration until this point.
Changes:
Now, we have a projekt in DomainB where we want to align the UPN (which is currently @DomainB.local) with the mail address (say @DomainB.tld)
Therefore the new UPN Suffix was added and enabled in the Forest and the Trust was updated
-> Login with the newly created UPN Suffix (@DomainB.tld) against the storefront internally with works as expected -> no NPS involved of course.
we also...
.. updated the Regex to match both UPN Suffixes from DomainB in the Connection Request Policy.
.. added the newly added UPN Suffix to the list of Trusted Domains in the Citrix configuration
Issue:
If we try to login from external through the F5, we can pass the MFA authentication enforced by the NPS/Radius environment.
But the Storefront tells us "something went wrong".
Observations:
We noticed, that the storefront reports an issue, that he cannot authenticate against DomainB.tld.
In the Kerberos logs we can see that the storefront does not find a suitable domain controller to contact DomainB.tld -> which of course is DNS related (as we see that the storefront server trys to resolve _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.domainb.tld SRV record.. but as this is not the real domain fqdn - as it's only an alternative upn suffix added to DomainB.local we don't have these SRV Records provided in the internal DNS -> and adding them will maybe solve the issue but this would increase DNS complexity by far more than we want (special lookup view policies only for the storefront servers etc.)
We can generate the same error if we want to login internaly with the following login schema: domainb.tld\samaccountname (which is also obviously failing as this is not the domain name but resulting in the same log entries written from the storefront).
Now I hope the issue was described clear and understandable - feel free to ask further details.
Question Time:
- I asume the NPS is returning the username in an arbitrary format like : domain.tld\username - is this correct?
- can this behaviour be changed - for example to return the UPN from AD as is?
- anyone an idea how to solve this issue?
- a) without creating a dedicated store for domainb
- b) without adding the SRV Records pointing to domainb.local
many thanks for your support