Instalar un Segundo Controlador de Dominio con Samba 4 de Sernet (Parte II)

En el post anterior se explicó la instalación de un Controlador de Dominio con Samba 4 de Sernet. En este post se intentará unir un nuevo Controlador de Dominio al creado anteriormente. Esta es la infraestructura:

Controlador de Dominio 1:

Nombre: pdc-master-1.lab.codesa.co.cu

Dirección IP: 10.0.1.130

Máscara de Subred: 255.255.255.128

Puerta de Enlace: 10.0.1.129

Nombre FQDN del Dominio establecido: lab.codesa.co.cu

Nombre NetBIOS del Dominio establecido: LAB-CODESA

Servidores DNS: 10.0.1.130 (el mismo servidor), 10.0.1.66, 10.0.1.67

Controlador de Dominio 2:

Nombre: pdc-master-2.lab.codesa.co.cu

Dirección IP: 10.0.1.66

Máscara de Subred: 255.255.255.224

Puerta de Enlace: 10.0.1.65

Nombre FQDN del Dominio al que pertenecerá: lab.codesa.co.cu

Nombre NetBIOS del Dominio al que pertenecerá: LAB-CODESA

Servidores DNS: 10.0.1.130, 10.0.1.66 (el mismo servidor), 10.0.1.67

El primer Controlador de Dominio ya está configurado, ahora toca configurar el segundo Controlador. Para ello se deben seguir los pasos en el post anterior desde el paso 1 hasta el paso 9. En otras palabras, realizar todos los pasos, pero no aprovisionando el dominio, dado que los datos los tomará del dominio existente.

Claro está que el contenido de los archivos cambia en algunos aspectos, como se ve a continuación:

Contenido del archivo /etc/resolv.conf:

search lab.codesa.co.cu

nameserver 10.0.1.130

nameserver 10.0.1.67

NOTA: ES FUNDAMENTAL que el cliente DNS esté configurado adecuadamente, o sea, que apunte al servicio DNS del Controlador Primario de Dominio anteriormente configurado. Si esto no se hace, el comando ‘kinit’ se tardará un buen tiempo en encontrar el nombre de dominio o dará un error. Claro, aparte de que todo lo demás dentro del proceso puede fallar.

Contenido del archivo /etc/hosts:

127.0.0.1         localhost                          localhost.localdomain

 

10.0.1.66         pdc-master-2.lab.codesa.co.cu      pdc-master-2

10.0.1.130        pdc-master-1.lab.codesa.co.cu      pdc-master-1

10.0.1.140        ws-lan-1.lab.codesa.co.cu          ws-lan-1

10.0.1.35         ws-admin-1.lab.codesa.co.cu        ws-admin-1

# The following lines are desirable for IPv6 capable hosts

::1     localhost ip6-localhost ip6-loopback

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

 

Contenido del archivo /etc/ntp.conf:

driftfile /var/lib/ntp/ntp.drift

statsdir /var/log/ntpstats/

 

statistics loopstats peerstats clockstats

filegen loopstats file loopstats type day enable

filegen peerstats file peerstats type day enable

filegen clockstats file clockstats type day enable

 

fudge   127.127.1.0 stratum 10

server  127.127.1.0

 

restrict 127.0.0.1

restrict ::1

 

broadcast 10.0.1.63

broadcast 10.0.1.255

 

Contenido del archivo /etc/ssh/sshd_config:

 

Port 53527

Protocol 2

ListenAddress 10.0.1.66

 

AllowUsers bolodia

 

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

 

UsePrivilegeSeparation yes

 

KeyRegenerationInterval 3600

ServerKeyBits 768

 

SyslogFacility AUTH

LogLevel INFO

 

LoginGraceTime 1m

PermitRootLogin no

StrictModes yes

 

RSAAuthentication yes

PubkeyAuthentication yes

 

IgnoreRhosts yes

RhostsRSAAuthentication no

HostbasedAuthentication no

PermitEmptyPasswords no

 

PasswordAuthentication no

 

X11Forwarding no

X11DisplayOffset 10

PrintMotd no

PrintLastLog yes

KeepAlive yes

 

Subsystem       sftp    /usr/lib/sftp-server

 

UsePAM yes

 

10.- Configurar Kerberos

Antes de ponerse a hacer cosas con la herramienta samba-tool, hay que configurar Kerberos. Primeramente se hace una copia de respaldo del archivo de configuración del servicio antes de hacer cualquier cosa, o sea:

