Win7 clientes fallando con credenciales en caché en samba4 RODC


9

Estoy configurando un entorno de prueba para un cliente a punto de implementar samba4 en 1400 sitios remotos y tengo un problema. Es mi trabajo, después de todo, tener problemas y luego resolverlos.

Directorio Activo

  • raíz del bosque y dominio único: main.adlab.netdirect.ca
  • creado en Windows 2008 R2
  • 2008 FFL
  • 2008 DFL

Oficina principal

  • AD1: Windows 2008 R2 DC
  • AD2: Windows 2008 R2 DC
  • Clientes Windows 7 Professional

Sucursal

  • SLES11SP2 (¡completamente actualizado!) Con Samba 4 (paquetes 4.1.1-7.suse111 de sernet)
  • Samba 4 configurado como RODC

Configuré una política de replicación de contraseña para permitir que ciertas cuentas se almacenen en caché en el RODC y luego completé esas cuentas en el RODC:

sles-shire:~ # samba-tool rodc preload 'win7-shire$' --server main.adlab.netdirect.ca
Replicating DN CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[2]

sles-shire:~ # samba-tool rodc preload 'win7-shire-2$' --server main.adlab.netdirect.ca
Replicating DN CN=WIN7-SHIRE-2,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=WIN7-SHIRE-2,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[1]

sles-shire:~ # samba-tool rodc preload 'bilbo' --server main.adlab.netdirect.ca
Replicating DN CN=Bilbo Baggins,OU=Shire,OU=Offices,DC=main,DC=adlab,DC=netdirect,DC=ca
Exop on[CN=Bilbo Baggins,OU=Shire,OU=Offices,DC=main,DC=adlab,DC=netdirect,DC=ca] objects[1] linked_values[2]

Yo que esas credenciales se almacenan en caché en el RODC ya que si se me cae el enlace del sitio puedo iniciar sesión con un usuario en caché pero no un usuario diferente:

michael@sles-shire:~> smbclient //sles-shire.main.adlab.netdirect.ca/sysvol -U michael
Enter michael's password: 
session setup failed: NT_STATUS_IO_TIMEOUT

michael@sles-shire:~> smbclient //sles-shire.main.adlab.netdirect.ca/sysvol -U bilbo
Enter bilbo's password: 
Domain=[MAIN] OS=[Unix] Server=[Samba 4.1.1-SerNet-SuSE-7.suse111]
smb: \> ls
  .                                   D        0  Mon Nov 18 16:09:44 2013
  ..                                  D        0  Mon Nov 18 16:11:15 2013
  main.adlab.netdirect.ca             D        0  Wed Nov 20 17:54:13 2013

¡Entonces la autenticación funciona bien! Pero cuando intento iniciar sesión en la PC con Windows 7 (WIN7-SHIRE) aparece el error:

Ha ocurrido un error interno.

Caramba. Gracias. Si uso una contraseña incorrecta obtengo:

El nombre de usuario o contraseña son incorrectos.

Entonces, la autenticación está sucediendo, pero a Windows 7 no le gusta algo . Veo estos errores en los registros de eventos y creo que son relevantes para este problema:

El sistema de seguridad detectó un error de autenticación para el servidor ldap / sles-shire.main.adlab.netdirect.ca. El código de falla del protocolo de autenticación Kerberos fue "Se produjo un error interno. (0xc00000e5)".

El sistema de seguridad detectó un error de autenticación para el servidor DNS / sles-shire.main.adlab.netdirect.ca. El código de falla del protocolo de autenticación Kerberos fue "Se produjo un error interno. (0xc00000e5)".

Si ya estoy conectado e intento usar los servicios de red, obtengo:

El sistema de seguridad detectó un error de autenticación para el servidor cifs / sles-shire.main.adlab.netdirect.ca. El código de falla del protocolo de autenticación Kerberos fue "Se produjo un error interno. (0xc00000e5)".

Mi krb5.conf en el servidor:

[libdefaults]
    default_realm = MAIN.ADLAB.NETDIRECT.CA
    dns_lookup_realm = true
    dns_lookup_kdc = true

[realms]

