RD Gateway com Azure Multifactor Authentication Perguntas e respostas

Artigo em parceria com Kristin Grifin

No artigo anterior http://www.andreluiz.adm.br/2014/07/usando-rd-gateway-com-azure-multifactor.html Nós montamos um ambiente com autenticação em 2 etapas usando RD Gateway com Azure MFA. Agora vamos analisar algumas questões sobre resolução de problemas nesse ambiente:

Quando uma conexão é bem-sucedida existem terá 16 entradas de log de eventos no log de eventos. Ele está localizado em:

Event Viewer / Applications and Services Logs / Microsooft / Windows / TerminalServices-Gateway / Operational

Estas 16 entradas seguintes correspondem a uma conexão bem sucedida:

1. User met CAP policy requirements and can connect to RD Gateway

2. User met RAP policy requirements and can connect to RD Connection Broker

3. The user connected to RD Connection Broker using HTTP

4. The user connected to RD Connection Broker using UDP

5. The user connected to RD Connection Broker using UDP Proxy

6. The user connected to RD Connection Broker using UDP (second channel)

7. The user connected to RD Connection Broker using UDP Proxy (second channel)

8. The user disconnected to RD Connection Broker using HTTP

9. The user disconnected to RD Connection Broker using UDP

10. The user disconnected to RD Connection Broker using UDP

11. User met RAP policy requirements and can connect to RD Session Host

12. The user connected to RD Session Host using HTTP

13. The user connected to RD Session Host using UDP

14. The user connected to RD Session Host using UDP Proxy

15. The user connected to RD Session Host using UDP (second channel)

16. The user connected to RD Session Host using UDP Proxy (second channel)

O que encontramos foi que, se você tem um problema com políticas mal configuradas no NPS, você provavelmente obterá um erro no log de eventos no primeiro passo. O log de eventos vai dizer que não encontrou os requisitos CAP, mesmo se você tiver feito.

Se você topar com isto, verifique suas políticas. Se você tem certeza que estão corretas e, em seguida, verifique se seu CAP funciona se você usar um NPS LOCAL. Se funcionar recomendamos que você refaça suas políticas. Remova as diretivas que você tiver editado ou criado no NPS. Então refaça o apontamento do CAP no Gerenciador de Gateway RD (Fazendo isso irá recriar os parâmetros exigidos no NPS, e você pode recriar e Editar Diretivas a partir de lá.

Perguntas e Respostas

P: Existem outras maneiras para configurar a comunicação no NPS ?

R: Sim, existem várias maneiras de configurar a comunicação no NPS. Por exemplo:

• Deixar o RD Gateway com um NPS local em vez de “redirecioná-lo” para fora.

• Adicionando dois clientes RADIUS no NPS, uma para o servidor Gateway RD e outro para o servidor do MFA.

• Configurando duas diretivas de solicitação de conexão para lidar com a comunicação do NPS para servidor MFA (um por nome amigável e o outro por endereço IP).

• Configurando duas diretivas de solicitação de conexão para lidar com a comunicação do servidor MFA para o NPS (um por nome amigável e o outro por endereço IP).

Mas esta configuração acabou por ser muito sensível. Tivemos um problema em que tivemos que refazer as políticas no NPS e começar de novo.

Vamos percorrer outros cenários de configuração possível no nosso próximo artigo, quando falaremos de Gateway de área de trabalho remota e cenários de alta disponibilidade do Azure AMF.

P: Por que precisamos alterar o tempo limite para o grupo de servidores remotos RADIUS no NPS de 5 segundos para 30-60 segundos?

R: Porque leva tempo para executar a autenticação primária com o RD Gateway e depois para executar a 2º autenticação antes de retornar uma resposta ao Gateway. Por isso os limites de precisam ser aumentados para 60 segundos.

P: como o Azure sabe como me cobrar quando implanto o Azure AMF on premisse ??
R: O servidor do MFA informa o número de usuários habilitados para o serviço de nuvem do MFA AMF, que relata o faturamento para o sistema de comércio do Azure.

P: Qual parte do Azure MFA se encarrega de enviar as mensagens de texto para telefones celulares?

R: todas as autenticações (2º fator) são executadas através do serviço de nuvem do MFA. Esse serviço executa as chamadas telefónicas, mensagens de texto e notificações “push” (app móvel). Ao usar o servidor MFA on premisse o servidor solicita a autenticação do serviço na nuvem.

P: quando recebo uma mensagem TXT do Azure MFA, aparentemente é originada de um número aleatório. Como saber se é legítimo? Existe uma maneira de identificar a or este que não seja usando o nome amigável na configuração do MFA?

R: o Azure utiliza vários provedores SMS, cada um com um pool de números a partir dos quais quais as mensagens SMS são enviadas. As informações são que a Microsoft trará em breve um código curto de SMS, e então a maior parte do tráfego SMS nos EUA será enviada a partir desse código Você também pode personalizar a mensagem SMS que é enviada em Company Settings->SMS.

P: como um servidor Azure MFA comunica-se com os serviços de nuvem Azure MFA?

R: o servidor MFA comunica-se ao serviço de nuvem pela porta 443 de saída. A Figura 1 mostra uma arquitetura de alto nível na qual mostra o servidor MFA local, Azure AD e o serviço de nuvem do MFA.