Se eu tiver example.comna minha lista de pesquisa de sufixo DNS e eu abrir um navegador e digitar, wwwo navegador se comunicará com o sistema operacional, que se comunicará com o DNS; se wwwnão conseguir resolver, meu sistema operacional anexará os itens da minha lista de pesquisa de sufixo até que um seja bem-sucedido; www.example.comse for bem-sucedido, obtenho um IP para o qual minha solicitação será enviada.

No entanto, olhando para a solicitação que meu navegador envia, o cabeçalho do host é definido wwwcomo o que foi digitado na barra de endereços, mesmo que esse não seja o FQDN que foi eventualmente resolvido para o IP. Isso significa que se o servidor web usar a vinculação de nome de host, ele tem que ouvir wwwtambém o FQDN de www.example.com, ou ele não reconhecerá a solicitação como sendo uma que ele deveria manipular.

Algum navegador tem funcionalidade para obter automaticamente o FQDN resolvido de volta do SO / há alguma configuração que possa ser ajustada para habilitar isso? Se não houver tal funcionalidade, há um motivo (por exemplo, talvez o SO não exponha informações sobre o FQDN que foi resolvido com sucesso por algum motivo de segurança?), ou esse cenário é muito específico para qualquer um implementar?

Eu tenho um gateway de aplicativo para o qual minhas configurações de back-end são configuradas com sondagens de integridade, permitindo o status 200-499 como íntegro (incluí os 4xxcódigos da série, pois algumas soluções têm raízes de site que retornam 404, embora tenham conteúdo em outros caminhos, e alguns sites retornam um 403 automaticamente para um usuário não autorizado / Não quero que isso afete o status de integridade do back-end / Queria que minha solução fosse o mais genérica possível para que eu pudesse reutilizar as mesmas configurações em uma série de sites para minimizar o esforço ao integrar novos sites ).

No entanto, minha integridade de back-end mostra um dos meus sites retornando HTTP 463códigos de status (portanto, o back-end ainda está íntegro, mas essa resposta é inesperada). Além disso, se eu navegar até o URI do ouvinte associado a esse back-end, ficarei preso em um redirecionamento 301 de/para o mesmo site. Eu tenho redirecionamentos configurados:

• O backend redireciona de /para /login.aspxpara um usuário não autenticado. Isso usa caminhos relativos, portanto, não é afetado pelo nome do host do AppGW ou pelo protocolo front-end versus back-end.
• O AppGW possui ouvintes HTTP e HTTPS, a regra HTTP redireciona para o ouvinte HTTPS, enquanto a regra HTTPS está associada ao backend.

No entanto, mesmo se eu remover esses recursos, obtenho o mesmo comportamento.

Outros sites no mesmo AppGW são configurados da mesma maneira, mas não apresentam esse problema.

Eu tenho um script do PowerShell para testar redirecionamentos: Get-HttpUrlRedirects . Se assumirmos que a configuração foi para example.com, a saída ESPERADA da execução Get-HttpUrlRedirects -Url 'http://example.com' -Verboseseria:

VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/login.aspx]
Url                                             StatusCode
---                                             ----------
http://example.com/                                    301
https://example.com/                                   302
https://example/login.aspx                             200

Embora a saída REAL seja:

VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
Url                                             StatusCode
---                                             ----------
http://example.com/                                    301
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/                                   301
VERBOSE: Redirecting to [https://example.com/]

# etc - I hit ctrl + C to terminate when I see this loop occurring

Pergunta

É válido que um subdomínio use servidores de nomes diferentes para o domínio pai sem que os servidores DNS do domínio pai forneçam registros NS para o subdomínio?

Por exemplo:

• Resolve-DnsName -Name example.com -Type NS -Server 1.1.1.1Retornos em execução ns1.example.com; o mesmo ns1.example.comacontece com o servidor de nomes oficial para example.com.
• Resolve-DnsName -Name subdomain.example.com -Type NS -Server 1.1.1.1Retornos em execução ns2.example.com; o mesmo ns2.example.comacontece com o servidor de nomes oficial para subdomain.example.com.

Eu esperaria que isso ns1.example.comcontivesse o conjunto de registros NS para subdomain.example.cominformar ao cliente "Eu não gerencio os registros NS deste subdomínio, para eles, converse com seus servidores de nomes". Ou seja, eu esperaria Resolve-DnsName -Name subdomain.example.com -Type NS -Server ns1.example.comvoltar ns2.example.com.

Nota: Se o subdomínio usasse os mesmos servidores NS que seu pai, eu não esperaria uma resposta ao acima.

( Resolve-DnsName é apenas um nslookupcomando, onde o Nameargumento é o FQDN a ser buscado, Serveré o servidor de nomes a ser consultado e Typenos permite especificar o tipo de registro DNS que procuramos).

Meu entendimento está correto ou um subdomínio pode ter servidores de nomes diferentes de seu pai sem que seu domínio pai hospede registros NS para o subdomínio?

Contexto

Temos um problema intermitente com o MS Dynamics 365 for Finance and Operations onde, ocasionalmente, os usuários que navegam para uma instância verão o erro abaixo:

The site can’t be reached
Check if there is a typo in EXAMPLE.operations.dynamics.com
If spellling is correct, try running Windows Networkk Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN

Os usuários estão usando o URI/nome de host correto.

Normalmente, esse problema se resolverá após cerca de 30 minutos. Vemos isso tanto para produção ( EXAMPLE.operations.dynamics.comquanto para teste ( EXAMPLE.sandbox.operations.dynamics.com).

Na investigação, se eu tentar resolver o FQDN usando nosso serviço DNS corporativo, ele não será resolvido; confirmando o erro do navegador; mas quando resolvemos um serviço DNS público (por exemplo, o do CloudFlare 1.1.1.1), as coisas geralmente resolvem corretamente. Observação: também vimos esse problema em que usuários que trabalham remotamente (que não usam nosso serviço DNS corporativo) têm o mesmo problema. Aqui, o serviço DNS do ISP mostra que não está conseguindo resolver o FQDN.

Acredito que o problema esteja relacionado ao DNS, e que o DNS do CloudFlare geralmente tem sido mais confiável, pois armazena em cache as entradas DNS por mais tempo (ou como seus servidores são atingidos com mais frequência, é mais provável que tenham entradas em cache).

Especificamente, quando há um problema ao resolver o FQDN para nosso ambiente, geralmente posso resolvê-lo no DNS do CloudFlare e nos servidores de nomes autorizados da MS para esse subdomínio (como seria de esperar)... mas tentando obter os servidores de nomes autorizados para o o subdomínio dos servidores de nomes autorizados para seu domínio pai falha; por exemplo, veja os 2 erros destacados abaixo:

Este é um problema com a minha compreensão do DNS (o que significa que a causa raiz dos nossos problemas requer mais investigação da nossa parte) ou é um problema de configuração com a implementação da MS?

Observação: entrei em contato com o suporte da MS para saber o que foi dito acima, mas a equipe que dá suporte ao Dynamics é uma equipe de suporte a aplicativos, portanto, não foi possível ajudar com problemas relacionados ao DNS/infraestrutura ou encaminhar meu ticket para uma equipe que pudesse ajudar.

Ao enviar e-mails por meio de nosso serviço Exchange 365, esses e-mails são enviados com êxito, mas se olharmos os cabeçalhos dos e-mails, vemos que onde o remetente e o destinatário estão em nosso locatário, o SPF do e-mail realmente falhou; enquanto que se enviamos e-mails para terceiros (por exemplo, para um endereço do Gmail), o SPF está correto.

Especificamente, vemos que o e-mail enviado internamente mostra ter um IP no ip6:2603:1000::/24intervalo (por exemplo 2603:10a6:400:49::16... e esse IP não está listado em spf.protection.outlook.com.

Da mesma forma, ao verificar os cabeçalhos dos e-mails enviados a terceiros, vemos que um seletor DKIM está incluído no cabeçalho do e-mail. Para aqueles enviados para outras caixas de correio dentro do nosso locatário, esse cabeçalho não existe.

Outros têm relatado o mesmo há vários anos. Como os outros, falei com o suporte da MS, mas esse cenário está fora do roteiro para eles, então isso não me levou a lugar nenhum.

Meu palpite é que a MS não se importa com SPF/DKIM quando as mensagens estão dentro do locatário, pois sabem que esses e-mails são válidos e não os filtram. No entanto, não consigo encontrar nenhuma documentação para confirmar isso, e isso parece errado (por exemplo, se o seu cliente de e-mail tiver sua própria lógica para validá-los, como ele saberia confiar neles). Este é um problema frustrante, pois ao investigar problemas reais de e-mail, é mais difícil dizer se os e-mails que falham nessas verificações indicam um problema real ou, como e-mails válidos também falham nessas verificações, estamos procurando no lugar errado.

Ao criar uma nova VM através do Portal do Azure , vemos apenas Datacenter Edition, mas os documentos parecem deixar claro que Standard Editioné uma opção válida no Azure; embora você tenha que criar sua própria imagem para isso.

Parece estranho que, como a Standard Edition é suportada, não exista uma imagem padrão para ela. Isso é apenas a MS tentando encorajar as pessoas a usarem a opção mais cara, tornando esse caminho mais conveniente, ou há alguma razão técnica pela qual a Standard Edition não está disponível OOTB (por exemplo, embora possa ser usada, existem restrições significativas que recomendariam contra isso)?

Ao pesquisar isso, a maioria das postagens leva a Hybrid Benefit, mas meu entendimento é que essa opção é para onde você tem servidores locais, permitindo que você use a mesma licença para uma VM do Azure e um dispositivo local; ou então permitir que você use licenças adquiridas anteriormente para evitar pagar novamente por licenças no Azure. Não estou interessado nisso; mas sim em novas VMs criadas diretamente no Azure, onde precisamos apenas dos recursos oferecidos pela Standard Edition e não queremos pagar mais por funcionalidades que não estamos usando.

Antes de criarmos nossa própria Windows Server 2022 Standard Editionimagem para evitar esse custo extra, espero entender se há outras implicações.

Problema

Criei um certificado por meio de serviços de certificado AD, mas ele apresenta erro "The issuer of this certificate could not be found."apesar de toda a cadeia estar presente no PFX.

Contexto

Criei um certificado de assinatura de código do servidor AD Certificate Services da nossa organização, usando o code signingmodelo padrão e exportando o certificado criado (com chave privada exportável).

Estamos tendo problemas ao usar este certificado para assinar código, apesar de nosso certificado raiz ser confiável em todos os dispositivos corporativos.

Na investigação, se eu converter o PFX em um PEM (com extensão de arquivo .CER) e abri-lo em um editor de texto, posso ver os certificados de cliente, intermediário e raiz listados no arquivo PEM. No entanto, se eu clicar duas vezes neste arquivo CER (ou seja, para abri-lo crypto shell extensions), a guia do caminho do certificado mostrará apenas o certificado do cliente e mostrará o status do certificado como "The issuer of this certificate could not be found.".

Olhando para o emissor do cliente, ele nomeia corretamente o certificado intermediário.

Se eu copiar os certificados intermediários e raiz do arquivo PEM para o seu próprio, salve-o como .CER e abra-o, então os certificados intermediários e raiz serão listados corretamente. O issuerdo cliente corresponde exatamente ao issued todo intermediário; e o issuerdo cliente corresponde exatamente ao subject namedo intermediário.

Para converter PFX em PEM estou usandoopenssl.exe pkcs12 -in "mycert.pfx" -out "mycert.cer" -nokeys -passin "pass:mypassword"

Pergunta

Se estiver usando o Proxy DNS do Firewall do Azure com servidores DNS internos atrás desse mesmo firewall, o que acontece com as solicitações de registros DNS externos (ou seja, isso causa um loop infinito em que o servidor DNS solicita registros de um servidor DNS público, mas essa solicitação é capturada pelo FW e enviado de volta ao servidor DNS interno)?

Contexto

Temos um hub/vwan seguro no Azure, onde todo o tráfego entre redes passa pelo firewall, assim como todo o tráfego de entrada e saída da nossa rede.

Queremos ativar o proxy DNS no firewall para nos permitir usar FQDNs em nossas regras.

Também especificamos servidores DNS personalizados em nosso FW (o que parece aceitável por esta captura de tela do MS Docs . Na captura de tela, eles estão usando um IP interno e 168.63.129.16um IP especial da MS. Para o nosso, temos os IPs internos de nossos 2 controladores de domínio , e eles são configurados com encaminhamentos condicionais 168.63.129.16para os domínios nos quais temos terminais privados com zonas DNS privadas.

Minha preocupação é que, com o DNS Proxy habilitado, uma vez que o tráfego de nossos DCs para a Internet passa por esse firewall, ele interceptará suas consultas de DNS público e causará um loop infinito, resultando na falha de qualquer solicitação de informações de DNS externo (uma vez que qualquer solicitação anterior entradas em cache expiram)?

Da mesma forma, as solicitações para 168.63.129.16 (por meio do encaminhador condicional) também seriam vistas como indo para a Internet e, portanto, interceptadas?

A captura de tela nos documentos implica que podemos adicionar 168.63.129.16um servidor DNS no firewall... mas isso seria tratado como um round-robin com os outros servidores DNS (ou seja, solicitações para zonas internas às vezes falhariam, pois não sei 168.63.129.16de nossas zonas internas além das zonas DNS privadas do Azure, mas às vezes retornam uma resposta esperada ao atingir nossos servidores DNS internos) ou há alguma ordem de preferência onde só é 168.63.129.16contatado se nossos servidores DNS internos não tiverem um registro?

Se esse loop infinito for uma possibilidade, qual é a solução correta? Apenas roteamos o tráfego de saída de nossos DCs como próximo salto 0.0.0.0/0(que impacta todo o tráfego, não apenas a porta 53), ou existe uma solução melhor?

O tipo está microsoft.authorization/roledefinitionsdisponível por meio do Azure Resource Graph?

Contexto

Espero consultar o Azure Resource Graph para buscar todas as funções que têm permissões específicas. Olhando em volta, descobri microsoft.authorization/roledefinitionsque parece ser um bom ponto de partida; está documentado aqui e listado tablesem Azure Resource Graph Explorer/ clicando duas vezes nele adiciona a linha | where type == "microsoft.authorization/roledefinitions"que parece promissora.

No entanto, quando executo o Kusto abaixo, esse tipo não aparece:

Search-AzGraph -query @'
resources 
| where type startswith "Microsoft.Aut" 
| distinct type
'@

A resposta é simplesmente:

type
----
microsoft.automation/automationaccounts
microsoft.automation/automationaccounts/runbooks

Eu tenho acesso para visualizar as definições de função; como execução Get-AzRoleDefinitionproduz uma lista de resultados.

Existe algo mais que eu preciso fazer para tornar esse tipo visível via Kusto; ou simplesmente ainda não está disponível através do ARG?

Percebemos um problema em nosso sistema de RH, onde os usuários solicitam licença, essa aprovação é enviada ao gerente e, quando o gerente clica no link para aprovar, eles veem um erro dizendo que a licença já foi aprovada ... Isso parece porque o Outlook envia uma solicitação GET para o URI de aprovação do sistema de RH para verificar se o link é malicioso; mas, ao fazê-lo, aprova a licença do empregado. Observação: esta solicitação GET é enviada antes mesmo de o e-mail ser visualizado/não é acionado por nenhuma ação do usuário destinatário.

O sistema de RH é de terceiros, com suporte ruim, então eles não puderam confirmar nossa teoria sobre o que está acontecendo... No entanto, testei enviando um e-mail de um endereço de e-mail externo que contém um link para um site que eu apoio (mas não está na lista de domínios verificados do Outlook). Olhando para os logs no meu servidor, vejo que momentos após este e-mail de teste chegar ao meu cliente de e-mail (sem que eu clique no link ou mesmo visualize o conteúdo do e-mail), com certeza uma solicitação GET aparece nos meus logs de um IP que pertence a MS (de acordo com um whois no IP).

Isso parece muito prejudicial... mas então trabalhamos com outros sistemas que possuem links de clique único (tanto para aprovações quanto também muitos e-mails que contêm unsubscribelinks ou verify my emaillinks que funcionam com um clique / não exigem acompanhamento manual) e parece que não temos problemas semelhantes com eles; e parece improvável que, em todos esses casos, os proprietários dos sites tenham colocado na lista negra os IPs do MS associados aos SafeLinks (especialmente como se fosse tão simples de contornar, um ator mal-intencionado também poderia usar esse truque para evitar a proteção de safelinks).

• É provável que nossa teoria sobre SafeLinks esteja causando as aprovações corretas?
• Em caso afirmativo, há alguma explicação de por que não está afetando mais sistemas?

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

Temos um domínio que possui 11 inclui; o mesmo ocorre com a falha na validação do SPF, pois ultrapassou o limite. A maioria das pesquisas são para recursos de terceiros, portanto, nivelar o registro SPF não é o ideal; preferimos garantir que as coisas sejam atualizadas dinamicamente quando os terceiros atualizarem seus registros.

Uma das pesquisas é um valor legado para o qual não encontramos documentação; então não temos certeza se é necessário... estamos perguntando antes de removê-lo, mas é uma grande empresa com muitos becos sem saída e fendas nas quais os proprietários de requisitos se escondem, portanto, verificar essas coisas leva tempo.

Estamos pensando que ter mais de 10 pesquisas é apenas um problema para os registros que excedem a 10ª pesquisa; todos os valores anteriores a esse devem ser bem-sucedidos, mesmo que haja mais no total. Como tal, se pudermos mover a pesquisa desconhecida para o final, isso reduzirá o risco de algo com o qual nos importamos ser impactado.

• Essa suposição está correta / as primeiras 10 pesquisas de SPF funcionam quando há mais de 10 no total?

• Em caso afirmativo, qual é o 11º registro - ou seja, as pesquisas são calculadas primeiro em largura, primeiro em profundidade ou não é especificado, então depende do provedor?

Um firewall pode melhorar a segurança de um serviço SFTP por meio da inspeção de solicitações recebidas (por exemplo, para bloquear quaisquer comandos SSH que não são necessários ao usar apenas SFTP?

Contexto

Recentemente, encontrei uma VM em nossa propriedade que possui um IP público para expor SFTP (ou seja, SSH; não FTPS) e um serviço HTTPS à Internet.

Estou procurando colocar o site por trás do Gateway de Aplicativo do Azure, executando o descarregamento de SSL e, em seguida, roteando a solicitação para a VM de back-end internamente por HTTP.

Como os serviços SFTP e HTTPS compartilham o mesmo nome de host, terei que apontar que, no Firewall do Azure, roteie solicitações na porta 22 para a VM e solicitações em 80/443 para o gateway do aplicativo (solicitações em 80 receberão apenas um HTTP 301 redireciona para o endpoint HTTPS; aqueles em 443 serão roteados para o back-end conforme descrito acima).

Como estamos colocando um firewall entre o público e a VM seria bom usá-lo para melhorar ainda mais a segurança... Já ele só encaminhará na porta 22 para a VM, então isso é uma vitória (por exemplo, bloquear RDP), e ele nos dá opções como lista branca de IP do cliente (embora para nosso caso de uso isso não seja desejado, pois poderíamos ter conexões legítimas de qualquer lugar).

No entanto, estou querendo saber se há algo como as regras OWASP para o firewall do gateway de aplicativo usa para HTTP, que poderia inspecionar o tráfego SSH e bloquear qualquer coisa que pareça suspeita.

Meu palpite é que não há, pois o SSH usará criptografia RSA com chaves conhecidas apenas pela VM e pelo cliente; não o firewall... mas eu não me aprofundei muito no SFTP/SSH, então pode haver opções que eu não pensei que melhorariam ainda mais a segurança da solução?

Resumo

Eu tenho um serviço de aplicativo do Azure executando um contêiner personalizado. Quando vinculo um caminho a um compartilhamento de Arquivos do Azure, meu contêiner para de funcionar. Olhando para os Container Issueslogs, vejo o erro: [BYOS] Custom storage volume(s) failed to initialize: [/var/LWASFiles/Sites/my-app/a3484543-39f9-45a3-816b-9524640dfd50].

Detalhe

• Meu contêiner personalizado tem um volume definido /var/www/html/v3/uploads.

• Estou tentando mapear isso para um compartilhamento de arquivos do Azure, que está em uma conta de armazenamento na mesma vnet que o ASE de hospedagem, com regras que permitem o tráfego entre a sub-rede do ASE e o compartilhamento de arquivos nas portas 137, 138, 138 e 445 .

• O ASE de hospedagem é configurado com um balanceador de carga interno (ou seja, é um ASE privado).

• A conta de armazenamento tem um ponto de extremidade privado configurado.

• O volume é mapeado em Configurações > Configuração > Mapeamentos de caminho do Serviço de Aplicativo, usando uma chave válida e um caminho de montagem que corresponda ao caminho do volume no contêiner.

• Antes de adicionar o mapeamento de caminho, o serviço de aplicativo é executado conforme o esperado.

• Após adicionar o mapeamento de caminho, o contêiner não inicia / as únicas informações de exceção que consigo encontrar são nos Container Issueslogs, conforme o resumo acima.

• Se eu remover o mapeamento de caminho, o problema persistirá, mesmo após forçar uma reinicialização. A única maneira de resolver o problema é descartar e reimplantar o serviço de aplicativo.

• Ele se conecta com sucesso a um banco de dados MySql (banco de dados do Azure para servidores MySQL) por meio de um ponto de extremidade privado.

• Usando dig {privateEndpointFqdn}sou capaz de provar que o endpoint privado da conta de armazenamento foi resolvido corretamente (como é o do MySQL; como seria de esperar)

• Usando tcptraceroute {privateEndpointFqdn} {destinationPort}, posso provar que posso me conectar à conta de armazenamento na porta 445 (e ao banco de dados MySQL na porta 3306).

• Observação: não consigo me conectar à conta de armazenamento nas portas 137, 138 ou 139, apesar de serem permitidas pelo NSG nas mesmas regras de entrada e saída usadas para 445, acima; embora eu suspeite que essas portas não sejam mais necessárias para o CIFS (eu as adicionei apenas como uma medida just-in-case depois de acertar o problema, caso fossem de alguma forma relevantes, pois foram mencionados em alguns posts).

• Estou executando os testes acima por SSH no contêiner, para que os comandos sejam executados a partir de seu contexto. Observação: como não consigo iniciar o contêiner após adicionar o mapeamento de caminho, esses testes são realizados após a criação do serviço de aplicativo, mas antes de adicionar o mapeamento de caminho.

• Eu aumentei WEBSITES_CONTAINER_START_TIME_LIMITpara seu valor máximo:1800

• Meu contêiner expõe a porta 80 (ou seja, uma das portas padrão com suporte pelo Serviço de Aplicativo para contêiner); e o site funciona quando o mapeamento de caminho não existe, então esse não deve ser o problema. Também configurei WEBSITES_PORTpara 80, apenas para cinto e suspensórios.

• WEBSITES_ENABLE_APP_SERVICE_STORAGEestá definido como false(embora eu também tenha experimentado defini-lo como true, apenas no caso de / não fazer diferença, então reverti para false).

• Meu compartilhamento de arquivos tem vários GBs de dados. Tentei criar um compartilhamento de arquivo idêntico sem conteúdo e mapeá-lo (imediatamente após recriar o serviço de aplicativo e provar que funcionou; para garantir que meus testes não fossem afetados pela ressaca do compartilhamento de arquivo maior). Isso dá o mesmo problema com o compartilhamento de arquivos maior.

• A imagem do meu contêiner está sendo carregada de um Azure Container Repo.

• A imagem é baseada naubuntu:21.04

• Eu incluí os pacotes azure-clie cifs-utils(acho que isso é necessário apenas ao executar a operação de montagem do contêiner, em vez da configuração do AppService; mas eu queria cobrir todas as suposições)

• O ASE de hospedagem está na UK Southregião (assim como a conta de armazenamento/todos os recursos).

Observação: esta é minha primeira experiência com a execução de contêineres no Serviço de Aplicativo; então PEBKAC é definitivamente uma possibilidade.

Quaisquer sugestões ou conselhos de solução de problemas seriam muito apreciados. Obrigada.

É possível configurar um grupo dinâmico de distribuição para conter todos os subordinados diretos de alguma pessoa, além de todos os seus subordinados diretos recursivamente?

Informações detalhadas

Para obter apenas os relatórios diretos, acredito que apenas executaríamos:

Set-DynamicDistributionGroup -Identity 'SomeManagersDirectReports' `
    -RecipientFilter "((RecipientType -eq 'UserMailbox') -and (Manager -eq 'CN=SomeManager,OU=Users,DC=domain,DC=example,DC=com')" 

Mas para obter um gerente, seus subordinados diretos e seus relatórios recursivamente, a única maneira que consigo pensar é executar algo como o abaixo para gerar uma lista de membros e usá-la para atualizar um grupo de distribuição (estático) dinamicamente.

# very rough code to demo thinking... Haven't yet considered things like character escaping /
# circular loops / other fun things which may be found in the wild...

[string]$FirstPersonDn = 'CN=SomeManager,OU=Users,DC=domain,DC=example,DC=com'
[System.Collections.Generic.List[string]]$newMembers = [System.Collections.Generic.List[string]]::new()
[System.Collections.Generic.List[string]]$members = [System.Collections.Generic.List[string]]::new()
$newMembers.Add($FirstPersonDn)
while ($newMembers.Count) {
    $members.Add($newMembers)
    $newMembers = $newMembers | %{Get-AdUser $_ -properties DirectReports} | % DirectReports
}
Update-DistributionGroupMember -Identity 'SomeManagerAndTheirReportsRecusive' -Members $members

Ao adicionar um segundo ouvinte HTTPS multisite em um gateway de aplicativo, recebo a exceção abaixo:

Falha ao salvar as alterações de configuração no gateway de aplicativo 'MyAppGateway'. Erro: Data ou KeyVaultSecretId deve ser especificado para o certificado 'MyResourceGroup/providers/Microsoft.Network/applicationGateways/MyAppGateway/sslCertificates/myCertificateName'>MyAppGateway/myCertificateName' no Gateway de Aplicativo.

Esse erro ocorre independentemente de eu usar o mesmo certificado para ambos os ouvintes (com os diferentes domínios cobertos pela lista SAN) ou configurar certificados individuais por ouvinte.

Depois de encontrar esse erro, não consigo atualizar o gateway do aplicativo de forma alguma / a única correção parece ser excluí-lo.

Este é um problema conhecido ou estou fazendo algo errado? Estou seguindo os passos descritos aqui ; só estou usando um certificado autoassinado para o certificado SSL inicial (ou seja, em vez de obter LetsEncrypt para emitir o certificado inicial / já que ele será substituído de qualquer maneira). Quando fiz um POC disso para um único site, tudo funcionou como esperado; portanto, o problema parece estar relacionado ao meu uso do recurso multissite (ou seja, ter diferentes FQDNs apontando para o IP público compartilhado do gateway do aplicativo e, em seguida, roteando as solicitações para diferentes back-ends com base nos valores do cabeçalho do host).

Estou procurando criar várias políticas do Azure usando infraestrutura como código.

A Documentação MS aconselha uma estrutura conforme abaixo:

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|

Isso faz sentido, mas todos os exemplos de definições de política que vi incluem as definições de parâmetros; então não vejo valor em ter o policy.parameters.jsonarquivo separado se for apenas duplicar informações.

Pergunta

Existe uma maneira de evitar essa duplicação; por exemplo, fazendo com que o policy.jsonarquivo se refira ao policy.parameters.jsonarquivo em vez de copiar seu conteúdo, ou há algum valor agregado por ter essa duplicação?

(O mesmo cenário ocorre para o arquivo de regras; suponho que a resposta para essa seção seja a mesma...)

Exemplo desta duplicação

No repositório de Políticas da Comunidade do Azure:

O arquivo de política inclui estas linhas:

"parameters": {
  "tagName": {
    "type": "String",
    "defaultValue": "DateCreated",
    "metadata": {
      "displayName": "Tag Name",
      "description": "Name of the tag, such as 'Date'"
    }
  }
}

O arquivo de parâmetros duplica exatamente o conteúdo encontrado na seção de parâmetros acima (bem, quase; neste caso, a descrição difere um pouco, mas isso parece um erro e não uma justificativa):

{
  "tagName": {
    "type": "String",
    "defaultValue": "DateCreated",
    "metadata": {
      "displayName": "Tag Name",
      "description": "Name of the tag, such as 'DateCreated'"
    }
  }
}

Pergunta

Por que a filtragem NetBios deve afetar o SMB3/a capacidade de se conectar à porta 445?

Contexto

Alguns usuários (inclusive eu) estavam tendo problemas para acessar compartilhamentos de arquivos hospedados em Arquivos do Azure a partir de suas conexões domésticas, recebendo o erro abaixo.

O Windows não pode acessar \myStorageAccount.file.core.windows.net\my-share\

Verifique a ortografia do nome. Caso contrário, pode haver um problema com sua rede. Para tentar identificar e resolver problemas de rede, clique em Diagnosticar.

Código de erro: 0x80070035

O caminho de rede não foi encontrado

A execução de um teste de porta online myStorageAccount.file.core.windows.netmostrou a porta 445 como aberta.

A execução Test-NetConnection -ComputerName 'myStorageAccountName.file.core.windows.net' -port 445da minha máquina local falharia; apesar do software de firewall do meu dispositivo local não bloquear a conexão.

Eventualmente, descobri que a causa estava NetBios filterno meu roteador; com isso habilitado, as conexões com a porta 445 em compartilhamentos de Arquivos do Azure falharam; com ele desativado tudo funcionou.

A documentação do meu roteador também menciona que esse filtro afeta o SMB:

Filtro NetBIOS ativado

Por motivos de segurança, o filtro NetBIOS no FRITZ!Box está ativado por padrão. Bloqueia pacotes NetBIOS, que normalmente não são necessários para comunicação na internet. Desative este filtro apenas se estiver usando aplicativos que precisam trocar pacotes NetBIOS com a Internet. Este é o caso, por exemplo, do acesso SMB ao Strato HiDrive.

Não tenho certeza se isso se deve a algum bug na lógica do filtro do roteador ou se há algo mais acontecendo.

Se for relevante, temos a filtragem RBAC ativada (por exemplo, minha conta tem a Storage File Data SMB Share Elevated Contributorfunção atribuída) e temos AD ACLS ativados em nosso compartilhamento de arquivos (conforme descrito neste vídeo de John Savill )... entrar em jogo para o teste de porta simples?

Estamos procurando melhorar a padronização e a qualidade dos dados em nosso diretório ativo. Ao fazer isso, encontramos inconsistências no formato do distinguishedName; especificamente o formato do CNpróprio. Muitas vezes temos consistência razoável (embora nunca 100%) dentro de uma entidade legal (OU de nível superior), mas entre essas entidades, vários formatos são usados. Os mais comuns são:

• GivenName + ' ' + Surnamepor exemplo, "John Bevan"
• Surname + ', ' + GivenName por exemplo, "Bevan, John"
• string.ToUpper(SURNAME) + ' ' + GivenNamepor exemplo, "BEVAN John"
• sAmAccountNamepor exemplo, "ukjlb023"

Existem diretrizes sobre o que é um bom formato ou considerações a serem feitas ao tomar essa decisão?

• Os valores devem ser únicos, então você quer algo que provavelmente não terá colisões com valores existentes (por exemplo, apenas usando givenNamevocê teria que anexar um valor adicional a muitas entradas para evitar colisões para todos, exceto para os nomes mais raros).
• Os valores imutáveis ​​são melhores (por exemplo, como alguns sistemas usam o DN como identificador, portanto, alterar o CN que faz parte do DN pode afetar o acesso a esses sistemas).
• Presumivelmente, há um benefício em usar nomes significativos, pois isso permite que uma pessoa descubra a qual conta um CN/DN se refere sem ter que procurar outros atributos... mas isso não é crítico, pois essas informações podem ser facilmente consultadas.
• O formato Surname + ', ' + GivenNameinclui uma vírgula, que é um caractere especial no DN, portanto, deve ser escapado. Ao evitar caracteres especiais no CN, estamos limitando o impacto de bugs em software/consultas/scripts (também há uma desvantagem nisso, pois é mais provável que esses bugs passem despercebidos).
• Presumivelmente, há um índice aplicado a esse campo, portanto, o que estiver à esquerda terá maior impacto no desempenho da pesquisa. Dado que as pessoas são mais propensas a conhecer os nomes dos colegas do que o sobrenome ou sAmAccountName, talvez haja algum pequeno benefício de desempenho em colocar o givenNameprimeiro.
• Algumas pessoas são conhecidas por outros nomes (por exemplo, Robert->Bob, Madeeha->Dee, Ashish->Ash / algumas pessoas simplesmente preferem ser chamadas pelo nome do meio ou por um nome totalmente diferente). Quando o apelido não for uma subsequência do nome real, pode haver algum benefício na capacidade de pesquisa ao incluir esse nome no CN; por exemplo John \"JB\" Bevan(caracteres de escape necessários em DN, mas não em CN).

Minhas suposições estão corretas ou alguma delas está apenas pensando demais no problema / longe?

Existem outras considerações a serem levadas em consideração?

NB: Há uma pergunta relacionada: https://stackoverflow.com/questions/7814569/what-do-people-use-for-cn-with-inetorgperson-in-ldap-directories - embora isso seja focado em "como evitar colisões" parte da discussão.

Estou tentando usar a Área de Trabalho Remota para fazer logon em um servidor Dynamics 365 AOS hospedado no Azure, usando o arquivo RDP e as credenciais exibidas na página LCS do ambiente .

O servidor Dynamics 365 AOS é uma Windows Server 2016 Datacenter Editioncaixa.

Ao acessá-lo através de um Windows Server 2012 R2servidor (ou seja, fazer RDP no servidor, baixar o arquivo DFO365 RDP do LCS para essa máquina e executar o cliente RDP no servidor "proxy") tudo funciona, mas tentar acessar diretamente da minha Windows 7 SP1máquina falha. Um colega, também executando Windows 7 SP1, tem exatamente o mesmo problema.

Meu IP público (ou seja, como visto visitando WhatsMyIp ) está na lista de permissões para RDP (através do LCS Maintain> Enable Access).

Tanto eu quanto meu colega conseguimos fazer o RDP nesta VM até meados da semana passada.

Ao passar pelo servidor "proxy", consegui visualizar os logs de eventos no servidor remoto do Dynamics 365 AOS. Olhando para o Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operationallog de eventos, pude ver minhas tentativas de conexão atingindo este servidor, pois havia mensagens de aviso informando: The server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP:123.45.67.89) has been disconnected. (onde 123.45.67.89 corresponde ao meu endereço IP público). Existem vários outros eventos de informação em ambos os lados do aviso:

• informaçãoThe server accepted a new TCP connection from client 123.45.67.89:58177.
• informaçãoConnection RDP-Tcp#4 created
• informaçãoInterface method called: PrepareForAccept
• informaçãoInterface method called: SendPolicyData
• informaçãoPerfCounter session started with instance ID 4
• avisarThe server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP:123.45.67.89) has been disconnected.
• informaçãoInterface method called: OnDisconnected
• informaçãoThe server has terminated main RDP connection with the client.
• informaçãoDuring this connection, server has not sent data or graphics update for 0 seconds (Idle1: 0, Idle2: 0).
• informaçãoChannel rdpinpt has been closed between the server and the client on transport tunnel: 0.
• informaçãoChannel rdpcmd has been closed between the server and the client on transport tunnel: 0.
• informaçãoChannel rdplic has been closed between the server and the client on transport tunnel: 0.
• informaçãoThe disconnect reason is 14

Esses eventos se repetem 3 vezes, o que implica que o MSTSC faz 3 tentativas de conexão antes de relatar a falha.

Olhando ao redor da web, vi menção de alguns certificados e problemas-chave. Percebi que existem 120.078 arquivos em C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, incluindo um começando f686aace6942fb7f7ceb231212eef4a4_ ( TSSecKeySet1 ). No entanto, não tentei remover ou alterar nenhum deles, pois não sei qual seria o impacto / não vi nenhuma explicação de por que essas correções deveriam funcionar. Meu instinto é que o grande volume de arquivos nesse diretório pode estar relacionado ao problema.

Pergunta

Alguém sabe o que pode estar bloqueando essas tentativas de conexão / o que é necessário para permitir as conexões?

Fundo

Temos alguns aplicativos em servidores Windows 2008 R2, apresentados via RemoteApp, via links do TS-Web. Esses aplicativos estão sendo executados dessa maneira há anos (~ 8 anos, eu acho).

Um de nossos usuários está tendo problemas para fazer login, com ele travando por alguns minutos na fase "configurando sessão remota" antes de sair sem explicação / erro / etc. Fizemos todas as correções óbvias (desativar o cache de bitmap, exclua o cache local, garanta baixa resolução, exclua o perfil dela, verifique se nenhum servidor TS possui uma cópia do perfil dela, verifique se os firewalls estão desativados ou têm as exceções necessárias, etc., mas sem alegria. Também confirmamos que o problema ocorre apenas com o combo exclusivo de sua conta em sua máquina.

Como temos um farm de servidores, e o login demora minutos, ainda não consegui capturar a tentativa de login dela com procmon a tempo de obter pistas...

Para ir mais fundo (e evitar a solução deselegante de substituir ou reconstruir toda a máquina), gostaria de saber mais sobre o que está acontecendo nos bastidores...

Perguntas

1. O que acontece durante uma conexão RDP; ou seja, quando o sistema diz configuring remote session, o que realmente está acontecendo (também interessado em outras fases; embora apenas por motivos acadêmicos)?

2. Algum log é criado que possa dar uma pista para a falha / você precisa habilitar esse log em algum lugar? NB: Eu verifiquei o log de eventos, mas no momento não vejo diferença entre a tentativa dela (falhou) e a de qualquer outro usuário.