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://meusite-backend.example.com) São solicitadas credenciais, após o que tudo funciona conforme o esperado. Quando acesso o site pelo App Gateway (configurado com IP privado) (https://meusite.exemplo.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 favicon.png. Se eu acessar o recurso diretamente (https://meusite.example.com/favicon.png) tudo funciona, mas quando acesso a página do site fazendo com que uma solicitação desse recurso seja enviada pelo navegador como parte dos recursos da página, vejo o erro. Isto implica que o recurso é acessível; mas algo sobre como isso é tratado na "transação" está causando problemas.
Tentei com navegadores diferentes, inclusive com uma nova instalação/de um dispositivo cliente diferente, para garantir que não haja nada em cache que esteja causando problemas. Além disso, verifiquei Disable Cacheas configurações da rede F12 para garantir que estou fazendo solicitações completas/comparações justas entre os dois sites.
O pool de back-end possui 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 web, as solicitações parecem semelhantes.
No log de eventos de segurança do servidor web, vejo logons com falha (event id 4625) com meu nome de usuário de teste; confirmando que a solicitação está chegando ao servidor back-end com o nome de usuário correto (e tomei muito cuidado para garantir que estou inserindo consistentemente a senha correta / fiz isso várias vezes para remover a chance de erro humano / tentei ambos 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 está definido como true); após o qual todas as solicitações obtêm 401 respostas (compreensivelmente).
Verifiquei os logs do App Gateway para confirmar se não está bloqueando nada. Também configurei uma regra WAF personalizada para este site e a configurei no detection onlymodo para garantir que ele não possa bloquear solicitações; apenas no caso de algo estar bloqueado, mas não registrado.
Ativei o rastreamento de solicitação com falha para o status 401 no servidor 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
Nota: Os recursos que são bloqueados (ou seja, obtêm respostas 401) geralmente são consistentes quando estou testando no mesmo dispositivo dentro de um determinado período de tempo; mas se eu testar em um dia diferente ou em um dispositivo diferente, poderei ver recursos diferentes sendo bloqueados. A 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 estar contaminados. Parece que eles são a causa principal - mas algo causa um problema na sessão.
Estou tentando obter acesso ao código-fonte do site de back-end para entender melhor o que esses pontos de extremidade de pesquisa codificaram neles e entender se isso pode estar causando o problema.
Enquanto isso, qualquer idéia que alguém aqui possa ter seria muito apreciada... Agradecemos antecipadamente.
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
Responder1
NTLM ("Autenticação do Windows") não é compatível com o App Gateway (Documentos MS).
Parece que geralmente os proxies reversos não implementam suporte NTLM devido a questões de segurança (MS YARP NTML Discussão).
Existem alguns proxies reversos alternativos que podem lidar com isso; por exemplonginx mais(a oferta comercial do nginx).