Autenticación en Apache: básica y PAM

Sin comentarios »
Leído 20 veces

apache El servidor web Apache puede acompañarse de distintos módulos para proporcionar diferentes modelos de autenticación. Hoy vamos a echarle un vistazo a la configuración básica de dos de los más utilizados y sencillotes. Vamos allá.

La primera forma que veremos es la más simple. Usamos para ello el módulo de autenticación básica que viene instalada “de serie” con cualquier Apache. La configuración que tenemos que añadir en el fichero de definición del Virtual Host a proteger podría ser algo así:

<Directory "/var/www/miweb/privado">
     Order deny,allow
     AuthUserFile "/etc/apache2/claves/passwd.txt"
     AuthName "Palabra de paso"
     AuthType Basic
     <Limit GET POST>
          Require valid-user
     </Limit>
</Directory>

La información a personalizar está marcada en negritas. En Directory escribimos el directorio a proteger, que puede ser el raíz de nuestro Virtual Host o un directorio interior a este. En AuthUserFile ponemos el fichero que guardará la información de usuarios y contraseñas que debería de estar, como en este ejemplo, en un directorio que no sea visitable desde nuestro Apache. Ahora comentaremos la forma de generarlo. Por último, en AutnName personalizamos el mensaje que aparecerá en la ventana del navegador que nos pedirá la contraseña. Existen otras directivas adicionales o modificaciones a estas útiles para personalizar el acceso: AuthGroupFile, Require user, Require group, etc. Ya sabéis: Google es vuestro amigo ;-)

El fichero de contraseñas se genera mediante la utilidad htpasswd. Su sintaxis es bien sencilla. Para añadir un nuevo usuario al fichero operamos así:

# htpasswd /etc/apache2/claves/passwd.txt carolina
New password:
Re-type new password:
Adding password for user carolina

Para crear el fichero de contraseñas con la introducción del primer usuario tenemos que añadir la opción -c (create) al comando anterior. Si por error la seguimos usando al incorporar nuevos usuarios borraremos todos los anteriores, así que cuidado con esto. Las contraseñas, como podemos ver a continuación, no se guardan en claro. Lo que se almacena es el resultado de aplicar una función hash.

josemaria:rOUetcAKYaliE
carolina:hmO6V4bM8KLdw
alberto:9RjyKKYK.xyhk

Para denegar el acceso a algún usuario basta con que borremos la línea correspondiente al mismo. No es necesario que le pidamos a Apache que vuelva a leer su configuración (/etc/init.d/apache2 reload) cada vez que hagamos algún cambio en este fichero de contraseñas, pero si lo es después de hacer los cambios en el fichero de definición del Virtual Host.

autenticación en apache La principal ventaja de este método es su sencillez. Sus inconvenientes: lo incómodo de delegar la generación de nuevos usuarios en alguien que no sea un administrador de sistemas o de hacer un front-end para que sea el propio usuario quien cambie su contraseña. Y, por supuesto, que dichas contraseñas viajan en claro a través de la red. Si queremos evitar esto último podemos crear una instancia Apache con SSL.

El segundo método que vamos a tocar usa PAM, el propio sistema de autenticación de la máquina donde está instalado nuestro servidor de Apache. Si ya tenemos alguna herramienta de gestión de usuarios y contraseñas en la misma este sistema nos ahora el engorro de tener que generar otro tipo de usuario. En caso contrario no ganamos mucho en este sentido y seguimos teniendo el problema de que las contraseñas viajan en claro con el agravante adicional de que ahora se trata de usuarios de la máquina… así que ya sabéis: o configuráis ssl o usáis el truco que comentamos el otro día por aquí para deshabilitar la conexión remota.

Usaremos para ello el módulo mod_auth_pam y lo primero que tenemos que hacer es instalarlo:

# sudo apt-get install libapache2-mod-auth-pam

En el fichero de configuración del Virtual Host tendríamos que incluir algo así:

<Directory "/var/www/privado">
     AuthType Basic
     AuthName "Palabra de paso"
     AuthPAM_Enabled On
     AuthBasicAuthoritative Off
     AuthUserFile /dev/null
     Require user josemaria gemma fernando araceli
