avril 2013 - Blog - Mathieu Chateau

L’objectif de ce plugin pour Nagios est de superviser l’état des comptes AD (oui, je ne fais pas que du SCOM malgré un ouvrage ENI dessus!)

J’utilise l’agent nsclient++ sur les serveurs afin de pouvoir exécuter des scripts PowerShell entre autre. On a donc:

Nagios => check_nrpe => script powershell => retour nagios

Je m’appui sur le module PowerShell Standard ActiveDirectory. Cela fonctionne également sur les serveurs Core.

La supervision peut porter sur:

Account Disabled
Account Expired
Account Expiring
Account Inactive
Locked Out
Password Expired
Password Never Expires

La sortie fournie les données pour avoir un graphe (performance data)

Configuration testée

Linux:

Centos 6.4 x64
Nagios 3.4.4
check_nrpe 2.13
Centreon 2.4.2

Active Directory:

Windows Server 2008 R2 / Windows Server 2012
nsclient++ 0.4.1 x64
Serveurs Core et normaux

Arguments du script

action (LockedOut par défaut)
searchBase (tout le domaine par défaut)
seachScope (récursif par défaut)
maxWarn (avertissement si supérieur)
maxCrit (Critique si supérieur)

action peut être:
AccountDisabled,AccountExpired,AccountExpiring,AccountInactive,LockedOut,PasswordExpired,PasswordNeverExpires
LockedOut par défaut

searchBase peut être:
dc=mydomain,dc=com / ou=my users,dc=mydomain,dc=com
tout le domaine par défaut

seachScope peut être:
Base,OneLevel,Subtree
Subtree par défaut

maxWarn and maxCrit doivent être des entiers

Exemples d’utilisation

Exemple en exécution directe PowerShell:

PS C:Program FilesNSClient++scripts> . .lotp_check_ad_accounts.ps1 AccountInactive "dc=mydomain,dc=com" subtree 5 10
CRITICAL: 216 AccountInactive|216;5;10
PS C:Program FilesNSClient++scripts>

Exécution NRPE:

[root~]# /usr/lib64/nagios/plugins/check_nrpe -H prd-dom-dc01 -n -c check_ad_account -a AccountInactive "dc=pmside,dc=net" subtree 5 10

CRITICAL: 216 AccountInactive|'AccountInactive'=216;5;10

[root~]#

Installation:

Sur les DC:

Activer l’exécution de scripts PowerShell non signés : Set-ExecutionPolicy RemoteSigned
copier le script dans C:Program FilesNSClient++scripts
Ajouter dans le fichier nsclient.ini:
- [/settings/external scripts/wrapped scripts]
  check_ad_account=lotp_check_ad_accounts.ps1 $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$

Configuration:

Par exemple, sur Centreon, en ajoutant la commande:

$USER1$/check_nrpe -H $HOSTADDRESS$ -n -c check_ad_account -a $ARG1$ "$ARG2$" $ARG3$ $ARG4$ $ARG5$

Téléchargement

(enlever le .txt à la fin)

lotp_check_ad_accounts.ps1

Code source en direct si le téléchargement ne passe pas:

# ====================================================================
# Search in AD for lockedout account. To be used through NRPE / nsclient++
# Author: Mathieu Chateau - LOTP
# mail: mathieu.chateau@lotp.fr
# version 0.1
# ====================================================================#
# Require Set-ExecutionPolicy RemoteSigned.. or sign this script with your PKI 
#
# ============================================================
#
#  Do not change anything behind that line!
#
param 
(
    [string]$action="LockedOut",
    [string]$searchBase="",
    [string]$searchScope="Subtree",
    [int]$maxWarn=5,
    [int]$maxCrit=10
)

# check that powershell ActiveDirectory module is present

if(Get-Module-Name "ActiveDirectory" -ListAvailable)
{
    try
    {
        Import-Module-Name ActiveDirectory
    }
    catch
    {
        Write-Host "CRITICAL: Missing PowerShell ActiveDirectory module"
        exit 2
    }
}
else
{
    Write-Host "CRITICAL: Missing PowerShell ActiveDirectory module"
    exit 2
}

# check params if provided

