Archives de catégorie : Active Directory

ElasticSearch, Logstash, Winlogbeat et Kibana et la consolidation d’événements Windows

Dans cet article je vais parler de la consolidation d’événements de sécurité avec Windows 2012R2 et la stack ELK.

Je me suis appuyé sur deux excellents articles pour y arriver.

Le premier explique comment à partir de PowerShell, on peut installer et configurer ELK par Rob Willis et on le trouve ici.

Le deuxième est un article sur le forwarding d’events Windows, et explique bien ce qu’il faut faire pour que les événements soient transférés vers une machine collecteur. On le trouve ici.

EVENT FORWARDING

Pour la consolidation d’événements nous avons besoin d’un serveur collecteur qui servira pour consolider les événements d’un ou plusieurs domaine controleurs Active Directory.

Il y a plusieurs façons de consolider les events Windows mais le forwarding est la méthode la plus simple à mettre en place et la plus optimisée car c’est une fonctionnalité native de l’Event Viewer. De plus il’ y a pas besoin de donner des droits à un compte utilisateur car on peut habiliter la machine collecteur directement.

SUR LE DOMAINE CONTROLEUR

Il n’ y a vraiment que deux opérations à faire sur un DC. La prèmière consiste à ajouter le compte machine du serveur collector dans le groupe builtin appelé Event Log Readers.

On démarre notre DSA.MSC favori.

dsa

Et on y ajoute le compte machine du serveur collector, dans mon cas, SRV1$.

eventlogreaders

La deuxième opération est un peu plus délicate. Il s’agit de modifier les droits d’accès du log Security.

Il faut pour cette opération une commande CMD en mode Administrator (click droit sur CMD, ou PowerShell puis Run as Administrator)

Puis on regarde les droits d’accès (channelAccess) du log security, voici la commande:

Ce qui devrait avoir comme output:

On voit que par défaut le SID S-1-5-32-573 (Builtin\Event) a les droits d’accès.

Comme le processus de récupération des events utilise le compte Network Service (SID S-1-5-20), nous allons l’ajouter à la liste.

Ainsi:

Pour finalement avoir:

Voilà c’est tout. On reviendra sur le DC plus tard pour vérifier l’Event Log et nous assurer que les événements sont bien envoyés au collecteur.

SUR LE SERVEUR DE COLLECTION

On démarre l’Event Viewer et on fait un click droit sur Subscriptions, puis Create Subscription.

newsubscription

Dans la fenêtre Subscription Properties (qui vient d’apparaître), on va nommer notre subscription, par exemple Event Subscription.

eventsubname

Ensuite on click sur Computers et on y ajoute un domaine contrôleur, dans mon exemple DC1.AD.LOCAL

computers

On clic sur Test pour vérifier la connectivité.

test

On crée un filtre pour ne sélectionner que les événements Sécurité:

 

queryfilter

Et voilà nous avons notre souscription. Et nous allons la tester en faisant un clic-droit dessus, suivi de Runtime Status:

runtimestatus

On devrait avoir ceci:

runtimestatus2

Si jamais ce n’est pas le cas. Il se peut qu’une étape soit à revoir:

Coté DC il faut vérifier que l’event 100 est bien créé dans le Log Applications and Service Logs\Microsoft\Windows\Eventlog-ForwardingPlugin/Operational.

Si vous voyez un event 102 en Erreur, c’est pas bon. Il faudra alors revoir les étapes ci-dessus.

Finalement, au bout de quelques minutes vous devriez voir arriver pal mal d’events dans le journal Forwarded Events:

 

 

fwevents

Et on voit bien qu’ils viennent de notre DC (DC1.ad.local).

INSTALLATION D’ELK+WINLOGBEAT

L’article de Rob Willis est vraiment bien fait, de plus il a ajouté une video youtube pour les explications (voir lien plus haut).

Ceci étant dit, je vais quand même revenir dessus, car certaines choses ont évolué et il a fallu faire de petites adaptations.

Tout d’abord il faut récupérer plusieurs sources dont, ELK, NSSM, Java et WinlogBeat:

Sur https://www.elastic.co/downloads récupérer ElasticSearch, Logstash, Kibana et la Beta 5.0 de Winlogbeat.

Sur https://www.java.com/   récupérer Java.

Sur https://nssm.cc récupérer NSSM.

Le script de Rob Willis se trouve ici.

Se créer un répertoire C:\ElK-Stack et pour chaque produit créer un sous-répertoire et y extraire chaque zip.

S’assurer que la variable d’environnement JAVA_HOME est créée et qui pointe vers le répertoire où Java est installé, par exemple C:\Program Files (x86)\Java\jre1.8.0_101.

Attention de redémarrer ISE si vous venez de créer la variable JAVA_HOME pour qu’elle soit prise en compte.

