Windows Server 2008 R2: Por que usar a autenticação no nível da rede?
Usando a autenticação de nível de rede (NLA), em vez do método mais antigo de serviços de terminal, é mais rápido e mais seguro.
Kristin Griffin
Movendo-se de serviços de Terminal do Windows Server 2003 para Windows Server 2008 R2 Remote Desktop Services tornou-se um caminho de atualização bastante comum. Como as pessoas fazem desta atualização, você ouvirá muitas vezes eles me perguntando por que a experiência do usuário de conexão entre as duas versões é tão diferente.
Ao se conectar a um servidor de Terminal de 2003, um usuário inicia uma sessão e tipos em suas credenciais. Ao usar um servidor de terminal, um usuário insere tipicamente credenciais em uma caixa de diálogo do lado do cliente. Por padrão, os clientes que não oferecem suporte a uma tecnologia chamada autenticação no nível da rede (NLA) não podem se conectar. Por que a diferença? Existem razões por que a Microsoft introduziu a autenticação no nível da rede e razões por que, de facto, é uma coisa boa.
O que É NLA?
NLA força o computador cliente para presentes credenciais do usuário para autenticação antes que o servidor irá criar uma sessão para esse usuário. Por causa deste processo, é por vezes chamado "frontal autenticação". Servidores que estão executando o Windows Server 2008/Vista ou posterior, e os clientes executando o Windows XP SP3 ou posterior, suportar NLA. Porque NLA baseia-se em uma tecnologia chamada protocolo Credential Security Support Provider (CredSSP), se você estiver usando um cliente Remote Desktop Protocol (RDP) para outro sistema operacional, você precisará pedir seu desenvolvedor se suporta o ELN.
Então, por que está apresentando credenciais antes de criação de sessão de uma coisa tão boa? Existem dois principais benefícios para não criar uma sessão até que você esteja certo a pessoa a tentar ligar é autorizada a fazê-lo: Ele oferece uma camada de defesa contra ataques de negação de serviço (DoS) e acelera o processo de intermediação.
Iniciando uma sessão — até mesmo apresentando uma tela de logon — requer que o servidor criar muitos dos processos necessários para oferecer suporte a uma sessão, tais como o Csrss. exe e Winlogon. exe. Por causa disto, criação de sessão é relativamente demorado e caro. Se um número de usuários não autorizados tentou se conectar a uma sessão ao mesmo tempo, eles poderiam bloquear outros potencialmente de usar esse servidor porque ele criado sessões para aceitar essas credenciais de login falso.
O problema de desempenho é mais crítico. No Windows Server 2003, fazendas foram relativamente raras. Começando com o Windows Server 2008, fazendas tornou-se mais comuns. Lembre-se de que cada servidor em um farm de servidores de terminal é potencialmente um redirecionador. Se o servidor host deve criar uma sessão inteira antes de redirecionar uma solicitação de conexão para a conexão de RD, isso diminui o tempo de conexão.
NLA usa CredSSP para apresentar as credenciais do usuário para o servidor de autenticação antes de criar uma sessão. Este processo evita ambos esses problemas. Usar CredSSP tem também outros benefícios. CredSSP pode reduzir o número de logons, que um usuário deve fazer ao armazenar credenciais para uma determinada conexão.
A primeira vez que um usuário se conecta a um servidor novo, máquina virtual (VM) ou até mesmo de outro PC, eles precisam fornecer suas credenciais. No entanto, eles também têm a opção de salvá-los. Se o fizerem, eles não precisarão fornecer credenciais novamente para essa conexão até que eles alterarem sua senha.
Como CredSSP suporta NLA
O protocolo de CredSSP ajuda aplicativos com segurança delegar credenciais de usuário de um cliente para um servidor de destino. Este protocolo estabelece primeiramente um canal criptografado entre o cliente e o servidor de destino usando segurança de camada de transporte (TLS) (como especificado em [RFC2246]).
Quando você se conectar a um servidor de terminal com uma RDC 6. x ou mais recente cliente, você deve ter notado que não conectar-se diretamente para a tela de logon do servidor de terminal para fornecer suas credenciais. Em vez disso, uma caixa de diálogo local aparece para levar suas credenciais no cliente. Esta caixa de diálogo é o front-end de CredSSP.
Quando você digita suas credenciais para esta caixa de diálogo, mesmo se você não optar por salvá-los, eles vão para CredSSP. Esta então passa as credenciais para o servidor de terminal através de um canal seguro. O servidor de terminal só vai começar a construir uma sessão de usuário depois que ele aceita essas credenciais.
Os clientes que suportam CredSSP e RDP 6. x e mais tarde serão sempre usam NLA se ele estiver disponível. Porque CredSSP (a tecnologia que suporta NLA) é parte do sistema operacional e não faz parte do RDP, o sistema operacional cliente deve oferecer suporte CredSSP para NLA trabalhar.
Portanto, embora haja um cliente RDC 6.0 disponível para o Windows XP SP2, isso não deixa Windows XP SP2 usar NLA. Clientes que executam o Windows XP SP3, Windows Vista e o Windows 7 suportam CredSSP. Também, o RDC irá dizer-lhe se ele suporta o ELN na tela sobre. Para ver isso, clique no ícone do computador no canto superior esquerdo da RDC e escolha "sobre". Isso indicará se ele suporta NLA.
Windows XP SP3 oferece suporte CredSSP, mas não tê-lo ativado por padrão. Para habilitá-lo, a Microsoft lançou um artigo da base de conhecimento com uma corrigi-lo para Me ligar. O artigo também explica como habilitar CredSSP manualmente. Depois que você ativa CredSSP, reinicie o computador.
Se sua máquina cliente não é configurada corretamente para suportar NLA você receberá uma mensagem dizendo que assim quando você tenta uma conexão remota a uma máquina que requer NLA. Por exemplo, se seu cliente Windows XP SP3 não tem CredSSP habilitado, você obterá este erro quando você tenta uma conexão remota para um servidor de terminal que exigido NLA: "O computador remoto requer autenticação no nível da rede, que não oferece suporte a seu computador".
Como forçar o uso do NLA
Servidores de terminal não requerem NLA por padrão. Você pode configurá-los para permitir conexões somente de computadores que suportam o ELN, por meio da diretiva de grupo ou em uma base por servidor de configuração do Host da Sessão RD.
Para exigir NLA para conexão com o servidor de terminal em uma base por servidor, abra o configuração do Host da Sessão RD. Clique duas vezes na RDP-Tcp (sob a seção Connections) e na guia geral, marque a caixa de seleção Permitir conexões somente de computadores executando o Remote Desktop com autenticação no nível da rede. Isso impedirá que todos os clientes que não suportam NLA (ou seja, qualquer cliente que executa o RDC anteriores à versão 6.x e qualquer sistema operacional não suporte CredSSP) de se conectar ao servidor.
Para habilitar o ELN via Diretiva de grupo, habilitar a seguinte diretiva e aplicá-lo para o servidor de terminal OU: Configuração do computador | Políticas | Modelos administrativos | Componentes do Windows | Serviços de área de trabalho remota | Host de sessão de área de trabalho remota | Segurança | Exigir autenticação de usuário para conexões remotas usando autenticação no nível da rede.
Desativar ou não definir esta política significa que o ELN não é necessária.
Solicitações VDI
Para implantações virtual desktop infrastructure (VDI), você também pode restringir o Windows Vista e Windows 7 para aceitar solicitações de conexão somente de clientes que suportam NLA. Vá ao painel de controlo | Sistema | Configurações remotas. Na guia Remoto da caixa de diálogo Propriedades do sistema, selecione a opção para permitir conexões somente de computadores executando Remote Desktop com NLA (mais seguro).
Isso deve explicar por que NLA habilitação em seus servidores de terminal e VDI VMs são uma boa idéia. Você deve compreender como exigir NLA em seus servidores e VDI VMs e como configurar computadores cliente para suportar NLA.
Certificados, enquanto mencionados apenas brevemente, são uma parte essencial de qualquer implantação de RDS. E isso não é apenas NLA, mas também para autenticação de servidor, usando o Gateway RD, acesso via Web RD e até mesmo conexão RD. Próxima vez vou mergulhar mais em requisitos de certificação para implantações de RDS.
.jpg)
Kristin Griffiné um MVP de serviços de Desktop remoto. Ela modera um fórum Microsoft dedicado a ajudar a Comunidade computação baseada em servidor (serviços de área de trabalho remota) e mantém um blog RDS no blog.kristinlgriffin.com. Ela é um colaborador "Mastering Windows Server 2008" de Mark Minasi (Sybex, 2008) e "Dominando o Windows Server 2008 R2" (Sybex, 2010). Ela também co-autor de "Microsoft Windows Server 2008 Terminal Services Resource Kit" (Microsoft Press, 2008) e "Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit" (Microsoft Press, 2010) com Christa Anderson.
NLA perguntas e respostas
**P.**Estou executando o Windows XP SP3. Eu tenho habilitado CredSSP, mas eu ainda recebo o seguinte erro ao se conectar a um servidor de terminal requer NLA: "Um erro de autenticação ocorreu".
. Há um hotfix resolve esse problema no meu blog.
Este erro também ocorrerá sob esta circunstância específica com esses fatores presentes:
- O cliente está executando o Windows XP SP3 com CredSSP habilitado.
- Você configurou o servidor para usar um certificado SSL real para se identificar (ele não está usando o certificado gerado automaticamente que existe por padrão).
- O cliente não confia o certificado usado para assinar o certificado SSL usado no servidor.
Porque NLA requer um canal seguro através da qual recebe credenciais, e ele não é possível criar este túnel se ele não confiar no certificado, NLA não vai funcionar. Para corrigir esse problema, certifique-se da que máquina cliente XP possui o certificado usado para assinar certificados SSL do servidor de terminal instalado no seu certificado de autoridades de certificação raiz confiáveis do computador armazenar pasta.
Observação: Este erro específico pode variar ligeiramente de RDC 6. x para RDC 7.0. Se você instalar o RDC 7.0, você pode receber essa mensagem de erro: "A conexão foi finalizada porque um certificado de autenticação de servidor inesperado foi recebido do computador remoto."