Eu tenho um site ASP.Net hospedado no IIS 10 no Windows Server 2019 DataCenter no Azure. Este site tem apenas a Autenticação do Windows habilitada.
Quando acesso o site diretamente ( http://mysite-backend.example.com ), sou solicitado a fornecer credenciais, após o que tudo funciona conforme o esperado. Quando acesso o site através do App Gateway (configurado com IP privado) ( https://mysite.example.com ), sou solicitado a fornecer credenciais, após o que sou novamente solicitado a solicitar recursos adicionais (hospedados no mesmo site, sem regras especiais para quaisquer subpastas). Sou solicitado repetidamente até clicar em Cancelar, momento em que vejo um 401 para a solicitação do recurso no registro de rede do Chrome.
Um dos recursos com os quais recebo esse problema é uma solicitação GET para arquivos favicon.png. Se eu acessar o recurso diretamente ( https://mysite.example.com/favicon.png ) tudo funciona, mas quando eu acessar a página do site fazendo com que uma requisição deste recurso seja enviada pelo navegador como parte dos recursos da página, Eu vejo o erro. Isso implica que o recurso é acessível; mas algo sobre como isso é tratado na "transação" está causando problemas.
Eu tentei com diferentes navegadores, inclusive com uma nova instalação / de um dispositivo cliente diferente, para garantir que não haja nada em cache causando problemas. Além disso, Disable Cacheverifiquei as configurações de rede F12 para garantir que estou fazendo solicitações completas/comparações justas entre os dois sites.
O pool de back-end tem apenas 1 nó. As configurações de back-end dizem para usar o nome de host do pool de back-end em vez do front-end - portanto, da perspectiva do servidor da Web, as solicitações são semelhantes.
No log de eventos de segurança do servidor da Web, vejo logons com falha (id do evento 4625) com meu nome de usuário de teste; confirmando que a solicitação está chegando ao servidor de back-end com o nome de usuário correto (e tenho sido muito cuidadoso para garantir que estou digitando a senha correta de forma consistente / fiz isso várias vezes para remover a chance de erro humano / tentei os dois usando e também substituindo a senha salva). Se eu tentar muitas vezes, minha conta de teste será bloqueada (ou seja, no AD, o lockedoutatributo é definido como true); após o qual todas as solicitações obtêm respostas 401 (compreensivelmente).
Verifiquei os logs do App Gateway para confirmar que não está bloqueando nada. Também configurei uma regra de WAF personalizada para este site e a configurei no detection onlymodo para garantir que não possa bloquear solicitações; apenas no caso de algo estar sendo bloqueado, mas não registrado.
Habilitei o rastreamento de solicitação com falha para o status 401 no servidor de back-end; que mostra o 401 como vindo de:
-MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName: IIS Web Core
Notification: AUTHENTICATE_REQUEST
HttpStatus: 401
HttpReason: Unauthorized
HttpSubStatus: 2
ErrorCode: Access is denied. (0x80070005)
ConfigExceptionInfo
Observação: os recursos bloqueados (ou seja, obtêm respostas 401) geralmente são consistentes quando estou testando no mesmo dispositivo em um determinado período de tempo; mas se eu testar em um dia diferente ou em um dispositivo diferente, posso ver recursos diferentes sendo bloqueados. Na primeira vez que testo em qualquer dispositivo (principalmente), vejo duas POSTsolicitações xhr para /subfolder###/Searchpáginas falharem e, depois de alguns testes nesse dispositivo, outros recursos parecem ser corrompidos. Parece que eles são a causa principal - mas algo causa um problema com a sessão.
Estou tentando obter acesso ao código-fonte do site de back-end para entender melhor o que esses endpoints de pesquisa codificaram neles para entender se isso pode estar causando o problema.
Enquanto isso, qualquer ideia que alguém aqui possa ter seria muito apreciada... Desde já, obrigado.
Atualização: chamar o endpoint de pesquisa diretamente também resulta em uma resposta HTTP 200/válida:
$resp = Invoke-RestMethod -Method Post -Uri 'https://mySite.example.com/subfolder###/Search' -Form @{recordsToTake=25;recordsToSkip=0;sortColumn='CategorieName';sortDirection='Ascending'} -Credential $cred -StatusCodeVariable sc;"Status $sc";$resp
NTLM ("Autenticação do Windows") não é suportado pelo App Gateway ( MS Docs ).
Parece que geralmente os proxies reversos não implementam suporte a NTLM devido a questões de segurança ( MS YARP NTML Discussion ).
Existem alguns proxies reversos alternativos que podem lidar com isso; por exemplo , nginx plus (a oferta nginx comercial).