Mi1anovic's questions

Alguém pode me explicar por que não consigo acessar minha partição de disco e ver o tamanho usado e livre do disco no explorer como administrador? Talvez eu não entenda corretamente como as permissões do sistema NTFS funcionam.

Aqui está a minha situação:

• Tenho o Windows Server 2022 com um disco de dados conectado.
• O disco de dados tem partição NTFS com letra F:
• Sou um usuário de domínio adicionado ao servidor como membro do grupo local "Administradores".
• Estou me conectando ao servidor usando RDP no contexto de usuário do domínio.
• Quando abro o explorer.exe, vejo a partição do disco, mas não consigo ver o tamanho livre e utilizado.
• Quando tento acessar o disco usando o Explorer, recebo o erro: "F:\ não está acessível. Acesso negado".
• Quando tento acessar o disco usando o explorer executando como administrador, recebo o erro: "F:\ não está acessível. Acesso negado"
• O proprietário da partição do disco é 'SYSTEM'
• As permissões da partição do disco contêm o grupo local 'administradores'

Quando adiciono o grupo de usuários local 'Usuários' com permissões: "Ler e Executar, Listar conteúdo de pastas, Ler" na partição do disco, tudo está funcionando. Posso ver o tamanho livre e usado, posso acessar as pastas e arquivos.

Por quê? Por que não consigo fazer essas coisas sem o grupo 'Usuários' quando estou de fato no grupo Administrador local?

Tenho uma situação muito interessante que não consigo explicar. Tenho dois usuários em dois dispositivos. Ambos os usuários e dispositivos estão configurados da mesma forma. Eu literalmente verifiquei tudo e ambos os usuários e dispositivos são os mesmos no escopo da configuração e dos logs.

No entanto, o primeiro usuário (usando o mesmo navegador que o segundo) é solicitado a usar o método WHFB no modo anônimo como uma opção para passar a validação do MS Entra ID MFA ao fazer login em "office.com". O segundo usuário não tem essa opção (ele deve usar as opções regulares do MS Entra ID MFA).

A Microsoft está me dizendo aqui: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/faq que o WHFB não pode ser usado no modo anônimo. Bem, pela minha experiência, pode e eu me pergunto o que diabos está acontecendo aqui.

Aqui estão as opções para passar o MS Entra ID MFA no modo anônimo com métodos WHFB que foram definidos no primeiro dispositivo:

Estamos usando o Cloud Kerberos Trust em dispositivos híbridos unidos. Tudo está configurado corretamente. Cada log, resultado e depuração estão ok.

Descobri que o segundo usuário pode ser logado com WHFB no modo anônimo de um navegador quando escolho a opção "Sign-in options" no portal "login.microsoftonline.com" em vez de digitar o UPN do usuário. Quando eu digito UPN, vou para o nosso ADFS e então tenho que usar o MS Entra ID MFA (WHFB não é uma opção neste caso). Então, não sei por que o primeiro usuário é solicitado para WHFB após passar pelo ADFS e o segundo usuário não é solicitado para WHFB ao passar pelo ADFS. O que é mais importante é o fato de que o WHFB pode ser usado no modo anônimo de um navegador no nosso caso. Não sei sobre o que a MS está falando no link de perguntas frequentes sobre WHFB que postei aqui.

Eu tenho um problema com meu sistema operacional. O utilitário ping está me retornando um endereço IP errado quando tento executar ping no servidor de nome de host local.

No meu servidor tenho 3 interfaces: Ethernet0, Ethernet1, Ethernet2

A interface principal com IP estático preferencial é Ethernet0. Ele também possui a métrica mais baixa na tabela de rotas do SO e também é o único que possui um gateway atribuído. Com Ethernet0 estou conectado a uma rede de domínio 'example.local'. Tenho servidores DNS configurados estaticamente nesta interface de rede.

