Administración de Kerberos
Este articulo esta seriamente incompleto porque necesita esclarecerse la terminología usada.
Contenido |
Resumen
Manual sobre la administración del servidor Kerberos
Introducción
Aunque no sea lo más usual, el hecho que un usuario se autentique en cualquier sistema implica de hecho varios componentes. Para los sistemas GNU/Linux, al menos debemos fijarnos en la definición de usuario y en la autenticación propiamente dicha del usuario. La definición del usuario se refiere a cosas tan fundamentales como el nombre de usuario (uid), el identificador numérico de usuario (uiNumber), ¿Cuál consola deberá usar (loginShell) según la normativa institucional)?, ¿Dónde se alojarán los datos dentro del equipo en el cual inicie sesión (homeDirectory)?; así como cuestiones de carácter más bien informativo, tal como su nombre (gecos).
La autenticación es algo más complicado. En realidad, el proceso implica métodos de verificar que el usuario es quién dice hacer (Por credenciales usuario/contraseña, por tickets OTP, por certificados digitales). En este caso, la autenticación se realiza en base a usuario/contraseña, con la diferencia que han de verificarse bajo el proceso ya conocido por kerberos (Lo que viene a significar al final de cuentas que, aunque se usen tales, no viajarán nunca por la red, entre otras cosas al menos)
Procedimiento
En el servidor
Creación de usuarios
El proceso a continuación descrito pareciera que crea dos veces a los usuarios. En realidad, tal como la introducción debiera sugerirle, definimos al usuario bajo la rama ou=Users de nuestro árbol LDAP, y creamos las credenciales a usar por Kerberos bajo cn=krbcontainer, en su dominio específico. Es posible que la misma entrada en ou=Users sirva para Kerberos, en este caso, agregaría a dicha entrada los atributos LDAP necesarios. Por otra parte, parece ser que complicamos tantos menos los permisos.
Una de las definiciones de usuario más sencillas podría ser de la siguiente forma:
dn: uid=alortiz,ou=Users,dc=salud,dc=gob,dc=sv objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount businessCategory: owncloud cn: Alexander Ortíz st: Nivel Administrativo Superior displayName: Alexander Ortíz gecos: Alexander Ortiz gidNumber: 1020 givenName: Alexander homeDirectory: /home/alortiz loginShell: /bin/bash mail: alortiz@salud.gob.sv o: Ministerio de Salud de El Salvador ou: DTIC postalAddress: 1610612736 sn: Ortíz telephoneNumber: 7459 title: Asistente Administrativo uid: alortiz uidNumber: 1005
Guardamos esto en un fichero .ldif y podemos agregarlo a nuestro directorio con ldapadd
ldapadd -D cn=admin,dc=salud,dc=gob,dc=sv -w srv2025 -f alortiz.ldif
Vale la pena destacar que ni siquiera agregamos el objectClass shadowAccount, porque no vamos a necesitar los atributos. Tampoco agregamos userPassword, aunque sea posible. Por otra parte, esto inhabilita a los usuarios de poder autenticarse al servidor LDAP por si mismo, lo cual, podría considerarse, es algo bueno.
Aprovechando la creación de nuestro usuario, crearemos el grupo al cual pertenece el usuario. Creamos el fichero con el original nombre de grupos.ldif con el siguiente contenido:
dn: cn=owncloud,ou=Groups,dc=salud,dc=gob,dc=sv objectClass: top objectClass: posixGroup cn: owncloud gidNumber: 1020 memberUid: alortiz
Y sí, aplicamos ldapadd de la forma ya conocida
ldapadd -D cn=admin,dc=salud,dc=gob,dc=sv -w srv2025 -f grupos.ldif
Luego, creamos sus credenciales en kerberos:
root@kerberos:~# kadmin -p admin/admin Authenticating as principal admin/admin with password. Password for admin/admin@SALUD.GOB.SV: kadmin: add_principal alortiz WARNING: no policy specified for alortiz@SALUD.GOB.SV; defaulting to no policy Enter password for principal "alortiz@SALUD.GOB.SV": Re-enter password for principal "alortiz@SALUD.GOB.SV": Principal "alortiz@SALUD.GOB.SV" created.
Que si no es posible verlo, lo que hacemos es usar el comando add_principal dentro de la consola administrativa de kerberos, kadmin. Así, sencillo e indoloro
Estos dos pasos, de forma indisoluble, conforman la creación de usuarios bajo un dominio como el nuestro.
En el cliente
Esta configuración no tiene que ser tan complicada como lo era antes. En realidad, es un sólo paquete, SSSD, que es capaz de manejar todos los componentes antes descritos para hacer posible al usuario autenticarse con credenciales remotas. Menos configuración, y por tanto, menos posibilidades de equivocarse.
Autenticación remota
Instalamos los paquetes necesarios:
aptitude install sssd
Configuramos a SSSD, configurando el fichero /etc/sssd/sssd.conf con el siguiente contenido:
[sssd] #debug_level = 0xFFF0 config_file_version = 2 services = nss, pam domains = salud.gob.sv [nss] filter_groups = root filter_users = root [pam] [domain/salud.gob.sv] cache_credentials = True enumerate = False auth_provider = krb5 chpass_provider = krb5 access_provider = simple krb5_server = kerberos.salud.gob.sv krb5_realm = SALUD.GOB.SV id_provider = ldap ldap_schema = rfc2307bis ldap_uri = ldap://kerberos.salud.gob.sv ldap_search_base = dc=salud,dc=gob,dc=sv ldap_user_search_base = ou=Users,dc=salud,dc=gob,dc=sv ldap_group_search_base = ou=Groups,dc=salud,dc=gob,dc=sv ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid ldap_id_use_start_tls = True ldap_tls_cacertdir = /etc/ssl/certs ldap_tls_cacert = /etc/ssl/certs/CA-sv.crt
Si es que varios usuarios podrían usar el mismo equipo, podemos automatizar la creación del directorio de usuario agregando
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
hacia el final de /etc/pam.d/common-auth
