Trouvez des comptes verrouillés dans Active Directory (une méthode qui fonctionne réellement!)


8

J'ai cherché sur Google comment répertorier les comptes verrouillés et trouvé jusqu'à présent deux méthodes, qui ne fonctionnent pas toutes les deux ...

Requête enregistrée - (&(&(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))))

Répertorie un certain nombre de comptes, dont beaucoup ne sont pas verrouillés. Si j'en déverrouille un dont je sais qu'il est verrouillé, il est toujours renvoyé par la requête.

Commande Powershell - Search-ADAccount -LockedOut

Ne fait rien.

Alors non plus - est-ce que je fais quelque chose de mal? Ou - Existe-t-il une méthode qui fonctionne réellement?


Juste une petite note: pour gérer le domaine avec les commandes incluses dans le module AD PowerShell (y compris l'utilisation du commandlet Search-ADAccount), vous devez avoir installé le service Active Directory Web Services (ADWS) sur au moins un contrôleur de domaine de ce domaine. Mais je suppose que ce n'est pas un problème car si vous n'avez pas d'instance ADWS, vous obtenez un message d'erreur vous en informant.
Mikhail

Réponses:


11

Je ne ferais pas nécessairement confiance Get-ADUser -LDAPFilter "(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))" -Properties LockedOut, car cela ne me donne pas de résultats fiables non plus, mais je ne peux pas non plus contacter directement mon PDCe pour le moment. Pour de meilleurs résultats, vous souhaitez cibler directement votre émulateur PDC, car il dispose toujours des informations les plus à jour sur les verrouillages de compte dans tout le domaine.

C'est ce que je parie que vous voyez ici un retard dans la réplication:

... le verrouillage de compte est répliqué de toute urgence vers le propriétaire du rôle d'émulateur du contrôleur de domaine principal (PDC) et est ensuite répliqué de manière urgente vers les éléments suivants:

• Contrôleurs de domaine du même domaine situés sur le même site que l'émulateur PDC.

• Les contrôleurs de domaine du même domaine qui se trouvent sur le même site que le contrôleur de domaine qui a géré le verrouillage de compte.

• Les contrôleurs de domaine du même domaine qui se trouvent dans des sites qui ont été configurés pour autoriser la notification des modifications entre les sites (et, par conséquent, la réplication urgente) avec le site qui contient l'émulateur PDC ou avec le site où le verrouillage de compte a été géré. Ces sites incluent tout site inclus dans le même lien de site que le site qui contient l'émulateur PDC ou dans le même lien de site que le site qui contient le contrôleur de domaine qui a géré le verrouillage de compte.

En outre, lorsque l'authentification échoue sur un contrôleur de domaine autre que l'émulateur PDC, l'authentification est réessayée sur l'émulateur PDC. Pour cette raison, l'émulateur PDC verrouille le compte avant le contrôleur de domaine qui a géré la tentative de mot de passe ayant échoué si le seuil de tentative de mot de passe incorrect est atteint. Pour plus d'informations sur la façon dont le propriétaire du rôle d'émulateur PDC gère les modifications de mot de passe et les verrouillages de compte, voir «Gestion des opérations flexibles à maître unique» dans ce livre.

Essayez donc de Search-ADAccount -LockedOut -Server DC-PDCEvoir si vos résultats sont meilleurs.

En outre, voici autre chose à considérer lors de la création de requêtes autour de l'attribut lockoutTime:

Cette valeur d'attribut n'est réinitialisée que lorsque le compte est correctement connecté. Cela signifie que cette valeur peut être différente de zéro, mais que le compte n'est pas verrouillé. Pour déterminer avec précision si le compte est verrouillé, vous devez ajouter la durée de verrouillage à cette heure et comparer le résultat à l'heure actuelle, en tenant compte des fuseaux horaires locaux et de l'heure d'été.

Edit: En guise d'ingénierie inverse Microsoft.ActiveDirectory.Management.dll, je peux vous dire que Search-ADAccount -LockedOut, qui me semble produire des résultats assez fiables, exécute le code suivant:

else if ((bool) this._paramSet.LockedOut)
      {
        list.Add(ADAccountFactory<ADAccount>.AttributeTable[cmdletSessionInfo.ConnectedADServerType]["AccountLockoutTime"].InvokeToSearcherConverter(ADOPathUtil.CreateFilterClause(ADOperator.Ge, "AccountLockoutTime", (object) 1), cmdletSessionInfo));
        this.OutputFilterFunction = new ADGetCmdletBase<SearchADAccountParameterSet, ADAccountFactory<ADAccount>, ADAccount>.OutputFilterDelegate(this.FilterIsLockedOut);
      }
      if (list.Count > 0)
        this.OutputSearchResults(list.Count != 1 ? ADOPathUtil.CreateAndClause(list.ToArray()) : list[0]);
      else
        this.OutputSearchResults((IADOPathNode) null);

Il semble donc que l' Search-ADAccount -LockedOuton regarde également l'attribut AccountLockoutTime!

Éditez un peu plus pour une grande justice: Richard Mueller, Dir. Services MVP, dit ceci:

Vous ne pouvez pas utiliser l'attribut userAccountControl pour identifier les utilisateurs verrouillés. Il y a un peu de userAccountControl documenté pour cela, mais il n'est pas utilisé.

Je peux le vérifier ainsi:

PS C:\Users\ryan> $(Search-ADAccount -LockedOut).Count
11
PS C:\Users\ryan> $(Get-ADUser -LDAPFilter "(&(objectCategory=User)(userAccountControl:1.2.840.113556.1.4.803:=16))").Count
0

Enfin, je voudrais terminer sur ce billet de blog sur le sujet , qui explique pourquoi l' lockoutTime>=1approche de la meilleure solution, mais ce n'est qu'une partie de l'histoire. Vous devez filtrer davantage la liste pour n'inclure que les utilisateurs dont le lockoutTime est supérieur à $ (la durée de verrouillage de votre domaine) minutes dans le passé.


Je vais être intéressé de trouver de la documentation sur le moment où ce userAccountControlbit a cessé d'être valide. Cela a bien fonctionné dans le passé, si ma mémoire est bonne. Cela me fait me demander si la fonctionnalité a été supprimée dans une révision ultérieure du code AD. Hmm ...
Evan Anderson

Eh bien, je déteste continuer de faire appel à l'autorité, mais Richard Mueller dit que cela n'a pas fonctionné depuis Windows 2000.
Ryan Ries

Je soupçonne que cela fonctionne dans Windows 2000 lorsqu'il y a des contrôleurs de domaine Windows NT 4.0, car il devrait être là pour faciliter la réplication vers les contrôleurs de domaine qui ont un SAM. Je n'ai plus d'environnement de test créé pour NT 4.0 (j'ai supprimé toutes ces anciennes machines virtuelles) mais je vais certainement l'essayer. Il devrait y avoir un moyen pour les contrôleurs de domaine SAM uniquement d'être en mesure d'être au courant du verrouillage du compte - c'est la seule façon pour moi de le voir fonctionner.
Evan Anderson

@EvenAnderson Je soutiens de tout cœur vos recherches et j'attends avec enthousiasme les résultats de vos tests. :)
Ryan Ries
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.