relacionamento complexo Kerberos e LDAP

Question

Tenho problemas para entender a relação entre o LDAP e o Kerberos (conceitualmente).

Eu entendo o LDAP como um serviço de diretório e o Kerberos como um serviço de autenticação.

Também sabemos que o LDAP também é capaz de armazenar senhas, mas o design do LDAP deve ser um diretório publicamente acessível e não adequado para armazenar informações confidenciais. É por isso que é preferível delegar a autenticação para outro serviço, como o Kerberos.

Agora, o que eu não entendo são essas duas perguntas:

1. Para qual servidor os clientes enviam sua solicitação quando um usuário tenta efetuar login? Minha intuição me diz que deve ser o servidor Kerberos. Se sim, onde entra o servidor LDAP?
2. Onde o sysadmin define as permissões? Neste caso, minha intuição me diz LDAP. Posso imaginar que poderia haver uma entrada para cada sistema e / ou serviço, e os usuários receberiam acesso a eles por meio de associações a grupos ou diretamente. Se sim, isso significa que o servidor LDAP (através de uma interface como o phpLDAPadmin) irá definir grupos e usuários de acordo com o servidor Kerberos?

Estou particularmente confuso porque vejo a conexão entre o LDAP e o Kerberos em ambas as documentações. O LDAP fala sobre a delegação de autenticação para o Kerberos aqui , e o Kerberos fala sobre ter o LDAP como um back-end aqui .

Todas as documentações que eu leio parecem ser peças de um quebra-cabeça que não consigo juntar. Eu aprecio se alguém pudesse explicar como fazer isso.

    

Answer 1

Ah, faz muito tempo. Vamos ver o que eu consigo lembrar.

Sim, definitivamente pode ser confuso porque você pode usar o Kerberos para autenticar para o LDAP, e também pode usar o Kerberos como LDAP como back-end. Embora eles não sejam a mesma coisa, é difícil diferenciar qual deles está sendo falado quando você tenta procurá-lo. Eu só posso falar sobre o LDAP usando o Kerberos para sua autenticação, já que não tenho experiência com isso do contrário.

1. Sua intuição está certa ao usar o servidor Kerberos. Pelo que entendi, o cliente solicita um TGT do servidor Kerberos para o servidor LDAP (usando o nome principal do serviço de "ldap/[email protected]" ou similar). O cliente pode usar isso para efetuar login no servidor LDAP, pois ele pode validar o ticket. A senha do cliente em si nunca é enviada para o servidor LDAP.
2. Isto é, se você estiver usando o LDAP como backend para o Kerberos, imagino. Você poderia usar um diretório LDAP aqui para salvar atributos e valores para várias coisas. Você, é claro, não tem para usar o LDAP como back-end para o Kerberos.

As coisas ficam ainda mais complicadas quando começam a falar sobre o SASL porque é difícil dizer se estão falando sobre o SASL no front-end ou no back-end do LDAP. Em outras palavras, ele está sendo usado pelos clientes para autenticar no LDAP? Ou ele está sendo usado pelo LDAP para passar a senha para outra fonte de autenticação? Apenas advertências para assistir.

Como um aparte: É possível usar uma ligação simples com o LDAP, enviar a senha para o servidor LDAP, que então passa a senha para outra fonte de autenticação (como o Kerberos). Se você está fazendo algo assim, é legal porque a senha em si não é armazenada no LDAP, mas como uma simples ligação é um texto claro, você deve usar o TLS entre o cliente e o servidor LDAP.

Espero que isso ajude um pouco. Parece que você basicamente tem a ideia certa.

    

Answer 2

Sua intuição está no caminho certo em ambos os casos. Vamos fazer as duas perguntas, uma por uma.

1. Aqui, o serviço kerberos é o sistema autenticação . O cliente receberá um ticket criptografado do servidor kerberos (após a autenticação bem-sucedida do curso) e apresentará isso ao servidor para mostrar que ele está autenticado.
2. Aqui, o serviço ldap é o sistema autorização . As informações do usuário são armazenadas no diretório (como UID / GID, etc.). Em essência, isso substitui as informações em / etc / passwd. O servidor ldap não atualiza nenhuma informação no servidor kerberos.

Answer 3

Isso realmente depende da sua configuração. Eu tenho lutado com isso por um tempo, mas não sou especialista.

Para um administrador do sistema, o relacionamento entre o LDAP e o Kerberos pode ser tão simples quanto uma máquina usando os dois. Sua configuração pode ser tão simples quanto usar o LDAP como fonte de / etc / passwd e / etc / group via nsswitch.conf (e um plugin como nss-pam-ldapd do repositório archlinux), deixando o atributo userPassword no LDAP como uma exclamação ponto ou asterisco (ou seja, sem senha e sem capacidade de login).

Um Kerberos KDC fornecendo a autenticação de senha para qualquer máquina que você deseje, onde a integração de login do sistema seria diferente dependendo do serviço oferecido. Por exemplo, se for uma máquina remota que exige apenas acesso via ssh, o LDAP ainda fornece as mesmas informações que em qualquer outro lugar, mas o Kerberos só precisa de algumas linhas nos arquivos de configuração do ssh. Em outro sistema em que a integração completa de login é necessária, isso pode acabar sendo um grande problema, porque requer muitas mudanças na configuração dos PAMs. Isso é fácil em clientes RHEL com authconfig, mas espera-se que seja uma grande dor de cabeça em outro lugar, a menos que você esteja confortável com o PAM. O lado positivo de fazê-lo funcionar com o PAM é que a maioria dos programas (como o ssh) pode usar o PAM, então você não precisa mais se preocupar com a configuração do ssh.

Em outras palavras, se o KDC estiver inativo, o sistema nunca aceitará sua senha ou não (mas saberá que você é um usuário por causa do LDAP) e, se o servidor LDAP estiver inativo, o sistema achará seu nome de usuário não existe.