AD Domain juntou-se ao servidor Linux equivalente ao NLA

Question

Primeiro, algumas informações básicas.

Hoje, se você estiver em um ambiente AD predominantemente Windows Server com apenas um pequeno número de servidores Linux, você terá a opção de autenticar nos servidores via SSH:

1. Gerencie os servidores Linux via SSH com autenticação de certificado (o modo normal do Linux)
2. Junte os servidores Linux ao seu domínio AD (realm+sssd) e gerencie-os via SSH com autenticação de nome de usuário/senha

O problema é que a opção 1 deixa os administradores gerenciarem um conjunto separado de credenciais do resto do ambiente, e a opção 2 faz com que os administradores forneçam senhas diretamente aos servidores remotos pela rede antes que as máquinas se identifiquem totalmente.

No mundo Windows, isso é resolvido (pelo menos para RDP, que eu sei que deve ser evitado) por meio da autenticação em nível de rede. Uma versão simplificada do processo é assim:

1. O usuário começa a se conectar ao computador remoto
2. O computador remoto responde com token de conta de computador AD
3. O computador local valida o token, vê o suporte do NLA e mostra uma caixa de diálogo de credenciais ao usuário
4. O usuário completa a caixa de diálogo com credenciais
5. O computador local valida credenciais com o controle de domínio (não o computador remoto)
6. O DC fornece ao computador local um token de autenticação
7. O computador local apresenta o token ao computador remoto
8. O computador remoto valida o token no domínio
9. Em caso de sucesso, o usuário terá permissão para acessar o computador remoto.

Na verdade, o processo pode ser ainda mais simples, onde o token de autenticação existente criado para o usuário quando ele efetuou login pela primeira vez no computador local já pode ser usado.

Este é um processo complexo e certamente cometi erros ao descrevê-lo. A questão é que o token de autenticação substitui o certificado da história do Linux, de forma que o usuário nunca forneça credenciais reais para uma máquina potencialmente desconhecida. Além disso, a confiança de todas as partes no controlador de domínio confiável torna as coisas ainda melhores do que a história do Linux, porque o usuário não precisa gerenciar seus próprios certificados, mesmo através de seu próprio software (em vez disso, é o software fornecido para eles).

---

Agora, a pergunta. Existe uma maneira de obter algo semelhante para autenticar uma sessão SSH em um servidor Linux associado ao AD, onde o servidor nunca vê as credenciais do usuário, mas a experiência do usuário ainda é a validação de credenciais nativas do Windows?

Answer 1

Isso é muito para resolver, mas essencialmente o que é necessário é um SSH "kerberizado" ou algo assim. O NLA também fornece uma etapa adicional (não especificada aqui) de não fornecer uma sessão de console (cuja criação é dispendiosa em termos de recursos) até que a autenticação seja validada.

Mais especificamente, além das complexidades, que são proibitivas, não vejo grande interesse nisso porque já existe uma solução alternativa. Use um host bastion jump para front-end dos hosts Linux, proibindo o tipo de acesso/porta(s) de outros. Esse host bastião pode ser o Windows e oferecer suporte a todos os recursos que estão faltando.

Os hosts Bastion Jump também estão se tornando mais comuns em ambientes AD por permitir tipos de acesso como RDP a recursos protegidos.

Também para o exemplo RDP, as credenciais não estão realmente protegidas do servidor. Isso é resolvido usando a opção /RemoteGuard.

https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mstsc