Perguntas[iis](server)

Nosso objetivo é hospedar um site ASP.NET Core 9.0 no IIS e usar o certificado de cliente para autenticação . O aplicativo web ASP.NET Core está funcionando bem: ao executar diretamente do Kestrel, tudo funciona conforme o esperado, ou seja, o usuário é solicitado a escolher um certificado válido que será usado para autenticá-lo.

O documento diz que a configuração do IIS é limitada a 3 etapas:

1. Selecione o site nas guias de conexões
2. Clique duas vezes na opção Configurações SSL
3. clique na caixa de seleção exigir ssl e selecione o botão de opção exigir na seção de certificados do cliente

Infelizmente, não funciona. Ativamos o Failed Requests Tracing e, com essa configuração, o ASP.NET Core Module sempre encerrará a solicitação com o erro request is not supported:

Observe que o usuário final sempre verá uma página de erro 500 e nem terá a chance de escolher o certificado que será usado para autenticação.

Então, para simplificar as coisas, decidimos remover o aplicativo principal do aspnet da equação e ter um site simples, com uma única página index.html, e ver se pelo menos podemos configurá-lo para que o navegador permita que o usuário escolha um certificado.

Ativamos apenas a vinculação https no site:

E também alterei as configurações SSL padrão:

Também ativamos o Failed request tracing para obter mais informações sobre o que está acontecendo. Esta configuração inicial terminou com o tradicional erro 500:

E aqui está a saída do arquivo de rastreamento de solicitação com falha:

Depois de mais algumas escavações, também encontramos este post . Mais uma vez, atualizamos nosso web.config para que ficasse assim (tivemos que desbloquear as subseções de autenticação no nível raiz):

<security>
  <authentication>
    <anonymousAuthentication enabled="false" />
    <iisClientCertificateMappingAuthentication enabled="true" />
  </authentication>
</security>

Os resultados ainda são os mesmos. Então, fomos em frente e adicionamos um mapeamento de um certificado para um usuário existente (usamos o gerenciador do IIS para fazer as coisas direito):

<security>
    <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="false" />
        <iisClientCertificateMappingAuthentication enabled="true">
            <oneToOneMappings>
                <add userName="XXX" 
                     password="[enc:IISCngProvider:wX....]" 
                     certificate="MIIFTDCCBDSgAwIBAgITdQAAEJsn8Q3PLgZ4iwAAAAAQm..." />
            </oneToOneMappings>
        </iisClientCertificateMappingAuthentication>
    </authentication>
</security>

Mais uma vez, ainda não funciona (ou seja, o usuário nunca tem uma mudança para escolher um certificado). Depois de mais algumas pesquisas, encontramos algumas postagens que dizem que o Windows Auth deve ser habilitado para que funcione. Então, nós o ativamos:

<windowsAuthentication enabled="true" />

Mas não, ainda não está funcionando. Carregar a página nunca me dá a chance de escolher um certificado.

Então, alguém pode me indicar um documento válido que mostre como configurar o IIS para exigir que o cliente apresente um certificado ao navegar em um site?

No Windows Server que estou olhando, o IIS executa o serviço de publicação WWW, e ele é protegido por firewall para permitir apenas as portas 80 e 443 para esse serviço. Conexões de navegadores de clientes expiram, e quando olho no log de eventos de segurança no servidor, vejo eventos registrados como este:

The Windows Filtering Platform has blocked a connection.

Application Information:
    Process ID:     4
    Application Name:   System

Network Information:
    Direction:      Inbound
    Source Address:     192.168.10.21 <= This is this server where the event is logged
    Source Port:        80 <= This is the IIS WWW publishing service listening port
    Destination Address:    192.168.10.3 <= This is the client PC where the browser requests the URL on the IIS
    Destination Port:       60112
    Protocol:       6

Filter Information:
    Filter Run-Time ID: 86327
    Layer Name:     Receive/Accept
    Layer Run-Time ID:  44

Se a conexão for de entrada, como dito acima, a origem deve ser 192.168.10.3, a porta de origem deve ser qualquer porta alta aleatória que o navegador usa, o destino deve ser 192.168.10.21 e a porta de destino deve ser 80, mas é o contrário.

Não entendendo por que os campos de eventos estão de cabeça para baixo, não consigo imaginar uma maneira de permitir essa conexão.

Se essa não for realmente a solicitação original, mas a resposta do IIS à solicitação que foi permitida, então por que ela está sendo bloqueada? Não há regras de bloqueio no firewall, e a única regra que pertence a conexões HTTP(s) é a regra Allow inbound para o serviço WWW do IIS.

Eu configurei vários servidores Apache e suas respectivas regras da maneira que descrevi acima, e nunca tive problemas. Se o IIS precisa de uma abordagem diferente, então por que e como? É um requisito do fornecedor que o site rode no IIS, então não tenho liberdade a esse respeito.