Modifier le script de Rob Willis à la ligne

Remplacer les lignes 91 et 119

par

Il s’agit des dépendances des services Kibana et Logbeat au service Elasticsearch lors de l’étape de création des services avec NSSM. Cette partie sera à adapter en fonction de la version de ElasticSearch.

S’assurer que les services elasticsearch, kibana, logstash et winlogbear, soient tous bien démarrés.

Modifier le fichier c:\elk-stash\winlogbeat\winlogbeat.yml

et remplacer

qui sont les journaux locaux, par

Exécuter en mode step by step le script de Rob Willis.

Il est suffisamment bien documenté pour comprendre comment mettre en place chaque service.

Et finalement pour vérifier le tout on se connecte à Kibana via l’adresse http://localhost:5601

kibana

Et là on voit bien que ça fonctionne.

On peut chercher avec la barre de recherche des events venant d’un computer_name en particulier, par exemple computer_name:DC1.ad.local qui est notre DC.

kibana2

Et on voit bien les events de notre DC.

Maintenant il faut creuser un peu plus l’aspect recherche des events avec PowerShell.

Voici quelques exemples avec Invoke-RestMethod

Résultat:

 

ou encore

 

On a le nombre d’éléments trouvés.

 

Et pour récupérer tous les éléments dans l’index:

 

Tous les éléments dont le computer_name est DC1.ad.local

 

Un grand classique comme petit dernier, la liste des locked accounts sur DC1.

 

A suivre…

 

Réplication Active Directory avec Powershell et .NET

Dans cet article, nous allons regarder comment utiliser les fonctions de .NET à travers Powershell pour récupérer l’état de réplication  d’un annuaire Active Directory.

Nous allons regarder spécifiquement le namespace System.DirectoryServices.ActiveDirectory dans laquelle il y a les classes suivantes:

DirectoryContext : permet de créer un contexte de connexion de type « DirectoryServer », « Domain » ou « Forest ». Voici un exemple de création d’objet Powershell de type DirectoryContext avec connexion DirectoryServer pour se connecter sur DC en particulier:

Ou en utilisant des credentials alternatifs:

Ou vers un domaine Active Directory et là le type de contexte sera « Domain »:

Version de type « Domain » mais avec credentials alternatifs:

 

DomainController: permet de chercher un serveur parmis les domain controllers du domaine. Si le contexte créé est de type DirectoryServer nous pouvons nous connecter sur le DC ainsi

Si le contexte est de type « Domain » nous pouvons faire une recherche pour trouver un DC ainsi:

ou tous les DCs du domaine ainsi:

Une fois notre objet $dc créé nous pouvons utiliser sa méthode GetAllReplicationNeighbors pour trouver tous les partenaires de réplication

Le résultat sera un array de DCs, que nous pouvons parcourir avec un ForEach et le contenu de chaque élément sera ainsi:

Chose intéressante, nous avons l’état de réplication du DC en question avec code de résultat et message.

Avec la classe DomainController nous pouvons également récupérer les partitions de l’Active Directory

et pour chaque partition nous pouvons récupérer les cursors:

Les cursors de l’Active Directory sont des objets représentant l’état de réplication entre DCs. Chose formidable est que ces objets sont répliqués sur tous les DCs, donc en récupérant les cursors d’un DC, nous avons l’état complet de réplication d’une partition donnée selon ce DC.

L’Active Directory étant un système multi-maître, cette vue de DC sera potentiellement vite obsolète, mais donne quand même un état général proche de la réalité. Si un DC est en erreur, les cursors auront cette information.

Les données dans un cursor sont:

  • LastSuccessfulSyncTime: dernière synchronisation
  • PartitionName: le nom de la partition, Domaines, Schema, Configuration, mais potentiellement aussi les partitions DNS stockées dans l’AD, ou autres partitions applicatives.
  • SourceInvocationId: le GUID du DC source
  • SourceServer: le nom du DC source
  • UpToDatenessUsn: le dernier Update Sequence Number connu du DC source. Si un objet est modifié l’USN est augmenté, c’est ainsi que les DCs savent s’ils doivent répliquer ou pas.

Par exemple, voici les cursors d’un domaine avec deux DCs, DC1 et DC2:

Les cursors, comme les neighbors ont la propriété LastSuccessfulSyncTime, et avec cette information nous pouvons faire un calcul de latence de synchronisation sur toute la forêt.

Pour faire ceci, nous allons tout d’abord réarranger la table en ordre croissant par rapport à la propriété LastSuccessfulSyncTime

Ainsi nous avons une vue ordonnée qui peut être intéressante.

Nous pouvons également parcourir la table, générer un objet Time-Span (différence de temps) entre maintenant et le LastSuccessfulSyncTime, et analyser tout ça:

