☰

Problema de Samba en Windows 7

tag-icon • tag-icon linux windows-7 redhat samba
Problema de Samba en Windows 7

Tenemos un extraño problema de samba que afecta solo a un usuario. Nuestra configuración de samba es la siguiente:

Red Hat Enterprise Linux Server versión 5.4 (Tikanga) - Servidor Samba

Versión Samba 3.0.33-3.14.el5 - Versión Samba

Controlador de dominio estándar WIN2008R2 - Windows DC

Windows 7 de 64 bits: PC cliente

El usuario mencionó que enfrentó este problema después de forzar el apagado de su PC hace unas semanas. Por cierto, para todos los usuarios cuando accedamos \\sambaservernameen Windows se mostrarán todos los recursos compartidos en el servidor Samba, pero para este usuario una vez que inicie su PC no podrá acceder \\sambaservername. Mensaje de error.

Windows no puede acceder\\sambaservername

Solución actual para resolver el problema:

Intente acceder a un recurso compartido, \\sambaservernamepor ejemplo \\sambaservername\sharedfolder1. Pero incluso al hacerlo, primero aparecerá un error al principio, el mensaje de error es el siguiente

Error de inicio de sesión: nombre de usuario desconocido o contraseña incorrecta.

El usuario debe ingresar las credenciales nuevamente y podrá acceder al recurso compartido. A partir de entonces podrá acceder \\sambaservernamesin problemas. Pero una vez que reinicie su computadora, el problema persistirá.

Solución de problemas realizada hasta el momento:

  1. Asegúrese de las siguientes configuraciones:

    Vaya a: Panel de control → Herramientas administrativas → Política de seguridad local Seleccione: Políticas locales → Opciones de seguridad

    "Seguridad de red: nivel de autenticación de LAN Manager" → Enviar respuestas LM y NTLM "Seguridad de sesión mínima para NTLM SSP" → desmarcar: Requerir cifrado de 128 bits

  2. Aconseje al usuario que restablezca su contraseña y vuelva a intentarlo, pero el problema persiste

  3. Probé mi cuenta en la PC de los usuarios, no hay problemas. Probé una cuenta de usuario en varias otras PC con Windows 7, incluida la mía, pero el problema persiste. Windows XP no tiene este problema.

  4. Asegúrese de que no haya credenciales almacenadas en la PC con Windows 7. Verifiqué el administrador de credenciales en el Panel de control y escribí este comandorundll32.exe keymgr.dll, KRShowKeyMgr

  5. Reinicie el demonio winbindd en el servidor samba pero fue en vano.

Sospecho que esto se debe a algún problema de almacenamiento en caché, pero no estoy seguro de dónde está el problema. Siempre que el usuario tenga un error al acceder \\sambaservername, los siguientes errores se registrarán en el servidor samba:

[2012/10/10 17:10:26, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!

Pero después de la solución, no habrá más errores. Sospecho que después de leer el artículo que figura a continuación es necesario realizar algunas modificaciones en el \var\samba\cachedirectorio:

Hay varios usuarios que utilizan el servidor samba y me gustaría resolver este problema sin ningún impacto.

Vi el siguiente artículo:

"Inicio de sesión sin conexión de winbind (G) Este parámetro está diseñado para controlar si Winbind debe permitir el inicio de sesión con el módulo pam_winbind utilizando credenciales en caché.Si está habilitado, winbindd almacenará las credenciales de usuario de inicios de sesión exitosos cifradas en un caché local.

Valor predeterminado: inicio de sesión sin conexión de winbind = falso

Ejemplo: inicio de sesión sin conexión de winbind = verdadero "

¿Alguna idea sobre cómo eliminar la entrada de un usuario en el caché local?

Respuesta1

No estoy seguro si elnbtstat -Rcomando (que"purga y recarga la tabla de nombres de caché remota".) o el nbtstat -RR(que"envía paquetes de liberación de nombres a WIN y luego inicia la actualización".) puede hacer cualquier cosa para imponer el tipo de actualización que está buscando...

Si quieres consultar el manual,mira aquí..

Respuesta2

Verifique para asegurarse de que ntpd esté sincronizado con el controlador de dominio. Tuve el mismo problema hasta que hoy noté una diferencia de tiempo de 45 minutos entre el servidor infractor y el controlador de dominio. Una vez que ejecuté ntpdate funcionó bien.

Respuesta3

En mi experiencia, esto suele ser el resultado de una desviación del tiempo en el controlador de dominio o, en su caso, con un solo cliente que tiene un problema, la máquina cliente que se conecta. Debido a que Kerberos incluye parámetros relacionados con el tiempo tanto en la solicitud del servidor de autenticación como en la respuesta del servidor de autenticación (AS_Req y AS_rep), una discrepancia amplia hará que se rechace el token de sesión.

AS_Req incluye la vida útil del token solicitado: AS_REQ = (PrincipalClient, PrincipalService, IP_list, Lifetime)

AS_Rep incluye la marca de tiempo de DC y la vida útil aplicada: AS_REP = {PrincipalService, Timestamp, Lifetime, SKTGS}

Entonces, si la variación de tiempo está fuera del tiempo de vida, la conexión se rechaza.

CONJECTURA: No he podido confirmar con documentación que la vida útil se especifica en minutos, pero creo que es porque tuve una máquina que funcionaba de forma intermitente y la única razón que se me ocurrió fue que estaba justo en el límite. de la vida. Entonces, durante unos 30 segundos funcionaría y luego el minuto cambiaría y las conexiones serían rechazadas.

información relacionada