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

Lors de l’utilisation d’un service web tel que Apache, il est intéressant de fournir le service de façon sécurisé même au sein de l’entreprise, ne serais-ce que pour éviter la transmission des mots de passe en clair sur le réseau.

Lors de mes différentes interventions, je vois souvent la mise en place d’un certificat auto-signé  affichant dans le navigateur un message d’avertissement effrayant auprès des utilisateurs. Hors dans la majorité des cas, les postes clients sont des machines Windows intégré à un annuaire Active Directory, grâce à cela il est possible de pousser des certificats par GPO. Mais ce n’est pas le plus élégant; en effet depuis des années Microsoft fourni une PKI intégré directement dans l’Active Directory. Chacun des postes intégré à l’AD dispose dans son magasin de certificat la CA root de l’entreprise.
Et c’est sur cette base que nous allons créer une certificat qui sera reconnu par les navigateurs (enfin la Internet Explorer car le magasin de certificat windows n’est utilisé que par IE).

Le scénario est le suivant :

  • ActiveDirectory 2008 R2 incluant la PKI
  • Un client Windows 2008 R2 intégré au domaine (j’avais que ça sous le coude)
  • Serveur Web apache2 sous CentOS 6.4 et OpenSSL (la version non troué :p )

Cette procédure est effectué sur une CentOS, mais je suis certain que cela fonctionne sur d’autres distributions

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

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

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

centOS# openssl req -new -key /etc/pki/tls/private/apache.domain.tld.key > /etc/pki/tls/private/apache.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) []:apache.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 via la mmc dédié :

Apache-MPKI-01

Apache-MPKI-02

Mais pourquoi cela ne fonctionne pas ?

La solution est simple,la PKI de Microsoft ne sais pas sur quel template SSL il doit s’appuyer pour créer le certificat et comme vous êtes des barbus, vous n’avez pas installé l’interface IIS pour gérer les certificats (sinon il faut copier-coller la demande sur le site web et roule ma poule)

Il ne nous reste plus qu’a sortir la ligne de commande windows et :

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

Apache-MPKI-03

Grâce a cette commande, le système nous proposer de sauvegarder le certificat signé par la PKI. Il faut savoir que je m’appuie sur le template web standard où la validité du certificat est limité à 2 ans…

Il ne reste plus qu’a l’intégrer dans votre serveur apache :

vim /etc/httpd/conf.d/ssl.conf (ou autre fichier pour votre site web)

SSLCertificateFile /etc/pki/tls/private/apache.domain.tld.crt <= notre certificat
SSLCertificateKeyFile /etc/pki/tls/private/apache.domain.tld.key

Enfin pour tester on lance son navigateur web depuis  le client on va sur l’url de notre site web et on oh miracle :

Apache-MPKI-05

Références :

– https://dusk1911.wordpress.com/2012/07/10/issuing-exchange-certificate-from-ca-without-gui-and-getting-denied-by-policy-module-0x80094801/

J’ai eu récemment un souci d’envoi de mail sur redmine.  En effet, après un update de ma plateforme, celui-ci n’envoyait plus de mail lors d’un nouveau commit.Après avoir pas mal cherché il s’avère que la denière gem mail ne fonctionne pas comme attendu par l’application lorsque l’on utilise du SSL pour l’envoi de mail. Il faut donc downgrader celle-ci afin que cela fonctionne correctement :

gem install mail -v 2.5.3

Référence : redmine issue

Je continue l’intégration de mes services à FreeIPA; dans cette optique je vous présente aujourd’hui comment intégrer Zabbix à FreeIPA grâce au module Kerberos d’Apache

Génération de la keytab

A faire sur le serveur FreeIPA

ipa service-add HTTP/zabbix.domain.local

Dans mon cas j’ouvre le service sur l’extérieur, il faut donc que le nom du service externe soit aussi dans la keytab sinon le service Kerberos ne valide pas l’authentification.

ipa service-add HTTP/zabbix.domain.com

une fois les deux services ajoutés, on peut concaténer le tout directement sur le serveur cible (ici Zabbix):

A faire sur le serveur cible

ipa-getkeytab -s freeipa.domain.local -p HTTP/zabbix.domain.local -k /etc/httpd/zabbix.keytab
ipa-getkeytab -s freeipa.domain.local -p HTTP/zabbix.domain.com -k /etc/httpd/zabbix.keytab

On liste le contenu de la keytab pour vérifier :

klist -e -k /etc/httpd/zabbix.keytab

FILE:/etc/httpd/zabbix.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 HTTP/zabbix.domain.local@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
   1 HTTP/zabbix.domain.local@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
   1 HTTP/zabbix.domain.local@DOMAIN.LOCAL (des3-cbc-sha1)
   1 HTTP/zabbix.domain.local@DOMAIN.LOCAL (arcfour-hmac)
   1 HTTP/zabbix.domain.com@DOMAIN.LOCAL (aes256-cts-hmac-sha1-96)
   1 HTTP/zabbix.domain.com@DOMAIN.LOCAL (aes128-cts-hmac-sha1-96)
   1 HTTP/zabbix.domain.com@DOMAIN.LOCAL (des3-cbc-sha1)
   1 HTTP/zabbix.domain.com@DOMAIN.LOCAL (arcfour-hmac)