# cp /etc/krb5.conf /etc/krb5.conf.orig

Luego modificar el archivo de manera tal que el contenido final sea este:

[libdefaults]

default_realm = LAB.CODESA.CO.CU

dns_lookup_realm = true

dns_lookup_kdc = true

[realms]

LAB.CODESA.CO.CU = {

kdc = 10.0.1.130

kdc = 10.0.1.66

admin_server = 10.0.1.130

}

[domain_realm]

.lab.codesa.co.cu = LAB.CODESA.CO.CU

lab.codesa.co.cu = LAB.CODESA.CO.CU

[login]

krb4_convert = true

krb4_get_tickets = false

Inicializar la contraseña del administrador mediante este comando:

# kinit administrator@LAB.CODESA.CO.CU

Password for administrator@LAB.CODESA.CO.CU:<Introducir contraseña>

Si sale un mensaje como este:

Warning: Your password will expire in 41 days on Mon Dec 22 05:33:17 2014

Quiere decir que el DNS y Kerberos está funcionando apropiadamente.

Luego ejecutar el siguiente comando para ver la lista de tickets activos

# klist -e

Debe salir algo como esto:

Ticket cache:/tmp/krb5cc_0

Default principal: administrator@LAB.CODESA.CO.CU

Valid starting    Expires            Service principal

10/11/2014 06:00  10/11/2014 16:00   krbtgt/LAB.CODESA.CO.CU@LAB.CODESA.CO.CU

renew until 11/11/2014 05:59, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

Ya en este punto se puede proceder a convertir este Servidor de Dominio a Controlador de Dominio del dominio existente.

 

11.- Unir al dominio existente el nuevo Controlador de Dominio

11.1.- Ejecutar el siguiente comando como root:

# samba-tool domain join lab.codesa.co.cu DC -Uadministrator –realm=lab.codesa.co.cu

Esto, aparte de hacer el proceso tradicional de unión del servidor al dominio, Samba 4 utilizará el formato de DNS propio (el DNS interno) como servicio DNS. No obstante, si se desea usar Bind9 como almacén de datos, el comando anterior debe tener la forma siguiente:

# samba-tool domain join lab.codesa.co.cu DC -Uadministrator –realm=lab.codesa.co.cu –dns-backend=BIND9_DLZ

Durante el proceso de unión, se muestra una serie de datos referente a la replicación de datos entre el Controlador de Dominio existente y el nuevo, donde una de las líneas que salen tiene el siguiente aspecto:

(…)

Partition[CN=Configuration,DC=lab,DC=codesa,DC=co,DC=cu] objects[1614/1614] linked_values[28/0]

(…)

Ya al final del proceso, se verá un mensaje parecido a este:

Joined domain SAMBA (SID S-1-5-21-3565189888-2228146013-2029845409) as a DC

Completado todo, el nuevo Servidor de Dominio Samba 4 se ha unido al dominio existente como Controlador de Dominio adicional. No obstante, antes de iniciar el servicio, hay que hacerle algunos cambios al archivo de configuración, que debe verse así:

[global]

workgroup = LAB-CODESA

realm = lab.codesa.co.cu

netbios name = PDC-MASTER-2

server role = active directory domain controller

idmap_ldb:use rfc2307 = yes

server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate, smb

server services = -s3fs +dns

allow dns updates = secure

dns forwarders = 10.0.1.67

dcerpc endpoint servers = +winreg +srvsvc

interfaces = eth0 lo

template shell = /bin/false

log file = /var/log/samba/lab.codesa.co.cu.log

syslog = 0

vfs objects = full_audit

template homedir = /home/users/%ACCOUNTNAME%

[netlogon]

path = /srv/services/samba/data/sysvol/lab.codesa.co.cu/scripts

read only = No

[sysvol]

path = /srv/services/samba/data/sysvol

read only = No

El camino establecido para la carpeta Sysvol puede ser una partición específica del disco duro, otro disco duro o la misma partición donde está instalado el servicio Samba4 de Sernet. En el archivo /etc/fstab se debe añadir algunas características específicas:

/dev/sdb1      /srv/services/samba/data ext4 rw,errors=remount-ro,user_xattr,acl 1 1

Enfatizo que para que se carguen apropiadamente los permisos al estilo Windows, deben estar establecidas las características “user_xattr” y “acl” en la(s) partición(particiones) que utilizará Samba 4 para compartimentación de archivos.

Finalmente, reiniciar el servicio Samba.

