JESUISUNGEEK.COM - Mot-clé - icinga2022-10-15T08:24:27+02:00urn:md5:80fcbbbeeb78d335e0ba1eaeec99fb37DotclearConnexion en LDAPS avec Icingaurn:md5:09ce0dac9aabf317caf6b181d701f1342016-05-24T12:30:00+02:002016-05-24T12:56:26+02:00Jean-Baptiste LangloisBidouillesicingaldaplinux<p>Authentification sur Icinga via un serveur LDAP nécessitant un certificat</p> <p><img src="http://www.jesuisungeek.com/public/pictures/real/.icinga-ssl_s.png" alt="Icinga avec LDAPS" style="float:left; margin: 0 1em 1em 0;" title="Icinga avec LDAPS, mai 2016" /> Ce problème m'a été posé au bureau, et comme je n'ai pas trouvé de page traitant de ce problème, j'en détaille la configuration.<br />
Le serveur LDAPS utilisé dans ma société est permissif et autorise les connexions sans certificats. Il est être remplacer par un serveur forçant la connexion via un certificat en SHA-256. Quant à moi, je suis chargé de m'occuper de la migration correcte pour le serveur <a href="https://www.icinga.org/" hreflang="fr">Icinga</a>. La plupart des applicatifs dans ma société étant basé sur Java, plus qu'un certificat, il s'agit d'un TrustKeyStore (JKS) qui est fourni pour réaliser la migration.<br />
Dans Icinga, l'authentification LDAP s'effectue à travers Icinga-Web. A savoir dans les fichiers suivants (dans le cas d'une installation par défaut) :</p>
<ul>
<li><strong>/usr/share/icinga-web/app/modules/AppKit/config/auth.xml</strong></li>
<li><strong>/etc/icinga-web/conf.d/auth.xml</strong></li>
</ul>
<p>On y trouve la partie suivante :</p>
<pre class="brush: xml">
<setting name="provider">
<ae:parameter name="openldap-ldap1">
<ae:parameter name="auth_module">AppKit</ae:parameter>
<ae:parameter name="auth_provider">Auth.Provider.LDAP</ae:parameter>
<ae:parameter name="auth_enable">true</ae:parameter>
<ae:parameter name="auth_authoritative">true</ae:parameter>
<ae:parameter name="auth_create">true</ae:parameter>
<ae:parameter name="auth_update">true</ae:parameter>
<ae:parameter name="auth_map">
<ae:parameter name="user_firstname">givenName</ae:parameter>
<ae:parameter name="user_lastname">sn</ae:parameter>
<ae:parameter name="user_email">email</ae:parameter>
</ae:parameter>
<ae:parameter name="ldap_allow_anonymous">false</ae:parameter>
<ae:parameter name="ldap_dsn">ldaps://serveur1:636</ae:parameter>
<ae:parameter name="ldap_start_tls">false</ae:parameter>
<ae:parameter name="ldap_basedn">ou=people,dc=societe</ae:parameter>
<ae:parameter name="ldap_binddn">uid=userdn,ou=Applis,dc=societe</ae:parameter>
<ae:parameter name="ldap_bindpw"><![CDATA[mot_de_passe_userdn]]></ae:parameter>
<ae:parameter name="ldap_filter_user"><![CDATA[(&(uid=__USERNAME__))]]></ae:parameter>
</ae:parameter>
</setting>
</pre>
<p>Le paramètre <code>ldap_start_tls</code> semble attirant mais malheureusement ne correspond pas à mon cas où le serveur s'attend à trouver un certificat client sur la machine interrogeant l'annuaire.<br />
En fait, après plusieurs recherches, j'ai réalisé que Icinga-Web délègue l'intégralité du processus de connexion LDAP à PHP, en se basant sur les fonctions <a href="http://php.net/manual/fr/function.ldap-connect.php" hreflang="en">ldap_connect()</a> et <a href="http://php.net/manual/fr/function.ldap-search.php" hreflang="en">ldap_search()</a>, elles-mêmes s'appuyant sur la configuration locale.<br /></p>
<h3>Récupération du certificat</h3>
<p>Comme indiqué, je pars d'un <a href="https://en.wikipedia.org/wiki/Keystore" hreflang="en">Keystore</a> duquel je dois extraire le certificat nécessaire. Tout d'abord, je récupère l'alias du certificat que je compte extraire :</p>
<pre>
[root@icinga]# keytool -list -keystore mon_keystore.jks -storepass mot_de_passe_keystore
</pre>
<p>Ensuite, j'extrais le certificat (au format PEM) du Keystore (j'ai choisi le répertoire par défaut pour y stocker le certificat) :</p>
<pre>
[root@icinga]# keytool -exportcert -keystore mon_keystore.jks -storepass mot_de_passe_keystore -rfc -alias alias_du_certificat > /etc/openldap/cacerts/alias_du_certificat.pem
[root@icinga]# chmod 644 /etc/openldap/cacerts/alias_du_certificat.pem
</pre>
<p>Et je vérifie si l'algorithme de ce certificat est bien, comme demandé du SHA-256.</p>
<pre>
[root@icinga]# openssl x509 -text -noout -in /etc/openldap/cacerts/alias_du_certificat.pem | grep Algorithm
Signature Algorithm: sha256WithRSAEncryption
Public Key Algorithm: rsaEncryption
Signature Algorithm: sha256WithRSAEncryption
</pre>
<h3>Configuration du client LDAP</h3>
<p>Comme je l'ai dit plus haut, Icinga-Web se base, à travers PHP, sur la configuration locale, à savoir, <ins>l'environnement de l'utilisateur exécutant Apache</ins> (généralement <strong>www</strong>) :</p>
<pre>
[www@icinga]$ cat > ~/.ldaprc << EOF
TLS_REQCERT never
TLS_CACERT /etc/openldap/cacerts/alias_du_certificat.pem
EOF
</pre>
<p>On peut alors tester le bon fonctionnement de cette configuration :</p>
<pre>
[www@icinga]$ ldapsearch -H ldaps://serveur2:636 -d 1 2>&1 | grep TLS
TLS: loaded CA certificate file /etc/openldap/cacerts/alias_du_certificat.pem.
TLS: certificate [CN=server2,OU=0002,O=SOCIETE,C=TEST] is valid
...
</pre>
<p>Si le résultat est concluant, ne pas oublier de <ins>redémarrer Apache</ins>.</p>
<h3>Reconfiguration de Icinga-Web</h3>
<p>Finalement, je modifie le fichier auth.xml de Icinga-Web, et je vide le cache.</p>
<pre>
[icinga@icinga]$ sed -i.bak 's/serveur1/serveur2/1' /etc/icinga-web/conf.d/auth.xml
[icinga@icinga]$ /usr/share/icinga-web/bin/clearcache.sh
Cachedir: /usr/share/icinga-web/cache
Deleting cache from config (69 files) ... ok
Deleting cache from Squished (4 files) ... ok
</pre>
<p>Si aucune erreur n'a été faite, on devrait pouvoir se connecter avec ses <em>credentials</em> LDAP sur l'interface graphique de Icinga-Web <img src="/dotclear/themes/chestnut/smilies/wink.gif" alt=";-)" class="smiley" /></p>http://www.jesuisungeek.com/index.php?post/2016/05/24/Connexion-en-LDAPS-avec-Icinga#comment-formhttp://www.jesuisungeek.com/index.php?feed/atom/comments/250Remonter les checks Icinga grâce à Rubyurn:md5:4c15f6d766824a599be4ed6a9d0930442016-02-15T11:51:00+01:002016-02-15T14:21:17+01:00Jean-Baptiste LangloisBidouillesdashingicingaruby<p><img src="http://www.jesuisungeek.com/public/pictures/divers/icinga-api-2.PNG" alt="icinga-api-2.PNG" style="display:block; margin:0 auto;" title="icinga-api-2.PNG, fév. 2016" />Classe Ruby permettant de remonter des informations grâce à l'interface REST de Icinga-Web</p> <p><img src="http://www.jesuisungeek.com/public/pictures/divers/icinga-icon.png" alt="Logo Icinga" style="float:left; margin: 0 1em 1em 0;" title="Logo Icinga, fév. 2016" />Actuellement en plein développement de modules pour <a href="http://dashing.io/" hreflang="en" title="Dashing">Dashing</a>,on m'a demandé de créer un <em>widget</em> remontant le nombre de checks réalisés en recette et passant en orange ou rouge en fonction des erreurs pouvant être remontés par <a href="https://www.icinga.org/icinga/icinga-2/" hreflang="en" title="Icinga2">Icinga2</a>. Plus que créer un <em>widget</em>, le problème qui se pose à moi est la remonté d'informations à partir d'<a href="https://www.icinga.org/icinga/icinga-2/" hreflang="en" title="Icinga2">Icinga2</a>. Certes, il existe une API REST qui gère cela mais la versin d'<a href="https://www.icinga.org/icinga/icinga-2/" hreflang="en" title="Icinga2">Icinga2</a> dont je dispose est trop ancienne pour en bénéficier. Plutôt que de partir sur une mise à jour du système (On est en RedHat 5 <img src="/dotclear/themes/chestnut/smilies/hmm.gif" alt=":-/" class="smiley" /> ), j'ai préféré tabler sur l'existant et utiliser l'API disponible avec <a href="https://www.icinga.org/icinga/screenshots/icinga-web/" hreflang="en" title="Icinga-Web">Icinga-Web</a>.<br />
Néanmoins, même si l'usage de cette API est (moins ou plus) documenté, rien n'existe pour la récupération des données à partir de <a href="http://dashing.io/" hreflang="en" title="Dashing">Dashing</a>, <a href="http://rubyonrails.org/" hreflang="en" title="Ruby on Rails">Rails</a> ou tout autre application issue de Ruby (à l'opposé une fois encore, de l'API de <a href="https://www.icinga.org/icinga/icinga-2/" hreflang="en" title="Icinga2">Icinga2</a> <img src="/dotclear/themes/chestnut/smilies/sad.gif" alt=":-(" class="smiley" /> ). Du coup, j'ai décidé de développer moi-même ce type d'interface via une classe Ruby : <strong>IcingaWebParser.rb</strong> <img src="/dotclear/themes/chestnut/smilies/biggrin.gif" alt=":-D" class="smiley" />
<div class="dcnote noteclassic">
<p>L'usage de cette classe ne se limite bien sûr pas à <a href="http://dashing.io/" hreflang="en" title="Dashing">Dashing</a> et peut être utilisé dans n'importe quel programme Ruby. On peut, par exemple, imaginer un script calculant un pourcentage de disponibilité hebdomadaire en fonction de l'état renvoyé par Icinga.</p>
</div>
</p>
<h3>INSTALLATION</h3>
<p>Tout d'abord, il faut créer une clé d'authentification permettant d'accéder à l'API REST dirrectement via une URL. Pour ce faire, se connecter à l'interface d'administration d'Icinga Web et créer un nouvel utilisateur.<br />
<img src="http://www.jesuisungeek.com/public/pictures/divers/icinga-api-1.PNG" alt="icinga-api-1.PNG" style="display:block; margin:0 auto;" title="icinga-api-1.PNG, fév. 2016" /><br /></p>
<ul>
<li><ins>User name :</ins> Remplir avec un <em>username</em> sans espace ni caractères spéciaux</li>
<li><ins>Auth via :</ins> Choisir <strong>auth_key</strong></li>
<li><ins>Authkey for API :</ins> Cliquer sur l'icône de flèches bleues pour générer une clé. Cette clé (<em>Authkey</em>) sera nécessaire lors de la connexion avec la classe Ruby.</li>
</ul>
<p><img src="http://www.jesuisungeek.com/public/pictures/divers/icinga-api-2.PNG" alt="icinga-api-2.PNG" style="display:block; margin:0 auto;" title="icinga-api-2.PNG, fév. 2016" /><br /></p>
<ul>
<li><ins>Credentials :</ins> cocher l'identifiant <strong>appkit.api.access</strong></li>
<li>Cliquer sur <strong>Save</strong> pour créer l'utilisateur.<br /></li>
</ul>
<h3>UTILISATION</h3>
<p>Avant tout, ne pas oublier d'installer la Gem <q>rest-client</q>, utilisé par <strong>IcingaWebParser.rb</strong> pour se connecter à l'API d'<a href="https://www.icinga.org/icinga/screenshots/icinga-web/" hreflang="en" title="Icinga-Web">Icinga-Web</a>. L'exemple suivant récupérera le nom de services et d'hôtes dont l'état est <strong>CRITICAL</strong>.</p>
<pre>
irb(main):001:0> require './lib/icingawebparser.rb'
=> true
irb(main):002:0> i = IcingaWebParser.new "icinga_url", "auth_key"
=> #<IcingaWebParser:0x007fa3629ec548 @url="icinga_url", @authkey="auth_key">
irb(main):003:0> i.query("service", "AND(SERVICE_CURRENT_STATE|=|2;0)", ["SERVICE_NAME", "HOST_NAME"])
=> [{:SERVICE_NAME=>"Oracle Process", :HOST_NAME=>"server1"}, {:SERVICE_NAME=>"Logs JVM", :HOST_NAME=>"server2"}]
</pre>
<p><div class="dcnote noteclassic">
<p>Les arguments pour créer une nouvelle instance sont :</p>
<ul>
<li>L'URL du serveur Icinga Web</li>
<li>La <em>Auth key</em> précédemment créée</li>
</ul>
<p></p>
</div>
La classe est attachée à ce post. La documentation complète de la classe est ici : <a href="http://www.jesuisungeek.com/public/files/etc/icingawebparser/IcingaWebParser.html">IcingaWebParser.html</a><br /><br />
<ins>Icinga utilisé :</ins> <strong>2.3.4</strong><br />
<ins>Icinga-Web utilisé :</ins> <strong>1.13.0</strong><br />
<ins>Pour en savoir plus :</ins> <strong><a href="https://wiki.icinga.org/display/Dev/Icinga-Web+REST+API">Icinga Wiki</a></strong></p>http://www.jesuisungeek.com/index.php?post/2016/02/15/Remonter-les-checks-Icinga-gr%C3%A2ce-%C3%A0-Ruby#comment-formhttp://www.jesuisungeek.com/index.php?feed/atom/comments/248