Nagios + openldap auth + apache 2.4

Esta vez, vamos a integrar la authenticación de usuarios de nuestro nagios con nuestro openLDAP.

Primero de todo, habilitamos los módulos ldap / authnz_ldap

a2enmod authnz_ldap
a2enmod ldap

Modificamos el fichero de sites del nagios:

#nano /etc/apache2/sites-available/nagios.conf

Y lo dejamos tal que:

# SAMPLE CONFIG SNIPPETS FOR APACHE WEB SERVER
#
# This file contains examples of entries that need
# to be incorporated into your Apache web server
# configuration file. Customize the paths, etc. as
# needed to fit your system.

ScriptAlias /nagios/cgi-bin "/usr/local/nagios/sbin"


# SSLRequireSSL
Options ExecCGI
AllowOverride None
"<"IfVersion >= 2.3>

AuthType Basic
Require all granted
AuthName "Nagios Access"
AuthLDAPURL "ldap://ldap.miserver.local/dc=miserver,dc=local?uid?sub?(objectClass=*)"
AuthBasicprovider ldap
AuthUserFile /dev/null
Require valid-user


"<"IfVersion < 2.3>
Order allow,deny
Allow from all
AuthType Basic
Require all granted
AuthName "Nagios Access"
AuthLDAPURL ldap://ldap.miserver.local/dc=miserver,dc=local?uid?sub?(objectClass=*)
AuthBasicprovider ldap
AuthUserFile /dev/null
Require valid-user


Alias /nagios "/usr/local/nagios/share"


# SSLRequireSSL
Options None
AllowOverride None
"<"IfVersion >= 2.3>

AuthType Basic
Require all granted
AuthName "Nagios Access"
AuthLDAPURL ldap://ldap.miserver.local/dc=miserver,dc=local?uid?sub?(objectClass=*)
AuthBasicprovider ldap
AuthUserFile /dev/null
Require valid-user



"<"IfVersion < 2.3>
Order allow,deny
Allow from all
AuthType Basic
Require all granted
AuthName "Nagios Access"
AuthLDAPURL ldap://ldap.miserver.local/dc=miserver,dc=local?uid?sub?(objectClass=*)
AuthBasicprovider ldap
AuthUserFile /dev/null
Require valid-user



Ahora modificamos el nagios para que acepte los usuarios:

/
#nano /usr/local/nagios/etc/cgi.cfg

Y dejamos las siguientes líneas así:


authorized_for_system_information=*
authorized_for_configuration_information=*
authorized_for_system_commands=*
authorized_for_all_services=*
authorized_for_all_hosts=*
authorized_for_all_service_commands=*
authorized_for_all_host_commands=*

Reiniciamos apache + nagios y a probar !!!!!!!!

Añadir schema zarafa a openLdap

Otra entrada que es un apunte.

Recientemente he tenido que volver a instalar otro zarafa y necesitaba añadir el esquema en el openLdap.

Tras intentar importar el schema con zcat:

zcat /usr/share/doc/zarafa/zarafa.ldif.gz | ldapadd -H ldapi:/// -Y EXTERNAL

Y ver los múltiples errores con las comillas, atributos y demás gaitas, googleando he visto este post:


http://www.linuxquestions.org/questions/linux-server-73/how-to-add-a-new-schema-to-openldap-2-4-11-a-700452/

Resumiendo……. para poder importar el schema de manera correcta, los pasos:

1º) Generamos el fichero schema_convert.conf con el siguiente contenido:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/pmi.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/zarafa.schema

2º) Creamos el directorio temporal

# mkdir /tmp/ldif_output

3º) Generamos los ldif

# slaptest -f schema_convert.conf -F /tmp/ldif_output

4º) Nos vamos al directorio donde hemos generado los ficheros

cd tmp/ldif_output/cn=config/cn=schema

Y creamos el fichero fixit.sed con el siguiente contenido:

s~dn: cn=\{([0-9]+)\}(.*)$~dn: cn=\2,cn=schema,cn=config~g
s~cn: \{([0-9]+)\}(.*)$~cn: \2~g
s~^(structuralObjectClass|entryUUID|creatorsName|createTimestamp|entryCSN|modifiersName|modifyTimestamp):.*$~~g