</code>

Si en este caso la directiva usada fuese Require valid-user se permitiría el acceso a cualquier usuario con cuenta en la máquina. Ah, y no olvides hacer un reload de apache después de este cambio.

Sólo nos quedan un par de pasos. Primero, añadir el usuario www-data (el que usa apache) al grupo shadow para que pueda verificar las contraseñas:

usermod -a -G shadow www-data

Y dos, hacer un enlace como el que sigue. Ignoro la causa, pero el motivo de que esto sea necesario es debido a que apache (en los binarios de Debian y Ubuntu, al menos) pretende leer del archivo /etc/pam.d/http mientras que el módulo de autenticación ha creado el archvo /etc/pam.d/apache2. El módulo auth_pam hace años que no está soportado e imagino que esto tiene algo que ver, pero no lo se a ciencia cierta. Simplemente lo leí por ahí...

ln -s /etc/pam.d/apache2 /etc/pam.d/httpd

Y con esto está todo listo. No lo he probado nunca pero también he leído que la autenticación se hace contra el directorio activo si Apache está instalado en una máquina windows configurada en un dominio. Existe también un módulo para autenticar contra un ldap (mod_auth_ldap) que si que he probado y que ya veremos otro día ;-)

Instalar un servidor de correo IMAP en Linux

2 comentarios »
Leído 132 veces

herramientas Hoy vamos a dejar por aquí un paso a paso para montar un servidor de correo de la forma más sencilla posible y con acceso a través de IMAP y de webmail. Partimos, para ello, de un servidor Debian recien instalado y disponemos de un dominio y de un servicio desde el que gestionar los registros de nuestro DNS. Para la instalación usaremos Postfix como SMTP, Dovecot como servidor IMAP y Squirrel como servicio de Webmail.

Lo primero que debemos de hacer es planificar los nombres que necesitamos dar de alta en el DNS para hacerlo cuanto antes y dar tiempo a que se propaguen. Realmente un único registro A y otro MX nos valdrían ya que todo va a funcionar en la misma máquina, pero por aquello de que quede bonito y pensando en futuros cambios en los que el servicio crezca y necesitemos usar máquinas diferentes para cada cosa, deberíamos de crear un registro A diferente para cada uno de los servicios. Algo así:

smtp IN A 99.99.99.99
mail IN A 99.99.99.99
webmail IN A 99.99.99.99
@ IN MX 10 mail.midominio.com

Donde, lógicamente, hemos de cambiar midominio.com por el nombre de dominio que vamos a usar y 99.99.99.99 por la IP de nuestra máquina.

En segundo lugar debemos de instalar los paquetes que necesitamos. Dejaremos el webmail para el final y nos centraremos en el resto. Para ponerlo en funcionamiento necesitamos instalar, además de postfix y dovecot, los paquetes necesarios para realizar la autenticación mediante el protocolo SASL:

# apt-get install postfix-tls libsasl2-2 sasl2-bin libsasl2-modules dovecot-imapd

El archivo de configuración principal de postfix es /etc/postfix/main.cf. Lo siguiente que tenemos que hacer es editarlo y añadir las siguientes líneas a su contenido:

smtpd_sasl_local_domain = midominio.com
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_security_options = noanonymous
home_mailbox = Maildir/

En la primera línea debemos de sustituir la cadena en negritas por el dominio cuyo correo queremos recibir. El resto de los parámetros determinan el tipo de autenticación que vamos a realizar, el servicio que se encargará de la autenticación (dovecot en este caso) y las restricciones de acceso más comunes al servidor. Tienes información detallada de todas ellas en este enlace.

Con el parámetro home_mailbox, muy importante, indicamos a Postfix que queremos usar el formato de correo Maildir y que la ubicación de las carpetas donde se almacenará este será un directorio denominado Maildir en el raiz del directorio home de cada usuario. Si no lo especificamos así, el correo se almacenará en un único fichero con el nombre de la cuenta de cada usuario y bajo el directorio /var/mail.