Ajout de l’utilisateur dans Zabbix et modification de l’authentification

Afin de ne pas se retrouver sans pouvoir accéder a notre plateforme après la modification de l’authentification, il faut créer les utilisateurs sur la plateforme. Faite ça de façon classique en passant par l’interface de Zabbix. Il faut savoir que par défaut l’authentification va prendre en compte l’uid du compte , il faut donc que les uid corresponde.

Une fois l’ajout effectué on peut changer l’authentification en HTTP

Ne vous déloguez pas, ainsi vous gardez le ticket de session le temps de valider que votre infrastructure est fonctionnel.

Modification d’Apache

On va s’appuyer sur un module qui s’appel : auth_kerb. Pour l’installer sur CentOS il suffi de simplement faire :

yum install mod_auth_kerb.x86_64

Il ne reste plus qu’à modifier apache pour prendre en compte la nouvelle méthode authentification

On modifie le virtualhost de Zabbix pour intégrer les lignes en gras :

<VirtualHost *:80>
...
<Directory /usr/share/zabbix/>

                      AuthType Kerberos
                      AuthName "Kerberos Login"
                      KrbMethodNegotiate on
                      KrbMethodK5Passwd on
                      KrbServiceName HTTP
                      KrbAuthRealms DOMAIN.LOCAL
                      Krb5KeyTab /etc/httpd/zabbix.keytab
                      KrbSaveCredentials on
                      KrbConstrainedDelegation on
                      Require valid-user

</Directory>

...

</VirtualHost>

puis on redémarre apache

service httpd restart

A ce stade vous en mesure de vous authentifier sur Zabbix via Kerberos

Si maintenant vous voulez filtrer par groupe d’utilisateurs, le module Kerberos n’est pas en mesure de le faire en l’état, il faut passer par le module LDAP de apache qui va vérifier l’appartenance du compte au groupe avant de valider l’accès.

Je ne l’ai pas encore fait, mais cela ne serai tarder, j’updaterai ce billet en fonction.

Monitoring Web

Dans Zabbix il est possible d’effectuer des checks de services web. Mais une problématique se pose quand ceux-ci se situe derrière un proxy. En effet, dans les versions antérieurs à la 2.2 il n’est pas possible de configurer dans l’interface web le serveur proxy.

Il faut donc passer par le système d’exploitation pour effectuer l’opération. La documentation de Zabbix est clair sur le comment, mais après moult essais, je n’ai pas réussi à le faire fonctionner correctement. Je livre donc ici une méthodologie qui m’est fonctionnel.

Configuration du système

Pour faire les choses propres, on va créer un fichier de configuration qui exportera les variables systèmes et qui sera lu au lancement du serveur.

On créer donc le fichier de configuration suivant : /etc/sysconfig/zabbix (Red Hat like) en y mettant le contenu suivant :

export http_proxy=http://PROXY_USER:PROXY_USER_PASSWORD@PROXY_IP:PROXY_PORT
export https_proxy=$http_proxy
export ftp_proxy=$http_proxy
#Upper Case
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$http_proxy
export FTP_PROXY=$http_proxy
# Exclusions Proxy
export no_proxy="127.0.0.1,HOST_TO_Exclude,DOMAIN_TO_Exclude"
export NO_PROXY=$no_proxy

puis on modifie le script de lancement du serveur afin d’y ajouter notre fichier de configuration. Celui-ci sera lu au lancement par l’utilisateur système zabbix (ici zabbixsrv), ce qui permettra aux checks de pouvoir sortir via le proxy.

Modifiez le fichier /etc/init.d/zabbix-server afin d’y ajouter ces deux lignes :

...
# Source function library.
 . /etc/rc.d/init.d/functions
# Source sysconfig
 . /etc/sysconfig/zabbix
exec=zabbix_server
 prog=${exec##*/}
 ...

Puis redémarrer le serveur Zabbix :

/etc/init.d/zabbix-server restart

Si vous avez bien suivi, le fichier est lu au démarrage de Zabbix, cela veux dire que si vous voulez ajouter des exclusions, il faut redémarrer le serveur Zabbix.

Vivement mon passage en 2.2 🙂

Merci a l’utilisateur BDiE8VNy qui a donné la solution sur le forum Zabbix

Il m’est arrivé de ne plus me souvenir du mot de passe admin d’une plateforme Zabbix de préproduction que j’avais mis en place quelques temps auparavant. Après avoir cherché un peu je suis tombé sur la solution et la marque ici afin d’avoir un pense bête en cas de nouvel oublis.
Il faut bien évidement avoir accès root à la machine puis :

mysql -u root -p
use zabbix;
update zabbix.users set passwd=md5('MYNEWPASSWORD') where alias='Admin';

Avec ça reset le mot de passe admin (ou autre utilisateur), par contre ce que j’avais oublié c’est que j’avais connecté ce Zabbix sur un LDAP, du coup même le reset du mot de passe ne m’a servi à rien.

La solution consiste à changer la méthode d’authentification le temps de tout reconfigurer correctement :

mysql -u root -p
select zabbix;
update zabbix.config set authentication_type=0 where authentication_type=1;

Puis, pour que cela ne se reproduise plus j’ai créé un nouveau groupe qui ne s’authentifiera qu’en interne :

et le tour est joué !