Si la différence est moins d’une heure, plus d’une heure mais moins d’une journée, moins de 7 jours, plus de 7 jours mais moins de 30, etc. on les organise comme on veut pour les regrouper.

Ensuite nous pouvons créer un objet qui contiendra ces arrays

Voici le résultat :

Et ainsi j’ai une idée globale de la latence de réplication.

 

SID

Voici comment récupérer le SID d’un utilisateur très rapidement.

Si on regarde cette commande d’un peu plus près:

On crée un objet NT account a partir d’un nom d’utilisateur:

Et ensuite on utilise la méthode Translate qui permet de récupérer un objet Security Indentifier

On peut également trouver le nom d’un Security Principal à partir d’un SID.

Pour ceci on commence par:

Le résultat sera:

 

 

Partager ce contenu

sIDHistory

Pour les besoins d’un projet, j’ai besoin de récupérer la liste des SIDs dans le champs sIDHistory de tous les utilisateur Active Directory.

Ceci sans utiliser les dernières cmdlets Active Directory disponibles depuis Windows 2008.

Alors comme on dit, on va faire de l’ADSI old school.

Un SID en très court:

Un Security Identifier (SID) est un chiffre complexe qui permet à un Security Principal (utilisateur, ordinateur, groupe) d’être identifié. Cet identifiant est placé dans les Access Control List (ACL) et reçoit des droits d’accès.

Par exemple on peut donner un droit de lecture d’un fichier à un utilisateur. Windows pour ça va créer un Access Control Entry (ACE), contenant le SID de l’utilisateur ainsi que le droit, Read, et va placer cet ACE dans l’ACL du fichier. Powershell a d’ailleurs d’excellentes cmdlets pour traiter tout ça: Get-Acl et Set-Acl.

Lors des migrations d’utilisateurs entre domaines ou entre forêts Active Directory, il est nécessaire de se rappeler l’identifiant utilisé dans la forêt d’origine, ceci car en migrant, l’utilisateur recevra un nouvel identifiant, mais tous les fichiers sur les serveurs sont protégés en utilisant l’ancien SID.

Du coup lorsqu’on migre des utilisateurs d’un domaine vers un autre, souvent on garde l’ancien SID dans le champs sIDHistory.

J’ai créé une cmdlet, Get-sIDHistory, qui permet de récupérer les SIDs dans la sIDHistory et sauvegarde le résultat dans un fichier CSV.

voici le Get-Help de la cmdlet:

Seuls le Domaine et le Path sont des paramètres obligatoires, le premier pour indiquer le domaine à scanner, et le deuxième pour définir le nom du fichier CSV à générer.

Le Serveur est optionnel et permet de cibler un DC en particulier.

Append est utilisé pour ne pas écraser le fichier CSV si on exécute cette cmdlet en boucle sur plusieurs domaines.

Et voici le code:

Partager ce contenu

Replication Status

Ecrit par @mickyballadelli

Le script ci-dessous vérifie la santé de la réplication Active Directory et génère un rapport en HTML.

Le script se base sur la commande repadmin et génère un output en CSV. Le fichier CSV est ensuite importé pour générer une version en HTML.

Les données de réplication de tous les DCs de la forêt sont vérifiés (d’où le temps qu’il faut pour la commande repadmin pour qu’elle s’exécute).

Dans cette version le script ne prend pas de paramètres, par contre il est facile de le customiser en fonction de ses besoins.

Point intéressant, la transformation du code erreur retourné par repadmin en un message lisible par un humain.

Replication errors as of « +[datetime]::Now+ »

Replication OK as of « +[datetime]::Now+ »

Partager ce contenu

Topologie Active Directory avec Visio

Ecrit par @mickyballadelli

Ce script est un exemple d’utilisation de Powershell avec Visio. Le script se connecte à un domaine Active Directory, récupère la topologie de réplication, dont les sites, les DCs dans les site, les liens de sites, et en fait un rendu en forme de spirale en s’appuyant sur Visio pour l’afficher.

Le script génère des calques Visio pour chosir quels objets sont affichés.

Utilisation:

ADvisio.ps1 -domain nom-de-domaine [-connectTo nom-de-serveur]

Ce script a été testé avec une infrastructure Windows Server 2003 et Visio 2010.

Partager ce contenu

Utilisateurs Active Directory « DES Only »

Ecrit par @mickyballadelli

Lors d’une migration d’une infrastructure Active Directory sous Windows Server 2003 vers Windows Server 2012 R2 il est important de trouver tous les comptes utilisant le protocole de chiffrage DES. Ce protocole devient obsolète.

Ce script cherche des comptes utilisateur ayant le flag DES Only dans un domaine Active Directory en fonction de la dernière date d’authentification paramétrée et crée un rapport Excel.

Ce script a été testé avec une infrastructure Windows Server 2003 et Excel 2010.

Partager ce contenu