A autenticação AD utiliza dois protocolos principais: Kerberos e NTLM
NTLM
O processo de certificação é o seguinte:
- O cliente gera um hash NTLM localmente, e o valor é o valor hash da senha do usuário.
- O cliente envia o nome de usuário para o servidor de aplicação.
- O servidor de aplicação gera um valor aleatório para o cliente, que geralmente é chamado de nonce ou challenge.
- o cliente criptografa o nonce com hash NTLM e o envia para o servidor de aplicação.
- Após recebê-lo, o servidor de aplicação envia para o servidor AD junto com o nome de usuário e o nonce.
- O AD gera um hash NTLM baseado na senha do usuário, criptografa o nonce e então compara a mensagem do cliente.
- Se os valores forem iguais, a autenticação passa, e se forem diferentes, a autenticação falha.
Kerberos
Termos-chave:
- KDC: Centro de Distribuição de Chaves, que oferece dois serviços: Serviço de Autenticação (AS) e Serviço de Concessão de Tickets (TGS). O domínio gera uma conta chamada krbtgt para KDC, e o TGT usa a senha para criptografia e descriptografia. Quando um usuário de domínio acessa pela primeira vez, ele quer que o AS autentique e, após passar, o AS solicita ao TGS que forneça um ticket (TGT) ao usuário do domínio.
- SPN: Nome do Principal de Serviço。 Além das contas de usuário, as contas do AD também possuem contas de serviço. A aplicação também terá uma conta de serviço associada, que facilitará o acesso dos recursos do servidor, como Exchange, SQL, IIS, etc. SPN é um serviço usado para associar o serviço, habilitado pela aplicação, à conta do serviço no AD.
Processo de Certificação:
1. Quando um usuário do domínio faz login, uma requisição AS (AS_REQ) é enviada ao DC, que contém um carimbo de data criptografado criptografado com o hash da senha e o nome de usuário do usuário.
2. Após receber a solicitação, o DC usa o hash do nome de usuário e senha do usuário para descriptografá-la. O DC responde uma resposta AS (AS_REP) ao cliente, que inclui uma chave de sessão e um TGT (Ticket Granting Ticket). A chave de sessão é criptografada com o hash da senha do usuário. O TGT contém a pertença ao grupo, domínio, carimbo de data, IP do cliente e chave de sessão. O TGT também é criptografado, criptografado com a senha da conta do serviço KDC, e o cliente não pode descriptografá-lo. (O TGT é válido por 10 horas por padrão, e as atualizações que ocorrem depois disso não exigem que o usuário digite novamente a senha)
3. Quando um usuário solicita um recurso no domínio, uma Solicitação de Serviço de Concessão de Bilhetes (TGS_REQ) é enviada, incluindo o nome de usuário, carimbo de data, TGT e SPN. Carimbos de data e nomes de usuário são criptografados com uma chave de sessão.
4. Após receber a solicitação, o KDC primeiro determina se há um SPN na solicitação, depois descriptografa o TGT, extrai a chave de sessão e o carimbo de tempo no TGT, e usa a chave de sessão no TGT para descriptografar o nome de usuário e o carimbo de data criptografados. Realize várias verificações:
(1) O carimbo de data descriptografado pelo TGT deve ser válido. (Se ocorrer um ataque de repetição, o carimbo de tempo é inválido.) ）
(2) Se o nome de usuário no TGT é consistente com o nome de usuário na solicitação.
(3) Se o endereço IP no TGT é o mesmo do endereço IP na solicitação.
A verificação responderá ao ServiceReply (TGS_REP) de concessão de tickets do cliente, que contém o acesso autorizado do SPN, a nova chave de sessão usada para acesso entre o cliente e o SPN, e o novo ticket de serviço do Service Ticket (incluindo a nova chave de sessão, nome de usuário e grupo de usuários). Tanto o SPN autorizado quanto a chave de sessão que acessa o SPN são criptografados com a chave de sessão no TGT. O chamado de serviço é criptografado com a senha da conta de serviço SPN correspondente.
1. Após o processo acima, o usuário obteve a chave de sessão e o ticket de serviço relacionados ao serviço da aplicação. O usuário envia uma Solicitação de Aplicação (AP_REQ) para o serviço de aplicação, que contém o nome de usuário e o carimbo de data, e é criptografada com uma chave de sessão.
2. O serviço de aplicação utiliza o hash da senha da conta de serviço para descriptografar o chamado de serviço e extrair o usuário, grupo de usuários e chave de sessão. Descriptografe o nome de usuário e o carimbo de data no AP_REQ com a chave de sessão descriptografada. AP_REQ Se sim, a solicitação é aceita, e o serviço de aplicação atribui permissões com base nas informações do grupo de usuários no ticket de serviço, e então o usuário pode acessar o serviço solicitado.
Endereço original:O login do hiperlink está visível.
|
Publicado em 22/08/2023 19:16:28
|
|
|
|
