Estou tentando ingressar em um servidor Ubuntu 14.04 em um domínio do Windows 2003 R2. Meu administrador diz que, do lado do controlador, faz parte do domínio. Mas o SSSD parece não iniciar e a atualização do DNS falha.
Tenho acompanhado vários guias para tentar fazer com que isso funcione, mas não consegui concluir nenhum deles sem erros.
Guia do Servidor Ubuntu
KiloRoot
NetNerds
Fedora SSSD Guide
A descoberta parece estar funcionando bem:
kyle@Server21:~$ realm discover COMPANYNAME.LOCAL
CompanyName.Local
type: kerberos
realm-name: COMPANYNAME.LOCAL
domain-name: companyname.local
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
login-formats: %U
login-policy: allow-realm-logins
companyname.local
type: kerberos
realm-name: COMPANYNAME.LOCAL
domain-name: companyname.local
configured: no
realmd
diz que também estou associado ao domínio:
kyle@Server21:~$ realm join COMPANYNAME.LOCAL
realm: Already joined to this domain
O Kerberos aceitou a autenticação do meu administrador:
kyle@Server21:~$ kinit -V administrator
Using default cache: /tmp/krb5cc_0
Using principal: [email protected]
Password for [email protected]:
Authenticated to Kerberos v5
Mas quando chega a hora de ingressar, a atualização do DNS falha:
kyle@Server21:~$ sudo net ads join -k
Using short domain name -- COMPANYNAME
Joined 'SERVER21' to dns domain 'CompanyName.Local'
No DNS domain configured for server21. Unable to perform DNS Update.
DNS update failed: NT_STATUS_INVALID_PARAMETER
E o SSSD ainda está tendo um problema:
kyle@Server21:~$ systemctl status sssd.service
● sssd.service - System Security Services Daemon
Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2016-06-22 09:57:57 EDT; 37min ago
Process: 16027 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=1/FAILURE)
Jun 22 09:57:55 Server21 sssd[16038]: Starting up
Jun 22 09:57:55 Server21 sssd[16041]: Starting up
Jun 22 09:57:55 Server21 sssd[16042]: Starting up
Jun 22 09:57:56 Server21 sssd[be[16043]: Starting up
Jun 22 09:57:57 Server21 sssd[be[16043]: Failed to read keytab [default]: No such file or directory
Jun 22 09:57:57 Server21 sssd[16031]: Exiting the SSSD. Could not restart critical service [COMPANYNAME.LOCAL].
Jun 22 09:57:57 Server21 systemd[1]: sssd.service: Control process exited, code=exited status=1
Jun 22 09:57:57 Server21 systemd[1]: Failed to start System Security Services Daemon.
Jun 22 09:57:57 Server21 systemd[1]: sssd.service: Unit entered failed state.
Jun 22 09:57:57 Server21 systemd[1]: sssd.service: Failed with result 'exit-code'.
A única parte de krb5.conf
que é específica para mim é a [libdefaults]
:
kyle@Server21:~$ cat /etc/krb5.conf
[libdefaults]
default_realm = COMAPNYNAME.LOCAL
Embora em uma instalação anterior eu achei que havia algo mais em [realms]
, mas não me lembro o quê. O guia do Fedora fala sobre adicionar algo lá quando as pesquisas de DNS não estão funcionando, mas não entra em detalhes suficientes para eu descobrir exatamente o que deveria estar lá.
Minhas modificações no smb.conf
:
[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = COMPANYNAME
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = COMPANYNAME.LOCAL
security = ads
Meu sssd.conf
kyle@Server21:~$ sudo cat /etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = COMPANYNAME.LOCAL
[domain/COMPANYNAME.LOCAL]
id_provider = ad
access_provider = ad
override_homedir = /home/%d/%u
E como o guia do Ubuntu diz que a propriedade e as permissões são importantes:
kyle@Server21:~$ sudo ls -la /etc/sssd
total 12
drwx--x--x 2 sssd sssd 4096 Jun 21 14:34 .
drwxr-xr-x 103 root root 4096 Jun 22 10:21 ..
-rw------- 1 root root 172 Jun 21 14:22 sssd.conf
O guia do Ubuntu também menciona que o arquivo hosts
pode causar problemas com a atualização do DNS, mas acho que segui o exemplo deles corretamente:
kyle@Server21:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 Server21
192.168.XXX.XXX Server21 Server21.COMPANYNAME.LOCAL
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Então, onde estou errado aqui? O controlador de domínio diz que é parte do domínio. Eu tenho o Apache e o OpenSSH ativos e acessíveis. Mas há muito mais que esse servidor vai fazer e, portanto, quero ter certeza de que tudo está configurado corretamente antes de avançar.
Editar:
Eu alterei meu arquivo hosts
com base no conselho de esta página . que se parece com isso agora:
kyle@Server21:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 Server21.COMPANYNAME.LOCAL Server21
192.168.11.11 Server21.COMPANYNAME.LOCAL Server21
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Agora, getent
retorna:
kyle@Server21:~$ sudo getent hosts Server21
127.0.1.1 Server21.COMPANYNAME.LOCAL Server21 Server21
192.168.11.11 Server21.COMPANYNAME.LOCAL Server21 Server21
E net ads join
agora tem uma mensagem de erro diferente:
kyle@Server21:~$ sudo net ads join -k
Failed to join domain: failed to lookup DC info for domain 'COMPANYNAME.LOCAL' over rpc: An internal error occurred.
Até agora, o único conselho que encontrei sobre esse erro diz para garantir que o servidor do AD esteja em resolv.conf
e que o IP seja a única entrada.
kyle@Server21:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.XXX.XXX
Para responder um comentário:
kyle@Server21:~$ nslookup -type=SRV _ldap._tcp.companyname.local
Server: 192.168.XXX.XXX
Address: 192.168.XXX.XXX#53
_ldap._tcp.companyname.local service = 0 100 389 companynamedc.companyname.local.
Em algum lugar ao longo do caminho, o SSSD foi capaz de iniciar e agora está ativo. Embora eu não tenha certeza do que fiz, consertei isso.