En ambientes ideales donde la relación pc a usuario es de 1:1 el trabajo encaminado al desarrollo por cada cual se puede optimizar más. Sin embargo esto provoca que aumenten los riesgos ya que la pérdida de la información en una pc puede acarrear atrasos y riesgos ulteriores.
La creación de un ambiente homogéneo en el que todas las pc's puedan ser accedidas por todos los usuarios se nos acerca como una variante que ayuda a igualar las condiciones de trabajo del equipo y que nos permite centralizar y respaldar la información más fácil.
En este artículo hablaremos sobre la centralización de usuarios para su autenticación a través de las estaciones de trabajo. Aunque existen variantes para lograr este objetivo con servicios como bases de datos relacionales u otros servicios, hay un servicio que es usado ampliamente y es el de Directorio. Explicaremos el uso de la instrumentación libre del servidor LDAP openldap para ello.
Servidor
En el servidor es necesario instalar el paquete slapd y configurar el fichero /etc/ldap/slapd.conf. Es necesario definir las opciones de configuración. Mostraremos un ejemplo sobre una configuración ejemplo:
* Tipo de base de datos: bdb
* Base del dominio: dc=subdom1,dc=subdom,dc=dom
* Acceso a las contraseñas: admin modifica todas y los usuarios sólo las propias, anónimos requieren de autenticación
* Acceso al contenido: admin tiene todos los permisos, el resto sólo lectura
* Base del dominio: dc=subdom1,dc=subdom,dc=dom
* Acceso a las contraseñas: admin modifica todas y los usuarios sólo las propias, anónimos requieren de autenticación
* Acceso al contenido: admin tiene todos los permisos, el resto sólo lectura
Así queda el archivo finalmente:
database bdb
suffix "dc=subdom1,dc=subdom,dc=dom"
rootdn "cn=admin,dc=subdom1,dc=subdom,dc=dom"
rootpw secret
directory /var/lib/ldap
suffix "dc=subdom1,dc=subdom,dc=dom"
rootdn "cn=admin,dc=subdom1,dc=subdom,dc=dom"
rootpw secret
directory /var/lib/ldap
Una vez configurado, es necesario añadir la base del dominio y el usuario admin. Para esto podemos usar cualquier cliente ldap que nos permita añadir información vía ficheros ldif.
Las bases de dato de tipo ldif al ser sistemas de acceso local, se acceden interpretando ficheros .ldif de los cuales se extraen los directorios y otras informaciones para construir la base de datos
Crearemos entonces un fichero ldif con la siguiente información:
dn: dc=subdom1,dc=subdom,dc=dom
objectClass: top
objectClass: dcObject
objectClass: organization
o: proyecto
dc: proyecto
dn: cn=subdom1,dc=subdom,dc=dom
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: administrador LDAP
objectClass: top
objectClass: dcObject
objectClass: organization
o: proyecto
dc: proyecto
dn: cn=subdom1,dc=subdom,dc=dom
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: administrador LDAP
Luego de crearlo lo añadimos con cualquier cliente para ello. En este caso usamos el programa ldapadd que viene como parte del paquete ldap-utils.
# apt-get install ldap-utils
Al entrar la siguiente línea se pedirá la contraseña de administración que especificamos en la instalación de slapd:
# ldapadd -x -D "cn=admin,dc=subdom1,dc=subdom,dc=dom" -W -f a.ldif
Una vez creados el dominio base del servidor y el superusuario (admin) accederemos con cualquier cliente para administrar este tipo de servicios. Un cliente muy usado es el phpmyadmin
Clientes
Para configurar el acceso por ldap a cada una de las estaciones de trabajo por PAM debemos instalar dos paquetes libpam-ldap y libnss-ldap.
# apt-get install libpam-ldap libnss-ldap
Cuando se instalan ellos piden automáticamente los datos necesarios. Los siguientes datos los pondremos si se piden.
1. LDAP Server host "ip del servidor"
2. Distinguished name ... dc=subdom1, dc=subdom, dc=dom
3. LDAP version to use 3
4. Make local root Database admin No
5. Database requires logging in No
6. Local crypt to use when... md5
2. Distinguished name ... dc=subdom1, dc=subdom, dc=dom
3. LDAP version to use 3
4. Make local root Database admin No
5. Database requires logging in No
6. Local crypt to use when... md5
Luego editaremos en /etc los ficheros nsswitch.conf, pam.d/common-account, pam.d/common-auth, pam.d/common-password y pam.d/common-session para que queden así:
nsswitch.conf
passwd: files ldap
group: files ldap
shadow: files ldap
group: files ldap
shadow: files ldap
common-account
account [success=1 default=ignore] pam_unix.so
account sufficient pam_ldap.so
account required pam_permit.so
account sufficient pam_ldap.so
account required pam_permit.so
common-auth
auth [success=1 default=ignore] pam_unix.so
auth sufficient required pam_ldap.so use_first_pass
auth required pam_permit.so
auth sufficient required pam_ldap.so use_first_pass
auth required pam_permit.so
common-password
password required pam_passwdqc.so min=disabled,16,12,8,6 max=256
password [success=1 default=ignore] pam_unix.so use_authtok md5
password required pam_ldap.so use_first_pass use_authtok md5
password required pam_permit.so
password [success=1 default=ignore] pam_unix.so use_authtok md5
password required pam_ldap.so use_first_pass use_authtok md5
password required pam_permit.so
common-session
session required pam_mkhomedir.so
session required pam_unix.so
session required pam_unix.so
Ya con esto se podrá autenticar por PAM desde las estaciones de trabajo. Si quisiéramos añadir usuarios del sistema al directorio del LDAP podemos emplear una herramienta llamada migrationtools que nos permite hacerlo
# apt-get install migrationtools
Una característica que tiene este sistema de autenticación es que como todos los usuarios autentican por PAM y los servidores también autentican por PAM para tener la información de los usuarios en base a permisos, autorizaciones, etc ... estos podían acceder a los servidores, aunque con permisos restringidos. Se planteó una solución a esto modificando las directivas de ssh en el fichero /etc/pam.d/ssh. Estas incluyen las básicas de autenticación. Simplemente le negamos ese privilegio y sólo le declaramos autenticación por usuarios locales (sólo por root) y queda resuelto el problema. Nos quedaría así:
# PAM configuration for the Secure Shell service
# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth required pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
auth required pam_env.so envfile=/etc/default/locale
# Standard Un*x authentication.
# Cambio aqui para incluir solo por el local
#@include common-auth
auth required pam_permit.so
# Disallow non-root logins when /etc/nologin exists.
account required pam_nologin.so
# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account required pam_access.so
# Standard Un*x authorization.
# Cambio aqui para incluir solo el local
#@include common-account
account required pam_permit.so
# Standard Un*x session setup and teardown.
@include common-session
session required pam_unix.so
# Print the message of the day upon successful login.
session optional pam_motd.so # [1]
# Print the status of the user's mailbox upon successful login.
session optional pam_mail.so standard noenv # [1]
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
# Set up SELinux capabilities (need modified pam)
# session required pam_selinux.so multiple
# Standard Un*x password updating.
# Cambio aqui para local
#@include common-password
password required pam_unix.so use_authtok nullok md5 use_first_pass
# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth required pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
auth required pam_env.so envfile=/etc/default/locale
# Standard Un*x authentication.
# Cambio aqui para incluir solo por el local
#@include common-auth
auth required pam_permit.so
# Disallow non-root logins when /etc/nologin exists.
account required pam_nologin.so
# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account required pam_access.so
# Standard Un*x authorization.
# Cambio aqui para incluir solo el local
#@include common-account
account required pam_permit.so
# Standard Un*x session setup and teardown.
@include common-session
session required pam_unix.so
# Print the message of the day upon successful login.
session optional pam_motd.so # [1]
# Print the status of the user's mailbox upon successful login.
session optional pam_mail.so standard noenv # [1]
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
# Set up SELinux capabilities (need modified pam)
# session required pam_selinux.so multiple
# Standard Un*x password updating.
# Cambio aqui para local
#@include common-password
password required pam_unix.so use_authtok nullok md5 use_first_pass
Siguiente ...
No hay comentarios:
Publicar un comentario