PDF de programación - Sistema de cuentas de usuario centralizadas con Kerberos 5, OpenLDAP y NFSv4 en Debian GNU/Linux (lenny)

CONSEJERIA DE EDUCACION
IES Gonzalo Nazareno

Sistema de cuentas de usuario centralizadas con Kerberos 5,

OpenLDAP y NFSv4 en Debian GNU/Linux (lenny)

Alberto Molina Coballes
21 de enero de 2010

Usted es libre de copiar, distribuir y modificar este documento de acuerdo
con las condiciones de la licencia Attribution-ShareAlike 3.0 de Creative Com-
mons. Puede ver una copia de ésta en:
http://creativecommons.org/licenses/by-sa/3.0/es/

Índice

1. Introducción

2. Características del montaje

3. Configuración previa

3.1. Instalación de bind9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Configuración de los clientes DNS . . . . . . . . . . . . . . . . . . . . . . .
3.3. Instalación de ntp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. Instalación del servidor OpenLDAP

4.1. Estructura básica del directorio . . . . . . . . . . . . . . . . . . . . . . . .
4.2. Definición de entradas destacadas . . . . . . . . . . . . . . . . . . . . . . .

5. Configuración del cliente LDAP. Name Service Switch (nss)

5.1. libnss-ldap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2. Modificación de /etc/nsswitch.conf . . . . . . . . . . . . . . . . . . . . . . .
5.3. Prueba de funcionamiento de nss . . . . . . . . . . . . . . . . . . . . . . .

6. Instalación del servidor MIT Kerberos 5

6.1. Definciones previas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Instalación de paquetes en el servidor Kerberos 5 . . . . . . . . . . . . . . .
6.3. Puesta en marcha de los servicios . . . . . . . . . . . . . . . . . . . . . . .
6.4. Ficheros keytab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5. Creación de usuarios para la administración de Kerberos . . . . . . . . . . .

7. Configuración del cliente Kerberos

7.1. klist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. kinit

8. SASL/GSSAPI

9. PAM

9.1. Modificación de los ficheros common-* . . . . . . . . . . . . . . . . . . . .
9.2. Prueba de funcionamiento de PAM . . . . . . . . . . . . . . . . . . . . . .

10.Network File System 4 (NFS4)

2

3

3

3
4
5
6

6
8
10

10
10
11
11

12
12
13
14
15
16

16
16
16

17

19
19
20

20

1.

Introducción

3

La forma clásica de almacenar información sobre las cuentas de los usuarios en sistemas UNIX
es mediante la información existente en los ficheros /etc/passwd, /etc/shadow y /etc/group,
método que funciona bien para gestionar las cuentas de usuarios en un solo equipo pero no es
útil para tener un sistema centralizado de cuentas. Entendemos como sistema centralizado de
cuentas aquel que permite a un usuario de una red usar diferentes equipos de la misma con
los mismos datos de autenticación y pudiendo acceder siempre a sus ficheros, para ello tanto
los datos de autenticación como los ficheros del usuario deben estar ubicados en servidores
de la red en lugar de en cada equipo.
En los sistemas que utilizan cuentas centralizadas se suelen utilizar dos tipos de cuentas: lo
que se denominan cuentas locales para los que se emplea el método tradicional de ficheros
y mediante un segundo método para las cuentas de usuarios que puedan autenticarse en
cualquier equipo de la red, lo que podríamos denominar usuarios de red.
En entornos UNIX durante bastante tiempo se ha utilizado NIS/NFS para la gestión centra-
lizada de cuentas de usuarios en una red local y su configuración es muy sencilla, pero es
una opción cada vez más en desuso por diferentes problemas que presenta, principalmente
porque no funciona sobre TCP/IP y la comunicación entre el cliente y el servidor no es cifrada,
lo que puede provocar problemas de seguridad.
Este documento se centra en explicar la forma de configurar un sistema centralizado de cuen-
tas de usuario, gestionando la información de autenticación con Kerberos, guardando el resto
de la información de la cuenta en un directorio OpenLDAP y utilizando Network File System
version 4 (NFS4) para los ficheros de los usuarios.
Aviso: Este documento se utiliza con fines educativos y no tiene como objetivo utilizarse en
una implantación real. Algún lector interesado podría utilizarlo como primer paso para la
implantación en un entorno real, pero debería realizar posteriormentes algunos ajustes para
la administración y seguridad de los servicios utilizados.

2. Características del montaje

Todo el montaje se va a realizar en dos equipos con sistema Debian GNU/Linux (lenny), uno
que va a actuar como servidor, en el que se realizarán la mayoría de pasos y otro que actuará
como cliente. Los nombres y direcciones IP de los equipos son:

Servidor
correcaminos
192.168.122.2 192.168.122.3 192.168.122.0/24

Red
example.com

Cliente
coyote

donde hemos utilizado example.com como nombre de dominio para los equipos de la red,
siendo éste uno de los nombres de dominio reservado para documentación de acuerdo con la
RFC-2606 [1].

3. Configuración previa

Es un requisito previo para el correcto funcionamiento de los servicios posteriores (en parti-
cular de Kerberos) la configuración de un servidor DNS con todos los nombres de los equipos

4
de la red y un servidor de hora para sincronizar los relojes de todos los equipos1. En esta
sección explicaremos de forma sucinta la manera de configurar estos servicios en la red, por
simplicidad todos los servicios se instalarán en correcaminos.