EDITAR:

Se eu modificar a regra para aplicar a quaisquer programas ou serviços, então a conexão funciona. Se eu restringi-la para aplicar somente a serviços, ela ainda funciona. E somente quando eu seleciono especificamente o Worldwide Web Publishing Service como seu alvo, então ele para de permitir a conexão. A partir disso, fica claro que há algum problema entre o Firewall do Windows e o IIS, mas o que é?

A configuração é a seguinte:

Windows Server 2022 Standard com IIS 10.

Aplicativo baseado em ASP .NET 4.8, executado com Integrated modee Application Pool Identity.

Estou tentando remover os seguintes cabeçalhos:

Server, X-Powered-By, X-ASPNet-Version, X-ASPNetMVC-Version.

Não importa o que seja feito, os cabeçalhos permanecem.

Coisas tentadas:

1. Remover no nível do servidor do RESPONSE HEADERScabeçalho X-Powered-By- sem efeito, ainda aparece no conteúdo dinâmico.

2. Defina enableVersionHeader no arquivo de configuração applicationhost.config do servidor e no arquivo de configuração do aplicativo sem efeito:

<configuration>
  <system.web>
    <httpRuntime enableVersionHeader="false" />
  </system.web>
</configuration>

3. Definido no nível do servidor sem efeito:

<configuration>
  <system.webServer>
    <security>
      <requestFiltering removeServerHeader="true" />
    </security>
  </system.webServer>
</configuration>

4. Defina o valor de registro DWORD DisableServerHeader como 1 e reinicie o IIS sem efeito: HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters!DisableServerHeader

5. Tentei modificar Global.asaxpara remover o cabeçalho ASPNetMVC, mas isso quebrou o aplicativo.

Confirmei que as alterações no nível do servidor vão para o nível do site. Tentei configurar manualmente também no web.config no site. Mesmo efeito (nenhum).

O URL Scan não está mais disponível, então não é uma opção. A última opção parece ser usar o URL Rewrite, mas eu preferiria não usá-lo se possível, já que supostamente há soluções nativas para isso.

O que estou fazendo errado e há algo que não estou entendendo?

Então, estou pensando em hospedar dois sites em servidores separados. Por exemplo: site de produção no servidor IIS: 192.168.0.1 e SpecialApps IIS: 192.168.0.2, que também é o servidor de teste atual que eventualmente entrará em produção.

Atualmente, após inúmeras horas de pesquisa, foi sugerido que eu instalasse o Application Request Routing (ARR), o que eu fiz no servidor .2

meu objetivo é poder ir para https://test.mycompany.com.au para ir para .2 e https://test.mycompany.com.au/prod para ir para .1

quando o usuário acessa https://test.mycompany.com.au/prod , precisa redirecionar para https://mycompany.com.au , que é a URL de produção hospedada em .1

Está com problemas para tentar fazer o padrão de código de reescrita de URL funcionar

Isso é mesmo viável?

Existe uma maneira de fazer solicitações de despejo do IIS para seus arquivos de log o mais rápido possível?

Contexto

Estou enfrentando um atraso muito longo entre uma solicitação que faço ao IIS ser atendida e ser realmente registrada nos logs do IIS. Isso pode variar entre 20 e 60 segundos de atraso.

Alguns pontos-chave:

• Assim que a solicitação aparecer no arquivo de log, ele mostrará a hora real em que a solicitação ocorreu,
• os relatórios de solicitação são processados ​​em até 350 ms,
• nos logs de solicitação do IIS, as solicitações também não ficam "travadas"
• a solicitação é totalmente tratada no navegador rapidamente
• Pude notar que em uma produção, pouco ocupada ou nada, o Windows Server 2012 (IIS 6.2 build 9200)
• mesmo comportamento em meu host de desenvolvimento, nem um pouco ocupado , Windows 10 (IIS 10.0.19041.1)
• a produção está no armazenamento da Amazon (não sei dizer a tecnologia exata que eles usam, acredito que seja derivada do SSD)
• o armazenamento local é um disco SSD
• se eu monitorar arquivos no mesmo disco/sistema de arquivos, as atualizações dos arquivos serão refletidas instantaneamente na tela (no máximo, se houver, atraso de 1s)

Algumas coisas que eu tentei

Tentei tail -fou continuo repetindo tailo comando e também o Notepad ++ com o modo "Visualizar> Monitoramento (tail -f)" . Todos atualizando o conteúdo do arquivo ao mesmo tempo, obedecendo ao atraso um tanto aleatório, mas sempre longo.

