Como determinar a região do Kerberos a partir de um diretório LDAP?

Question

Eu tenho dois domínios do Kerberos nos quais posso autenticar. Um deles eu posso controlar, e o outro é externo do meu ponto de vista. Eu também tenho um banco de dados interno do usuário no LDAP. Digamos que os reinos são INTERNAL.COM e EXTERNAL.COM. No ldap eu tenho entradas de usuário como esta:

1054 uid=testuser,ou=People,dc=tml,dc=hut,dc=fi
shadowFlag: 0
shadowMin: -1
loginShell: /bin/bash
shadowInactive: -1
displayName: User Test
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uidNumber: 1059
shadowWarning: 14
uid: testuser
shadowMax: 99999
gidNumber: 1024
gecos: User Test
sn: Test
homeDirectory: /home/testuser
mail: [email protected]
givenName: User
shadowLastChange: 15504
shadowExpire: 15522
cn: User.Test
userPassword: {SASL}[email protected]

O que eu gostaria de fazer, de alguma forma, é especificar por usuário a qual servidor / domínio de autenticação o usuário é autenticado. Configurar o kerberos para lidar com múltiplos reinos é fácil.

Mas como configurar outras instâncias, como o PAM, para lidar com o fato de que alguns usuários são de INTERNAL.COM e alguns de EXTERNAL.COM? É preciso haver uma pesquisa LDAP de algum tipo de onde o domínio e o nome de autenticação são buscados e, em seguida, a autenticação propriamente dita.

Existe uma maneira padronizada de adicionar essas informações ao LDAP ou procurá-las? Existem algumas outras soluções alternativas para uma base de usuários multi-realm? Eu posso estar bem com uma única solução de domínio, também, desde que eu possa especificar o nome de usuário - combinação de domínio para o usuário separadamente.

    

Answer 1

Acho que a melhor abordagem seria usar sssd . Isso lhe dá a maior flexibilidade, pois o sssd suporta o que ele chama de domínios. Note que as Distros mais novas já usam sssd. É um sonho realizado e não há desculpa para usar libpam_krb5.so e libpam_ldap.so ou qualquer um deles.

A abordagem mais simples seria usar um filtro ldap para selecionar em qual região você precisa ir para tgts como este:

Primeiro, crie dois grupos de segurança que contenham os membros para realms internos e externos para poder obter o kdc adequado.

Configure sssd e verifique sua documentação, este trecho é um esboço de como você precisa configurar os dois domínios.

[domain/internal.com]
access_provider = ldap
id_provider = ldap
ldap_access_filter = memberOf=cn=allowedusersinternal,ou=Groups,dc=internal,dc=com
auth_provider = krb5 

[domain/external.com]
access_provider = ldap
ldap_access_filter = memberOf=cn=allowedusersexternal,ou=Groups,dc=internal,dc=com
id_provider = ldap
auth_provider = krb5

Em seguida, configure seus kerberos para os dois reinos de acordo com a necessidade (mas você já conseguiu isso).

    

Answer 2

As configurações que você está procurando estão em /etc/krb5.conf aqui você pode armazenar múltiplos reinos sob a tag [realms], cada um apontando para seu próprio servidor LDAP.

[realms]
       INTERNAL.COM = {
               kdc = some.server.internal.com:88
               admin_server = some.server.internal.com:749
               default_domain = internal.com
       }
       EXTERNAL.COM = {
               kdc = some.server.external.com:88
               admin_server = some.server.external.com:749
               default_domain = external.com
       }  

    

Answer 3

pam_ldap
Para a entrada do exemplo LDAP ssh password / challenge-response já é suficiente.
Modifique o (s) arquivo (s) apropriado (s) em /etc/pam.d para usar a biblioteca pam_ldap .
Configuração Autenticação de passagem SASL em seu (s) servidor (es) OpenLDAP.
RHEL (CentOS): nss_ldap
Debian: libpam-ldap
Ubuntu: ldap-auth-client

krb5.conf
auth_to_local deve funcionar para autenticação baseada em GSSAPI.

[realms]
$LOCALREALM = {
auth_to_local = RULE:[1:$1]
auth_to_local = DEFAULT
}
This might be too permissive.

! pam_krb5 alt_auth_map não deveria funcionar como cotado na página man antes de OpenSSH will reject usernames that don't match local accounts

    

Answer 4

O modo do Windows de se autenticar em domínios diferentes é especificar o domínio além do nome de login. Então, é aceitável que você faça algo semelhante e faça com que as pessoas façam login como usuá[email protected] ou usuá[email protected]? E se você acabou de usar o "user3" você pode entrar no domínio padrão.

De acordo com o pam_krb5 (5), isso é possível:

If the username provided to PAM contains an "@" and Kerberos can, treating the username as a principal, map it to a local account name, pam_authenticate() will change the PAM user to that local account name. This allows users to log in with their Kerberos principal and let Kerberos do the mapping to an account.

Infelizmente, continua:

Be aware, however, that this facility cannot be used with OpenSSH. OpenSSH will reject usernames that don't match local accounts before this remapping can be done and will pass an invalid password to the PAM module. Also be aware that several other common PAM modules, such as pam_securetty, expect to be able to look up the user with getpwnam() and cannot be called before pam_krb5 if this feature is used.