3.1.

Instalación de bind9

En primer lugar instalamos el paquete bind9:
correcaminos:˜# aptitude install bind9
Definimos las zonas de resolución local:

/etc/bind/named.conf.local

9 zone "example.com" {
type master;
file "/var/cache/bind/example.com.db";

10

11

12 };

13

14 zone "122.168.192.in-addr.arpa" {

type master;
file "/var/cache/bind/192.168.122.db";

15

16

17 };

y creamos los ficheros para la resolución directa e inversa, donde se han definido además
alias para las direcciones ldap y Kerberos que se utilizarán posteriormente y entradas SRV 2
correspondientes a los servicios LDAP y Kerberos:

/var/cache/bind/example.com.db

1 $TTL 86400
2 @
SOA

IN

correcaminos.example.com.

3

4

5

6

7

8 ;
9 @
10 coyote
11 correcaminos
12 kerberos
13 ldap

14

15 _kerberos

16

17 _kerberos._udp
18 _kerberos_adm._tcp
19 _ldap._tcp

IN
IN
IN
IN
IN

IN

IN
IN
IN

NS
A
A
CNAME
CNAME

TXT

SRV
SRV
SRV

hostmaster.example.com. (
1 ; Serial
604800 ; Refresh
86400
2419200 ; Expire
604800 ) ; TTL

; Retry

correcaminos
192.168.122.3
192.168.122.2
correcaminos
correcaminos

"EXAMPLE.COM"

0 0 88
kerberos.example.com.
0 0 749 kerberos.example.com.
0 0 389 ldap.example.com.

/var/cache/bind/example.com.db

1 @

2

IN

SOA

correcaminos.example.com.

1 ; Serial

hostmaster.example.com. (

1Realmente es necesario que todos los equipos de la red puedan hacer resolución directa e inversa de los

nombres y que tengan la misma hora

2Algunas aplicaciones utilizan entradas DNS tipo SRV y por eso la hemos incluido, aunque no son necesarias

para lo expuesto en este documento

5

3

4

5

6

7

8 @
9 2
10 3

604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL

NS
PTR
PTR

correcaminos.example.com.
correcaminos.example.com.
coyote.example.com.

Después de reiniciar el servicio, comprobamos el correcto funcionamiento del servidor DNS
realizando una consulta con dig:

correcaminos:˜$ dig ldap.example.com

; <<>> DiG 9.5.1-P3 <<>> ldap.example.com
;; global options:
;; Got answer:
;; ->>HEADER <<- opcode: QUERY , status: NOERROR , id: 17880
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

printcmd

;; QUESTION SECTION:
;ldap.example.com.

IN

A

;; ANSWER SECTION:
ldap.example.com.
86400
correcaminos.example.com. 86400

IN
IN

CNAME
A

correcaminos.example.com.
192.168.122.2

;; AUTHORITY SECTION:
example.com.

86400

IN

NS

correcaminos.example.com.

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan
5 17:02:51 2010
;; MSG SIZE

rcvd: 85

3.2. Configuración de los clientes DNS

En todos los equipos de la red habrá que definir el dominio de búsqueda y la dirección del
servidor DNS, esto es algo tan sencillo como hacer en correcaminos:

/etc/resolv.conf

1 domain example.com
2 search example.com
3 nameserver 127.0.0.1

En el resto de equipos habría que hacer la misma modificación, aunque considerando que en
ese caso la dirección IP del servidor de nombres es 192.168.122.2.
Tras hacer todas estas modificaciones, es conveniente verificar que el FQDN está bien confi-
gurado en todos los equipos de la red3:

correcaminos:˜$ hostname -f

correcaminos.example.com

3Hay que comprobar que no haya entradas mal definidas en el fichero /etc/hosts

3.3.

Instalación de ntp

6

Para instalar un servidor de hora en el equipo hay que hacer:

correcaminos:˜# aptitude install ntp
Para comprobar que se ha realizado una conexión a servidores de hora públicos y se ha
sincronizado el reloj local, verificamos la salida de la instrucción:

correcaminos:˜# ntpq -np

r e f i d

remote

j i t t e r
==============================================================================
2.665
+84.88.69.10
193.67.79.202
1.546
+163.117.131.239 219.76.239.59
∗158.227.98.15
2.387
−77.226.252.14
0.301

−2.308
31.764
0.161
14.545
−0.178
25.295
65.936 −12.789

140 512 277
389 512 377
93 512 377
390 512 377

. GPS .
150.214.94.5

2 u
2 u
1 u
2 u

t when p o l l

o f f s e t

reach

d e l a y

s t

En los clientes de la red instalaremos el mismo paquete, pero habrá que definir el servidor
ntp de la red y obviar los servidores de hora públicos:

/etc/ntp.conf

two ( o r

s e r v e r c o r r e c a m i n o s . example . com

15 # You do need t o t a l k t o an NTP s e r v e r o r
16
17
18 # p o o l . ntp . o r g maps t o about 1000 low−st r at u m NTP s e r v e r s .
19 # p i c k a d i f f e r e n t
20 # p o o l : <h t t p : / / www. p o o l . ntp . o r g / j o i n . html>
21 #s e r v e r 0. debian . p o o l . ntp . o r g i b u r s t dynamic
22 #s e r v