Una de las operaciones que se realiza durante la instalación de Dovecot es crear la estructura necesaria para albergar los buzones de correo en el directorio /etc/skel que es el que sirve de plantilla para generar el home de los nuevos usuarios. Eso quiere decir que los usuarios que tengamos previamente creados antes de hacer esta instalación no dispondrán de dichos directorios y, por tanto, no funcionaran correctamente. Para remedir esto tenemos que copiar manualmente dicha estructura. Supongamos que queremos copiar la estructura de buzones al usuario josemaria, ya creado antes de esta instalación. La operación sería la siguiente:

# cp -r /etc/skel/Maildir /home/josemaria
# chown -R josemaria:josemaria /home/josemaria/Maildir
# chmod -R 700 /home/josemaria/Maildir

La configuración de dovecot la realizamos en el fichero /etc/dovecot/dovecot.conf. Así como el archivo de configuración de postfix es sencillito y asequible (apenas tiene 20 líneas), el de dovecot es un engendro de más de 1000 líneas. Casi todas son comentarios, si, pero aun así asusta bastante…

Los dos primeros cambios son para determinar el protocolo que vamos a usar y habilitar la autenticación mediante texto plano. Busca las siguientes líneas y asegúrate de que no están comentadas y de que sus valores son estos:

protocols = imap
disable_plaintext_auth = no

El siguiente cambio va encaminado a configurar el identificador único que usaremos para cada email. Para que exista compatibilidad con algunos de los clientes de Microsoft es necesario que se defina de esta forma:

pop3_uidl_format = %08Xu%08Xv

Y ya sólo nos resta por definir los parámetros relativos al mecanismo de autenticación que hemos elegido. Lo hacemos con el siguiente bloque:

auth default {
     mechanisms = plain login
     passdb pam {
     }
     userdb passwd {
     }
     socket listen {
          client {
               path = /var/spool/postfix/private/auth
               mode = 0660
               user = postfix
               group = postfix
          }
     }
}

Ahora necesitamos hacer unas pequeñas modificaciones para permitir la comunicación entre postfix y sasl. Puesto que el daemon de postix se ejecuta mediante chroot en el directorio /var/spool/postfix, crearemos un enlace allí al que podrá acceder el daemon de sasl:

# mkdir -p /var/spool/postfix/var/run/saslauthd
# rm -r /var/run/saslauthd/
# ln -s /var/spool/postfix/var/run/saslauthd /var/run
# chgrp sasl /var/spool/postfix/var/run/saslauthd
# adduser postfix sasl

Y, finalmente, debemos de reiniciar los tres servicios involucrados para que lean los cambios hechos en sus respectivas configuraciones:

#/etc/init.d/saslauthd restart
#/etc/init.d/postfix restart
#/etc/init.d/dovecot restart

Para quién la autenticación mediante usuario y contraseña con texto plano se le quede corta, puede echarle un vistazo a este tutorial donde explican como realizarla mediante TLS.

Vamos ahora con la instalación de Squirrel Mail que es mucho más sencilla. Para ello necesitamos instalar apache, php y el propio squirrel:

# apt-get install apache2 libapache2-mod-php5 php5-cli php5-common php5-cgi squirrelmail

En el directorio /etc/squirrelmail tenemos un archivo llamado apache.conf con la configuración necesaria para crear la instancia de apache que nos permitirá acceder a Squirrel. Debemos de editarlo para modificar los datos correspondientes al Virtual Host que queremos crear:

<VirtualHost *:80 >
     DocumentRoot /usr/share/squirrelmail
     ServerName webmail.midominio.com
</VirtualHost>

Luego creamos un enlace a este archivo en el directorio sites-availables de apache:

# ln -s /etc/squirrelmail/apache.conf /etc/apache2/sites-available/squirrelmail

Y, por último, habilitamos el sitio y pedimos a Apache que vuelva a recargar su configuración:

# a2ensite squirrelmail
# /etc/init.d/apache2 reload

La configuración de squirrel se realiza a través de un sencillo programa en modo consola que permite seleccionar, desde el idioma por defecto o el icono de la página de login, hasta la ubicación de carpetas por defecto o los plugins disponibles. Dicho programa se lanza con el siguiente comando:

# /usr/sbin/squirrelmail-configure

Con esto tenemos nuestro servidor de correo perfectamente operativo. Para crear una nueva cuenta de correo basta con que creemos un nuevo usuario en la máquina. Si creamos una cuenta llamada paquito, automaticamente se creará un buzón de correo para paquito@midominio.com cuyos mensajes se almacenaran en un directorio llamado Maildir que colgará del home de nuestro nuevo usuario.

Un par de ajustes finales. Si nuestra máquina permite el acceso por ssh y sólo queremos dar acceso de correo pero no permitir que estos usuarios accedan a la consola de la misma, lo mejor es que creemos un grupo con los usuarios que tendrán acceso de ssh y lo indiquemos así. Además, recordad que la autenticación de las cuentas de correo la estamos haciendo en texto plano, con lo cual cualquiera podría “escucharlas” y disponer de una cuenta de acceso a nuestra máquina. Podríamos, por ejemplo, tener un grupo llamado ssh_permitido al que pertenecerían los usuarios con permiso de acceso e indicarlo en el fichero /etc/ssh/sshd_config con la siguiente directiva:

AllowGroups ssh_permitido

Otro posible “extra” sería permitir que los usuarios con cuenta de correo pudieran modificar sus contraseñas a través de la web. En Unixcraft nos cuentan como hacer un script PHP para permitirlo.

Thunderbird, Lightning & Google Calendar

1 comentario »
Leído 338 veces

thunderbird Hace ya muchos años que uso Thunderbird como cliente de correo electrónico y Google Calendar como gestor de citas y eventos, pero como muchos de los que hemos echado los dientes con el Outlook siempre he echado de menos un calendario integrado en el cliente de correo electrónico y ni Evolution ni Kmail despiertan mis simpatías. Además, el recordatorio gratuito por SMS de Google Calendar es, hoy por hoy, insustituible. Ahora podemos tener lo mejor de ambos mundos gracias a dos extensiones disponibles para thunderbird: Lightning y Provider for Google Calendar.

Una vez instaladas ambas Lightning proporciona un calendario integrado perfectamente con Thunderbird y Provider for Google Calendar la sincronización con uno o varios calendarios creados previamente en Google Calendar. Partiendo de que ya has instalado ambas extensiones y tienes ese (o esos) calendario creado en el sistema de Google, configurar la sincronización entre ambos es tan sencillo como seguir estos pasos:

entrando en lightning1. Una vez instalado lightning tendremos disponibles dos pequeños iconos en la parte superior derecha de nuestro thunderbird y bajo la caja de filtros de búsquedas. Pulsamos el primero de ellos para entrar en la vista de calendario y esta se nos abrirá en otra solapa. El atajo de teclado es Ctrl+May+C y la opción de menú se encuentra bajo el nuevo item etiquetado como “Events and Tasks”.

creando un nuevo calendario en lightning2. Ya dentro de la vista de calendario, creamos uno nuevo pulsando con el botón derecho del ratón sobre el panel izquierdo y eligiendo la opción de “New Calendar”.

3. A continuación se nos abre una sencilla ventana de diálogo en la que debemos de elegir si el nuevo calendario que queremos crear se almacenará en local o estará ubicado en la red. Elegimos la segunda opción y pulsamos Intro.

creando un nuevo calendario en lightning 2

tomando datos de google calendar 1 4. En el siguiente diálogo se nos pedirá la ubicación en la red de dicho calendario, así que necesitamos que google calendar nos proporcione esos datos. Lo abrimos, elegimos el calendario que queremos sincronizar con Lightning y, pulsando sobre el pequeño icono a su derecha, escogemos la opción de “Configuración de Calendario”.

tomando datos de google calendar 25. Ya en la página de “Configuración del calendario”, nos vamos al apartado de dirección de calendario y pulsando con el botón derecho sobre el botón de XML elegimos la opción de “Copiar dirección de enlace”.

6. Volvemos a thunderbird-lightning y en el diálogo siguiente elegimos el formato de Google Calendar y en la caja de Localización copiamos la dirección que hemos obtenido en Google Calendar. Al pulsar siguiente, y si es el primer calendario que sincronizamos, se nos pedirá usuario y contraseña para validar la conexión con los servicios de Google.