[logging]
    kdc = FILE:/var/log/krb5/krb5kdc.log
    admin_server = FILE:/var/log/krb5/kadmind.log
    default = SYSLOG:NOTICE:DAEMON

Aquí está el verdadero pateador:

El comportamiento aún ocurre cuando el enlace del sitio está activo . Puedo iniciar sesión en la PC de dominio con cuentas que no están en caché en el RODC, pero si están en el RODC obtengo el mismo error.

Me aseguré de que todos los registros SRV apropiados en AD DNS estén en su lugar. Me aseguré de esto promoviendo un Windows 2008 R2 DC en la sucursal a un rol RODC y asegurando que todos los registros DNS apropiados estén presentes tanto para Windows como para Samba RODC.

(algunos fueron necesarios para agregarlos a mano ya que todavía no los agrega samba:

SRV _ldap._tcp.${SITE}._sites.DomainDnsZones.${DNSDOMAIN} ${HOSTNAME} 389
SRV _ldap._tcp.${SITE}._sites.ForestDnsZones.${DNSFOREST} ${HOSTNAME} 389

) (debe cerrar el soporte)

Entonces ... ¿qué está roto y cómo lo arreglo?


Información SPN

> dsquery * "CN=SLES-SHIRE,OU=Domain Controllers,DC=main,DC=adlab,DC=netdirect,DC=ca" -attr servicePrincipalName
  servicePrincipalName
  ldap/SLES-SHIRE;
  ldap/4116d553-d66b-4c8b-9a60-90380ac69c04._msdcs.main.adlab.netdirect.ca;
  ldap/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
  HOST/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
  ldap/SLES-SHIRE.main.adlab.netdirect.ca;
  ldap/SLES-SHIRE.main.adlab.netdirect.ca/MAIN;
  HOST/SLES-SHIRE.main.adlab.netdirect.ca/MAIN;
  RestrictedKrbHost/SLES-SHIRE.main.adlab.netdirect.ca;
  RestrictedKrbHost/SLES-SHIRE;
  GC/SLES-SHIRE.main.adlab.netdirect.ca/main.adlab.netdirect.ca;
  HOST/SLES-SHIRE.main.adlab.netdirect.ca;HOST/SLES-SHIRE;

> dsquery * "CN=WIN7-SHIRE,CN=Computers,DC=main,DC=adlab,DC=netdirect,DC=ca" -attr servicePrincipalName
  servicePrincipalName
  TERMSRV/WIN7-SHIRE.main.adlab.netdirect.ca;
  TERMSRV/WIN7-SHIRE;
  RestrictedKrbHost/WIN7-SHIRE;
  HOST/WIN7-SHIRE;
  RestrictedKrbHost/WIN7-SHIRE.main.adlab.netdirect.ca;
  HOST/WIN7-SHIRE.main.adlab.netdirect.ca;

Respuestas:


2

Es una posibilidad remota, pero lo intentaría: me parece cierta incompatibilidad entre win7 y RODC basado en samba en términos de configuración de nivel de seguridad. También supongo que alguna configuración de seguridad predeterminada en win 7 es demasiado restrictiva que samba no admite. Intentaré relajar la configuración de seguridad en win 7 cambiando la política local: Configuración del equipo-> Configuración de Windows-> Configuración de seguridad-> Políticas locales-> Opciones de seguridad.

Los sospechosos habituales incluyen, entre otros:

Cliente de red de Microsoft: firma digitalmente las comunicaciones (si el servidor lo acepta) Cliente de red de Microsoft: envía una contraseña sin cifrar a servidores SMB de terceros Seguridad de la red: nivel de autenticación de LAN Manager Seguridad de la red: requisitos de firma del cliente LDAP Seguridad de la red: seguridad de sesión mínima para NTLM basado en SSP ( incluidos clientes RPC seguros) Requiere confidencialidad del mensaje Requiere seguridad de sesión NTLMv2 Requiere cifrado de 128 bits


0

Parece que los problemas pueden haber tenido que ver con todos los puntos muertos y cables sueltos asociados con una instalación exploratoria / de prueba.

Después de restaurar el entorno y volver a hacer AD y la configuración de RODC a partir de un procedimiento de configuración real, ¡este escenario funcionó perfectamente sin ningún problema!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.