5º) Una vez creado el fichero, creamos el directorio fixed y ejecutamos el siguiente script:

for f in *ldif; do sed -rf fixit.sed "$f" > fixed/$f; done

Llegados aquí, en el directorio fixed, tendremos los directorios:

root@radius:/tmp/ldif_output/cn=config/cn=schema/fixed# ls -l
total 96
-rw-r--r-- 1 root root 15267 Aug 24 10:39 cn={0}core.ldif
-rw-r--r-- 1 root root 1091 Aug 24 10:39 cn={10}openldap.ldif
-rw-r--r-- 1 root root 6212 Aug 24 10:39 cn={11}pmi.ldif
-rw-r--r-- 1 root root 3073 Aug 24 10:39 cn={12}ppolicy.ldif
-rw-r--r-- 1 root root 11121 Aug 24 10:39 cn={13}zarafa.ldif
-rw-r--r-- 1 root root 1289 Aug 24 10:39 cn={1}collective.ldif
-rw-r--r-- 1 root root 1051 Aug 24 10:39 cn={2}corba.ldif
-rw-r--r-- 1 root root 11129 Aug 24 10:39 cn={3}cosine.ldif
-rw-r--r-- 1 root root 4253 Aug 24 10:39 cn={4}duaconf.ldif
-rw-r--r-- 1 root root 1461 Aug 24 10:39 cn={5}dyngroup.ldif
-rw-r--r-- 1 root root 2623 Aug 24 10:39 cn={6}inetorgperson.ldif
-rw-r--r-- 1 root root 2357 Aug 24 10:39 cn={7}java.ldif
-rw-r--r-- 1 root root 1280 Aug 24 10:39 cn={8}misc.ldif
-rw-r--r-- 1 root root 6259 Aug 24 10:39 cn={9}nis.ldif

6º) Importamos el ldif de zarafa:

# ldapadd -Y EXTERNAL -H ldapi:/// -f cn\=\{13\}zarafa.ldif

Esto se puede aplicar, como me ha pasado a mi, con el schema de freeradius o otros schemas.

enjoy 🙂

Squid3 + openLdap Debian

Hace unos días, me tocó usar squid contra openLdap para autentificar los usuarios. A priori, es bastante más fácil que contra un active directory, ya que no hace falta ni kerberos, samba ni windbind.

Partimos de la base que ya tenemos el openLdap funcionando correctamente y nuestro squid también… así que ahora, editamos el fichero /etc/squid3/squid.conf y lo dejamos tal que:


auth_param basic program /usr/lib/squid3/squid_ldap_auth -b "dc=craem,dc=net" -f "uid=%s" -h 192.168.2.5
auth_param basic children 30
auth_param basic realm Servidor Proxy cRAeM
auth_param basic credentialsttl 6 hours
auth_param basic casesensitive off

acl usuariosLdap proxy_auth REQUIRED
http_access allow usuariosLdap
http_access deny all

Antes de todo, miraremos si tenemos el fichero /usr/lib/squid3/squid_ldap_auth y probamos si el ldap funciona correctamente, haciendo la siguiente prueba:

root@proxy:/etc/squid3# /usr/lib/squid3/squid_ldap_auth -b "dc=craem,dc=net" -f "uid=%s" 192.168.2.5

Le damos al intro y ponemos un user y password:

root@netflow:/etc/squid3# /usr/lib/squid3/squid_ldap_auth -b "dc=craem,dc=net" -f "uid=%s" 192.168.2.5
usuario password
OK

Si sale Ok, entonces es que funcionará.. sinó, pues es que faltará alguna librería o similar

El primer parámetro: auth_param basic children
Indica el número máximo de procesos de auth concurrentes… ojo si tenemos muchos usuarios y colocamos un número bajo, aunque no debería ser problema.

auth_param basic realm Servidor Proxy cRAeM
Es lo que saldrá en la ventanita de user / pass … me gusta tenerlo personalizado 😉

auth_param basic credentialsttl 6 hours
Básicamente, el tiempo que tendrá cacheada nuestras credenciales

auth_param basic casesensitive off
Pues eso

El resto:

acl usuariosLdap proxy_auth REQUIRED
http_access allow usuariosLdap
http_access deny all