Si todo está OK, la salida del comando nmap contra el servidor debe ser o igual o parecido a esto:

root@pdc-master-1:~# nmap -sT -sU 10.0.1.130

Starting Nmap 6.00 ( http://nmap.org ) at 2014-11-16 16:27 CST

Nmap scan report for pdc-master-1.lab.codesa.co.cu (10.0.1.130)

Host is up (0.00025s latency).

Not shown: 1980 closed ports

PORT     STATE         SERVICE

53/tcp   open          domain

88/tcp   open          kerberos-sec

111/tcp  open          rpcbind

135/tcp  open          msrpc

139/tcp  open          netbios-ssn

389/tcp  open          ldap

445/tcp  open          microsoft-ds

464/tcp  open          kpasswd5

636/tcp  open          ldapssl

1024/tcp open          kdm

3268/tcp open          globalcatLDAP

3269/tcp open          globalcatLDAPssl

53/udp   open          domain

88/udp   open|filtered kerberos-sec

111/udp  open          rpcbind

137/udp  open          netbios-ns

138/udp  open|filtered netbios-dgm

389/udp  open|filtered ldap

464/udp  open|filtered kpasswd5

983/udp  open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 1.46 seconds

NOTA: Estos puertos deben estar permitidos en el PC-Router/Router/Cortaguegos en caso de tener subredes internas. En nuestro caso, se tienen dos Controladores de Dominio ubicados en subredes diferentes y se permite la conexión a estos puertos entre ellos.

11.2.- Chequear que el servicio DNS funciona para el nuevo Controlador de Dominio

Antes de iniciar Samba 4, hay que cerciorarse si las entradas DNS correspondientes fueron creadas correctamente durante el proceso de unión al dominio. Esto no siempre funciona 100% en muchos casos, lo cual hace que la opción de completar el proceso manualmente sea algo obligatorio si algo falla.

Para el nuevo equipo, tratemos de resolver su nombre:

Esto se puede hacer de dos maneras:

  • Con el comando ‘dig’:

# dig @10.0.1.130 pdc-master-2.lab.codesa.co.cu

  • Con el comando ‘host’:

# host -t A pdc-master-2.lab.codesa.co.cu.

Si falla la resolución del nombre del nuevo Controlador de Dominio, se debe añadir manualmente el registro A de la siguiente manera:

# samba-tool dns add 10.0.1.130 lab.codesa.co.cu pdc-master-2.lab.codesa.co.cu A ‘10.0.1.66’ -Uadministrator

También se debe chequear si el objectGUID del nuevo servidor se puede resolver. Para ello, basta con ejecutar lo siguiente:

# ldbsearch -H /var/lib/samba/private/sam.ldb ‘(invocationid=*)’ –cross-ncs objectguid

Entonces el resultado se parecería a lo siguiente:

# record 1

dn: CN=NTDS Settings,CN=PDC-MASTER-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=codesa,DC=co,DC=cu

objectGUID: 0dfc9f67-c457-4c55-85d3-2cab3849a029

# record 2

dn: CN=NTDS Settings,CN=PDC-MASTER-2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=codesa,DC=co,DC=cu

objectGUID: ad5c61b3-fdd0-428e-8997-3167b823a211

# returned 2 records

# 2 entries

# 0 referrals

En este caso, el objectGUID del nuevo Controlador de Dominio es 737506d0-bfe6-40c8-815d-08c3dff7a67f. Entonces, mediante el siguiente comando se puede consultar si existe el alias correspondiente:

# host -t CNAME 737506d0-bfe6-40c8-815d-08c3dff7a67f._msdcs.lab.codesa.co.cu.

Esto debe dar como resultado el alias (CNAME) de esta entrada apuntando al nombre del nuevo Controlador de Dominio.

Para el Controlador de Dominio 1 saldría esto:

0dfc9f67-c457-4c55-85d3-2cab3849a029._msdcs.lab.codesa.co.cu is an alias for pdc-master-1.lab.codesa.co.cu.

Y para el Controlador de Dominio 2 saldría esto otro:

ad5c61b3-fdd0-428e-8997-3167b823a211._msdcs.lab.codesa.co.cu is an alias for pdc-master-2.lab.codesa.co.cu.

Si estos registros no se encuentran, entonces se deben añadir manualmente de la siguiente manera:

# samba-tool dns add 10.0.1.130 _msdcs.lab.codesa.co.cu 0dfc9f67-c457-4c55-85d3-2cab3849a029 CNAME pdc-master-1.lab.codesa.co.cu –Uadministrator

# samba-tool dns add 10.0.1.130 _msdcs.lab.codesa.co.cu ad5c61b3-fdd0-428e-8997-3167b823a211 CNAME pdc-master-2.lab.codesa.co.cu –Uadministrator

Claro está que en ambos casos hay que proporcionar la contraseña del Administrador del Dominio.

Ahora toca el turno de añadir una nueva línea con el nuevo servidor DNS en el archivo /etc/resolv.conf:

nameserver 10.0.1.66

o

nameserver 127.0.0.1

El cual quedaría así

search lab.codesa.co.cu

nameserver 10.0.1.130

nameserver 10.0.1.66

nameserver 10.0.1.67

o

search lab.codesa.co.cu

nameserver 10.0.1.130

nameserver 127.0.0.1

nameserver 10.0.1.67

Con esto se notará que la replicación DNS está activada, cualquier configuración adicional, como son los servidores DNS a los que se le reenviarán las consultas de nombre de equipos ubicados en dominios externos, no se copiará. Esto hay que hacerlo manualmente.

11.3.- Bueno, sólo queda iniciar el servicio Samba 4:

# service sernet-samba-ad start

NOTA: Cuando se inicia Samba 4 como un nuevo Controlador de Dominio en un dominio Windows existente, en el log del servicio puede aparecer un mensaje de error como este:

UpdateRefs failed with WERR_DS_DRA_BAD_NC/NT code 0xc00020f8 for 5344d0a6-78a1-4758be69-66d933f1123._msdcs.lab.codesa.co.cu CN=RID Manager$,CN=System,DC=lab,DC=codesa,DC=co,DC=cu

La causa de este error está dada porque el Controlador de Dominio con Windows no se ha ejecutado aún el Knowledge Consistency Checker (KCC), lo que nos dice que aún no se ha creado conexión alguna con el nuevo Controlador de Dominio Samba 4.

Para corregir esto se pueden hacer dos cosas, o ejecutar el comando

(…)\> repadmin /kcc

en el Windows con credenciales de Administración del Dominio, o ejecutar en el Samba 4 su herramienta de gestión de la siguiente manera:

# samba-tool drs kcc -Uadministrator <Controlador de Dominio con Windows>.lab.codesa.co.cu

Ahora se debe chequear que la replicación entre los Controladores de Dominio Samba 4 funciona adecuadamente. Esto se hace con el comando siguiente:

root@pdc-master-1:# samba-tool drs showrepl

Y si no hay ningún problema, se obtendría un resultado similar a este:

Default-First-Site-Name\PDC-MASTER-1

DSA Options: 0x00000001

DSA object GUID: b4545980-3462-498a-b379-b3b3758a3c1f

DSA invocationId: 0ebbdee7-7e93-457a-907c-94f9520e200b

==== INBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ Sat Nov 15 23:15:16 2014 CST was successful

0 consecutive failure(s).

Last success @ Sat Nov 15 23:15:16 2014 CST

DC=ForestDnsZones,DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ Sat Nov 15 23:15:16 2014 CST was successful

0 consecutive failure(s).

Last success @ Sat Nov 15 23:15:16 2014 CST

DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ Sat Nov 15 23:15:17 2014 CST was successful

0 consecutive failure(s).

Last success @ Sat Nov 15 23:15:17 2014 CST

CN=Schema,CN=Configuration,DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ Sat Nov 15 23:15:17 2014 CST was successful

0 consecutive failure(s).

Last success @ Sat Nov 15 23:15:17 2014 CST

CN=Configuration,DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ Sat Nov 15 23:15:17 2014 CST was successful

0 consecutive failure(s).

Last success @ Sat Nov 15 23:15:17 2014 CST

==== OUTBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ NTTIME(0) was successful

0 consecutive failure(s).

Last success @ NTTIME(0)

DC=ForestDnsZones,DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ NTTIME(0) was successful

0 consecutive failure(s).

Last success @ NTTIME(0)

DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ NTTIME(0) was successful

0 consecutive failure(s).

Last success @ NTTIME(0)

CN=Schema,CN=Configuration,DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ NTTIME(0) was successful

0 consecutive failure(s).

Last success @ NTTIME(0)

CN=Configuration,DC=lab,DC=codesa,DC=co,DC=cu

Default-First-Site-Name\PDC-MASTER-2 via RPC

DSA object GUID: c43c8608-1e4f-480f-9d48-c4f6e95f1d54

Last attempt @ NTTIME(0) was successful

0 consecutive failure(s).

Last success @ NTTIME(0)

==== KCC CONNECTION OBJECTS ====

Connection —

Connection name: 0253d78d-deec-4b63-97aa-11665a502334

Enabled        : TRUE

Server DNS name : pdc-master-2.lab.codesa.co.cu

Server DN name  : CN=NTDS Settings,CN=PDC-MASTER-2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=codesa,DC=co,DC=cu

TransportType: RPC

options: 0x00000001

Warning: No NC replicated for Connection!

11.4.- Probar la Replicación del Directorio

Creando un usuario en cualquiera de los dos Controladores de Dominio

Para chequear si la replicación funciona correctamente entre los dos Controladores de Dominio, basta con añadir un nuevo usuario en uno de los Controladores de Dominio. Si uno de ellos es un Windows y el otro un Samba 4, sería bueno hacerlo en el segundo, ya sea usando las herramientas CLI de Samba 4 o las Herramientas Administrativas de Gestión Remota en una estación de trabajo con Windows. Luego se verá que el usuario aparece a los pocos segundos en el otro Controlador de Dominio. Claro está que también se puede hacer lo mismo a la inversa, al final se obtiene el mismo resultado.

Usando la herramienta ldapcmp

También se puede usar la herramienta ldapcmp para verificar que los mismos datos están siendo proporcionados o servidor por todos los Controladores de Dominio.

Una nota sobre la replicación del recurso compartido Sysvol

Actualmente la replicación del recurso compartido Sysvol no está implementada aún. Si se realiza cambios en este recurso compartido en uno de los Controladores de Dominio, los mismos cambios deben replicarse a los otros Controladores de Dominio, pero de manera manual (por ejemplo, una tarea programada que ejecute el comando rsync).

Esto puede verse posteriormente en el post “Replicación del recurso compartido Sysvol”.

Problemas de permisos de acceso en el recurso compartido Sysvol en dos Controladores de Dominio Samba 4.

Si existe cualquier otro Controlador de Dominio Samba 4 en la red, pueden existir problemas en los permisos de acceso en los directorios y archivos ubicados dentro del recurso compartido Sysvol, debido a que los UID/GID de los grupos que trae por defecto Samba (los Built-in Gropus) son diferentes en los Controladores de Dominio.

Por el momento no existe modo alguno para replicar estos UID/GID entre Controladores de Dominio Samba 4, pero se puede hacer lo siguiente:

  • Detener todos los Controladores de Dominio Samba 4
  • Copiar el archivo ubicado en /var/lib/samba/private/idmap.ldb al nuevo Controlador de Dominio Samba 4
  • Reiniciar todos los Controladores de Dominio Samba 4

Reportar al equipo de Samba 4 los éxitos o los fracasos en las implementaciones de Controladores de Dominio

Samba 4 como Controlador de Dominio de réplica sigue desarrollándose rápidamente. El equipo de trabajo de este servicio se mantiene a la escucha de la comunidad, de los aciertos y fracasos que tienen los usuarios con el uso de esta poderosa herramienta. La lista de distribución http://lists.samba.org está hecha para que los usuarios escriban todo lo que les ocurre con Samba.

Claro está que Samba 4 no está completo aún, así que su despliegue debe hacerse con cuidado hasta que esté completamente listo para entornos de producción.

Y bueno, estos dos primeros posts es mi pequeño aporte a la comunidad. Espero les sea de utilidad.

🙂

 

Acerca de Hector Suarez Planas

Es Licenciado en Ciencia de la Computación (3 de julio de 2002). Ha sido Administrador de Red en varias organizaciones, Programador y Analista de Sistemas. Actualmente se desempeña como Administrador de Red del Telecentro Tele Turquino de Santiago de Cuba. Tiene experiencia con sistemas Windows y GNU/Linux, Infraestructura de Redes (Cisco, AlliedTelesis, Netgear y HP ProCurve, Vyatta/VyOS), Servidores tanto físicos como virtuales (plataformas VMWare, Proxmox VE y Xen), Sistemas de Seguridad Informática (Snort/Suricata IDS, appliances AlienVault OSSIM), programador (Delphi, C++ Builder, Perl [poco], Python [algo]), entre otras cosas. Actualmente estoy incursionando en todo lo que tiene relación con Cloud Computing (OpenStack) y Centros de Datos. :-)
Esta entrada fue publicada en Debian, Directorio Activo, Linux, PDC, Samba 4, SERNET. Guarda el enlace permanente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *