O problema é muito pouco documentado ( uma postagem no blog da Technet e alguma documentação para AD do Azure ), mas na verdade existe, e é causado pelo fato de o ADFS não se comportar corretamente em determinadas situações específicas (vários domínios federados de nível superior e ao lançar domínios filhos federados na mistura); A solução envolve a edição de uma expressão regular em uma regra de declaração do ADFS que é usada para criar o IssuerUri associado ao UPN do usuário. Citando o segundo artigo:
So lets say for example that I have bmcontoso.com and then add
corp.bmcontoso.com. This means that the IssuerUri for a user from
corp.bmcontoso.com will need to be http://bmcontoso.com/adfs/services/trust.
However the standard rule implemented above for Azure AD, will generate a
token with an issuer as http://corp.bmcontoso.com/adfs/services/trust
which will not match the domain's required value and authentication will fail.
Para resolver o problema, a terceira regra de declaração no ADFS deve ser editada, indo de
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)","http://${domain}/adfs/services/trust/"));
para
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*[.].*)$", "http://${domain}/adfs/services/trust/"));
No entanto, lembre-se de que isso pode quebrar a compatibilidade com outros cenários, como um domínio federado de terceiro nível real cujo domínio pai não está federado.