Problemas ao ingressar em um domínio do Active Directory

1

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.

    
por embedded.kyle 22.06.2016 / 16:55

1 resposta

1

O problema parece ter sido que meu administrador criou uma entrada no controlador de domínio para esse servidor. Isso aparentemente causou um conflito que causou o Kerberos a encontrar o seguinte erro ao tentar ingressar:

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.

Não tenho certeza se esse erro foi totalmente correto, pois meu administrador disse que o servidor estava associado ao domínio e realmd indicou que eu também participei:

kyle@Server21:~$ realm join COMPANYNAME.LOCAL
realm: Already joined to this domain

As etapas que segui para obter uma associação bem-sucedida do Kerberos foram as seguintes:

  1. o administrador removeu a entrada no controlador de domínio
  2. Configuração do Kerberos Reran usando: sudo dpkg-reconfigure krb5-config
  3. Escolha as opções na configuração para adicionar o Controlador de domínio explicitamente à seção [realms] de krb5.conf
  4. Alterou o nome do host para garantir que um novo registro fosse criado
  5. Puxou um novo ticket usando kinit
  6. Entrou no domínio usando sudo net ads join -k

Resultado final:

kyle@SERV21:~$ sudo net ads join -k  
Using short domain name -- COMPANYNAME  
Joined 'SERV21' to dns domain 'CompanyName.Local'
    
por 30.06.2016 / 17:50