acl usuariosLdap proxy_auth REQUIRED
Definimos la acl usuariosLdap con autenticación requerida

http_access allow usuariosLdap
http_access deny all

Permitimos el acceso a los usuarios autentificados y el resto… deny

Enjoy your ldap + squid

OpenMeetings openLdap Backend

Hoy toca configurar el openMeetings contra el openLdap.

Suponemos que:

– nuestro dominio ldap es craem.net.
– El usuario de lectura es openmeetings y password openmeetings.
– los usuarios los tenemos en la ou usuarios.
– Nuestro servidor ldap es: ldap.craem.net

Editamos el fichero:

/usr/lib/red5/webapps/openmeetings/conf/om_ldap.cfg

Y lo dejamos tal que:

# en nuestro caso es openLdap, con AD de micro$oft no acaba de ir bien
ldap_server_type=OpenLDAP
# la url de nuestro servidor
ldap_conn_url=ldap://ldap.craem.net:389
# la sintaxis es diferente, en vez del = es :
ldap_admin_dn=CN:openmeetings,DC:craem,DC:net
ldap_passwd=openmeetings
# ou donde buscamos los usuarios
ldap_search_base=CN:usuarios,DC:craem,DC:net
field_user_principal=uid
ldap_auth_type=SIMPLE
# sincronizamos los usuarios / pass, con la bbdd de openmeetings
ldap_sync_password_to_om=yes
# Ldap user attributes mapping
# Set the following internal OM user attributes to their corresponding Ldap-attribute
ldap_user_attr_lastname=sn
ldap_user_attr_firstname=givenName
ldap_user_attr_mail=mail
ldap_user_attr_street=streetAddress
ldap_user_attr_additionalname=description
ldap_user_attr_fax=facsimileTelephoneNumber
ldap_user_attr_zip=postalCode
ldap_user_attr_country=co
ldap_user_attr_town=l
ldap_user_attr_phone=telephoneNumber

Entramos como administrador al openmeetings y en la pestaña administration y ldap, ponemos el fichero que acabamos de modificar, tal que:

OpenMeetings OpenLDAP backend

Enjoy 😉

ProFTPD Debian + openLdap

Hoy toca documentar la instalación de un servidor FTP en Debian con autenticación de LDAP, unificando todos nuestros logins.

En esta ocasion instalaremos ProFTPD.

Instalamos los paquetes necesarios:

# apt-get install proftpd proftpd-mod-ldap

Nos preguntará si lo queremos integrado en inetd o independiente…. en mi caso me interesa tenerlo como servicio independiente, para poder pararlo sin afectar a otros servicios.

Editamos los ficheros de configuración:

# cd /etc/proftpd
# nano ldap.conf

Y lo dejaremos tal que:

#
# Proftpd sample configuration for LDAP authentication.
#
# (This is not to be used if you prefer a PAM-based SQL authentication)
#


#
# This is used for ordinary LDAP connections, with or without TLS
#
LDAPServer ldap://mi.servidor.open.ldap/??sub
LDAPDNInfo “cn=proftpd,dc=craem,dc=net” “proftpd”
LDAPDoAuth on “dc=craem,dc=net” “(&(uid=%v)(objectclass=posixAccount))”
LDAPAttr uid cn homeDirectory
LDAPAuthBinds on
#
# To be set on only for LDAP/TLS on ordinary port, for LDAP+SSL see below
#LDAPUseTLS on
#

#
# This is used for encrypted LDAPS connections
#
#LDAPServer ldaps://ldap.example.com
#LDAPDNInfo “cn=admin,dc=example,dc=com” “admin_password”
#LDAPDoAuth on “dc=users,dc=example,dc=com”
#

Y explicamos

LDAPServer ldap://mi.servidor.open.ldap/??sub

Ponemos la url de nuestro servidor ldap, más /??sub. En la documentación oficial sale.

LDAPDNInfo “cn=proftpd,dc=craem,dc=net” “proftpd”

En este caso, me he creado un usuario de lectura para openLdap y tener que poner el administrador 😉

LDAPDoAuth on “dc=craem,dc=net” “(&(uid=%v)(objectclass=posixAccount))”
Dónde buscará los usuarios y la propiedad de búsqueda, siendo en este caso posixAccount

LDAPAttr uid cn homeDirectory
El directorio de cada usuario, lo leeremos de la propiedad homeDirectory del ldap, que me parece muuy acertada.

LDAPAuthBinds on
Lo activamos 😉

Ahora vamos a revisar la parte de configuración propia de proFTPD:

Editamos el fichero /etc/proftpd.conf

#
# Alternative authentication frameworks
#
Include /etc/proftpd/ldap.conf
#Include /etc/proftpd/sql.conf

Descomentamos la parte de ldap y lo personalizamos un poco:

UseIPv6 off
# If set on you can experience a longer connection delay in many cases.
IdentLookups off

ServerName “ftp.craem.net”
ServerType standalone
DeferWelcome off

Quito la parte de ipv6, ya que aún no tengo, cambiamos el servername y lo activamos como “pasivo”

Ahora editaremos el fichero /etc/modules.conf para activar que cargue la parte ldap:

# Install proftpd-mod-ldap to use this
LoadModule mod_ldap.c

# Install proftpd-mod-ldap to use this
LoadModule mod_quotatab_ldap.c

En la propiedad homeDirectory el LDAP en cada usuario, hemos de establecer el directorio, que por ejemplo puede ser /home/%usuario%, por ejemplo:

Deberemos de crear el directorio para el usuario…. # mkdir /home/proftpd
Y ahora lo arrancamos para depurar y verlos logs:

# proftpd -nd 10

Si ha ido todo vien, lo paramos y lo arracamos como daemon

# /etc/init.d/proftpd start

And enjoy your ftp server with ldap

OwnCloud y OpenLdap backend

Esta entrada es más un apunte…. me ha costado varias pruebas conseguirlo.

OwnCloud es un producto magnífico para tener una “nube” personal, que tan de moda está ahora. Hice una máquina virtual para probarla y tras varios días jugando con ella, decidí tener la auth. de usuarios vía openLdap… así sigo teniendo con el mismo user/pass: Zarafa, Radius 802.1x, validación vpn ipsec, openFire, openMeetings y ahora, OwnCloud…. todo ello openSource y sin tener que depender de micro$oft.

Para hacer la autenticación de openLdap, en la pestaña ajustes / Administrador y colocamos los siguientes ajustes:

Los campos / valores:

Host: IP.DEL.SERVIDOR.OPENLDAP
Port: 389
Name: cn=adminLDAP,dc=dominio,dc=ldap // usuario con derecho de lectura
Password: passwordLDAP //el password
base: dc=dominio,dc=ldap // raíz del openLDAP
User Login Filter: uid=%uid
Display Name Field:uid

Enjoy your OwnCloud with openLDAP 🙂

22/11/2015

Actualizamos los pantallazos:

ownldap01

ownldap02on03ldap

own07

own05

own04ldap

Migrando Exchange 2010 a Zarafa, parte 8

Ahora nos toca la integración de los teléfonos con los buzones de Zarafa. Hay un grupo de desarrolladores que se han basado en el active-sync de Microsoft para hacer una integración casi perfecta: z-push.

No es difícil, pero me he encontrado los siguientes problemas:

1º) Android 2.2.1 <-> zarafa 7.x <-> z-push = TODO OK
2º) iOS iPhone 4.x / iPAD <-> zarafa 7.x <-> z-push = TODO OK
3º) Android 2.3.x <-> zarafa 7.x <-> z-push = Problemas !!!
4º) WM 6.5/7 <-> zarafa 7.x <-> z-push = NO USO WM 🙂

La relación con Android ha sido extraña. Cuando tenía el exchange 2003, la sincronización era perfecta con mi HTC Hero y su 2.2.1…… una vez migrado el Exchange a la versión 2010, se acabó la armonía…… las citas en el Calendario (imprescindibles para mi trabajo diario), si las creaba en el teléfono, se replicaban en el exchange, pero si las creaba en el exchange, estas no se replicaban en el teléfono. Repasé los log’s del teléfono, pero por alguna razón, las citas creadas de esta manera no aparecían en las listas de sincronización…. así que lo dejé estar, ya que los días de exchange se estaban acabando.

