Hola chic@s.

Aquí vengo con una duda. En mi empresa tenemos un servidor de ficheros Linux, el cual se gestiona ante el dominio con un DFS. El tema del DFS no lo controlo demasiado, pero sé que por el lado de Linux está todo controlado por ACL's.

Bueno, el caso es que la empresa está toda manejada con clientes Windows XP y todo funcionaba correctamente hasta que se ha puesto un Windows 7. Éste, aunque está bien integrado en el dominio, dice que no tiene permiso para acceder a los recursos que sí debería poder acceder. El mismo usuario configurado en XP tiene acceso a los recursos correspondientes.

Pues bien, leyendo me encuentro con que la versión de samba que actualmente usamos no es compatible con clientes Windows 7. Espero estar en lo cierto.

Entonces, de lo que se trata es de actualizar samba a una versión posterior y aquí vienen mis dudas. Pongo datos:

S.O.: CentOS release 5 (Final)
Samba: 3.0.33

Mirando el tutorial que hay aquí en AlcanceLibre, veo que se puede poner la última versión instalando samba3x:



He indica que se haga:



Ahora vienen mis temores. Con esta acción qué riesgos corro? El servidor no pude quedar parado, pues me cae el pelo .

A mi se me ocurre hacer una copia de /etc/samba/smb.conf y luego restaurarla con la nueva versión. Y en principio es lo único de lo que depende samba. El resto son ACL's aplicadas a los directorios y en eso no se tocará nada.

Puede fallar algo?

Y ya de paso, voy por buen camino sobre el problema real? Es decir, es posible que un usuario que tiene permisos para acceder a ciertos recursos, no tenga permisos desde un Windows 7 por tener la versión de samba 3.0.33??

Perdonar el ladrillaco pero de verdad que es importante el tema.

Gracias desde ya!

Un saludo!

Lamentablemente es un problema del lado de windows 7, ya que usa un sistema de encriptación diferente.
Yo probaría:

Ejecutar gpedit.msc

Localizar

Console Root
Local Computer Policy
Computer Configuration
Windows Settings
Security Settings
Local Policies
Security Options

cambiar las siguientes politicas:

Microsoft network client: Send unencrypted password to third-party SMB server: colocarlo a "Enabled".

Network security: LAN Manager authentication level: seleccionar la opción: Send LM & NTLM - use NTLMv2 session security if negotiated.


OJO! Si es windows starter, no tendras acceso a esas gpedit.msc y deberías modificar el registro con estas claves:

HK_Local_Machine\System\CurrentControlSet\control\Lsa DWORD "LmCompatibilityLeveL" = 0
HK_Local_Machine\System\CurrentControlSet\control\Lsa\MSV1_0 Dword "NtLmMinClientxxxx" = 0x0000
"NtLmMinServer=" 0x0000


Probalo en un PC con windows 7 que sabes que te dá errores y me contas.

Hola xjuanjp, en primer lugar, muchísimas gracias por contestar.

Te comento. Aún no lo he probado, puesto que el PC es de un superior y tengo acceso a él en contadas ocasiones. A lo largo del día lo intentaré.

Respecto a lo que me comentas, he estado viendo esas opciones pero en los clientes XP, como desde el que te escribo y la opción:

Cliente de redes de Microsoft: enviar contraseña sin cifrar a servidores SMB de terceros (sí, en mi caso lo tengo todo en español), está deshabilitada. Luego, si en los clientes XP está deshabilitada y funciona, no veo por qué hay que habilitarla en los 7.

En varios sitios ya he leído que el problema viene del lado de Samba, por ser una versión muy antigua. Podrías aclararme algo respecto a esto?

Muchas gracias de nuevo!

Un saludo.


Edito: Ah! Comentar que el cliente Windows 7 no es que muestre errores, sino que directamente indica que no tiene permisos para acceder a dichos recursos. Y no es cuestión de permisos, puesteo que el mismo usuario, cuando antes usaba un cliente XP, accedía sin más problema. Y las ACL ya están comprobadas y debería tener acceso.

Vale, ya ha sido probado. He modificado esas dos políticas tal y como me indicabas y para asegurarme mejor he reiniciado el equipo.

Sigue igual...

Veremos si alguien puede arrojar algo de luz a este asunto.

Y mantengo mi primera pregunta sobre la actualización de Samba. Qué riesgos corro? Con hacer backup de /etc/samba/smb.conf y ponerlo una vez actualizado, debería quedar igual, no? Luego reinicio el servidor y... ¿cruzo dedos?

Bueno, para empezar, con hacer copia de del smb.conf debería andar bien.
Lo que podes hacer es actualizar a samba3x y luego usar el comando testparm que chequea que el /etc/samba/smb.conf esté en buen estado a nivel sintaxis.

Hola, ¿No tienes un laboratorio (una PC con VirtualBox, KVM, VMware o lo que más te guste) con una máquina virtual en la que puedas instalar la versión de CentOS que tiene el file server, copies la configuración actual que tienes de SAMBA y posteriormente pruebes la actualización? Dudo mucho que si respaldas el archivo smb.conf, actualizas SAMBA y después restauras el archivo de configuración pueda pasar alguna catástrofe, pero la experiencia me dice que primero pruebes en un ambiente en el que si bates todo no pase nada. Creo que lo más probable es que la actualización de SAMBA sea la respuesta, incluso en la TechNet de Micro$oft lo indican: http://technet.microsoft.com/es-es/library/ee681622%28WS.10%29.aspx Saludos!!