Minha organização está executando o Active Directory, que usa Kerberos para autenticação. Tenho um grupo de computadores Linux que não têm permissão para ingressar no AD. Para autenticação do usuário, configurei o Kerberos e o PAM para apontar para o servidor AD. Depois de adicionar o usuário ao sistema, posso fazer login usando meu nome de usuário e senha do AD. Depois de fazer login, tenho um tíquete. Isso é muito conveniente, pois não preciso manter um conjunto separado de credenciais para os usuários.
Agora eu gostaria de configurar o encaminhamento de tickets entre meu grupo de computadores para não ter que digitar minha senha novamente toda vez. Isso não funciona.
Cenário de exemplo: cliente AD ssh para server1 no meu grupo de computadores não no AD. Posso usar meu nome de usuário e senha para fazer login. Após o login, tenho um tíquete. Agora, quero fazer login no server1 no meu grupo de computadores não no AD. Isso me solicita uma senha novamente. Idealmente, como já tenho um tíquete no cliente AD, não preciso digitar minha senha para nenhum dos logins.
Com base no meu entendimento rudimentar do kerberos , acho que isso está falhando na etapa "TGS-REQ" em que o cliente tenta obter um tíquete de serviço de host (servidor) do kdc. Como meu host não está registrado/adicionado/ingressado, presumo que o KDC/AD não pode fornecer um e essa etapa falha.
Minhas perguntas?
- Estou certo, essa é a causa dos meus problemas?
- Existe alguma maneira de contornar isso para atingir minha meta de logon único usando credenciais do AD?
- E se eu configurar meu próprio KDC/AD/IDM local? Existe uma maneira de apontar isso para o AD principal?
Sim, especificamente para o servidor (alvo SSH) que não tem um principal Kerberos.
Não se trata apenas de uma entrada de BD, no entanto – a parte importante é que uma 'junção de domínio' configura uma chave compartilhada entre o servidor e o KDC (o /etc/krb5.keytab), que é associado ao principal do host do servidor. O Kerberos não pode funcionar sem isso, pois é a única maneira de um serviço verificar a autenticidade de um tíquete.
Não é "um ou ambos"; há três procedimentos distintos que criam um TGS-REQ e cada um espera apenas um princípio específico:
Durante seu login local inicial no sistema (ou seja, login baseado em senha por meio do PAM), o Windows ou o pam_krb5 faz um TGS-REQ para o host principal do seu próprio sistema local como parte da mitigação de "falsificação de KDC", ou seja, garantindo que o PAM não possa ser enganado e aceitar uma senha falsa. (Se você configurou o pam_krb5 em um sistema não associado, ele fica vulnerável à falsificação de KDC.)
Observe que isso não faz parte da aquisição do TGT, como tal – você pode perfeitamente obter tickets e usar o Kerberos sem que o host local tenha seu próprio principal (embora de preferência usando
kinitem vez da integração PAM).Durante a autenticação para serviços remotos (por exemplo, SSH), o cliente faz um TGS-REQ para o principal do host do sistema do servidor (ou algum outro principal de serviço). Por exemplo, se você executar,
ssh mailsrvele fará um TGS-REQ para ohost/mailsrvserviço.Observe que isso não é chamado de "encaminhamento de tíquetes" — esse termo se refere especificamente à delegação irrestrita (que encaminha tíquetes junto com suas chaves de sessão), enquanto a autenticação apenas apresenta um tíquete da mesma forma que um servidor TLS apresenta seu certificado, ou seja, sem nunca enviar a chave privada.
Após a autenticação, se o cliente e o servidor tiverem a opção habilitada, o Kerberos pode copiar todo o seu TGT para o servidor para autenticação de "segundo salto". Isso é o que o Unix Kerberos chama de "encaminhamento de tíquete" (compare com o encaminhamento do agente SSH), e também é conhecido como "delegação irrestrita" no Active Directory. Por razões históricas, o encaminhamento não copia apenas seu TGT como está, mas, em vez disso, faz um TGS-REQ para
krbtgtobter um TGT duplicado.Então, resumidamente, se você tem um TGT e está procurando autenticação Kerberos simples para outros sistemas, então é especificamente o servidor que deve ser unido ao domínio Kerberos – o principal do cliente nunca entra em jogo, então ele não pode ser descrito como "um ou ambos".
Mas o servidor para o qual você está fazendo SSH deve estar associado ao domínio Kerberos – esse é um requisito rígido, pois é a base fundamental do Kerberos como um protocolo: ele depende do serviço e do KDC terem uma chave de criptografia compartilhada (o keytab ou a senha da conta da máquina), que o serviço usaria para verificar o tíquete que recebe.
(O servidor não precisa necessariamente de uma configuração de junção "completa" do AD, com PAM, Samba, Winbindd e tudo mais; mas ele precisa ter uma conta de computador no AD.)
Se você não tiver permissão para criar contas de computador para sistemas Linux, não poderá configurar o Kerberos SSO para fazer SSH neles.
Configurar seu próprio KDC é possível, mas isso contradiria seu objetivo de não ter dois conjuntos de credenciais, pois o novo KDC teria um conjunto separado de contas. Você não pode ter um KDC "proxy".
Embora tecnicamente seja possível ter dois domínios Kerberos confiando um no outro (por exemplo, para que um usuário no domínio A possa obter tíquetes para serviços em ambos os domínios A e B sem precisar de credenciais separadas do domínio B), isso exigiria mais privilégios do que unir as máquinas individuais – exigiria uma "confiança de domínio" em todo o AD.
(Pode ser que os administradores do AD aceitem criar uma relação de confiança somente de saída do AD para seu domínio, já que isso não apresenta nenhum risco de segurança — ele só permite que usuários do AD acessem os servidores em seu domínio, e não o contrário — mas se eles recusarem algo tão básico quanto unir hosts não Windows ao Ad, provavelmente eles ficarão relutantes em sequer tocar na seção de relações de confiança.)
Então, sem privilégios, você só poderia configurar um sistema de ressincronização manual de senhas, onde alguém pode fazer login com seus detalhes do AD e o sistema automaticamente emite uma conta Linux Kerberos. (Na verdade, já vi várias universidades documentarem esse tipo de configuração, por exemplo, quando elas têm um domínio histórico do MIT Kerberos para o departamento de CS e um novo domínio do Windows AD para todos os outros.)
É possível ter mais de um TGT por vez, então você pode executar seu próprio KDC para suas máquinas Linux enquanto ainda obtém tickets AD para máquinas AD, mas isso às vezes pode se tornar uma dor de cabeça. Eu faço isso no meu laptop de trabalho, com TGTs totalmente separados do meu próprio reino Kerberos e do reino AD de trabalho.
No final, pode ser mais fácil usar a autenticação de chave pública SSH (ou até mesmo a autenticação baseada em host SSH , em que seu grupo de hosts confia implicitamente uns nos outros para login SSH).
Tenha em mente que se o sistema não tiver um keytab de host e fizer apenas um AS-REQ, ele estará vulnerável à falsificação de KDC. Se um invasor obtiver o controle da rede primeiro, ele poderá redirecionar todo o tráfego Kerberos para seu próprio KDC e fazer com que ele responda com AS-REPs "bem-sucedidos" e 'krbtgt's para qualquer nome de usuário e senha que o invasor desejar.
A mitigação padrão é fazer com que o sistema cliente use imediatamente o TGT recebido para solicitar um tíquete de serviço para si mesmo , para que ele possa validar esse tíquete em relação à sua própria chave que foi estabelecida anteriormente (ou seja, durante a associação ao domínio – senha da conta da máquina no Windows ou keytab no Linux) e que somente um KDC legítimo saberia.
(A postagem que você mencionou diz: "S1 tenta descriptografar o TGT usando uma chave gerada a partir da sua senha. Se a descriptografia for bem-sucedida, a senha será aceita como correta." Esta é a parte vulnerável, e é onde S1 também faria um TGS-REQ para seu próprio principal "host/S1".)