Je fait suite à mon précédent article sur l’intégration d’un certificat signé par la PKI Micorsoft au sein du serveur Apache.

On va ici effectuer une demande pour le webmail de Zimbra.

le scénario est le suivant :

  • ActiveDirectory 2008 R2 incluant la PKI
  • Un client Windows 2008 R2 intégré au domaine
  • Zimbra v8.0.7 sous CentOS 6.4 avec le paquet zimbra-proxy installé

Tout comme la demande pour Apache, il faut que le paquet OpenSSL soit installé.

On commence par créer la clef privé du serveur :

zimbra# openssl genrsa 2048 > /etc/pki/tls/private/zimbra.domain.tld.key

Puis on génère la requête :

zimbra# openssl req -new -key /etc/pki/tls/private/zimbra.domain.tld.key > /etc/pki/tls/private/zimbra.domain.tld.req
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -----
 Country Name (2 letter code) [XX]:FR
 State or Province Name (full name) []:IDF
 Locality Name (eg, city) [Default City]:Paris
 Organization Name (eg, company) [Default Company Ltd]:Les Titans
 Organizational Unit Name (eg, section) []:
 Common Name (eg, your name or your server's hostname) []:zimbra.domain.tld
 Email Address []:admin@domain.tld
Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:

Une fois le fichier de requête transféré au serveur Windows, on va demander à la CA de créer un certificat :

windows# certreq -submit -attrib "CertificateTemplate:WebServer" zimbra.domain.tld.req

Zimbra-MPKI-01

a la différence de apache, il est obligatoire de concaténer le root CA avec le certificat du service. Il faut donc récupérer le certificat public de notre ADSC :

windows# certutil -ca.cert c:\users\administrator\Desktop\ca_root.crt

Zimbra-MPKI-02

une fois les deux certificats sur le serveur Zimbra, concaténez les deux via la commande suivante :

cat /etc/pki/tls/certs/zimbra.lab.rezo.local.crt /etc/pki/tls/certs/ca_root.crt > /etc/pki/tls/certs/complete_zimbra.lab.rezo.local.crt

Enfin aller dans l’interface web d’administration de Zimbra et copier-coller le contenu du certificat dans l’onglet configuration -> domaine -> domain.tld > Certificats (colone de gauche) et dans la colonne de droite la clef privé du serveur que nous avons créé auparavant et cliquer sur sauvegarder.

Zimbra-MPKI-03

Comme l’indique le popup, il faut effectuer une commande sur le serveur lui même afin de déployer ce nouveau certificat. Pour cela

mkdir /opt/zimbra/conf/domaincerts <- petit bug de Zimbra qui ne créer pas le repertoire si celui-ci n'existe pas
 chown zimbra:zimbra /opt/zimbra/conf/domaincerts
 /opt/zimbra/libexec/zmdomaincertmgr deploycrts
 su - zimbra
 zmnginxctl restart

enfin connectez-vous sur l’interface web depuis le client :

Zimbra-MPKI-04

et voila un beau webmail reconnu par votre navigateur

Dans la version 8.0 de Zimbra il est maintenant possible de déléguer l’authentification à un serveur Kerberos. Quand on pense Kerberos, on pense assez rapidement à l’Active Directory, mais dans mon cas, je ne gère que des machines sous Linux et n’ai nul besoin d’un produit de chez Microsoft dans mon infrastructure. Comme solution alternative couvrant mes besoins, je me suis penché sur l’identity manager de chez Red Hat en sa version OpenSource : FreeIPA. Je ne détaillerai pas comment installer FreeIPA, mais je pense écrire des articles sur le produit au fur et à mesure de mon apprentissage sur le sujet en commençant par celui-ci :

Configuration de Zimbra avec FreeIPA

Ajout de la machine dans le domaine

Dans un premier temps il faut que la machine fasse parti du domain Kerberos. Pour cela, enregistrer la avec la commande suivante :

ipa-client-install --enable-dns-updates --domain=DOMAIN.TLD --server=FREEIPA.DOMAIN.TLD

Une fois passé le wizard vérifiez que vous pouvez acquérir un ticket kerberos via la commande suivante :

kinit admin

puis vérifiez la validité du ticket :

klist 
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@DOMAIN.TLD

Valid starting     Expires            Service principal
01/23/14 19:44:12  01/24/14 19:44:10  krbtgt/DOMAIN.TLD@DOMAIN.TLD

Maintenant que la machine est dans le domaine Kerberos, on passe a la suite.
Si vous n’arrivez pas jusqu’à cette étape, je vous recommande de lire la documentation de FreeIPA

Modification du système et configuration de Zimbra

Tout d’abord il faut vérifier que dans la configuration de votre système Kerberos va effectuer un reverse lookup DNS sur le KDC pour cela vérifier que l’option dns_lookup_kdc est bien à true dans le fichier krb5.conf

Une fois cela fait, mettez vous en tant qu’utilisateur Zimbra et effectuez les commandes suivantes :

zmprov md les-titans.com  zimbraAuthMech kerberos5 <= Modification de la méthode d'authentification
zmprov md les-titans.com zimbraAuthKerberos5Realm DOMAIN.TLD <= On  spécifie ici le domaine Kerberos, celui-ci sera ajouté au nom d'utilisateur. La case est très importante, il faut qu'elle soit en majuscule.

Une fois cela fait, il faut redémarrer Zimbra afin qu’il prenne en compte le fichier de configuration krb5.conf si celui-ci a été modifié.

zmcontrol restart

Votre serveur Zimbra est maintenant connecté à FreeIPA.

Si votre compte zimbra est different de votre compte Kerberos, l’authentification ne retrouvera pas l’utilisateur du coté de FreeIPA.
Il faut specifier alors a Zimbra le Princpipal a chercher dans le FreeIPA.
Pour cela, il faut commencer modifier la valeur de l’attribut utilisateur :

zmprov ma my_account@domain.tld zimbraForeignPrincipal kerberos5:account@DOMAIN.TLD

en precisant bien kerberos en debut de ligne.

Enjoy !

Un des problèmes que l’on rencontre souvent lors de l’installation de Zimbra sur un hôte, c’est qu’il ne faut pas installer le MTA de l’OS. En effet Zimbra en livre un par défaut (postfix). Du coup les mails systèmes ne sont pas transmis car ils n’utilisent aucun client. Pour que cela fonctionne, il suffi simplement de configurer le système d’exploitation pour qu’il utilise le postfix de Zimbra :

Dans un premier temps, on ajoute le postfix de Zimbra danes les alternatives pour le service « mta »

/usr/sbin/alternatives --install /usr/sbin/sendmail mta /opt/zimbra/postfix/sbin/sendmail 25 \
--slave /usr/bin/mailq mta-mailq /opt/zimbra/postfix/sbin/mailq \
--slave /usr/bin/newaliases mta-newaliases /opt/zimbra/postfix/sbin/newaliases \
--slave /usr/share/man/man1/mailq.1.gz mta-mailqman /opt/zimbra/postfix/man/man1/mailq.1 \
--slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman /opt/zimbra/postfix/man/man1/newaliases.1 \
--slave /usr/share/man/man8/sendmail.8.gz mta-sendmailman /opt/zimbra/postfix/man/man1/sendmail.1 \
--slave /usr/share/man/man5/aliases.5.gz mta-aliasesman /opt/zimbra/postfix/share/man/man5/aliases.5 \
--initscript zimbra

Puis on configure le système pour qu’il l’utilise en choisissant notre option (ici la 2) :

/usr/sbin/alternatives --config mta
There are 2 programs which provide 'mta'.
Selection Command
-----------------------------------------------
*+ 1 /usr/sbin/sendmail.postfix
2 /opt/zimbra/postfix/sbin/sendmail

Et si l’on souhaite vérifier :

update-alternatives --display mta
mta - status is manual.
link currently points to /opt/zimbra/postfix/sbin/sendmail
/usr/sbin/sendmail.postfix - priority 30
slave mta-pam: /etc/pam.d/smtp.postfix
slave mta-mailq: /usr/bin/mailq.postfix
slave mta-newaliases: /usr/bin/newaliases.postfix
slave mta-rmail: /usr/bin/rmail.postfix
slave mta-sendmail: /usr/lib/sendmail.postfix
slave mta-mailqman: /usr/share/man/man1/mailq.postfix.1.gz
slave mta-newaliasesman: /usr/share/man/man1/newaliases.postfix.1.gz
slave mta-aliasesman: /usr/share/man/man5/aliases.postfix.5.gz
slave mta-sendmailman: /usr/share/man/man1/sendmail.postfix.1.gz
/opt/zimbra/postfix/sbin/sendmail - priority 25
slave mta-pam: (null)
slave mta-mailq: /opt/zimbra/postfix/sbin/mailq
slave mta-newaliases: /opt/zimbra/postfix/sbin/newaliases
slave mta-rmail: (null)
slave mta-sendmail: (null)
slave mta-mailqman: /opt/zimbra/postfix/man/man1/mailq.1
slave mta-newaliasesman: /opt/zimbra/postfix/man/man1/newaliases.1
slave mta-aliasesman: /opt/zimbra/postfix/share/man/man5/aliases.5
slave mta-sendmailman: /opt/zimbra/postfix/man/man1/sendmail.1
Current `best' version is /usr/sbin/sendmail.postfix.

Si comme moi vous utilisez un reverse proxy pour desservir plusieurs sites web, vous devez avoir connu le problèmes du relayage des adresses IP du proxy dans les logs des serveurs web (aka backends).

J’en ai parlé dans cet article ici

Maintenant j’ai le même souci avec Zimbra. En effet Zimbra utilise un mécanisme de reverse proxy basé sur du NGINX et Memcached; la configuration de celui-ci inclus de nombreuses variables basée sur des attributs LDAP. Lorsque utilise les briques natives de Zimbra, dans les fichiers de logs des Mailbox on retrouve bien le « oip » (Originating IP); mais lorsqu’on utilise un proxy maison, celui-ci n’est évidement pas pris en compte. On peux voir ça dans les logs du serveur Zimbra (mailbox.log) :

2013-10-02 00:01:39,190 INFO  [btpool0-12://mail.domain.tld/service/soap] [name=wolfy@les-titans.com;mid=8;ip=reverse_proxy_IP;] soap - EndSessionRequest

Pour modifier cela il faut renseigner notre reverse proxy dans la configuration de Zimbra. Pour cela passer en tant qu’utilisateur Zimbra puis effectuez les commandes suivantes :

[zimbra@zimbra ~]$ zmprov ms `zmhostname` +zimbraMailTrustedIP reverse_proxy_IP
[zimbra@zimbra ~]$ zmprov ms `zmhostname` +zimbraMailTrustedIP reverse_proxy_IP_n°2

Pensez bien a mettre le « + » devant l’attribut sinon cela écrasera les autres occurrences.

Une fois l’opération effectué, redémarrez Zimbra et vous verrez ce changement dans les logs :

2013-10-03 13:43:06,994 INFO  [btpool0-13://mail.domain.tld/service/soap/SearchRequest] [name=wolfy@les-titans.com;mid=8;ip=reverse_proxy_IP;oip=Client_IP;ua=ZimbraWebClient - FF3.0 (Win)/7.2.5_GA_2906;] soap - SearchRequest elapsed=5

Pour la majorité des migrations de messagerie sur lesquels je suis intervenu, j’utilise pour la migration de messagerie un outil libre : ImapSync. Je l’utilise maintenant depuis un certains nombres d’années et je dois dire qu’il ne finit pas de me surprendre. Voici quelques fonctionnalités :
– Migration Imap à Imap,
– Migration d’une adresse de messagerie vers une autres,
– Modification des Headers,
– Pré-synchronisation,
– etc…
et en plus c’est développé par un français 🙂

Installation ImapSync depuis le repository GIT :

Tout d’abord on installe les repository EPEL pour plus de confort :
rpm -Uvh http://mirror.ibcp.fr/pub/epel/6/i386/epel-release-6-8.noarch.rpm

Puis on installe IMAPSync :
yum -y update (ça mange pas de pain)
yum install git perl-Mail-IMAPClient.noarch perl-Digest-HMAC.noarch perl-TermReadKey.x86_64 perl-NTLM.noarch perl-Net-SSLeay.x86_64 perl-IO-Socket-SSL.noarch perl-File-Copy-Recursive.noarch perl-Time-HiRes.x86_64 perl-Test-Simple
git clone https://github.com/imapsync/imapsync
cd imapsync
make install
imapsync -v
1.547

Pour plus d’info sur ImapSync : http://imapsync.lamiral.info/

Exemples de commandes : http://imapsync.lamiral.info/FAQ

Pourquoi ?

Effectivement, pourquoi installer un proxy IMAP/POP plutot que de laisser le serveur de messagerie faire son travail. Plusieurs points (ceci peut être purement subjectif) :

  • Assurer une zone d’étanchéité entre les utilisateurs provenant de l’externe et le serveur de messagerie IMAP situé en interne
  • Faire de la répartition de charge sur X backend
  • Assurer une migration sur différent service
  • etc.

Mon besoin personnel est la création d’une zone DMZ dans mon infrastructure, je ne voulais donc pas que les utilisateurs parviennent directement sur mon serveur de messagerie. Mais je me sert aussi de cette solution pour assurer des migrations de messagerie.

Je suis parti sur une installation sur Centos, mais le principe reste le même sur Debian-like.

Installation sur Centos-6

Tout d’abord on créer un fichier de configuration de yum, ainsi nous pourrons installer le proxy plus simplement que par la compilation. Le repository le plus a jour que j’ai trouvé est celui d’OpenSuse, les paquets datant du 30 Septembre 2012.

vim /etc/yum.repos.d/perdition.repo
[perdition]
 name=perdition repo
 baseurl=http://download.opensuse.org/repositories/home:/horms:/perdition/CentOS_CentOS-6/
 gpgcheck=0
 enabled=1

Puis on installe l’application :

yum install perdition

si vous souhaitez utiliser le backend LDAP (ou autre) il suffit d’installer la librairie correspondante. Dans mon cas je vais faire des interrogations LDAP afin de dire a Perdition sur quel backend aller se connecter.

yum install libperditiondb_ldap0.x86_64

Fichiers de configuration de Perdition

Explications des fichiers de configuration se trouve dans /etc/perdition/

Makefile  Makefile.popmap  perdition.conf  popmap  popmap.re

Le fichier popmap est un fichier a plat qui pourrai s’apparenter au aliases de Postfix avec une syntaxe de type user:destination

Il en va de même pour le fichier popmap.re qui lui prend en charge les expressions régulières.

Le fichier Makefile est un lien symbolique vers Makefile.popmap

Le fichier Makefile.popmap sert a générer le fichier db a partir du fichier popmap pour cela il suffit de faire la commande make all. Celle-ci va générer le fichier popmap.gdbm.db qui sera a intégrer dans la configuration de perdition. Pour plus d’informations je vous recommande le site de perdition ici

Enfin le fichier perdition.conf pour toute la configuration du logiciel. C’est ce que je vais détailler ci dessous. Cette configuration fonctionne en mode LDAP et n’utilisera pas le fichier map.

Configuration de perdition

Tout d’abord on va activer/desactiver les services qui ne nous interesse pas. Pour mon compte, je ne vais juste activer que l’IMAPS. Pour cela, il faut éditer le fichier /etc/sysconfig/perdition et modifier les occurrence pour correspondre a notre besoin :

RUN_PERDITION=yes
 POP3=no
 POP3_FLAGS=
 POP3S=no
 POP3S_FLAGS=
 IMAP4=no
 IMAP4_FLAGS=
 IMAP4S=yes
 IMAP4S_FLAGS=
 MANAGESIEVE=no
 MANAGESIEVE_FLAGS=

ET maintenant on va éditer le fichier perdition.conf afin de correspondre a notre besoin.

On commence par une copie de sauvegarde

cp /etc/perdition/perdition.conf  /etc/perdition/perdition.conf.bak

puis on édite le fichier. Voici la configuration que j’ai mis en place pour mon système

 no_bind_banner
 bind_address 192.x.x.x
 imap_capability IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN SASL-IR COMPRESS=DEFLATE
 no_lookup
 server_resp_line
 ssl_cert_file /path/to/certificate.cert
 ssl_cert_verify_depth 9
 ssl_key_file /path/to/certificate.key
 ssl_no_cert_verify
 ssl_no_cn_verify
 M /usr/lib64/libperditiondb_ldap.so.0
 m "3:ldap://zimbra-ldap.domain.tld/?zimbraMailDeliveryAddress,zimbraMailHost?sub?(&(objectClass=zimbraAccount)(zimbraMailDeliveryAddress=%25s))?!BINDNAME=uid=zmpostfix%2ccn=appaccts%2ccn=zimbra,X-BINDPW=mypassword"

Explications des options :

no_bind_banner : On résoud l’adresse stipulé dans l’option « bind_address »
bind_address : adresse d’écoute du service
imap_capability : Capacité IMAP présenté aux clients se connectant à Perdition
no_lookup : On ne fait pas de lookup sur le serveur
server_resp_line : plutôt que de générer un message de bienvenue lors de la connexion, on affiche le message du backend
ssl_cert_file : chemin vers le certificat
ssl_cert_verify_depth : Profondeur de vérification du certificat
ssl_key_file : chemin vers la clef du certificat
ssl_no_cert_verify : On ne vérifie pas la cryptographie inclus dans le certificat du backend
ssl_no_cn_verify : On ne vérifie pas le nom inclus dans le CN du certificat du backend
M : libairie utilisé pour rechercher le backend
m : recherche LDAP utilisé avec les options ci-dessous :

  • 3 : version de protocole a utiliser
  • ldap://zimbra-ldap.domain.tld : adresse du serveur LDAP
  • zimbraMailDeliveryAddress,zimbraMailHost : attribut de retour
  • sub : scope de la recherche LDAP
  • (&(objectClass=zimbraAccount)(zimbraMailDeliveryAddress=%25s)) : la recherche envoyé au serveur LDAP
  • !BINDNAME=uid=zmpostfix%2ccn=appaccts%2ccn=zimbra,X-BINDPW=mypassword : pour le LDAP de Zimbra il faut se binder

Une fois le fichier enregistré, on place le service au démarrage du système puis on le démarre :

chkconfig perdition on
service perdition start

Test

Faisons un test avec l’utilitaire fournit par Openssl

openssl s_client -connect 127.0.0.1:993
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=PLAIN SASL-IR COMPRESS=DEFLATE] perdition ready on imap.domain.tld 0002eec5
A login login@domain.tld password
A OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+ LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN completed

Et voila un proxy IMAP/POP qui ronronne !