Étiquette : ActiveDirectory

Pas de commentaire

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

  de

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.

Pas de commentaire

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

  de

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.

Pas de commentaire

Powershell : récupération d’une liste des comptes utilisateurs et ordinateurs modifiés depuis une date donnée

  de

Ne rencontrant pas de problèmes particuliers en ce moment, je prends un peu de temps pour scripter et être un peu plus à l’aise avec PowerShell et essayer de me constituer une petite banque de scripts pouvant être utiles.

Dans ce but, j’ai écrit un script listant les objets comptes utilisateurs et ordinateurs de l’ActiveDirectory qui ont été modifiés depuis la date donnée lors de l’exécution du script. Ce dernier génère deux fichiers, l’un contenant les informations par rapport aux objets « user » et l’autre aux objets « computer », avec leur nom, l’OU conteneur ainsi que le timestamp de dernière modification.

Write-Host "Fill in the date."
$D = Read-Host -Prompt 'Day'
$M = Read-Host -Prompt 'Month'
$Y = Read-Host -Prompt 'Year'
$ChangeDate=New-Object DateTime($Y,$M,$D)
Write-Host "Getting modified users..."
$ModifiedUsers = Get-ADObject -Filter 'whenChanged -gt $ChangeDate -and ObjectClass -eq "user" -and ObjectCategory -eq "person"' -Properties whenChanged | FT Name,DistinguishedName,WhenChanged
$ModifiedUsers > modifiedusers-since-$Y$M$D.txt
Write-Host "Getting modified computers..."
$ModifiedComps = Get-ADObject -Filter 'whenChanged -gt $ChangeDate -and ObjectClass -eq "computer"' -Properties whenChanged | FT Name,DistinguishedName,WhenChanged
$ModifiedComps > modifiedcomps-since-$Y$M$D.txt
Télécharger
Pas de commentaire

Powershell : Détection des comptes ayant un mot de passe expirant prochainement et envoi d’un rapport par mail

  de

Aujourd’hui, je souhaitais me connecter à mes serveurs Windows dans mon nuage. Cela faisait quelques semaines que je ne m’étais pas connecté aux machines Windows, mais uniquement à ma machine de rebond qui me permet ensuite de prendre la main sur le réseau interne aux autres machines. Possédant deux comptes différents, j’ai été quelque peu pris au piège en m’apercevant que tous mes comptes, y compris celui d’administration, avaient leurs mots de passe expirés : impossible donc d’ouvrir une console AD ou une session sur l’AD directement avec mon compte pour y modifier mes mots de passe. Il a donc fallu que je me connecte sur l’ESX pour prendre la main directement en console sur l’AD et pouvoir accéder au prompt de login classique afin que Windows me propose naturellement de modifier mon mot de passe.

Changeant irrégulièrement mes mots de passe de mes trois comptes, le fait de changer le mot de passe d’un compte ne m’indique pas que les deux autres sont proches de l’expiration, et ne me connectant pas toujours sur les machines Windows de ma plateforme ni même l’AD, je n’ai pas les rappels habituels m’indiquant que j’arrive à la fin de la durée de vie pour mon mot de passe. Il est vrai que je pourrais tout simplement procéder au changement des trois password une fois pour toutes afin de partir sur un seul délai mais ce n’est pas ce qu’il y a de plus pratique.

Afin d’éviter d’avoir à refaire face à cette situation, j’ai écrit un script plutôt simple qui contrôle les comptes de l’AD et qui vérifie la date d’expiration des comptes dont le mot de passe n’est pas permanent, en envoyant un courriel avec un fichier contenant les noms des comptes dont il va falloir penser à s’occuper.

Import-Module ActiveDirectory

$From = « admin-win@localhost »
$To = « supervision@localhost »
$Smtp = « smtp.localdomain »
$SoonToExpireList = @()
$ReportFilePath = ‘c:\temp\exp.log’
$ReportFile = New-Item -ItemType File -path c:\temp\exp.log
$Proc = $false

$AccountArray = Get-AdUser -Filter {PasswordNeverExpires -eq « false »} -Properties msDS-UserPasswordExpiryTimeComputed | select samAccountName,msDS-UserPasswordExpiryTimeComputed

foreach ($Account in $AccountArray)
    {
    $ExpDate = [datetime]::FromFileTime($Account.’msDS-UserPasswordExpiryTimeComputed’)
    $NowDate = Get-Date
    $DiffDate = $ExpDate – $NowDate
    if ($DiffDate.Days -lt 15 -and $DiffDate.Days -gt 0)
        {
        $Proc = $true
        Add-Content -path $ReportFilePath -value ($Account.samAccountName)
        }
    }

if ($Proc -eq $true)
    {
    $MailString = « Bonjour, les mots de passe des comptes indiques dans le fichier en PJ expirent dans moins de 15 jours. »
    Send-MailMessage -From $From -To $To -Subject « Comptes aux mots de passe expirant prochainement » -SmtpServer $Smtp -Body $MailString -Attachments $ReportFilePath
    }   

Remove-Item $ReportFilePath

Bien entendu, il est possible d’améliorer ce script, en programmant l’envoi de mail lorsqu’il reste 7 jours, puis 3 jours, par exemple. Dans mon cas, le script est en exécution hebdomadaire, ce qui me laisse deux courriels pour prendre quelques minutes et m’occuper de changer mes password avant que mes comptes soient inaptes à ouvrir une session TS.

Le script est téléchargeable avec ses commentaires et prêt à l’emploi sur mon miroir de téléchargement.