creando un nuevo calendario en lightning 3

7. Y ya casi estamos. Finalmente elegimos un nombre y un color distintivo para los eventos de nuestro calendario (muy útil si, como yo, separas los eventos por categorías en diferentes calendarios) y pulsamos el botón de Siguiente.

creando un nuevo calendario en lightning 4

El resultado final, una vez repetida la operación con todos nuestros calendarios, debería de mostrarnos algo así:

Lightning & Thunderbird

La sincronización desde ambos extremos es perfecta e, incluso, tareas como la configuración de avisos por SMS procedentes de Google se pueden realizar perfectamante desde el propio Thunderbird:

Configurando avisos por SMS desde Thunderbird

Integrando un servidor Samba en un Dominio Windows

8 comentarios »
Leído 8,149 veces

corte del icono de samba El punto de partida es el siguiente: en tu empresa ya se usa un dominio con directorio activo de windows para la gestión de usuarios y grupos y quieres introducir una nueva maquina que haga funciónes de servidor de ficheros pero no te hace gracia pagar una nueva licencia y, además, quieres sacarle un poco más de rendimiento a esa máquina tan bonita que se ha comprado. La solución es usar Samba que desde su versión 3 se integra perfectamente con el directorio activo de windows. La chuleta que os cuento a continuación funciona tanto con windows server 2000 como con la versión 2003.

  • Nombre de dominio: madrid.midomino.es
  • Nombre NETBIOS del dominio: MADRID
  • Nombre e IP del servidor windows: win2k / 192.168.1.2
  • Nombre e IP del servidor Debian: samba / 192.168.1.3

Nuestro servidor windows además de ser el controlador principal del dominio tiene activado el servicio de DNS y lo primero que debemos hacer es abrir manualmente un registro para nuestro servidor samba con su correspondiente IP. Los paquetes que deberíamos de tener instalados en nuestro debian son samba, winbind y krb5-user (creo que los nombres son los mismos en una Ubuntu Server).

Manos a la obra. En primer lugar nos aseguramos de que la resolución de nombres de nuestro servidor samba apunte correctamente al DNS del servidor que contiene nuestro directorio activo. Para ello editamos el fichero /etc/resolv.conf de esta forma:

search madrid.midominio.es
domain madrid.midominio.es
nameserver 192.168.1.2
nameserver 80.58.61.250
nameserver 80.58.61.254

En segundo lugar editamos el fichero /etc/krb5.conf para permitir la validación a través de kerberos con el siguiente contenido:

[libdefaults]
default_realm = MADRID.MIDOMINIO.ES

[realms]
MADRID.MIDOMINIO.ES = {
kdc = 192.168.1.2
admin_server = 192.168.1.2
}

[domain_realms]
.dominio.es = MADRID.MIDOMINIO.ES

Tres: editar el fichero /etc/nsswitch.conf que es quien regula el orden en el que se realizaran las búsquedas de usuarios, grupos, nombres de máquinas en nuestra máquina Linux. El contenido debería de ser algo así:

passwd: files winbind ldap
shadow: files winbind ldap
group: files winbind ldap

hosts: files dns wins
networks: files dns

services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
publickey: files

bootparams: files
automount: files
aliases: files

Y cuatro: editamos el fichero /etc/samba/smb.conf:

[global]
unix charset = LOCALE
realm=MADRID.MIDOMINIO.ES
workgroup=MADRID
security=ADS
password server=*
winbind separator=+
log level = 1
syslog = 0
log file = /var/log/samba/%m
max log size = 50
winbind uid=10000-20000
winbind gid=10000-20000
winbind enum users=yes
winbind enum groups=yes
template homedir=/tmp
template shell=/bin/false

Y ya casi estamos. Lo primero que vamos a hacer ahora es validad nuestro fichero smb.conf mediante el comando testparm:

samba:/etc# testparm -s
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
'winbind separator = +' might cause problems with group membership.
Server role: ROLE_DOMAIN_MEMBER
[global]
unix charset = LOCALE
workgroup = MADRID
realm = MADRID.MIDOMINIO.ES
security = ADS
log level = 1
syslog = 0
log file = /var/log/samba/%m
max log size = 50
idmap uid = 10000-20000
idmap gid = 10000-20000
template homedir = /tmp
winbind separator = +
winbind enum users = Yes
winbind enum groups = Yes
samba:/etc#

Ahora tenemos que asegurarnos de que la sincronización horaria entre nuestros dos servidores es correcta. Para ello usamos el comando net time set:

samba:/etc# net time set
mié nov 28 22:19:23 CET 2007
samba:/etc#

Puesto que es muy importante que esta sincronización sea permanente lo mejor es programar la ejecución de este comando en nuestro cron. Por ejemplo así:

samba:/etc# crontab -l
# m h dom mon dow command
0 5 * * * /usr/bin/net time set

samba:/etc#

Hora, finalmente, de añadir nuestra máquina Linux al directorio activo de windows.

samba:/etc# net ads join -UAdministrador%micontraseña
Using short domain name -- MADRID
Joined 'SAMBA' to realm 'MADRID.MIDOMINIO.ES'
samba:/etc#

Donde sustituiremos los parámetros que acompañan al comando net ads join por un usuario y su contraseña (Administrador y micontraseña respectivamente en este caso) con privilegios de administradores del dominio. Y ya debería de estar todo funcionando. Ahora podemos comprobar que la resolución es correcta y que podemos usar los usuarios y grupos de nuestro directorio activo para validar permisos en samba mediante los siguientes comandos: wbinfo nos lista los usuarios y grupos del directorio activo.

samba:/etc# wbinfo -u
MADRID+administrador
MADRID+invitado
MADRID+tsinternetuser
MADRID+krbtgt
MADRID+arturof
MADRID+josemaria
...

samba:/etc# wbinfo -g
BUILTIN+administrators
BUILTIN+users
MADRID+equipos del dominio
MADRID+controladores de dominio
MADRID+administradores de esquema
MADRID+administración de empresas
MADRID+publicadores de certificados
MADRID+admins. del dominio
MADRID+usuarios del dominio
MADRID+invitados de dominio
MADRID+propietarios del creador de directivas de grupo
MADRID+dnsupdateproxy
MADRID+administracion
MADRID+finanzas
MADRID+proyectos
MADRID+sistemas
...

Por último comprobaremos que la validación de usuarios y grupos funciona también vía NSS mediante getent:

samba:/home/josemaria# getent passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
...
MADRID+administrador:*:10000:10000:Administrador:
/tmp:/bin/false
MADRID+invitado:*:10001:10000:Invitado:/tmp:/bin/false
MADRID+tsinternetuser:*:10002:10000:TsInternetUser:
/tmp:/bin/false
MADRID+krbtgt:*:10003:10000:krbtgt:/tmp:/bin/false
MADRID+arturof:*:10004:10000:Arturo:/tmp:/bin/false
...
samba:/home/josemaria# getent group
root:x:0:
daemon:x:1:
bin:x:2:
sys:x:3:
adm:x:4:
...
MADRID+equipos del dominio:x:10001:
MADRID+controladores de dominio:x:10002:MADRID+itziarr
MADRID+administradores de esquema:x:10003:MADRID+administrador
MADRID+administración de empresas:x:10004:MADRID+administrador
MADRID+publicadores de certificados:x:10005:
...

A partir de ahora podremos usar los usuarios y grupos almacenados en el directorio activo de windows para conceder acceso a los recursos de samba de esta forma:

[sistemas]
path = /media/samba/sistemas
guest ok = no
read only = no
valid users = @MADRID+sistemas-r @MADRID+sistemas-rw @BUILTIN+administrators
read list = @MADRID+sistemas-r @BUILTIN+administrators
write list = @MADRID+sistemas-rw
force group = @MADRID+sistemas-rw
create mask = 0775
directory mask = 0775

ACTUALIZACIÓN: El capítulo Active Directory Domain with Samba Domain Member Server del libro Samba 3 by example es un excelente complemento y ampliación a esta entrada.