Una vez migrado a zarafa, la armonía entre mi samsung Galaxy con 2.2.1 era perfecta, pero, por aquellas cosas de probar, lo actualicé a la versión 2.3.4…. aquí empezaron otra vez los problemas…. el correo no se sincronizaba de manera automática en el modo “difusión” y las citas del calendario tampoco iban finas….. si creaba la tarea en el teléfono, ésta aparecía en el calendario, pero si las creaba directamente en el webaccess, estas no se replicaban en el teléfono; lo mismo con las modificaciones…. así que tocó volver al android 2.2.1.

Salvado esto, para instalar el z-push, hemos de seguir los siguientes pasos:

1º) Descargamos z-push, por ejemplo en /usr/src

root@zeus:/usr/src# wget -c http://download.berlios.de/z-push/z-push-1.5.5-790.tar.gz

Y lo extraemos en el directorio raiz del servidor apache

tar -xzvf z-push-.tar.gz -C /var/www

Nos vamos al fichero /var/www/z-push–versionquesea/config.php y ponemos nuestra zona horaria:

// Defines the default time zone
if (function_exists(“date_default_timezone_set”)){
date_default_timezone_set(“Europe/Madrid”);
}

Una vez realizado, hemos de hacer un Alias, ya que el active-sync va a buscar la carpeta Microsoft-Server-ActiveSync. Como ya tenía los teléfonos con Active-sync SSL, me gustaba la idea de cifrar en SSL la sincronización de los teléfonos, así que editamos (en mi caso), nano /etc/apache2/sites-available/zarafa-webaccess y lo dejamos de la siguiente manera:

Alias /webaccess /usr/share/zarafa-webaccess
Alias /owa /usr/share/zarafa-webaccess
Alias /Microsoft-Server-ActiveSync /var/www/z-push–version/index.php

De esta manera, puedo acceder a mi webAccess:

a) https://nombredelservidor/webaccess
b) https://nombredelservidor/owa (like Exchange)

y nos funciona el active-sync con SSL 🙂

Ahora damos permisos a la carpeta state, que sirve para mantener los datos de sincronización y el estado de las mismas.

chmod 777 /var/www/z-push–version/state

Y ahora a eliminar (en mi caso) la cuenta en el teléfono y volverla a crear/sincronizar.

Con ésto, tenemos remplazado el Exchange sin perder (casi) funcionalidades.

Migrando Exchange 2010 a Zarafa, parte 7

Ahora toca añadir SSL al webaccess.

Primero, vamos al servidor y añadimos los siguientes directorios con los permisos:


# mkdir /etc/apache2/certs
# chmod 700 /etc/apache2/certs
# cd /etc/apache2/certs

Generamos el certificado:


openssl req -nodes -newkey rsa:2048 -keyout zarafa-ssl.key -out zarafa-ssl.csr

Y respondemos a las preguntas….

Vemos si se ha generado el certificado…

cat /etc/apache2/certs/zarafa-ssl.key

Firmamos el certificado:


openssl x509 -req -in zarafa-ssl.csr -signkey zarafa-ssl.key -out zarafa-ssl.crt -days 9999

root@zeus#a2enmod ssl

Habilitamos el SSL en el webaccess de zarafa:


root@zeus#nano /etc/apache2/sites-available/zarafa-webaccess

Y añadimos al final del fichero..


SSLEngine On
SSLCertificateFile /etc/apache2/certs/zarafa-ssl.crt
SSLCertificateKeyFile /etc/apache2/certs/zarafa-ssl.key

Reiniciamos el apache y listo …


/etc/init.d/apache2 restart

Migrando Exchange 2010 a Zarafa, parte 6

En esta sección, procederemos al apartado de las copias.

Con la versión free, no se incluye la utilidad zarafa-backup, así que tendremos que montar nosotros el sistema de copias.

Como no tengo muchos datos (4 gigas aprox de correo entre todos los buzones), haré un dump de la base de datos.

Creamos en la carpeta /usr/local/copias/ un script en bash, con el siguiente contenido

root@zeus#nano /usr/local/copias/copia.sh

Y añadimos lo siguiente:

echo “————————————————————–”
echo “— Exportamos la bbdd mysql zeus :: zarafa —————–”
echo “————————————————————–”
cd /media/backup_zfc/bbdd
mysqldump -uroot -pPASSWORD –single-transaction –skip-opt –quick zarafa > zarafa.sql
echo “—— Exportacion finalizada ——————————–”
echo “————————————————————–”
echo “—- renombramos los ficheros .sql y los comprimimos ———”
tar -zcvf respaldo_zarafa_$(date +%d%m%y).tgz zarafa.sql
echo “—– Ahora borramos los ficheros de logs de + de 5 dias —–”
find -name ‘*.tgz’ -type f -mtime +5 -exec rm -f {} ;
echo “—- proceso finalizado ————————————–”
echo “——— copiamos ficheros postfix ————————-”
cd /etc/postfix
cp -r * /media/backup_zfc/postfix_zeus
echo “—- proceso finalizado ————————————–”
echo “——- copiamos ficheros zarafa —————————–”
cd /etc/zarafa
cp -r * /media/backup_zfc/zarafa
echo “—- proceso finalizado ————————————–”

Y ahora explicamos:


cd /media/backup_zfc/bbdd
mysqldump -uroot -pPASSWORD –single-transaction –skip-opt –quick zarafa > zarafa.sql

Hacemos un volcado total de la base de datos.


tar -zcvf respaldo_zarafa_$(date +%d%m%y).tgz zarafa.sql

Hacemos un TAR con la fecha de la copia.


find -name ‘*.tgz’ -type f -mtime +5 -exec rm -f {} ;

Eliminamos todos los ficheros de > de 5 días, para no llenar el disco iSCSI con copias.

Ya sé que no es la mejor opción y, si quiero recuperar un buzón en concreto es complicado, pero jugando un poco con los backups, mysql y la utilidad zarafa-migration-tool es posible hacerlo.

Migrando Exchange 2010 a Zarafa, parte 5

Ahora configuraremos de manera correcta postfix, que será el encargado de recoger el correo del antispam y entregarlo al lmtp local.


root@zeus#apt-get remove exim4 exim4-doc
root@zeus#apt-get install postfix postfix-ldap postfix-doc

Ahora configuramos postfix, en /etc/postfix

Editamos el fichero main.cf y lo dejamos tal que:


myhostname = zeus.craem.net
mydomain = craem.net
inet_interfaces = all
mydestination = $hostname, localhost.$mydomain, localhost
mynetworks = 192.168.0.0/16, 127.0.0.0/8
relayhost = 192.168.2.2
zarafa_destination_recipient_limit = 1
virtual_transport = zarafa:
#
virtual_mailbox_domains = craem.net, misdominiosSeparadosPorComas
zarafa_destination_recipient_limit = 1
virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf
virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf
virtual_transport = lmtp:127.0.0.1:2003

# mail size an some generic settings
message_size_limit = 15360000
delay_notice_recipient = craem@craem.net
bounce_notice_recipient = craem@craem.net
2bounce_notice_recipient = craem@craem.net
error_notice_recipient = craem@craem.net

Ahora el fichero ldap-aliases

server_host = 192.168.2.5
search_base = dc=craem,dc=net
version = 3
bind = yes
bind_dn = uid=admin,dc=craem,dc=net
bind_pw = passwordUsuario
scope = sub
query_filter = (zarafaAliases=%s)
result_attribute = mail

Y ahora el fichero ldap-users.cfg


server_host = 192.168.2.5
search_base = dc=craem,dc=net
version = 3
scope = sub
query_filter = (mail=%s)
result_attribute = mail
bind = yes
bind_dn = cn=admin,dc=craem,dc=net
bind_pw = passwordUsuarioLdap

Editamos el fichero master.cf y añadimos al final:


zarafa unix – n n – 10 pipe
flags= user=vmail argv=/usr/bin/zarafa-dagent ${user}

Reiniciamos Postfix, con /etc/init.d/postfix restart.

En principio, tenemos zarafa de la siguiente manera:

– Buzones creados con ldap
– WebAccess funcionando
– El idioma configurado correctamente
– Entrega y recibe correo local y externamente

Nos queda por configurar:

– Webaccess por SSL
– ActiveSync
– Copias de seguridad.