Visão geral

O servidor da Web da Microsoft, o IIS (Serviços de Informações da Internet), integra vários mecanismos de autenticação para validar usuários em relação a sistemas Active Directory ou autônomos (autenticação baseada em LDAP). NTLM é o protocolo de autenticação Desafio / Resposta do Windows que pode ser usado em redes e aplicativos que podem ser usados ​​em ambos os ambientes.

Dois cenários diferentes poderiam ser levados em conta: Autenticação Interativa NTLM é composto de dois sistemas, um cliente e um controlador de domínio, que é usado para armazenar os dados dos usuários necessários para servir autenticações, e Autenticação NTLM não interativa envolve três sistemas diferentes, um cliente, um servidor de aplicativos e um domínio para permitir que um usuário acesse um determinado recurso em um aplicativo.

Representação do asp.net permite que aplicativos da web autentiquem e autorizem usuários que dependem do Microsoft IIS.

Neste artigo, vamos explicar como balancear a carga de aplicativos que integram o protocolo NTLM para cenários de autenticação de usuários não interativos.

Como funciona o NTLM?

O protocolo NTLM depende do protocolo HTTP / S, em que um determinado cliente inicia um handshake de um total de etapas 6 para estabelecer a sessão autenticada.

O handshake da sessão autenticada requer as seguintes etapas:

1. O cliente inicia uma solicitação anônima de um determinado recurso para um servidor da web.

GET / HTTP

2. As respostas do servidor com uma mensagem não autorizada e o método de autenticação que o cliente deve usar.

401 Unauthorized
WWW-Authenticate: NTLM

3. O cliente reenvia a solicitação incluindo um desafio de autenticação de formato NTLM.

GET / HTTP
Authorization: NTLM <base64-encoded first NTLM message>

4. As respostas do servidor com uma mensagem não autorizada e pedidos de mais informações para o cliente.

401 Unauthorized
WWW-Authenticate: NTLM <base64-encoded second NTLM message>

5. O cliente reenvia a solicitação incluindo um restante das informações da sessão.

GET / HTTP
Authorization: NTLM <base64-encoded third NTLM message>

6. O servidor se conecta ao controlador de domínio para concluir a solicitação de autenticação e, em seguida, confirma ao cliente a autenticação.

HTTP 200 OK

Observe que esse handshake é necessário em cada nova conexão, não em solicitações HTTP, e durante as etapas 3 a 6, a conexão deve ser mantida ativa. Se a conexão for fechada, esta parte do handshake deve ser repetida e não é válido apenas repetir a partir da etapa 5. Por outro lado, uma vez que a conexão é autenticada, o cabeçalho de autorização não precisa ser enviado novamente enquanto o a conexão não é fechada independentemente do recurso acessado.

Como balancear a carga de aplicativos da web usando a autenticação NTLM?

Com o Zevenet, existem as principais formas do 2 de balancear a carga e construir um aplicativo da web baseado em NTLM em alta disponibilidade, com um balanceador de carga 4 TCP de camada simples ou com um proxy 7 de camada para recursos avançados.

Balanceamento de carga NTLM simples na camada 4

Para balancear a carga das aplicações web com suporte à autenticação NTLM com uma configuração simples, podemos criar farms baseados em LSLB com o perfil L4xNAT. Podemos usar protocolos HTTP ou HTTPS.

Então, na configuração global, assegure-se de que o protocolo usado seja TCP mas podemos selecionar NAT or DTA de acordo com a topologia requerida.

Na série Serviços seção, é necessário definir a persistência para garantir que a autenticação de um determinado cliente sempre vá para o mesmo backend, caso contrário, a autenticação da conexão não poderia ser realizada.

Por fim, adicione sua lista de back-ends e configure uma verificação de integridade, conforme indicado nas seções abaixo.

Balanceamento de carga NTLM na camada 7

Essa opção permite manipular os dados HTTP / S com suporte a NTLM com o proxy 7 da camada configurado por meio do módulo LSLB e do farm HTTP. Para isso, precisamos criar um farm para HTTP ou HTTPS de acordo com os requisitos de SSL para o serviço virtual. A única diferença seria o Ouvinte configurado no Configurações globais da fazenda criada.

Nesta camada, como o aplicativo não é capaz de criar qualquer cookie de sessão ainda, a fim de criar uma persistência ou fixação de conexão, podemos fazer uso do Inserção de Cookie opção que permite que o balanceador de carga crie um novo cookie durante o handshake inicial da autenticação NTLM.

Por fim, adicione sua lista de back-ends e configure uma verificação de integridade, conforme indicado nas seções abaixo. Você pode configurar opções de aplicativo adicionais no nível de proxy incluídas nesse tipo de farm e o suporte NTLM não será afetado.

Verificações de integridade avançadas para sites de autenticação NTLM

Para criar nossa verificação de integridade avançada personalizada para aplicativos autenticados por NTLM, devemos criar sob o caminho / usr / local / zevenet / app / libexec um script para verificar o back-end como mostrado abaixo. Por exemplo, check_ntlm.sh com as permissões apropriadas.

#!/bin/bash

# get input parameters
BACKEND=$1
PORT=$2
USER=$3
PASS=$4
URI=$5
STRING=$6

/usr/bin/curl http://${BACKEND}:${PORT}${URI} --ntlm -negotiate -u ${USER}:${PASS} 2>/dev/null | grep "${STRING}" &>/dev/null

if [ $? == 0 ]
then
	# if the curl command doesn't fail then notify that the backend is up
	echo "Server ${BACKEND}:${PORT} OK"
	exit 0
fi

# if the the curl command fails then notify that the backend is down
echo "Server ${BACKEND}:${PORT} is not OK"
exit 1

Na série Monitoramento >> Farmguardian seção, se aplicável, ou adicioná-lo ao comando para fazer o check-in do serviço do farm.

Podemos testar o script de verificação de integridade executando:

/usr/local/zevenet/app/libexec/check_ntlm.sh 192.168.0.99 80 johndoe johnsecret "/my/uri" "DOCTYPE html"

Sabendo que o IP backend é 192.168.0.99 o porto é 80 HTTP johndoe é um usuário fictício em nosso domínio, johnsecret é a senha fictícia “/ Meu / uri” é o URI para verificar e “DOCTYPE html” é a string a ser encontrada nos dados de resposta quando a solicitação é bem-sucedida.

Recomendamos criar um usuário fictício que seja capaz de fazer login no domínio, mas sem permissões, para incluí-lo na verificação de saúde de nossos serviços. Essa é a razão de usar o johndoe usuário fictício em nossa verificação de integridade personalizada.

Quando nossa verificação de integridade é testada a partir da linha de comando e pronta, podemos atribuí-la aos farms configurados com o suporte NTLM.

Aproveite a sua carga balanceada de aplicações web NTLM!