if($action -notmatch "^(AccountDisabled|AccountExpired|AccountExpiring|AccountInactive|LockedOut|PasswordExpired|PasswordNeverExpires)$")
{
    Write-Hos t"CRITICAL: action parameter can only be AccountDisabled,AccountExpired,AccountExpiring,AccountInactive,LockedOut,PasswordExpired,PasswordNeverExpires. Provided $action"
    exit 2
}
if($searchScope -notmatch "^(Base|OneLevel|Subtree)$")
{
    Write-Host "CRITICAL: searchScope parameter can only be Base,OneLevel,Subtree. Provided $searchScope"
    exit 2
}
if(($searchBase -ne "") -and $searchBase -ne ((Get-ADDomain).DistinguishedName))
{
    $search=Get-ADObject -Filter 'ObjectClass -eq "OrganizationalUnit" -and DistinguishedName -eq $searchBase'

if ($search.Count -ne 1)
    {
        Write-Host"CRITICAL: SearchBase not found or duplicate. Provided $searchBase"
        exit 2
    }
}
else
{
    $searchBase=(Get-ADDomain).DistinguishedName
}

$command="Search-ADAccount -"+$action+" -SearchBase '"+$searchBase+"' -SearchScope "+$searchScope

$result=invoke-expression $command

if($result.Count -gt $maxCrit)
{
    $state="CRITICAL"
    $exitcode=2
}
elseif($result.Count -gt $maxWarn)
{
    $state="WARNING"
$exitcode=1
}
else
{
    $state="OK"
$exitcode=0
}

$output=$state+": "+$result.Count+""+$action+"|"+$action+"="+$result.Count+";"+$maxWarn+";"+$maxCrit

Write-Host $output
exit $exitcode

En informatique, comme pour beaucoup de choses, on finit par être à l’étroit dans l’existant. Peut-être un peu plus vite en informatique que dans les autres domaines. Se pose alors toujours le choix entre mieux gérer l’existant versus investir dans une nouvelle solution / faire une upgrade.

Mieux gérer l’existant

Ce choix est plus courageux que le deuxième, mais aussi plus risqué. Il revient à dire que pensez pouvoir faire mieux que ce qui a été fait depuis le début. Cela se caractérise en général par du temps à passer, avec un gain difficile à estimer à l’avance. Je pense qu’il faut l’essayer en premier car:

Il va potentiellement générer des économies, même s’il est insuffisant et qu’il faille quand même investir.
Il permettra de mieux comprendre le besoin en passant en revue les usages, et donc de justifier l’investissement éventuel.
Il montre qu’on ne se contente pas « d’investir ».

Le principal est de se fixer un objectif en termes de délai et de charge pour produire un résultat. Il ne devrait cependant jamais dépasser un certains % que coûterait la deuxième solution.

La demande en ressource informatique croit inexorablement dans les entreprises. Les projets les plus stratégiques font normalement l’objet d’un « capacity planning » permettant de s’assurer que la solution tiendra les fameux 3 ou 4 ans de son amortissement. Il y a cependant quelques parents pauvres qui bénéficient rarement de ce traitement:

Le stockage de fichiers bureautiques,
Le stockage des mails,
La consommation réseau (inter sites, et Internet).

Crédit

Demander le ménage dans les fichiers bureautiques revient à ramer dans le désert. Tout le monde estime avoir mieux à faire, mais personne n’a envie de payer le prix que cela coûte (stockage central €MC / N€tApp, sauvegarde…). Face à l’hémorragie, des solutions soit disant « miracle » ont vu le jour (archivage 3 tiers, déduplication, SharePoint…). Ce dernier permet l’indexation, ce qui est presque le pire. Où comment s’y retrouver dans un capharnaüm sans ranger sa chambre. Non seulement les utilisateurs ne veulent plus supprimer les vieux fichiers, mais ils ne veulent plus classer non plus…

Heureusement, on peut transformer le virus en vaccin : chercher les mots salaires et primes. Résultats garantis!

Le réseau fait partie des investissements « lourds » qui fonctionnent par palier. Le stockage et la sauvegarde en font également partis. Des solutions existent depuis pas mal de temps, vu que c’était le premier point de contention dans les entreprises en général:

QOS : permet de gérer l’intérieur du tuyau : garantir des flux, en restreindre d’autres,
Compression : Riverbed & co. Espérer que les données sont redondantes et faire l’équivalent d’un « zip » des flux réseaux.

En réponse à tout cela, je propose deux approches en parallèle:

Vérifier que les bonnes pratiques « minimum » sont appliquées
Outiller la DSI pour pouvoir faire de la refacturation interne.

Quelques bonnes pratiques ayant fait leurs preuves:

Les flux http/https sont compressés par les serveurs Web et proxy,
Les réplications (DFS, SQL…) inter sites sont faites pendant les heures creuses ou avec la gestion de bande passante intégrée,
Privilégier l’envoi de Delta plutôt que complète,
Chercher les fichiers les plus volumineux,
Bloquer dès le départ plutôt qu’a posteriori (fichiers multimédias…),
Mettre des quotas pour gérer des croissances non prévues. Même si le blocage ne sera pas maintenable.
Noter toute solution « temporaire », en identifiant le demandeur, la raison, et la date de suppression,
Mettre des sécurités (alerte/blocage) en dessous des valeurs réellement bloquantes.
Après une mise en production, revalider le capacity planning initial.

Lors de besoins pour un projet spécifique, il est souvent facile d’identifier le motif des coûts. Cela est plus difficile quand il s’agit de la connexion Internet ou du stockage. Les outils de refacturation permettent d’objectiver la consommation. Même si la refacturation interne ne sera pas faite, elle permet d’identifier clairement les consommateurs, et de ventiler le coût de la prochaine upgrade.

Investir

Cette solution permet d’avoir, de manière presque certaine, une réponse immédiate à un problème ou à un besoin. Sur certains sujets, comme les fichiers bureautiques, il permet de ne pas s’attirer les foudres des utilisateurs, surtout quand ces derniers n’hésitent pas à comparer avec le prix d’un disque de 1To chez le marchand du coin. Cependant il y a des cas où ce choix n’apporte pas les gains escomptés. C’est notamment le cas avec les problèmes de performances, où acheter un deuxième serveur ne veut pas forcément dire deux fois plus vite.

L’investissement est souvent favorisé car il permet également d’avoir des ressources pour mener les actions. Si vous souhaitez optimiser votre infrastructure virtuelle, vous aurez peut-être du mal à obtenir un budget, tout au plus pour un audit. Alors que si vous faites un projet avec de nouveaux serveurs et une montée de version, on vous donnera le budget pour cela, avec les jours hommes qui vont avec. Cela est dû à la difficulté d’afficher des gains avant de faire l’optimisation.

Conclusion

Je recommande les actions suivantes pour le « label » DSI++:

Avoir les indicateurs clés de saturation. Ceux-ci doivent être suffisants pour avoir le temps de mener une phase d’optimisation. Sinon on se retrouve dos au mur et l’investissement sera systématiquement retenu.
Demander l’exercice de chiffrer la consommation de ressources dans les projets. Profiter des montées de version pour inclure cet exercice sur l’existant. Vérifier à posteriori la différence entre le prévu et le réel. Les chiffres sont tout aussi intéressants que la prise de conscience des personnes sur l’impact de leur projet.
Quand une solution à un problème de consommation est identifiée dans un projet (activer la compression http), l’inclure dans des normes et standard, afin qu’elle soit généraliser « par défaut ».
Implémenter des outils de refacturation sur les éléments partagés et ceux où le consommateur n’est pas clairement identifiable.
Vérifier que des graphiques de consommation sont bien disponibles sur les éléments clés de l’architecture : stockage, réseau, processeur, mémoire. Ce n’est pas quand il y aura une saturation que ces graphes doivent être mise en place.
Ramener le prix du stockage central au Go. Cela permet facilement une prise de conscience lors des demandes. Idem pour le réseau.
Remettre en cause les choix du passé lors des renouvellements d’architecture. On fait certains choix en fonction:
- D’un contexte,
- De l’état des technologies (maturité, coût, connaissance),
- De choix du groupe,
- du budget.

Parfois c’est même d’autres personnes qui ont fait ces choix sur l’architecture actuelle. Il moins engageant de « juste renouveler », mais cela vous enferme indirectement dans des choix limités pour la suite.

Nagios: Superviser les comptes Active Directory