Emita autenticação no servidor Centos 7 associado ao AD

1

Usando este link , eu configurei um servidor que esteja devidamente associado a um servidor do Active Directory, mas por algum motivo não consigo autenticar nesse servidor com um ticket do kerberos em vários usuários de teste que fiz no meu laptop.

Todos os usuários no meu laptop local têm o mesmo .ssh / config e todos usam o mesmo /etc/krb5.conf; Todos os usuários também podem obter com sucesso um ticket válido do AD, usando kinit. No entanto, os problemas surgem quando eu tento enviar o ssh para o servidor acima mencionado que está associado ao AD.

Quando tento fazer o login com minha própria conta, 'parkel', ele me pergunta a senha, eu digito minha senha do AD e sou autenticado para fazer login no servidor, na primeira vez que eu fiz login, meu homedir foi feito corretamente e fui designado para os grupos que foram definidos em gidNumber no AD; tudo parecia bem no mundo. Eu testei a alteração de gidNumber no AD, todas as alterações estavam ativas imediatamente após o relogging. Tudo ainda parecia bem no mundo.

Foi quando os problemas começaram; depois de ver o meu sucesso, fiz duas contas de teste no AD, cópias da minha própria conta do AD que estava trabalhando antes, 'test1' & 'test2'. Eu mudei para essa conta no meu laptop, fiz kinit e consegui um ingresso. No entanto, quando tentei fazer o login no servidor, ele só está tentando autenticar com senha e nenhuma menção é feita nos logs que está tentando autenticar usando o pam_sss, já que o usuário local não existe, isso falhará miseravelmente.

Eu verifiquei muito mais pesquisas e documentação do google do que gostaria de admitir, mas estou realmente perdido aqui; Tenho certeza que estou negligenciando alguns pequenos detalhes estúpidos, mas eu realmente não consigo descobrir onde estou dando errado.

Incluem-se algumas saídas do log do sshd no servidor e meu krb5.conf no servidor e no meu cliente.

saída SSHD

Dec 10 11:59:04 ldaptest.vs.lan sshd[2384]: Authorized to parkel, krb5 principal [email protected] (ssh_gssapi_krb5_cmdok)
Dec 10 11:59:04 ldaptest.vs.lan sshd[2384]: Accepted gssapi-with-mic for parkel from 192.168.100.2 port 56752 ssh2
Dec 10 11:59:04 ldaptest.vs.lan systemd[1]: Created slice user-2001.slice.
Dec 10 11:59:04 ldaptest.vs.lan systemd[1]: Starting Session 3 of user parkel.
Dec 10 11:59:04 ldaptest.vs.lan systemd[1]: Started Session 3 of user parkel.
Dec 10 11:59:04 ldaptest.vs.lan systemd-logind[776]: New session 3 of user parkel.
Dec 10 11:59:04 ldaptest.vs.lan sshd[2384]: pam_unix(sshd:session): session opened for user parkel by (uid=0)
Dec 10 11:59:10 ldaptest.vs.lan sshd[2410]: Invalid user test1 from 192.168.100.2
Dec 10 11:59:10 ldaptest.vs.lan sshd[2410]: input_userauth_request: invalid user test1 [preauth]

KRB5.conf SERVER

[libdefaults]
    default_realm = VS.LAN 
    dns_lookup_realm = false
    dns_lookup_kdc = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = yes

[realms]
    VS.LAN = {
        kdc = ad01-test.vs.lan:88
        admin_server = ad01-test.vs.lan:749
        default_domain = vs.lan
    }

[appdefaults]
    pam = {
        debug = true
        ticket_lifetime = 36h
        renew_lifetime = 36h
        forwardable = true
        krb4_convert = false
    }

[logging]
    default = FILE:/var/log/krb5/kdc.log
    kdc = FILE:/var/log/krb5/kdc.log
    admin_server = FILE:/var/log/krb5/kadmind.log

CLIENTE KRB5.conf

includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = false
 rdns = false
 default_realm = VS.LAN 
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
 VS.LAN = {
  kdc = 172.19.254.5
 }

[domain_realm]
 .vs.local = VS.LAN
 vs.local = VS.LAN

SSSD.conf SERVER

[sssd]
domains = vs.lan
services = nss, pam, pac
config_file_version = 2

[nss]

[pam]

[pac]

[domain/vs.lan]
## Comment out if you want offline logins
# cache_credentials = true
ldap_id_mapping = False
default_shell = /bin/bash
fallback_homedir = /home/%d/%u

id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

ldap_schema = ad

dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600

ad_server = ad01-test.vs.lan
    
por Peter van Arkel 10.12.2015 / 12:29

2 respostas

1

Como referência futura, essa linha de registro é a chave:

Dec 10 11:59:10 ldaptest.vs.lan sshd[2410]: Invalid user test1 from 192.168.100.2

Ele diz que o ssh pode até encontrar o usuário, portanto, a próxima etapa na depuração deve ser ativar os logs do sssd e ver por que getent passwd test1 não está funcionando.

O glad sssd funciona para você agora!

    
por 14.12.2015 / 10:26
0

Eu finalmente resolvi meu problema com as configurações dos valores corretos uidNumber, gidNumber, homeDirectory e loginShell no AD para o usuário 'test1'; aparentemente, quando copiei meu usuário de trabalho, esses valores não foram copiados juntamente com todo o restante das informações.

    
por 10.12.2015 / 13:38