Powershell : obtention de la station qui déclenche un verrouillage de compte AD

Ayant eu un cas récalcitrant de compte qui se verrouillait a priori tout seul, j'ai créé un petit script PowerShell à lancer en tant qu'administrateur sur un contrôleur de domaine. Ce script parcourt le journal d'événements de sécurité afin d'y trouver une entrée avec un identifiant 4740 correspondant à l'identifiant passé en paramètre.

Le script est disponible dans une version commentée sur mon miroir de téléchargement.

param
([string]$User)

$EventLog = Get-EventLog -LogName "Security" -InstanceID "4740" -Message "*$User*" -Newest 1
if ($EventLog -eq $null) {
Write-Host "User doesn't exist or there is no log entry related to it."
Break
}
Write-Host $EventLog[0].TimeGenerated
Write-Host $EventLog[0].Message

On appellera donc ensuite le script comme ceci :

PS > win_event4740.ps1 usertest

Par exemple, on peut utiliser LockoutStatus pour déterminer le DC qui procède au verrouillage du compte :

Sur cette capture, le compte n'est pas verrouillé, mais si il l'est, la colonne encadrée donnera le nom du DC ayant procédé au blocage du compte.

Ensuite, en se connectant au domain controller en question, l'exécution du script en passant en paramètre le login du compte verrouillé évitera d'ouvrir le journal d'évenements et d'avoir à filtrer parmi plusieurs évenements de verrouillages de compte.

Erreur 530 lors de la connexion sur un FTP géré par IIS

J'ai installé récemment sous IIS un site FTP de backup qui est une réplication exacte du premier pour un client externe. Avant de procéder à la livraison de celui-ci, je voulais faire un test de connexion avec un utilisateur lambda pour m'assurer que tout était bien configuré proprement. Dans cet exemple, le serveur FTP se base sur ActiveDirectory pour obtenir la liste des comptes habilités ou non à lire ou écrire.

Et voilà que sur FileZilla, je me heurte à une erreur 530.

Un petit tour dans l'ActiveDirectory pour voir si il ne s'agit pas d'une variable mal configurée :

Aucun répertoire de profil n'est configuré, mais pas plus sur tous les autres comptes qui fonctionnent sur le premier environnement. Je décide donc de tester ce compte sur ce dit premier environnement et pas mieux, je me heurte à la même erreur.

Avec accord du client, je duplique donc un compte qui fonctionne et fais le test : pas mieux.

Je vérifie donc ma configuration IIS, et tous les paramètres sont strictement identiques. S'agissant visiblement d'un problème de répertoire, je vais sur la page des paramètres d'isolement des utilisateurs et le désactive (ce qui fait que chaque utilisateur n'est plus cantonné à son propre répertoire) :

Sur cette capture d'écran, le réglage bloque l'utilisateur dans un répertoire donné afin qu'il ne puisse pas browser l'intégralité du serveur FTP.

Une fois l'option Do not isolate users cochée, tout fonctionne avec les deux comptes, le dupliqué et mon compte de test. Le problème provient donc bien d'un répertoire non accessible qui est indiqué quelque part dans les comptes utilisateurs. Je fais un test avec l'original du compte dupliqué, et ça fonctionne !

Je décide donc de regarder au niveau des attributs des comptes. Sur les comptes qui fonctionnent, je vois ceci :

Deux attributs msIIS-FTPDir et msIIS-FTPRoot qui contiennent les informations permettant au serveur FTP d'isoler l'utilisateur. Sans ces attributs, pas de connexion possible. En analysant les attributs du compte dupliqué et de mon compte de test, je ne vois pas ces attributs, rendant alors la connexion impossible :

L'erreur n'a donc côté client jamais existé puisque les comptes utilisés avaient bien ces attributs de renseignés, ce qui n'était pas le cas pour mon compte de test.

Désactivation des ciphers AES 128, AES 256 et 3DES 168 sous Windows Server

Il y a peu, j'ai dû désactiver sur une plateforme TLS 1.0 et 1.1. Aujourd'hui, rebelote, mais avec les ciphers Triple DES, ainsi qu'AES 128 et 256.

J'ai placé un extract de ces clefs de registre dans une archive disponible sur mon miroir de téléchargement.

En ouvrant regedit, on va se placer dans le chemin suivant :
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

Puis, il suffira de créer une clef par cipher que l'on souhaite désactiver. Dans notre cas, nous allons créer 3 clefs ayant les noms suivants :

  • Triple DES 168
  • AES 128
  • AES 256

Dans chacune de ces clefs, il faudra créer une valeur DWORD appelée Enabled et ayant pour valeur 0.

On obtient donc quelque chose de similaire à ceci :

Un redémarrage est nécessaire pour appliquer les modifications car la DLL schannel ne lit les paramètres du registre qu'au démarrage du système. Si jamais il y a besoin d'annuler les modifications réalisées, il suffit de supprimer les clefs tout juste créées. A noter que si il y a désactivation d'un cipher utilisé pour encrypter les pages web utilisées par le serveur IIS, ces pages ne seront plus accessbiles, il convient donc de faire un test au préalable et de désactiver avec parcimonie les ciphers.

Si l'on désactive le cipher AES 256 via le registre, cette page ne sera plus accessible

Plus d'informations concernant les ciphers désactivables sous Windows sont disponibles à ce lien.

Powershell : récupération des informations sur le(s) pagefile.sys

Dans l'idée du billet d'hier concernant la résolution de problématiques d'espace disque, j'ai codé rapidement un petit script Powershell pour récupérer les informations système propres au(x) fichiers de pagination.

En passant en argument du script un nom de machine, on récupère le chemin du fichier, sa taille de base, l'utilisation actuelle et maximale de celui-ci.

Param
([string]$Comp)

$pfsys = Get-WmiObject Win32_PagefileUsage -Computer $Comp | select Name, CurrentUsage, PeakUsage, AllocatedBaseSize
foreach ($pf in $pfsys)
{
echo "Location: "$pf.Name
echo "File base size in MB: "$pf.AllocatedBaseSize
echo "Current usage: "$pf.CurrentUsage
echo "Max. usage: "$pf.PeakUsage
}