A partir de uma cópia desta pergunta que postei (fora do tópico) em StackOverflow , Xudong Peng sugeriu que eu tentasse uma configuração flushByEntryCountW3CLog do arquivo de configuração de todo o servidor IIS ( %WinDir%\System32\Inetsrv\Config\applicationHost.configou nó de nível superior do Gerenciador IIS (computador) > Editor de configuração > sites.applicationHost/sites/siteDefaults/logFile). Isso fez com que o intervalo de registro mudasse, mas para pior. Senti que agora estava sendo descartado a cada minuto, então reverti para 0.

No tópico acima, também garanti que o específico <site>que estava testando não substituísse o sitesDefault/logFile/flushByEntryCountW3CLogin applicationHost.config. Também reciclei o pool de aplicativos (portanto, os sites também foram reciclados) e a configuração certamente entraria em vigor. Continua a mesma mudança de “comportamento” que parecia pior.

Parece que, mesmo que o buffer (dessas configurações, 64k) não seja preenchido, ele é despejado a cada minuto. Ao definir 1isso, senti que o despejo aconteceu entre 1 e 2 minutos.

Não consegui encontrar nenhuma outra configuração relacionada ao "buffer do arquivo de log" (para que o IIS preenchesse um buffer de entradas de log antes de "despejá-las" nos arquivos).

Conclusão

Isso é normal? Todo mundo que lida com logs do IIS precisa reservar um tempo para verificar as solicitações nos logs, ou talvez haja uma maneira de (pelo menos temporariamente) fazer solicitações de despejo do IIS para o arquivo de log o mais rápido possível?

Configurei um servidor FTP do Windows usando IIS. As regras de porta do firewall foram configuradas e habilitadas automaticamente durante a instalação do FTP, permitindo o tráfego FTP nas portas 21, 1024-65535 e 990.

Quando tento conectar-me a partir do servidor em que o servidor FTP está sendo executado, consigo conectar-me com êxito e sem problemas. No entanto, quando tento conectar-me ao servidor FTP a partir de um computador na rede, a conexão atinge o tempo limite. Se eu desabilitar o firewall, poderei conectar-me com sucesso.

Estou testando a conexão FTP usando o PowerShell.

Qualquer ajuda será apreciada. Obrigado.

Quando executo manualmente a consulta diretamente no SSMS, ela é executada com êxito (em 10 a 20 segundos). Quando a consulta é iniciada por meio do aplicativo Web .NET/IIS, ela trava praticamente indefinidamente e acaba bloqueando outras consultas. Acabei matando depois de esperar 20 minutos.

Quais são os fatores que fariam com que uma consulta fosse interrompida quando aplicada por meio do aplicativo .NET/IIS?

Ele contém algumas junções de tabelas grandes, mas, novamente, funciona muito bem no SSMS, então eu esperaria quase ao mesmo tempo no aplicativo da web .NET. Alguma ideia?

Obrigado!

Ao acessar o site externamente nos é servido um certificado SSL que foi removido anteriormente (meses atrás) por ter expirado e um novo certificado emitido. Não consigo encontrar nenhuma referência ao certificado antigo em lugar nenhum. Ao executar, netsh http show sslcerto certificado antigo não aparece na saída, enquanto o certificado reemitido está. Ao acessar o site no servidor, o certificado esperado é servido corretamente.

Este é um padrão do Windows Server 2019 e IIS 10. O servidor é anterior a mim, então não estive envolvido na configuração. Provavelmente foi criado a partir de uma imagem de um servidor existente enquanto era movido de uma empresa de hospedagem para outra.

Temos um aplicativo da web .aspx de formulários da web herdado instalado em "Site padrão". É possível ativar https: apenas para este aplicativo da web? dado que existem outros aplicativos da web implantados em "Site padrão"

Todas as instruções que encontrei on-line insistem na criação de uma ligação https: no IIS na porta: 443

O desafio é: quero saber se existe alguma outra maneira possível de habilitar https: apenas para aquele aplicativo da web sem impactar os outros aplicativos?

Um dos meus serviços de descanso ficou offline em um servidor mais antigo (iis 7). E embora eu precise mover isso para um servidor atualizado; Preciso colocá-lo online novamente, pelo menos por um curto prazo.

Estou conversando com o carteiro para verificar a resposta, mas estou recebendo um erro de servidor 500 em troca.

Infelizmente, não parece que FailedReqLogFiles seja atualizado para serviços de descanso; pelo menos nada está aparecendo lá.

No arquivo de log iis do site, tenho o seguinte:

16/05/2024 13:32:41 10.1.1.101 GET /api/GetInfo - 443 checkuser 10.1.1.202 PostManRuntime/7.37.3 500 0 0 15312

Eu entendo a maior parte da linha, exceto os últimos 3 números.

500 é o erro, mas quanto é 0 0 15312?