Linux, autenticação de senha básica em 2 AD diferentes sem ingressar no domínio

Linux, autenticação de senha básica em 2 AD diferentes sem ingressar no domínio

Temos servidores AIX e Linux rodando com autenticação de senha básica em um Windows AD usando Kerberos, portanto são usuários locais com um nome de usuário idêntico ao seu sAMAccountName no AD e tudo o que é feito é a verificação de senha.

Ambos os sistemas operacionais usam um krb5.conf simples

    [libdefaults]
        default_realm = COMPANYA.COM

    [realms]
            COMPANYA.COM {
                    kdc = ad.companya.com:88
                    admin_server = ad.companya.com:749
            }
    
    [domain_realm]
            .companya.com = COMPANYA.COM
            companya.com = COMPANYA.COM

Isso funciona bem em ambos os sistemas operacionais.

Temos agora a situação de que haverá uma empresa B e portanto também um 2º AD. Um usuário nunca estará disponível em ambos os ADs, apenas em qualquer um deles.

Então comecei no AIX porque imaginei que seria o mais difícil de fazer funcionar.

Atualizado o krb5.conf

[libdefaults]
    default_realm = COMPANYA.COM

[realms]
        COMPANYA.COM {
                kdc = ad.companya.com:88
                admin_server = ad.companya.com:749
        }
        COMPANYB.COM {
                kdc = ad.companyb.com:88
                admin_server = ad.companyb.com:749
        }

[domain_realm]
        .companya.com = COMPANYA.COM
        companya.com = COMPANYA.COM
        .companyb.com = COMPANYB.COM
        companyb.com = COMPANYB.COM

Depois de um pouco de pesquisa, parecia que tudo que eu precisava fazer era

chuser auth_domain=COMPANYB.COM <user>

isso atualiza o arquivo /etc/security/user e fará a validação da senha na Empresa B AD. Fiquei agradavelmente surpreso com o quão fácil isso foi.

Em seguida veio o Linux (caixas Ubuntu). Fiz o mesmo krb5.conf, mas infelizmente não consigo encontrar o comando equivalente para chuser no Ubuntu para apontar esse usuário específico para o outro AD.

O que posso encontrar são páginas sobre como usar sssd e ingressar no reino (Linux SSSD com dois domínios ADe/ouhttps://ubuntu.com/server/docs/service-sssd-ad), mas tudo isso é mais do que necessário (juntar-se aos reinos).

o que descobri até agora usando tcpdump e kinit é o seguinte:

kinit [email protected] 
<password>
kinit: KDC reply did not match expectations while getting initial credentials

kinit [email protected]
<password>
<no error>

login [email protected]
<password>
access denied

login [email protected]
<password>
access denied

Como o kinit com letras maiúsculas funcionava, eu suspeitava que o login funcionaria, mas infelizmente não funcionou.

atualização: login[e-mail protegido]funciona se o usuário for criado na caixa Linux como[e-mail protegido], ainda não estou feliz com isso

(esquecendo o fato de que não é realista pedir aos usuários que escrevam seus domínios em letras maiúsculas)

Resumindo, como apontar usuários específicos para outro AD diferente do padrão no arquivo krb5.conf.

Cumprimentos,

Responder1

bem, cheguei um pouco mais longe na semana passada e isso parece funcionar. Embora eu ainda esteja analisando os detalhes exatos de como o PAM funciona.

atualizou/alterou o /etc/pam.d/common-auth

original

auth   [success=2 default=ignore]      pam_krb5.so minimum_uid=1000
auth   [success=1 default=ignore]      pam_unix.so nullok try_first_pass

nova versão

auth    sufficient           pam_krb5.so minimum_uid=1000 realm=COMPANYA.COM
auth    sufficient           pam_krb5.so minimum_uid=1000 realm=COMPANYB.COM
auth    sufficient           pam_unix.so nullok try_first_pass

ao efetuar login como usuário da empresa A ele verifica o AD da empresa A e como o usuário existe lá a senha é verificada. ao logar como usuário da empresa B ele verifica o AD da empresa A, o usuário não existe lá e então vai verificar a empresa B e como o usuário existe lá a senha é verificada.

não é tão bom quanto o AIX, mas mesmo assim funciona.

Cumprimentos,

informação relacionada