TimPotter Samba Team tpot@linuxcare.com
AndrewTridgell Samba Team tridge@samba.org
NaagMummaneni Notas para Solaris <getnag@rediffmail.com>
JohnTrostel<jtrostel@snapserver.com>
JelmerR.Vernooij The Samba Team <jelmer@samba.org>
JohnH.Terpstra Samba Team <jht@samba.org>
27 Junio 2002
La integración de UNIX y Microsoft Windows NT a través de un inicio de sesión ha sido considerado durante mucho tiempo una quimera en entorno heterogéneos de computación.
Hay alguna otra utilidad sin la cual la interoperatividad entre redes UNIX Microsoft Windows sufriría mucho. Es necesario que haya un mecanismo para compartir ficheros entre sistema UNIX y que pueda asignar como propietarios a usuarios y grupos del dominio con integridad.
winbind es un componente de la suite de programas Samba que resuelve los problemas de inicio de sesión unificados. Winbind usa una implementación UNIX de las llamdas RPC de Microsoft, PAM (Pluggable Authentication Modules), y el servico de nombres (NSS, Name Service Switch) para permitir a los usuarios de dominios NT aparecer y operar como usuarios UNIX en una máquina UNIX. Este capítulo describe el sistema Winbind, explicando las funcionalidades que proporciona, cómo se configura y como funciona internamente.
Winbind proporciona tres funciones separadas:
Autenticación para credenciales de usuario (vía PAM).
Resolución de identidad (vía NSS).
Winbind mantiene una base de datos llamada winbind_idmap.tdb en lacual guarda las asociaciones entre UNIX UIDs / GIDs y NT SIDs. Esta asociación se usa sólo para usuario y grupos que no tienen unos UID/GID locales.Guarda los UID/GID del rango uid/gid de idmap que ha asociado al SID NT. Si se ha especificado el backend idmap como ldapsam:url, entonces en lugar de usar de usar la asociación local Winbind la obtendrá de la base de datos LDAP.
Si winbindd no esá en ejecución, smbd (que llama a winbindd) tendrá que usar sólo la información local de /etc/passwd y de /etc/group no podrárealizar asociaciones dinámicas.
Es bien conocido que UNIX Microsoft Windows NT tienen distintss modelos para representar las informaciones de usuario y grupo y utilizan diferentes tecnologías para desarrollarlos. Este hecho dificulta integrar los dos sistemas de forma satisfactoria.
Hasta ahora una solución frecuente era crear usuarios con los mismos nombres en ambos sistemas, UNIX y Windows y usar Samba para suministrar servicios de ficheros e impresión entre ambos. Esta solución dista mucho de ser perfecta, ya que añadir y borrar usuarios en ambos conjuntos de sistemas se convierte en una tarea pesada y se necesitan dos conjuntos de contraseñas lo que conlleva problemas de sincronización entre UNIX y Windows y puede producir confusión entre los usuarios.
Dividimos el problema de la sesión unificada para máquinas UNIX en tres problemas más pequeños:
Obtención de la información de usuarios y grupos Windows NT.
Autenticar usuarios Windows NT.
Cambio de contraseña para usuarios Windows NT.
Winbind unifica la gestión de cuentas UNIX y Windows NT permitiendo a una máquina Unix volverse un miembro completo de un dominio NT. Una vez hecho, la máquina Unix verá a los usuarios y grupos NT como si fueran usuarios y grupos nativos permitiedo usar el dominio NT usarse de la misma forma que se usa NIS+ en entorno exclusivos UNIX.
El resultado final es que cuando cualquier programa en la máquina Unix solicita al sistema operativo que busque un nombrer usuario o un grupo, la consulta se resuelve preguntando al controlador de dominio NT del dominio corresondiente. Como winbind enlaza con el sistema operativo a bajo nivel (via módulo de resolución NSS de la biblioteca C), la redirección al controlador de dominio NT es completamente transparente.
Los usuarios de la máquina Unix pueden utilizar los nombres de usuarios y grupos NT como si fueran nombres nativos. Se pueden cambiar propietarios de ficheros para que sean propiedad de usuarios de usuarios del dominio NT o incluso iniciar una sesión en la máquina Unix y lanzar una sesión X-Window como miembro del dominio.
La única indicación obvia de que se está usando Winbind que los nombres de usuarios y grupos tienen la forma DOMAIN\user and DOMAIN\group. Esto es necesario para permitir a Winbind determinar a qué controlador de dominio hay que redireccionar para la búsqueda particular y qué dominios de confianza se están refereciando.
Adicionalmente, Winbind proporciona un servicio de autenticación que engancha con el sitema PAM (Pluggable Authentication Modules) (PAM) para proporcionar autenticación via dominio NT a cualquier aplicación con soportee PAM. Esta capacidad resulve el problema de sincronizar las contraseñas entre sistema ya que todas las contraseñas se almacenan en una sola ubicación, en el controlador de sominio.
Winbind está pensada para organizaciones que tienen una infraestructura existente basada en dominio NT en la cual desean poner estaciones trabajo o servidores de UNIX. Winbind permitirá que estas organizaciones desplieguen los estaciones de trabajo de UNIX sin tener que mantener una infraestructura de cuentas separada. Esto simplifica enormemente los gastos indirectos administrativos de introducir estaciones de trabajo de UNIX en una organización basada en NT.
Otra manera interesante en la cual esperamos utilizar Winbind es como parte central de aplicaciones basadas en UNIX. Las aplicaciones que proporcionan servicios de ficheros y de impresión a las redes basadasMicrosoft podrán utilizar Winbind para proporcionar la integración de la aplicación en el dominio.
El sistema Winbind está diseñado sobre una arquitectura cliente/servidor. Un demonio Winbindd escucha en un socket Unix esperando las solicitudes. Estas peticiones son normalmente de los clientes NSS y PAM y se procesan secuencialmente.
La tecnología que se usa para implementar Winbind se describe en detalle más abajo.
Durante los últimos años ha habido un importante esfuerzo dealgunos miembros del Samba Team para decodificar ciertos aspectos del sistema Microsoft Remote Procedure Call (MSRPC). Este sistema se usa en la mayoría de las operaciones de redes, incluyendo el mantenimiento remoto, validación de usuarios y colas de impresión. Aunque inicialmente se este trabajo se realizaba para ayudar en el desarrollo de la funcionalidad de PDB (controlador primario de dominio), con posterioridad ha constituido el cuerpo de código paraotros propósitos.
Winbind usa varias llamadas para enumerar los usuarios y grupos del dominio y obtener información detallada sobre usuarios individuales y grupos. Se pueden usar otras MSRPC para validar usuarios de dominios NT y para modificar contraseñas. Entonces, consultando información sobre usuarios y grupos directamente a un PDC, Winbind asocia información de cuentas NT en usuarios grupos UNIX.
Desde finales de 2001, Samba tiene la habilidad de interactuar con W2000 usando los protocolos del Modo Nativo en lugar de los servicios RPC de NT4. Usando LDAP y Kerberos, un miembro del dominio que esté ejecutando Winbind puede obtener usuarios y grupos de la misma forma que lo haría un cliente W200x y de esta forma proporciona una implementación más eficiente y efectiva de Winbind.
El servicio Name Service Switch, o NSS, es una característica presente en la mayoría de los sistemas operativos Unix. Permite al sistema obtener información del tipo nombre de host, alias de correo e información de usuario para resolverla a partir distintas fuentes. Por ejemplo, una estación Unix aislada puede resolver esta información del sistema a partir de una serie de ficheros locales. Una estación de red puede intentar primero averiguar la información del sistema a partir de ficheros locales y después consultar una base de datos NIS para obtener la información sobre el usuario o a un servidor DNS para la información sobre los nombres de host.
La interfaz de programación de la aplicación NSS permite a winbind presentarse a si mimo como fuente de información del sistema cuando se trata de averiguar información sobre usuarios y grupos. Winbind utiliza esta interfaz y la información obtenida de servidores NT utilizando llamdas MSRPC para proporcionar una nueva fuente de enumeración de cuentas. Se pueden enumerar los usuarios y grupos de un dominio NT, además de sus dominios de confianza, mediante las llamadas a la biblioteca estándar Unix como si fueran usuarios y grupos locales.
El fichero principal de control de NSS es /etc/nsswitch.conf. Cuando una aplicación realiza una solicitur de búsqueda, la biblioteca C busca una línea en /etc/nsswitch.conf que se corresponda con el servicio solicitado, por ejemplo, se usa el servicio passwd cuando se buscan nombres de grupos o usuarios. Esta líneade configuración especifica qué implementaciones del servicio se deben llamar y en qué orden. Si la línea passwd es:
passwd: files example |
entonces la biblioteca C primero cargará un módulo llamado /lib/libnss_files.so seguido por el módulo /lib/libnss_example.so. La biblioteca C cargará cada uno de esos módulos dinámicamente por orden y realiza la llamada a la función con la que el módulo trata de resolver la petición. Una vez que se ha resuelto la petición, la biblioteca C devuelve el resultado a la aplicación.
Esta interfaz del NSS proporciona a Winbind una manera fácil de enlazar con el sistema operativo. Todo lo que tiene que hacer es pponer libnss_winbind.so en /lib/ y agregar winbind en /etc/nsswitch.conf en el lugar apropiado. Entonces, la biblioteca C llamará Winbind para resolver nombres de usuario y de grupo.
Pluggable Authentication Modules, también conocidos como PAM, es un sistema para las abstracción de las tecnologías de autentificación y autorización. Con un módulo del PAM es posible especificar diversos métodos de autentificación para diversas aplicaciones del sistema sin necesidad de tener que recompilarlas. PAM es también útil para poner una política particular de autorización. Por ejemplo, un administrador de sistemas puede permitir solamente conexiones en la consola de los usuarios almacenados en el archivo local de contraseñas y permitir solamente a usuarios obtenidos de una base de datos NIS+ para iniciar una sesión sobre la red.
Winbind utiliza la interfaz PAM de gestión de validación y de contraseñas para integrar a usuarios de Windows NT en un sistema de UNIX. Esto permite que los usuarios de Windows NT abran una sesión a una máquina de UNIX y sean autenticados contra un contolador primario del dominio adecuado. Estos usuarios pueden también cambiar sus contraseñas y que estos cambios tengan efecto directamente en el controlador primario del dominio.
El PAM se configura mediante ficheros de control en el directorio /etc/pam.d/ para cada uno de los servicios que requieren la autenticación. Cuando se hace una petición de validación por una aplicación, el código del PAM de la biblioteca de C busca este archivo de control para determinarse qué módulos tiene que cargar para verificar la validación y en qué orden. Esta interfaz se hace de forma muy fácil agregando un nuevo servicio de la autenticación para Winbind. Todo lo que tiene que hacer es copiar el módulo de pam_winbind.so en /lib/security/ y los archivos de control de PAM para los servicios relevantes se actualiza para permitir la autentificación vía Winbind. Vea la documentación de la autentificación PAM en la alidación distribuida basasda en PAM.
Cuando se crea un grupo bajo Windows NT/200x, se guarda un identicador numérico relativo (RID). Es ligeramente diferente de Unix, que tiene un rango de números que se utilizan para identifcar usuarios y el mismo rango para identificar grupos. Winbind se encarga de convertir los RID en ID Unix y viceversa. Cuando se configura Winbind se proporciona parte del conjunto de números de ID y GID Unix en los cuales almacenar los usuarios y grupos NT. Si se encuentra un usuario NT por primera vez, se le asigna el siguiente ID del rango. Este mismo criterio se utiliza para los grupos. A lo largo del tiempo, Winbind habrá asociado todos los usuarios y grupos NT con UID y GID Unix.
Los resultados de estas asociaciones se almacenan permanentemente en una base de datos TDB. Gracias a esto podemos garantizar que las asociaciones entre RID y GID son consistentes.
Un sistema activo puede generar un gran número de búsquedas de usuarios y grupos. Para reducir el coste de la red, Winbind usa un esquema de cacheo basado en el número de secuencia SAM proporcionado por los controladores de dominio NT. Winbind almacena en cache la información de usuario y grupo devuelta por el PDC con un número de secuencia también proporcionado por el PDC NT. Este número de secuencia lo incrementa el NT cuando cambian los datos de cualquier usuario o grupo. Si una entrada del cache ha expirado se solicita el número de secuencia del PDC y se compara con el número de secuencia guadado en el cache. Si los número no son iguales se descarta la información del cache y directamente se solicita una información actualizada del PDC.
Esta sección describe los procedimientos para tener Winbind funcionando correctamente. Winbind es capaz de proporcionar un control de acceso y validación a los usuarios de Dominios NT a través de PDC NT 0 200x PDC para servicios habituales como telnet and ftp, también servicios Samba.
Por qué hacerlo
Esto permite al administrador de Samba hacer recaer los mecanismos de validación en un PDC NT/200x PDC para la validación de los miembros del dominio. Ya no es necesario tener cuentas separadas para el servidor Samba.
Quien debería leer este documento
Este documento está dirigido a administradores de sistemas. TAmbién deberías leer esto si estás instalando Samba en un servidor de ficheros y quieres integrar los usuarios Nt/200x existentes en el PDC en el servidor Samba.
En primer lugar, si tiene un fichero de configuración de samba que esté actualmente en uso, haga una copia de seguridad. Si su sistema usa PAM haga una copia de seguridad del directorio /etc/pam.d . Si no tiene un disquete de arranque haga uno ahora.
Cuando se tocan los ficheros de configuración de PAM puede hacer casi imposible entrar en el sistema. Por esto bueno tener un disquete de arranque para poder entrar en la máquina en modo monousuario y recuperar el directotrio original /etc/pam.d de la copia de seguridad.
La desde la última versión de Samba-3 se incluye un demonio winbind. Por favor vea página principal de Samba o, mejor aun, la web espejo más cercana para ver como obtener el código fuente.
Para permitir a los usuarios del dominio la posibildad de acceder a los ficheros y recursos, y también potencialmente a otros servicios porporcionados por la máquina samba hay que configurar PAM adecuadamente en la máquina cliente. Para compilar el módulo Winbind debería, al menos, tener instaladas las bibliotecas de desarrollo de PAM. Vea la web de PAM en http://www.kernel.org/pub/linux/libs/pam/.
Antes de comenzar, problablemente los mejor es matar todos los demonios de samba y winbind del sistema, smbd, nmbd y winbindd. Para usar PAM, asegúrese de que tiene el paquete estándar de pan que incluye el directorio /etc/pam.d incluyendo los módulos PAM que van a utilizar los servicios que usan este tipo de validación,varias bibliotecas pam y las entradas /usr/doc y /usr/man de PAM. Winbind se construye mejor en Samba si el paquete pam-devel package también está instalado. Es necesario para compilar aplicaciones con soporte PAM.
PAM es un componente estándar de las generaciones más recientes de sistemas Linux. Por desgracia sólo unos pocos sistemas instalan las bibliotecass pam-devel que son necesarias para construir samba con soporte PAM. Además, Samba3 puede autoinstalar los ficheros Winbind en su sistema en sus ubicaciones correctas, y en consecuencia, antes de ir más lejos debería comprobar si la siguiente configuración es realmente necesaria. Puede que sólo necesite configurar /etc/nsswitch.conf.
Las bibliotecas necesarias para ejecutar el domonio winbindd mediante nsswitch tienen que copiarse en sus ubicaciones correspondientes:
root# cp ../samba/source/nsswitch/libnss_winbind.so /lib |
También he visto que es necesario hacer los siguientes enlaces simbólicos:
root# ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2
Y en el caso de Sun Solaris:
root# ln -s /usr/lib/libnss_winbind.so /usr/lib/libnss_winbind.so.1 root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.1 root# ln -s /usr/lib/libnss_winbind.so /usr/lib/nss_winbind.so.2 |
Ahora, como root, tiene que editar /etc/nsswitch.conf para permitir que los usuarios y grupos sean visibles para el demonio winbindd. Mi fichero /etc/nsswitch.conf, tras modificarlo es similar a:
passwd:
files winbind
shadow:
files
group:
files winbind
|
Las bibliotecas necesarias para el demonio winbindd daemon entrarán automáticametne en el cache de ldconfig cache la próxima vez que se reinicie el sistema, pero es más rápido hacerlo a mano (y no hace falta reiniciar ):
root# /sbin/ldconfig -v | grep winbind
Esto hace que libnss_winbind es disponible para winbindd además de mostrar la salida.
(Esta sección es sólo para quienes utilizan AIX.)
El módulo de identificación Winbind de AIX se construye como libnss_winbind.so in el directorio nsswitch de las fuentes de Samba. Este fichero se puede copiar en /usr/lib/security, y el convenio de nombres de AIX indicaría que se se debería llamar WINBIND:
WINBIND: program = /usr/lib/security/WINBIND options = authonly |
se puede añadir a /usr/lib/security/methods.cfg. Este módulo sólo admite identificación, pero hay informes de éxito en le uso del módulo estándar PAM de Winbind para validación. Utilice con precaución la configuración de los módulos de autenticación ya que puede hacer imposible entrar en el sistema. Hay más información sobre la API de los módulos de validación en Kernel Extensions and Device Support Programming Concepts for AIX en el Capítulo 18 Loadable Authentication Module Programming Interface y más información sobre la administración de módulos en System Management Guide: Operating System and Devices.
Se necesitan varios parámetros en el fichero smb.conf para controlar el funcionamiento de winbindd. Se describen con más detalle en la página del manualwinbindd(8). Mi fichero smb.conf, como se muestra en el siguiente ejemplo, se ha modificado para incluir las entradas necesarias en la sección [global]
Ejemplo 21.1. smb.conf para la configuración de Winbind
|
[global] |
|
# separa domainio y usuario con '+', como DOMINIO+username |
|
winbind separator = + |
|
# usa uids desde 10000 a 20000 para los usuarios del dominiop |
|
idmap uid = 10000-20000 |
|
# usa gids desde 10000 a 20000 para los grupos del dominio |
|
idmap gid = 10000-20000 |
|
# allow enumeration of winbind users and groups |
|
winbind enum users = yes |
|
winbind enum groups = yes |
|
# da a los usuarios de winbind una shell real (sólo necesario si tienen acceso a telnet) |
|
template homedir = /home/winnt/%D/%U |
|
template shell = /bin/bash |
Introduzca la siguiente orden para hacer que el servidor SAmba se una al PDC del dominio, donde DOMAIN es en nombre de su dominio NT y Administrator es el usuario del dominio que tiene privilegios administrativos en el dominio.
root# /usr/local/samba/bin/net rpc join -S PDC -U Administrator
La respuesta a esta orden debería ser Joined the domain DOMAIN donde DOMAIN es su nombre de dominio.
También puede que sea necesario modificar el script de inicio de Samba para que llame automáticamente al demonio wnibindd cuando inicia otros componentes de samba, sino es posible verificar Winbind primero. Para comenzar los servicios Winbind introduzca como root (verifique las rutas correctas):
root# /usr/local/samba/bin/winbindd
The above assumes that Samba has been installed in the /usr/local/samba directory tree. You may need to search for the location of Samba files if this is not the location of winbindd on your system.
Winbindd can now also run in “;dual daemon mode”. This will make it run as two processes. The first will answer all requests from the cache, thus making responses to clients faster. The other will update the cache for the query that the first has just responded. The advantage of this is that responses stay accurate and are faster. You can enable dual daemon mode by adding -B to the command-line:
root# /usr/local/samba/bin/winbindd -B
Siempre soy un paranoico y me gusta asegurarme de que el demonio está realmente en ejecución:
root# ps -ae | grep winbindd
Esta orden debería generar una salida similar a la siguiente si el demonio está en ejecución:
3025 ? 00:00:00 winbindd |
Ahora el test real, itnentamos obtener información sobre los usuarios de su PDC:
root# /usr/local/samba/bin/wbinfo -u
Esto debería devolver una lisa de usuarios Windows en el PDC. Por ejemplo yo obtengo la siguiente resspuesta:
CEO+Administrator
CEO+burdell
CEO+Guest
CEO+jt-ad
CEO+krbtgt
CEO+TsInternetUser
|
Obviamente el nombre de mi dominio es CEO y mi winbind separator is +.
Se puede hacer lo mismo para obtener infomación de los grupos del PDC:
root# /usr/local/samba/bin/wbinfo -g
CEO+Domain Admins
CEO+Domain Users
CEO+Domain Guests
CEO+Domain Computers
CEO+Domain Controllers
CEO+Cert Publishers
CEO+Schema Admins
CEO+Enterprise Admins
CEO+Group Policy Creator Owners
|
Ahoa se puede usar la función getent para obtener listas unificadas de usuarios y grupos locales y del PDC. Intente la siguiente orden:
root# getent passwd
Debaría obtener una lista similar a su /etc/passwd seguida de los usuarios del dominio con sus nuevos UID, GID, directorio personal y shell predeterminada.
Lo mismo de puede hacer para los grupos:
root# getent group
El demonio winbindd tiene que iniciarse una vez que los demonios smbd y nmbd ya estén en ejecución. Para esto tiene que que modificar los script de inicio de su sistema. Normalmente se guardan en /etc/init.d/smb en Red Hat Linux y en /etc/init.d/samba en Debian Linux. Modifique su script de inicio para añadirlas órdenes llmarlos en en orden adecuado. Mi script de inicio lanza smbd, nmbd y winbindd directamente desde el directorio /usr/local/samba/bin. La función start del script se parece al lo siguiente:
start() {
KIND="SMB"
echo -n $"Starting $KIND services: "
daemon /usr/local/samba/bin/smbd $SMBDOPTIONS
RETVAL=$?
echo
KIND="NMB"
echo -n $"Starting $KIND services: "
daemon /usr/local/samba/bin/nmbd $NMBDOPTIONS
RETVAL2=$?
echo
KIND="Winbind"
echo -n $"Starting $KIND services: "
daemon /usr/local/samba/bin/winbindd
RETVAL3=$?
echo
[ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \
touch /var/lock/subsys/smb || RETVAL=1
return $RETVAL
}
|
Si quisiera ejecutar winbindd em modo demonio dual, sustituya la línea:
daemon /usr/local/samba/bin/winbindd |
del ejemplo anterior por:
daemon /usr/local/samba/bin/winbindd -B |
.
La función tienestop tiene una entrada correspondiente para detener los servicios similar a la siguiente::
stop() {
KIND="SMB"
echo -n $"Shutting down $KIND services: "
killproc smbd
RETVAL=$?
echo
KIND="NMB"
echo -n $"Shutting down $KIND services: "
killproc nmbd
RETVAL2=$?
echo
KIND="Winbind"
echo -n $"Shutting down $KIND services: "
killproc winbindd
RETVAL3=$?
[ $RETVAL -eq 0 -a $RETVAL2 -eq 0 -a $RETVAL3 -eq 0 ] && \
rm -f /var/lock/subsys/smb
echo ""
return $RETVAL
}
|
Winbind no funciona en Solaris 9, vea la secciónWinbind en Solaris 9 para más detalles.
En Solaris tiene que modificar el script de inicio /etc/init.d/samba.server. Normalmente sólo inicia smbd y nmbd pero ahora debería iniciar winbindd también. Si tiene Samba instalado en /usr/local/samba/bin, el fichero podría contener algo como lo siguiente:
##
## samba.server
##
if [ ! -d /usr/bin ]
then
# /usr not mounted
exit
fi
killproc() {
# kill the named process(es)
pid=`/usr/bin/ps -e |
/usr/bin/grep -w $1 |
/usr/bin/sed -e 's/^
*//' -e 's/ .*//'`
[ "$pid" != "" ] && kill $pid
}
# Start/stop processes required for Samba server
case "$1" in
'start')
#
# Edit these lines to suit your installation (paths, workgroup, host)
#
echo Starting SMBD
/usr/local/samba/bin/smbd -D -s \
/usr/local/samba/smb.conf
echo Starting NMBD
/usr/local/samba/bin/nmbd -D -l \
/usr/local/samba/var/log -s /usr/local/samba/smb.conf
echo Starting Winbind Daemon
/usr/local/samba/bin/winbindd
;;
'stop')
killproc nmbd
killproc smbd
killproc winbindd
;;
*)
echo "Usage: /etc/init.d/samba.server { start | stop }"
;;
esac
|
De nuevo, si quisiera ejecutar Samba en modo demonio dual:
/usr/local/samba/bin/winbindd |
en el anterior script con:
/usr/local/samba/bin/winbindd -B |
Si lo ha hecho todo hasta llegar a este punto sabe que winbindd y Samba están funcionando juntos. Si quiere usar Winbind para proporcionar validación para otros servicios, siga leyendo. Los ficheros de configuración PAM necesarios tienen que modificarse para este paso. (Recuerde que tenía que hacer una copia de seguridad del directorio original /etc/pam.d files. Si no la hizo, hágala ahora).
Necesitará un módulo PAM para usar winbindd con estos otros servicios. Este módulo se compilará en el directorio ../source/nsswitch ejecutando:
root# make nsswitch/pam_winbind.so
from the ../source directory. The pam_winbind.so file should be copied to the location of your other PAM security modules. On my Red Hat system, this was the /lib/security directory. On Solaris, the PAM security modules reside in /usr/lib/security.
root# cp ../samba/source/nsswitch/pam_winbind.so /lib/security
El fichero /etc/pam.d/samba no hay que modificarlo. Lo dejo como estaba:
auth
required
/lib/security/pam_stack.so service=system-auth
account required
/lib/security/pam_stack.so service=system-auth
|
Los otros servicios que he modificado para permitir el uso de Winbind como servicio de autenticación fueron el login normal en la consola (o sesión desde un terminal), telnety sevicio ftp. Para activarlos, primero tiene que cambiar las entradas de /etc/xinetd.d (o /etc/inetd.conf). Red Hat Linux 7.1 y posteriores usan el nuevo xinetd.d, en este caso tiene que cambiar las líneas de /etc/xinetd.d/telnet y /etc/xinetd.d/wu-ftp de
enable = no |
a:
enable = yes |
Para que los servicios ftp funcionen correctamente también tendrá que tener directorios personales para los usuarios del dominio ya presentes en el servidor o cambiar el parámetro correspondiente al directorio personal a un directorio general para todos los usuarios del dominio. Esto se hace fácilmente usando el el parámetro template homedir del fichero smb.conf.
El fichero /etc/pam.d/ftp se puede modificar para permitir a Winbind acceso ftp de forma similar al fichero samba. Mi fichero /etc/pam.d/ftp lo modifiqué para dejarlo similar a:
auth required /lib/security/pam_listfile.so item=user sense=deny \ \ file=/etc/ftpusers onerr=succeed auth sufficient /lib/security/pam_winbind.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_shells.so account sufficient /lib/security/pam_winbind.so account required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth |
El fichero /etc/pam.d/login se puede modificar de una forma parecida. Ahora podría parecer a:
auth required /lib/security/pam_securetty.so auth sufficient /lib/security/pam_winbind.so auth sufficient /lib/security/pam_UNIX.so use_first_pass auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account sufficient /lib/security/pam_winbind.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so |
En este caso he añadido las líneas
auth sufficient /lib/security/pam_winbind.so |
como antes, pero tambien he añadido
required pam_securetty.so |
antes para deshabilitar las conexiones de root en red. También he añadido la línea:
sufficient /lib/security/pam_unix.so use_first_pass |
tras la líneaa winbind.so para evitar que solicite dos veces la contraseña.
Es necesario modificar /etc/pam.conf. He modificado este fichero para que los usuarios de mi dominio puedan conectarse tanto localmente como por telnet. A continuación vienen los cambios que he realizado. Puede personalizar el fichero pam.conf según los requitos de su sistema, pero asegúrese de los cambios porque en el peor de los casos hará que sea imposible iniciar su sistema.
# #ident "@(#)pam.conf 1.14 99/09/16 SMI" # # Copyright (c) 1996-1999, Sun Microsystems, Inc. # All Rights Reserved. # # PAM configuration # # Authentication management # login auth required /usr/lib/security/pam_winbind.so login auth required /usr/lib/security/$ISA/pam_UNIX.so.1 try_first_pass login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 try_first_pa\ ss # rlogin auth sufficient /usr/lib/security/pam_winbind.so rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 rlogin auth required /usr/lib/security/$ISA/pam_UNIX.so.1 try_first_pass # dtlogin auth sufficient /usr/lib/security/pam_winbind.so dtlogin auth required /usr/lib/security/$ISA/pam_UNIX.so.1 try_first_pass # rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 other auth sufficient /usr/lib/security/pam_winbind.so other auth required /usr/lib/security/$ISA/pam_UNIX.so.1 try_first_pass # # Account management # login account sufficient /usr/lib/security/pam_winbind.so login account requisite /usr/lib/security/$ISA/pam_roles.so.1 login account required /usr/lib/security/$ISA/pam_UNIX.so.1 # dtlogin account sufficient /usr/lib/security/pam_winbind.so dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 dtlogin account required /usr/lib/security/$ISA/pam_UNIX.so.1 # other account sufficient /usr/lib/security/pam_winbind.so other account requisite /usr/lib/security/$ISA/pam_roles.so.1 other account required /usr/lib/security/$ISA/pam_UNIX.so.1 # # Session management # other session required /usr/lib/security/$ISA/pam_UNIX.so.1 # # Password management # #other password sufficient /usr/lib/security/pam_winbind.so other password required /usr/lib/security/$ISA/pam_UNIX.so.1 dtsession auth required /usr/lib/security/$ISA/pam_UNIX.so.1 # # Support for Kerberos V5 authentication (uncomment to use Kerberos) # #rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass #dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 #other account optional /usr/lib/security/$ISA/pam_krb5.so.1 #other session optional /usr/lib/security/$ISA/pam_krb5.so.1 #other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass |
También he añadido una línea try_first_pass tras winbind.so para evitar que pida la contraseña dos veces.
Ahora reinicie su Samba e intente conectar mediante la aplicación que ha configurado en pam.conf.
El sistema Winbind, mediante eñ uso de NSS (Name Service Switch), PAM (Pluggable Authentication Modules), y las llamdas Microsoft RPC han permitido proporcinar la integración de los usuarios de dominios NT en sistemas Unix. El resultado es un gran reducción del coste administrativo de ejecutar redes mixtas UNIX y NT.
Winbind tiene cierto número de limitaciones en su versión actual que esperamos corregir en las príximas.
Winbind sólo está disponible pra Linux, Solaris, AIX, e IRIX, aunque son posibles adaptaciones para otros sistems operativos. Para que tales adaptaciones sean posibles necesitamos que la biblioteca C de la máquina destino admita los sistemas Name Service Switch y Pluggable Authentication Modules. Esto se hace más frecuetne ya que NSS y PAM ganan sporte entre los vendedores de UNIX.
La asociación entre los RID de Windows NT RIDs con los ID de UNIX no se hace mediante algoritmo, depende del orden en el que Windbind ve a los usuario no asociados. Puede ser difícil recuperar las asociaciones si entre RID e ID si el fichero que las contiene se corrompe o se destruye.
En la actualidad el módulos PAM para Winbind no tiene en cuenta ni las estaciones de trabajo ni las restricciones de hora de conexión que se pueden fijar para los usuarios de NT.
Bajo ninguna circunstacia ejecute nscd sobre un sistema en el que winbindd esté en ejecución.
Si nscd está en ejecución en un sistema UNIX/Linux, entonces incluso aunque NSSWITCH esté correctamente configurado no es posible resolver usuarios y grupos del dominio para control de ficheros y directorios.
Mi smb.conf está correctamente configurado. He especificado idmap uid = 12000, y idmap gid = 3000-3500 y winbind está en ejecución. Cuando hago lo sigueinte todo funciona bien
root# wbinfo -u MIDEARTH+maryo MIDEARTH+jackb MIDEARTH+ameds ... MIDEARTH+root root# wbinfo -g MIDEARTH+Domain Users MIDEARTH+Domain Admins MIDEARTH+Domain Guests ... MIDEARTH+Accounts root# getent passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash ... maryo:x:15000:15003:Mary Orville:/home/MIDEARTH/maryo:/bin/false |
Pero la siguiente orden falla:
root# chown maryo a_file chown: `maryo': invalid user |
El mismo problema anterior. Probablemente está ejecutando nscd, el demonio del servicio decacheo de nombres. Párelo y no lo reinicie, verá como se resuelve el problema.