Esta opción afecta a como los clientes responden a Samba y es uno de los valores más importantes del fichero smb.conf.
Esta opción fija el "security mode bit" en respuesta la la negociación de protocolos con smbd(8) para activar o desactivar el nivel de seguridad de los resursos compartidos. El cliente dedice basándose en este bit si (y como) transferir la información de usuario y clave al servidor.
El valor por defecto es "security = user", principalmente porque la más común cuando se habla con Windows 95/98/NT.
Las alternativas son security = share, security = server o security = domain .
IEn versiones de Samba anteriores a 2.0.0, el valor predeterminado era security = share principalmene porque era la única opción de un paso.
Hay un bug en WfWg que puede afectar su decisión. Cuando tenga user level security un cliente WfWg ignorará totalmente la clave que incluya en el cuadro de diálogo "conectar unidad de red". Esto hace muy difícil (si no imposible) conectar al servicio Samba a cualquiera salvo al usuario con el que se ha conectado a WfWg.
Si su PC usa nombres de usuario que son los mismos que sus usuarios en la máquina UNIX entonces querrá usar security = user. Si usa principalmente usario que no existen en la máquina UNIX entonces use security = share.
Debería usar security=share si quiere principalmente mantener recursos sin una clave (invitados). Esto es común para servidores de impresoras comartidas. Es más difícil configurar recursos de invitados con security = userr, vea el parámetro map to guest para más detalles.
Es posible usar smbd en modo "híbrido" donde ofrece los dos niveles de seguridad user y share bajo diferentes alias NetBIOS. Vea los parámetros netbios aliases e include para más información.
Explicamos las diferentes configuraciones:
Cuando los cliente conectan a un servicio con nivel de seguridad share no necesita conectarse al servidor con un nombre y clave válidos antes de intentar conectar a un recurso compartido (aunque los clientes modernos como Windows 95/98 y Windows NT envíen solicitudes de conexión con nombre de usuario pero sin clave cuando hablan con un servidor con security=share). En su lugar, los clientes envían información de validación (claves) por cada recurso en el momento que intenten la conexión al recurso.
Observe que smbd SIEMPRE utiliza un usuario UNIX válido para actual en nombre del cliente, incluso en el nivel de seguridad security = share.
Como no se requiere que los clientes envíen un nombre de usuario al servidor en el nivel de seguridad share, smbd usa varias técnicas para determinar el usuario UNIX correcto para usar en nombre del cliente.
Se construye una lista de posibles nombres de usuarios UNIX para verificar la clave suministrada por el cliente usando los siguientes métodos:
Si el parámetro guest only está activo, entonces se pierden el resto de los pasos y sólo se verifica el nombre de usuario guest account.
Si se envía un nombre de usuario con la solicitud de conexión al recurso, entonces este nombre de usuario (tras aplicar - ver username map), se añade como nombre de usuario potencial.
Si el cliente hizo una solicitud previa de "logon" request (llamada SMB SessionSetup) entonces el nombre de usuario enviado en este SMB se añadirá como nombre de usuario potencial.
El nombre del servicio que solicita el cliente se añadirá como nombre de usuario potencial.
El nombre NetBIOS del cliente se añadirá como nombre de usuario potencial.
Cualquier usuario de la lista user se añadirá como nombre de usuario potencial.
Si el parámetro guest only está activo o no se puede determinar el nombre de usuario, si el recurso está marcado como disponible para guest account, entonces se usará este usuario invitado, en otro caso se deniega el acceso.
Observe que puede ser muy confuso en el nivle de seguridad share qué nombre de usuario UNIX se usará para garantizar el acceso.
Ver también la sección Observaciones sobre validación USUARIO/PASSWORD.
Este es el valor por defecto de seguridad en Samba 3.0. Con el nivel de seguridad user un cliente tiene que conectarse con un nombre de usuario y clave válidos (que se puede aplicar usando el parámetro username map). Tambien se pueden usar claves cifradas (ver el parámetro "encrypted passwords") en este modo de seguridad. Los parámetros tales como user y guest only, si están activos se usan y puede cambiar el usuario UNIX que se utiliza en esta conexión, pero sólo una vez que el usuario ha sido validado correctamente.
Observe que el nombre del recurso que se solicita NO se envía al servidor hasta que se ha validado al cliente. Por esto los recursos invitados no funcionan en el nivel de seguridad user sin permitir al servidor aplicar los usarios desconocidos en la guest account automáticamente. Ver el parámetro map to guest para tener más detalles sobre como hacer esto.
Ver también la sección Observaciones sobre validación USUARIO/PASSWORD.
Este modo sólo funcionará correctamente si se ha usado smbpasswd para añadir esta máquina a un dominio NT. Espera activo el parámetro "encrypted passwords". en este modo Samba intentará validar usuario/clave pasándolo a un Windows NT PDC o BDC, de la misma forma que lo haría un servidor Windows NT.
Observe que tiene que existir un usuario UNIX válido también como la cuenta en el Controlador de Dominio para permitir a Samba tener una cuenta válida en la que aplicar los accesos.
Tenga en cuenta que desde el punto de vista del cliente "security = domain" es lo mismo que "security = user". Esto sólo afecta a como el servidor realiza la validación, no afecta para nada a lo que ve el cliente.
Observe que el nombre del recurso que se solicita NO se envía al servidor hasta que se ha validado al cliente. Por esto los recursos invitados no funcionan en el nivel de seguridad user sin permitir al servidor aplicar los usarios desconocidos en la guest account automáticamente. Ver el parámetro map to guest para tener más detalles sobre como hacer esto.
Ver también la sección Observaciones sobre validación USUARIO/PASSWORD.
Ver también password server y encrypted passwords.
En este modo Samba intentará validar usuario/clave pasándolo a otro servidor SMB, un NT por ejemplo. Si esto falla se pasa a "security = user", pero observe que si se ha negociado encrypted passwords entonces Samba no puede volver a verificar el fichero de claves UNIX, tiene que tener un fichero smbpasswd válido con el que comprobar los usuarios. Vea el capítulo sobre las bases de datos de usuarios dela documetnación de Samba para más detalles sobre como configurar esto.
Observación
Este modo de operación pegas significativas. En particular, este modo de operación puede ocasionar un consumo de resursos significativo en el PDC ya que debe mantener una conexión activa durante la sesión del usurio. Más aun, si esta conexión se pierde, no hay forma de restablecerla y las siguientes validaciones con el servidor pueden fallar. (Desde un cliente individual, hasta que desconecte).
Observación
Desde el punto de vista del cliente security = server es lo mismo que security = user. Sólo afecta a como el servidor maneja la validación, en ninguna forma afecta a lo que ve el cliente.
Observe que el nombre del recurso que se solicita NO se envía al servidor hasta que se ha validado al cliente. Por esto los recursos invitados no funcionan en el nivel de seguridad user sin permitir al servidor aplicar los uusarios desconocidos en la guest account automáticamente. Ver el parámetro map to guest para tener más detalles sobre como hacer esto.
See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION.
Ver también el parámetro password server y encrypted passwords.
En este modo Samba actúa como miembro de un dominio real ADS. Para opera de este modo la maquina que ejecuta Samba necesita tener Kerberos instalado y configurado y Samba necesita unirse al realm ADS usando la utildad net.
Observe que este modo no hace a Samba operar como controlador de dominio Active Directory.
Lea el capítulo de pertenencia la dominio para más detalles.
Predeterminado:
security = USER |
Ejemplo:
security = DOMAIN |
Relacionados:
realm
encrypt passwords