O resto das interfaces (Ethernet1 e Ethernet2) não possuem gateway, mas possuem IP estático atribuído.

Agora vamos ao problema. Quando executo o nslookup recebo esta resposta:

PS C:\Users\Administrator> nslookup server01.example.local
Server:  dc01.example.local
Address:  100.72.10.133
Name:    server01.example.local
Address:  100.72.10.137

mas quando executo o ping recebo esta resposta:

PS C:\Users\Administrator> ping server01.example.local

Pinging server01.example.local [100.76.26.142] with 32 bytes of data:
Reply from 100.76.26.142: bytes=32 time<1ms TTL=128
Reply from 100.76.26.142: bytes=32 time<1ms TTL=128
Reply from 100.76.26.142: bytes=32 time<1ms TTL=128
Reply from 100.76.26.142: bytes=32 time<1ms TTL=128

Ping statistics for 100.76.26.142:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

O IP '100.72.10.137' do nslookup é meu IP estático preferido da NIC primária.

O IP '100.76.26.142' do ping é meu ip estático da NIC Ethernet2.

O que estou tentando conseguir é que quando coloco 'server01.example.local' nas configurações do meu programa localizadas diretamente neste server01, o programa entrará em contato com o host local com o IP da LAN da NIC primária (100.72.10.137). Eu sei que isso pode ser resolvido adicionando '127.0.0.1 server01.example.local' ao arquivo hosts, mas quero entender esse problema mais profundamente.

Por que tenho respostas diferentes no utilitário ping? Já desativei 'Desativar NetBIOS sobre TCP/IP' na NIC. Também desabilitei o serviço 'TCP/IP NetBIOS Helper'. Tenho 100% de certeza de que meu arquivo hosts está vazio. Reiniciei o servidor, removi o cache (ipconfig/flushdns). Presumo que o ping agora deva tentar resolver o endereço usando os servidores DNS apenas na NIC primária. No entanto, parece que há outro componente ou lógica subjacente no sistema operacional Windows que me retorna um endereço IP errado usando ping.

Tenho uma situação estranha com meu nginx atuando como proxy reverso. Quando meu site de back-end está respondendo a uma solicitação do usuário (navegador do usuário) por meio do proxy reverso nginx, o usuário obterá o protocolo http em redirecionamentos 302 FOUND em vez do protocolo https.

Cheguei a uma situação em que duas coisas no proxy reverso nginx me ajudarão a resolver esta situação com protocolo errado nos redirecionamentos:

add_header Content-Security-Policy "upgrade-insecure-requests";

ou

proxy_redirect http:// https://;

No entanto, a abordagem é muito diferente com esses comandos.

Eu preferiria usar a primeira opção CSP porque parece ser a melhor maneira de resolver isso. No entanto, não tenho certeza do que acontece ao usar a segunda opção 'proxy_redirect'.

Para ser mais específico, meu back-end está escutando HTTP (80) e também HTTPS (443). No entanto, o certificado HTTPS (TLS) no meu back-end expirou. Na configuração do proxy reverso nginx, estou usando o protocolo HTTP para o 'proxy_pass' para back-end.

Quando uso 'proxy_redirect' nesta situação, parece que o proxy reverso nginx falha ao criar o handshake TLS. No entanto, em vez de encerrar a conexão 'proxy_pass', ele continua a se comunicar no protocolo HTTP. Pelo menos é isso que vejo nos logs do servidor web do backend. Da perspectiva do usuário, os redirecionamentos 302 FOUND agora estão configurados para HTTPS, o que parece estar correto. O site parece estar funcionando sem nenhum problema. Não há erros no proxy reverso nginx nem no console.

Então esse comportamento no proxy reverso nginx é normal? Qual opção devo implementar quando não quiser usar uma conexão HTTPS válida para o back-end? O proxy reverso nginx se comportará da mesma maneira com a opção 'proxy_redirect' quando o certificado HTTPS estiver totalmente ausente no back-end?