[HowTo] Bloquer l’exécution de PSexec.exe

 

Introduction

PSexec fait partie de la fameuse SysInternals Tools/PsTools Suite de Microsoft, créée par Mark Russinovich, qui n’est autre que le CTO actuel de la firme américaine.

PSexec vous permet d’exécuter des commandes/Processus sur des machines distantes, et ce sans avoir besoin d’installer de features/outils supplémentaires.

Il s’agit d’un outil très puissant d’Administration (à distance) et troubleshooting des plateformes Windows (Client & Server).

Télécharger la Suite SysInternals Tools

Télécharger l’outil PSexec.exe

Note : le guide d’utilisation de PSexec est détaillé depuis la même page de Download.

Tip : comme vous pouvez le constater, les tools de la Sysinternals peuvent être téléchargés séparément.

 

Bloquer l’exécution de PSexec ?!! Pourquoi ? Pour quelles raisons ?

Contrairement à la plupart des Softwares/Tools de Microsoft, le fonctionnement de PsExec.exe n’est pas un secret, il est assez simple. PsExec autorise les redirections des Input & Output d’un exécutable démarré à distance via l’utilisation de SMB et du partage (caché) $ADMIN sur le système distant. Avec ce partage, PsExec utilise l’API Windows Service Control Manager (WSCM) pour démarrer le service PsExecsvc sur le système distant, qui crée un canal nommé avec lequel PsExec communique. Ce canal nommé est ce qui permet la redirection des entrées / sorties vers le système qui a lancé PsExec.

PsExec peut être utilisé pour collecter des informations depuis des machines distantes (IPConfig, Net use, …) ou administrer un serveur Windows (Changer le password d’un compte Admin Loca, Patch management à partir d’un script…) ou encore lancer une instance Regedit.exe en tant que System Account pour pouvoir écrire/modifier certaines clés de Registre et bien plus encore !

La puissance de cet outil fait justement « peur » à certains RSSI/DSI, par conséquent, PsExec fait généralement partie des tools à Blacklister sur tout le parc Windows Client/Server.

A l’aide de PsExec, un Hacker ayant réussi à récupérer des crédentials depuis une machine vulnérable sur le réseau, peut les utiliser pour établir une connexion distante et tenter des collecter plus d’infos sensibles voire envisager une escalation de privilège.

 

Quelques Real-world scénarios

• Exéuction d’un programme malveillant à distance (eg : Backdoor)

• Exécuter un programme/file à distance via l’utilisation d’un UserName et le Hash de son password !

Exécution des outils /programmes en tant que Compte « System » : compte ayant le plus haut niveau de privilège sur les OS Windows

 

Vous aurez compris, l’utilisation de PsExec au sein d’un réseau Windows peut s’avérer dangereuse car permettrait à un Hacker ou toute personne malveillante d’accéder et récupérer à des informations sensibles (AD, comptes Admin…)

 

HowTo : Bloquer l’exécution du PSexec

Il existe différentes méthodes pour bloquer l’exécution de PsExec.exe :

• Désactivation du partage (par défaut) ADMIN$
• Déploiement d’une clé de registre (psexec.exe > Dubugger = svchost.exe)

 

Bloquer PsExec via la désactivation du Partage Windows ADMIN$

Pourquoi désactiver le partage ADMIN$ ?

Lorsque PsExec est utilisé pour exécuter une tâche/commande sur un système distant, il crée un nouvel exécutable/service appelé « psexesvc.exe ». Cet exe est copié dans le dossier Windows de la machine distante via le partage par défaut ADMIN$ (d’où la nécessité d’être un administrateur pour que psexec fonctionne à distance), désactiver ce partage bloque donc le fonctionnement de PsExec

Pour désactiver le partage ADMIN$, rien de plus simple, il faut lancer la console « Dossiers partagés » en exécutant l’outil « FsMgmt.msc » depuis le Menu Exécuter ou Démarré > Partages > ADMIN$ > Click-droit > Arrêter le Partage.

 

Bloquer PsExec via la clé de Registre

Pour bloquer l’exécution du PSexec via la clé de Registre, suivez les instructions suivantes :

• Créer une clé de Registre nommée « psexec.exe » au niveau de : HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
• Créer ensuite une sous-clé au niveau de « psexec.exe », avec les informations suivantes :
  • Type : REG_SZ (Data String)
  • Nom clé : Debugger
  • Valeur : svchost.exe

 

Aucun reboot de la machine n’est requis :).

Testons maintenant l’exécution du PSexec. Dans l’exemple suivant, je reprend l’exemple précédent pour lancer un CMD.exe en tant que « System », comme montré ci-dessous, aucun résultat n’est retourné.

PSexec est bloqué au lancement, vous n’aurez aucune info ni message d’erreur :

 

Bloquer PsExec via GPO (GPP)

Si vous devez généraliser le déploiement de la clé Registre créée précédemment, le meilleur moyen de le faire, est de configurer une GPP (Group Policy Preference), voir paramètres suivants ;

 

Télécharger la clé de Registre

Vous pouvez télécharger la clé de Registre depuis l’URL suivante et l’importer directement sur les machines (Client et/ou Serveur) sur lesquelles vous souhaitez bloquer l’exécution de PSexec

https://gallery.technet.microsoft.com/Block-PsExec-Execution-4a86c023

 

Pensez à implémenter AppLocker 

Le meilleur moyen de bloquer l’exécution des PsTools (PsExec, PsShutdown…) est d’implémenter des règles (Blacklisting) AppLocker à base de Hash, c’est le moyen le plus fiable en terme de software blacklisting dans les environnements Windows.

 

Note : un eBook sur AppLocker 2012 R2 et 2016 est disponible sur BecomeITExpert.com. Si le sujet vous intéresse, cliquez sur une des images ci-dessous pour en savoir plus.

 

A bientôt :).

Microsoft LAPS : Introduction au module PowerShell « AdmPwd.PS »

 

La configuration de la solution LAPS est réalisée via PowerShell (PowerShell V2 minimum), cette solution possède un module dédié nommé « AdmPwd.PS ». Ce module s’installe avec LAPS en sélectionnant l’option « PowerShell Module ». Avant l’installation et le déploiement de la solution il est préférable de se familiariser avec ce module.

Avant chaque opération LAPS via PowerShell, vous devez d’abord importer le module PowerShell « AdmPwd.PS » en exécutant l’une des deux commandes suivantes :

Ci-dessous vous trouverez la liste des Cmd-Lets inclus dans le module PowerShell.

Import-Module AdmPwd.PS IpMo AdmPwd.PS

Vous pouvez ensuite exécuter la commande suivante pour obtenir la liste complète des Cmd-lets fournis avec le module LAPS PS « AdmPwd.PS » :

Get-Command -Module AdmPwd.PS

Comme illustré dans la capture d’écran ci-dessous, le module « AdmPwd.PS » dispose de plusieurs Cmd-lets, celles-ci sont détaillées dans le tableau ci-dessous :

Cmd-Let /Explication

Find-AdmPwdExtendedRights Permet d’obtenir les groupes /comptes par OU ayant la permission de consulter les mots de passe.

Get-AdmPwdPassword Permet d’obtenir le mot de passe d’une machine.

Reset-AdmPwdPassword Permet de modifier la date d’expiration du mot de passe.

Set-AdmPwdAuditing Permet d’activer l’audit d’accès au mot de passe d’une machine. Créer l’événement 4662 sera consigné dans le journal des événements de sécurité des contrôleurs de domaine.

Set-AdmPwdComputerSelfPermission Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les comptes ordinateurs. Ceux-ci peuvent modifier les attributs LAPS afin de renseigner le mot de passe.

Set-AdmPwdReadPasswordPermission Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les groupes/utilisateurs. Ceux-ci peuvent afficher le mot de passe.

Set-AdmPwdResetPasswordPermission Permet de créer sur les OU dans Active Directory les délégations de contrôles pour les groupes /utilisateurs. Ceux-ci peuvent modifier la date d’expiration afin d forcer le changement du mot de passe.

Update-AdmPwdADSchema Permet de modifier le schéma AD en ajoutant les objets de type ordinateur les attributs suivants : ms-MCS-AdmPwd ms-Mcs-AdmPwdExpirationTime

 

Ceci est un extrait de l’eBook « Microsoft LAPS – Déploiement et Configuration en Entreprise« .

L’eBook est disponible ici.

N’hésitez pas à consulter la table des matières pour en savoir plus.

 

#HK

[New eBook] Active Directory – Gérez vos infrastructures AD 2016 et 2019 via PowerShell

A propos de cet eBook

Ce livre présente un ensemble de commandes PowerShell inclus dans le module Active Directory (2016 et 2019 Server). Il vous permettra de vous familiariser avec ce langage puissant.

A la fin de ce livre, vous serez capable de :

• Gérer les unités d’organisations
• Gérer les groupes
• Gérer les comptes d’utilisateurs et d’ordinateur
• Effectuer des recherches avancées dans AD DS
• Exporter des données formatées de votre annuaire
• Importer des comptes dans un traitement automatisé
• Planifier des scripts pour automatiser vos traitements
• Manipuler des objets

 

De plus, l’eBook présente une partie des commandes du module Active Directory, il n’est pas exhaustif. La majorité des exemples présentés ici fonctionneront également avec des contrôleurs de domaine en Windows Server 2008 R2, même si les illustrations ont été réalisés sur Windows Server 2016.

Publics concernés par cet eBook

Ce guide pas à pas peut intéresser plusieurs populations IT :

• DSI
• Responsable Technique /Infrastructure
• Architecte Infrastructure
• Consultant Infrastructure
• Chef de Projet Technique
• Ingénieur Systèmes /Réseaux
• Administrateur Système /Réseau
• Technicien de Support /Système /Réseau
• Toute personne désirant gérer son environnement Active Directory avec PowerShell

 

L’eBook est organisé en 8 Chapitres, voir la table des matières suivante pour en savoir plus :

Sommaire – 1

Sommaire – 2

L’eBook est disponible sur BecomeITexpert.com, cliquez sur l’image ci-après pour en savoir plus :

Très bon eBook de Philippe BARTH | Microsoft MVP sur Directory Services.

Bonne lecture à tous :).

A bientôt,

#HK

Différence entre Windows Server Active Directory (ADDS) vs Azure Active Directory (AAD) vs Azure AD Domain Services (AADDS)

Hi All,

Suite à la réalisation de plusieurs missions (Consulting /Expertise Azure), j’ai pu constater que plusieurs clients se posent toujours la même question quant il s’agit de gérer les identités et accès aux applications Cloud.

The Question est la suivante :

Quelle est la différence entre une infrastructure AD (Windows Server Active Directory) traditionnelle, Azure Active Directory (AAD) et Azure Active Directory Domain Services (AADDS) ?

Si vous vous posez aussi la même question, eh bien sachez que vous êtes à la bonne adresse :).

Let’s see la différence !

 

First of all, définissons ce que c’est Windows Server Active Directory, Azure AD et Azure ADDS !

Windows Server Active Directory (ADDS)

ADDS pour Active Directory Domain Services (aka AD pour Active Directory) est un rôle natif fourni (par défaut) sur toute nouvelle installation de Windows Server, que ce soit en mode GUI (Graphical User Interface) ou en mode Core (Installation Minimale)

Le rôle ADDS vous permet de déployer un annuaire AD (Base de données AD : NTDS.dit) pour stocker et gérer de manière centralisée tous vos objets réseaux et sécurité : ordinateurs, utilisateurs, imprimantes, partages, GPOs…etc

Cet annuaire permet également de stocker et gérer les données relatives aux applications pouvant être intégrées dans un AD et l’interroger via LDAP.

A l’aide de GPOs (Group Policy Objects) de domaine, vous pouvez également centraliser la configuration, le paramétrage et la sécurisation de vos comptes utilisateurs et ordinateurs du réseaux.

ADDS représente la base (Backbone) d’un réseau Microsoft d’entreprise.

 

Azure Active Directory (Azure AD)

Azure Active Directory (aka AAD) est l’offre IDaaS (IDentity-as–a–Service) proposé par Microsoft Azure.

AAD est une solution (service Cloud mutualisé >> Mulit-Tenant) de gestion des identités et des accès pour les applications (principalement WEB) hébergées et exécutées dans le Cloud Azure mais aussi celles hébergées dans vos Datacenters OnPrem(ise).

Je vous invite à regarder la vidéo suivante pour en savoir plus sur Azure AD :

La documentation complète sur Azure Active Directory est disponible à cet URL.

Azure Active Directory Domain Services (Azure ADDS)

AADDS (Azure Active Directory Domain Services) est une offre PaaS (Platform-as-a–Service) de Microsoft Azure, cette offre est aussi connue sous le nom de DCaaS (DomainController-as-a–Service).

Azure AD DS est une instance (Forêt AD standalone) Windows Server Active Directory managée par Microsoft, cela veut dire que Microsoft créé, déploie, Manage et sécurise les Domain Controller pour vous.

Vous n’avez plus à vous soucier de la sécurité de vos Domain Controllers (Patch Management, Hardening, Monitoring, Sécurité Physique…etc).

Consultez cet article pour en savoir plus sur Azure Active Directory Domain Services.

Note importante : Le fait que MS manage les Domain Controllers à votre place présente certaines limitations que vous devez prendre en considérations, voir cet article pour en savoir plus : https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-comparison > Rubrique « Compare Azure ADDS to DIY AD« 

 

Mais quelle est la différence entre un annuaire AD (traditionnel), un Azure AD et une instance Azure ADDS ?

Nous allons tout d’abord voir la différence entre Windows ADDS et Azure AD, car il s’agit des deux items souvent confondus par les clients.

Pour commencer, il faut toujours garder à l’esprit qu’un Azure AD n’est pas une solution remplaçante ou équivalente d’Active Directory dans le Cloud.

Quand on parle d’Active Directory (AD), on pense généralement à :

• Forêt /Domaine (Root & Child) Active Directory
• Contrôleurs de domaine (DC : Domain Controller) hébergés chez vous généralement et sur lesquels vous avez Full Control (qu’ils soient physiques ou virtuels).
• Service d’annuaire qui a une structure hiérarchique basée sur X.500
• Annuaire pouvant stocker de multiple type d’objet : utilisateurs, ordinateurs, imprimantes, GPOs, Sites AD, Partages…
• Service DNS utilisé en tant que « Locator » de ressources réseaux (traduction d’@IP en Host et vice versa)
• Annuaire pouvant être interrogé à l’aide du protocole LDAP (Lightweight Directory Access Protocol) ou LDAPS
• Authentification via Kerberos/NTLM
• Organisation des objets à l’aide d’OU (Organitional Unit)
• Configuration des postes clients (Ordinateurs) et utilisateurs à l’aide de GPO (Group Policy Object)
• Relation d’approbation entre deux ou plusieurs forêts/Domaine AD si ces dernières ont besoin de discuter et partager des ressources entre elles.

 

Un Azure AD quant à lui est :

• Un service Cloud (IDaaS) : cela veut dire que Microsoft conçoit, déploie et gère toute l’infrastructure (mutualisée) hébergeant Azure AD. Et vous, en tant que « Cloud Customer », vous consommez et payer ce service de manière mensuelle (en fonction du nombre d’utilisateurs s’authentifiant à travers votre Azure AD).
• Authentifie les utilisateurs aux niveaux des applications hébergées dans Azure ou celles hébergées chez vous OnPrem, via l’utilisation du service Azure AD Application Proxy.
• L’authentification se fait via Internet : Azure AD s’appuie principalement sur une authentification over Internet (HTTP/80 ou HTTPS/433).
• L’authentification ne se limite pas aux devices connectés sur le réseau Corporate de l’Entreprise mais plutôt to Any Device (vu que la communication avec un Azure AD se fait à l’aide des protocoles HTTP ou HTTPS, il suffit d’avoir un device connecté à Internet pour pouvoir communiquer avec un Azure AD.
• Azure AD s’appuie quant à lui sur des protocoles dis « Modern Authentication Protocol » tels que OpenID Conncet /Oauth2 /SAML /WS-FEDERATION (Goodbye Kerberos & NTLM ^_^).
• Contrairement à un Active Directory, Azure AD peut être interrogé via une interface REST API, appelée AD Graph API
• Azure AD étant un service Cloud (IDentity-as-a-Service), vous n’avez pas la main sur l’infrastructure hébergeant cette solution IAM, il n’y pas de gestion de GPO possible, la création d’une structure d’OU n’est pas non plus disponible car il s’agit d’une structure Plate (Flat).
• Azure AD stocke et gère uniquement les objets « Users » et « Groups » : pas de GPO, pas de partage réseau, pas de sites AD…etc
• La manière dont les objets AD classiques (users, computers, partages, groupes….) sont stockés et gérés est complètement différente entre un AD et Azure AD :
  • AD : Structure Hiérarchique (Hierarchical Structure)
  • Azure AD : Structure plate (Flat Structure)

Les deux schémas suivants illustre les deux types de structures :

 

En ce qui concerne Azure ADDS, c’est ni plus ni moins qu’un Active Directory traditionnelle déployé et géré par Microsoft. Les mêmes caractéristiques liées à AD listées ci-haut s’appliquent également à un Azure ADDS, ce dernier s’appuie sur Kerberos/NTLM pour authentifier les utilisateurs du réseau, permet l’organisation des objets dans des OU et vous permet de créer et configurer des GPOs. Il existe tout de même certaines limitations relatives à un Azure ADDS :

• Contrairement à un AD, Azure ADDS ne vous permet pas d’établir/créer de relations d’approbation entre plusieurs instances Azure ADDS.
• Vous n’avez plus la main sur les comptes « Admins Entreprises » et « Admins du Schéma »
• Et enfin, l’extension du schéma AD n’est pas possible sur un domaine (Managé) Azure ADDS.

 

Ce qu’il faut retenir !

Ce qu’il faut garder en tête :

Windows Server Active Directory (ou Services de Domaine Active Directory, ou encore Windows ADDS) est un rôle natif dans les plateformes Windows Server (from Windows Server 2000 :)). ADDS authentifie les utilisateurs via les protocoles Kerberos (ou NTLM), vous permet de créer tout type d’objet dans l’AD et les stocker dans des OUs. Ces objets peuvent être gérés à l’aide de GPO (User ou Computer).

Azure Active Directory (ou Azure AD, ou encore AAD), est une offre IDaaS (IDentity-as-a-Service) de Microsoft Azure, qui vous permet d’authentifier vos utilisateurs sur les applications Cloud (ou locales via l’utilisation d’Azure AD Application Proxy). Il peut héberger uniquement des objets « Utilisateurs » et « Groupes ». Ces objets peuvent être directement créés dans Azure AD (Cloud Only mode) ou récupérés depuis votre AD local via une synchronisation AD to AAD à l’aide de l’outil Azure AD Connect (Synchro Mode). Azure AD est conçu pour les Apps/Services Web, il s’appuie sur les protocoles Web Modernes tels que SAML /WS-FEDERATION /OAuth2…etc.

Quand vous déployez un Azure AD, vous êtes considérés comme un « Tenant » > Client Cloud

Votre Azure AD étant « Trusted » par défaut avec plusieurs annuaires (comme ceux de Facebook, Google..etc), vous pouvez automatiquement accéder à d’autres services Web en utilisant le même compte Azure AD (SSO by default).
Pour finir, il faut considérer Azure AD comme un « Federation Hub » car vous pouvez à tout moment « Trust » un autre Azure AD (d’autres clients/partenaires) et accéder à leurs ressources (et vice versa) en rien de temps !

Azure Active Directory Domain Services (ou Azure ADDS ou encore AADDS) est une offre DCaaS (DC-as-a-Service) de Microsoft Azure. Cette plateforme représente votre infrastructure AD locale dans Azure, la différence réside dans le fait que c’est Microsoft (le Cloud Provider) qui créé, déploie, gère et sécurise les Contrôleurs de domaine pour vous. Il s’agit d’une instance « Standalone » d’une forêt AD isolée et déconnectée de votre réseau local. Si vous avez des contraintes de sécurité relatives à la réplication de votre AD local vers Azure (vers des DCs hébergés sous forme de VMs Azure), l’offre Azure ADDS peut être une solution à adopter pour créer rapidement une nouvelle forêt dédiée pour Azure, pour authentifier (via Kerberos/NTLM) vos utilisateurs/machines Windows hébergés dans Azure. Azure ADDS reste aussi le meilleur compromis (Sécu, Réduction de coût /Réduction des efforts liés aux MCO) quand il s’agit de migrer des plateformes/locales Apps « Legacy » vers Azure et donc faire du Lift-and-Shift (ou As-Is) Migration.

 

That’s All,

A bientôt :).

#HK

[Azure Scripting/Automation] HowTo #1 : Créer une Connexion VPN P2S (Point-to-Site) entre Azure et votre Machine d’Administration via Script Azure CLI 2.0

Note : cette Big-Picture est disponible en téléchargement ici.

Introduction

Si vous êtes amenés à déployer et administrer des VM IaaS dans Azure, il est fortement déconseillé d’établir des connexions Directes RDP & SSH (à travers Internet) sur celles-ci : il s’agit d’une « Bad Practice » /cas courant dans les entreprises !

Les VMs Azure disposant d’une interface Public (@IP Public) sont exposées à Internet et donc à plusieurs Security Risks liés aux protocoles RDP et SSH.

Quels « Best Practices » ?

La « Best Practice » consiste à utiliser une connexion VPN Site-to-Site (entre le VNET Azure et votre réseau local : canal sécurisé IPSec /IKEv2) ou Point-to-Site (entre le VNET Azure et votre Machine d’Administration : canal sécurisé SSTP/IKEv2).

Avec cette architecture, vous réduisez la surface d’attaque en supprimant l’interface Publique de vos VMs (utilisation d’une Private NIC Only).

L’objectif du présent post est de vous détailler (step-by-step) la procédure à suivre pour SetuPé et configurer une connexion VPN Point-to-Site entre votre environnement Azure et votre ou vos machines d’administration distantes.

Let’s do it 🙂

 

# OS Client supporté pour la connexion VPN Point-to-Site

Les Operating System (OS) suivants sont pris en charge pour la connexion VPN Point-to-Site :

• Windows :
  • Windows Client : Windows 7, 8, 8.1 et 10
  • Windows Server : Windows Server 2008, 2008 R2, 2012, 2012 R2 et 2016
• Mac OS X

 

#[Prérequis] Créez votre compte Azure

Pour mettre en pratique les différentes techniques expliquées dans le présent article, vous devez disposer d’un compte Azure. Vous pouvez en créer un gratuitement via ce lien.

Useful info : MS vous offre 200$ de crédit Azure pour tout nouveau compte créé. Cette offre est valable pendant 30 jours (Trial Mode).

 

#Utilisation de l’interface Azure CLI 2.0 vs Ouverture de Session Azure Cloud Shell

Les scripts/lignes de codes listées ci-dessous peuvent être exécutées depuis :

• Interface Azure CLI 2.0 (mode local)
• Azure Cloud Shell  (mode web)

Si vous souhaitez exécuter les lignes de codes ci-dessous localement depuis votre machine d’administration, je vous invite à installer l’interface Azure CLI 2.0 en suivant les instructions détaillées dans cet article.

Sinon, vous pouvez simplement vous connecter sur le site shell.azure.com, ouvrir directement une session Azure Cloud Shell exécutez les scripts décrits ci-dessous.

Console Azure Cloud Shell Web

Note : Azure Cloud Shell représente votre machine d’administration hébergée dans le Cloud Azure. Elle est accessible depuis n’importe ou et via n’importe quel device. Le Cloud Shell Azure est accessible depuis le Portail Azure (portal.azure.com), il peut également être accédé directement depuis l’URL shell.azure.com

 

#Créez votre connexion VPN Azure Point-to-Site

Pour créer une connexion VPN Point-to-Site (P2S), vous devez créer et configurer plusieurs objets/services Azure : Passerelle VPN Azure, Public @IP de la Gateway, Certificat pour l’authentification de vos clients VPN distants…

Voici les étapes à suivre pour créer et configurer correctement votre connexion VPN P2S.

1. Créer un nouveau groupe de ressource qui regroupera toutes les ressources Azure qui seront créées
2. Créer un nouveau VNET Azure
3. Créer/Déclarer le Gateway Subnet du VNET Azure créé
4. Créer une Nouvelle Passerelle VPN P2S (Point-to-Site)
5. Créer une nouvelle @IP Public pour la nouvelle Passerelle VPN
6. Créer/Générer un nouveau certificat Self-Signed (Auto-signé) pour authentifier les clients VPN Distants
7. Déclarer le contenu de la clé Public du Certificat Root sur la configuration VPN Point-to-Site

 

Note #1 : les étapes 1, 2 et 3 peuvent être by-passées si vous souhaitez configurer une connexion VPN P2S sur un VNET existant. Vous devriez dans ce cas changer les valeurs décrites ci-dessous par celles correspondant aux objets Azure existants (nom groupe de ressource, nom VNET, IP Address Prefix/CIDR…Etc)

Note #2 : si vous disposez d’une PKI sur le réseau local ou dans le Cloud, vous pouvez générer un certificat SSL signé/validé par votre CA et l’importer dans Azure. Dans notre cas, nous allons simplement utiliser un certificat Auto-Signé :).

 

Pour créer votre connexion VPN Azure P2S, exécutez les lignes de codes listées ci-dessous.

Notez que chaque bloc de code correspond à une des étapes décrite ci-haut.

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

#Etape1 :  Creation du ressource groupe
az group create -n hkdemorg -l WestEurope

#Etape2 : Creation du VNET
az network vnet create –name hkdemovnet –resource-group hkdemorg -l WestEurope –address-prefixes 10.110.0.0/16 –subnet-name hkdemosubbe –subnet-prefix 10.110.1.0/24 –ddos-protection false

#Etape3 : Creation du sous-reseau de la Passerell ‘Subnet Gateway’
az network vnet subnet create –address-prefix 10.110.254.0/24 –name GatewaySubnet –resource-group hkdemorg –vnet-name hkdemovnet

#Etape4 : Creation de l’adresse IP Public de la Gateway VPN
az network public-ip create –name hkdemovpngtwpip –allocation-method Dynamic –location westeurope –resource-group hkdemorg –sku Basic

#Etape5 : Creation de la Gateway VPN P2S
az network vnet-gateway create –name hkdemovpngtw -g hkdemorg –vnet hkdemovnet –public-ip-addresses hkdemovpngtwpip –location westeurope –gateway-type Vpn –sku VpnGw1 –vpn-type RouteBased –address-prefixes 172.116.1.0/24 –client-protocol SSTP

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

Plusieurs résultats vous sont retournés à la fin de l’exécution de chaque commande, cela vous permet de vérifier si les services Azure ont été créés correctement (ou pas : retour d’un ou plusieurs Error Messages).

Nous allons maintenant vérifier si tous les services Azure créés précédemment apparaissent depuis le Portail Azure.

Pour ce faire, connectez-vous sur Portal.azure.com et cliquez sur « Groupes de Ressources » ou « Resource Groups » si votre interface Web est en « Anglais ».

Notre Groupe de Ressource (hkdemorg) créé en « Etape 1 » doit apparaître sous « Groupe de ressources » :

Cliquez cette fois-ci sur le Groupe de Ressource hkdemorg pour visualiser toutes les ressources créées (VNET,  Passerelle VPN et son Adresse IP Publique associée) :

 

#Création du certificat Auto-Signé pour l’authentification des clients distants

Les Certificats sont utilisés par Azure pour authentifier les clients distants se connectant sur votre VNET Azure à travers la connexion VPN Point à Site.

Dès que vous aurez obtenu votre certificat (obtenu via votre PKI Enterprise ou un auto-signé), vous devez renseigner les informations relatives à sa clé Public au niveau de la configuration Point-to-Site Azure. Ce Certificat sera donc considéré comme étant « Trusted » pour toute connexion VPN P2S à votre VNET.

En outre, vous devez générer le certificat client à partir du Certificat Root de Confiance, vous l’installez ensuite sur chaque poste client devant s’authentifier/se connecter à travers le canal VPN P2S.

Maintenant que nous avons découvert à quoi servent les certificats dans une configuration VPN Azure, nous passerons à l’étape 6 qui consiste à créer/générer un certificat auto-signé Root pour l’authentification de nos postes clients VPN.

Pour générer ce certificat Auto-Signé, deux options s’offrent à vous :

• Utilisation de l’outil MakeCert.exe
• Utilisation de la Cmd-Let New-SelfSignedCertificate 

 

Note importante : l’outil MakeCert est considéré comme « Obsolète » et n’est plus recommandé par l’éditeur. Voir cet article pour en savoir plus

Nous allons donc utiliser la Cmd-let New-SelfSignedCertificate pour générer notre certificat

Commencez par ouvrir une Session Windows sur un Poste Windows 10, lancez ensuite PowerShell ISE en tant qu’Administrateur et exécutez les commandes suivantes :

#Etape6-Part1 : Creation du Certificat Auto-signe « Root »
$hkcert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject "CN=HKP2SRootCert" -KeyExportPolicy Exportable
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation « Cert:\CurrentUser\My » -KeyUsageProperty Sign -KeyUsage CertSign

#Etape6-Part2 :  Generation du certificat client
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature -Subject "CN=HKP2SChildCert" -KeyExportPolicy Exportable
-HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My"
-Signer $hkcert -TextExtension @(« 2.5.29.37={text}1.3.6.1.5.5.7.3.2 »)

Après exécution des commandes PowerShell ci-dessus, deux certificats sont générés au et stockés dans votre Magasin de certificats local (Certificats – Utilisateur Local):

• HKP2SRootCert : certificat Root (dont la clé Public doit être déclarée sur Azure)
• HKP2SChilfCert : certificat client (à installer sur chaque poste/client VPN).

Suivez les instructions suivantes pour exporter les deux certificats (Root & Child).

Export du Certificat Root, Pourquoi ?

Cette opération est importante car elle nous permettra de récupérer les informations sur la clé Public du Certificat Root pour les déclarer au niveau d’Azure (Config P2S) :

1. Saisissez CertMgr.msc depuis le Menu Démarrer et lancez l’outil retourné dans les résultats de recherche
2. La console « Certificats » apparaît. Développez « Personnel » > « Certificats« 
3. Faites un Clic-droit sur HKP2SRootCert > Toutes les Tâches > Exporter…
4. L’assistant suivant apparaît, cochez « Non, ne pas exporter la clé privée » et cliquez sur « Suivant » :

1. Cochez « X.509 encodé en base 64 (*.cer) » et cliquez sur « Suivant » pour continuer :

1. Cliquez sur « Parcourir… » et sélectionnez un emplacement dans lequel le certificat (.cer) sera placé (D:) dans l’exemple suivant) :

1. Enfin, cliquez sur « Terminer » pour fermer l’assistant:

 

Export du Certifica Child (Client), Pourquoi ?

Le certificat client doit être installé sur chaque machine cliente devant se connecter (via le VPN P2S) sur votre VNET Azure. La procédure décrite ci-dessous vous permettra de générer un fichier PFX (avec son mot de passe associé).

1. Saisissez CertMgr.msc depuis le Menu Démarrer et lancez l’outil retourné dans les résultats de recherche
2. La console « Certificats » apparaît. Développez « Personnel » > « Certificats« 
3. Faites un Clic-droit sur HKP2SChildCert > Toutes les Tâches > Exporter…
4. L’assistant suivant apparaît, cochez « Oui, exporter la clé privée » et cliquez sur « Suivant » :

1. Cochez « Echange d’informations personnelles – PKCS #12 (.PFX) » et cliquez sur « Suivant » pour continuer :

1. Cochez « Mot de passe« , spécifiez un mot de passe, sélectionnez AES256 comme algorithme de chiffrement et cliquez sur « Suivant » :

1. Choisissez un emplacement pour stocker votre fichier .Pfx et cliquez sur « Suivant » :

1. Enfin, cliquez sur « Terminer » pour fermer l’assistant :

Le fichier PFX doit être installé sur toutes les machines d’administration depuis lesquelles vous pouvez être amenés à vous connecter pour établir la connexion VPN P2S Azure.

 

#Déclarer le contenu de votre certificat Root sur Azure (Configuration Point-to-Site)

A l’aide de Notepad ou Notepad++, éditez le fichier .Cer (Certificat Root Exporté précédemment) et copiez le contenu de sa clé Public comme montré ci-dessous :

Ces informations doivent être déclarées côté Azure (Configuration Point-to-Site).

Pour ce faire, exécutez la commande Az CLI suivante :

Note importante : remplacez la valeur du paramètre « –public-cert-data » par le contenu du Cert Root que vous avez copié précédemment.

#Etape7 Declaration du Cert Root au niveau de la configuration Point-to-Site Azure
az network vnet-gateway root-cert create –resource-group hkdemorg –gateway-name hkdemovpngtw –name hkvpnp2scert –public-cert-data « MIIC6zCCAdOgAwIBAgIQN9CJJEC3KopF32cKXpvOLTANBgkqhkiG9w0BAQsFADAY
MRYwFAYDVQQDDA1IS1AyU1Jvb3RDZXJ0MB4XDTE4MDcyNzIwNDQyMFoXDTE5MDcy
NzIxMDQyMFowGDEWMBQGA1UEAwwNSEtQMlNSb290Q2VydDCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMHLP5DxRhA9nem2F2/nELeHLyjD+NSLl9NWjikO
I6fTF2gnl6+cmRfoFbuZmjl6ocS7h9g9bNatTDeN/AFQx1xyf7ZKp9nZryEM9VdC
HoaTGkMlmdiqmXmyHzxBH457s4spEvM4udCIrnCkczn8ocWX11ea96BF1ZaUJ6x7
t3o8V8FzvcVh/7zeoK8x+sQU/j8f6Qs20/prjFrrcZ7olI1C2R8eBZkBw1mEe1Nt
0txmd8lmkjWZJNi17V5C+SOxpWwuyZml/Hw186jNi4wvNXCg9nK3Wn0NLCfOkILN
oQIbvraz7yYWNBZLq/xKqSumGtF4aV0t9yL/0dRfENpkQD0CAwEAAaMxMC8wDgYD
VR0PAQH/BAQDAgIEMB0GA1UdDgQWBBQCR1tl1iycoP6oJDjKrWcRAh6+hTANBgkq
hkiG9w0BAQsFAAOCAQEABRpmIzysxcKEBrCm/EtgjOYoPaj5SlKD8wJhTk1BGXG0
OE9yLTeuIscmZygT1Wt20lAaWlJAqbRmuTkhXbbinttc+WOyWbqvWrAnsIbydVAP
DYqz0vOEfTIxROeAw+keorAc/jhmszBgLbkRAhJ9CDamutKtPGxNYq0lI9BAs46e
l109pxxz/6hDLGOJFNPXdZDWqceoxjtFhWnFNBMXj6Z/2NEIA3u474eI2hDoguRE
rz3NJ9qJyINrjf9ncg4Yc0/RlM3LaVhLjcLpCp31dkbfPXx1/3IqSusiiUUSFLHG
64XQ9jVxvozhkuUXqBbmKekCnOTfHPbIeHA5mcv9RA== »

#Téléchargez le Package « VPN Client »

Avant de télécharger le client VPN (Fichier .Exe), commencez par vérifier que la clé Public de votre certificat Root a bien été déclarée au niveau de la configuration Point-à-Site Azure.

Enfin, cliquez sur « Télécharger le client VPN » pour générer le client VPN à installer sur votre machine d’administration : il s’agit d’un .Exe qui configure automatiquement la connexion VPN avec toutes les informations que vous avez configurées tout au long de ce post.

Une fois téléchargé, Dé-zippez le fichier et exécutez le Setup File correspondant à la version de votre OS Client.
Dans mon cas, j’utilise une machine Windows 10 64-bit. Le fichier WIndowsAmd64\VpnClientSetupAmd64.exe a donc été exécuté :

Le Setup VPN Client installe et configure automatiquement la connexion VPN Suivante :

Cliquez sur le nom de la connexion (hkdemovnet) pour faire apparaître la boite de dialogue suivante :

Cliquez sur « Se connecter« , et ensuite sur « Connecter » pour établir la connexion VPN P2S :

Une fois connecté, le statut de la connexion passe à « Connecté« , vous pouvez également vérifier l’adresse IP qui vous a été attribuée depuis l’invite de commande > IPConfig /All et la comparer à celle qui apparaît depuis le volet « Configuration Point-à-Site »  :

Et voilà le tour est joué :).

N’hésitez pas à me laisser un commentaire si vous avez des questions.
A bientôt Dear Readers.

#HK

[Active Directory – Tip Of The Week] HowTo : Connaitre la date d’expiration du mot de passe de vos comptes users AD via PowerShell

AD Guys, Hello again 🙂

Si vous souhaitez connaître la date d’expiration des password de vos comptes users AD, eh bien pouvez simplement exécuter le code PS suivant :

Requirements

• Lancez Windows PowerShell en tant qu’Admin
• Exécutez les lignes de codes ci-dessous depuis un DC (not recommended) ou une machine d’administration ayant les outils RSAT installés et notamment le module PowerShell « ActiveDirectory » (recommended :)).

 

HowTo : connaitre la date d’expiration des mots de passes de vos comptes users AD

Get-ADUser -filter {Enabled -eq $True -and PasswordNeverExpires -eq $False} –Properties « DisplayName », « msDS-UserPasswordExpiryTimeComputed » | Select-Object -Property « Displayname »,@{Name= »ExpiryDate »;Expression={[datetime]::FromFileTime($_. »msDS-UserPasswordExpiryTimeComputed »)}}

Tip : si vous souhaitez trier les informations retournées par « Date la plus récente », exécutez la commande suivante :

Get-ADUser -filter {Enabled -eq $True -and PasswordNeverExpires -eq $False} –Properties « DisplayName », « msDS-UserPasswordExpiryTimeComputed » | Select-Object -Property « Displayname »,@{Name= »ExpiryDate »;Expression={[datetime]::FromFileTime($_. »msDS-UserPasswordExpiryTimeComputed »)}} | Sort ExpiryDate -Descending

Le résultat retourné par cette commande est affiché dans la screenshot ci-dessous :

[Azure Security] Introduction à Azure AD Password Protection et « Smart Lockout » : Désormais disponibles en ‘Public Preview’

 

Hi Folks,

Une very Powerful « Security » feature a été introduite/intégrée à Azure Active Directory (Azure AD).

Il s’agit d’Azure AD Password Protection, disponible en « Public Preview » au moment de la rédaction de cet article, cette fonctionnalité vous permet de définir une liste de mots de passe à bannir (Banned passwords) pour réduire tout risque lié à l’utilisation de « Weak Password », tels que MonPrenom2018$, MaSociete2018! ou encore Password2018$.

Azure AD Password Protection vous permet de :

1. Protéger les comptes utilisateurs hébergés au niveau de votre tenant Azure AD mais aussi dans votre infrastructure Active Directory (Locale/OnPrem) en empêchant les utilisateurs de sélectionner des mots de passe à partir d’une liste prédéfinie contenant plus de 500 mots de passes connus/communs proposés par MS.
2. Configurer et appliquer votre stratégie de Protection de mots de passe Azure AD pour votre tenant Azure AD ainsi que votre infra AD locale depuis une seule interface d’Admin : Portail Azure > Azure AD Blade
3. Personnaliser et configurer vos options de verrouillage de comptes utilisateurs : Smart Lockout
4. Spécifier une Liste de mots de passe « Personnalisés » à interdire : mot s de passe spécifiques à votre organisation.

 

Pourquoi auriez-vous besoin d’Azure AD Password Protection ?

Eh bien la réponse est simple : interdire l’utilisation de certains mots de passe !

En effet, plusieurs utilisateurs pensent utiliser des mots de passe « Forts » qui respectent la politique relative aux mots de passe (critères de complexité/longueur de mot de passe…), des mots de passe de type : P@$$w0rd, P@$$w0rd2018, ou encore P@$$W0RD2018!….etc,

Alors que c’est complètement faux !!

Les Hackers savent comment les utilisateurs réfléchissent voire devinent certains mots de passe, c’est la raison pour laquelle il faut toujours garder à l’esprit les trois règles suivantes :

Las Hackers :

• Savent comment les utilisateurs construisent leurs mots de passe : utilisation des caractères spéciaux tels que « $ » (à la place du S)
• Savent que si des règles de complexité de password sont mises en place, la plupart des utilisateurs vont construire leurs mots de passe de la même manière : PREMIERE LETTRE MAJUSCULE, utilisation d’un chiffre ou caractère spécial à la fin…etc
• Enfin, Les Hackers savent que les utilisateurs doivent changer leurs mots de passe de manière périodique, par conséquent, la plupart des utilisateurs ont tendance à garder une partie du mot de passe et changer deux ou trois caractères à la fin. eg : Remplacement du « MyP@$$w0rd2017! » par « MyP@$$w0rd2018! »

 

Note importante : Microsoft a publié une liste de « Best Practices » quant à l’utilisation des mots de passe [Password Guideline]. Je vous recommande la consultation de ce document.

 

L’application d’une stratégie de protection de mots de passe basée sur une liste de « Mots de passe Interdits » permet de répondre à cette contrainte de sécurité.

La fonctionnalité « Azure AD Password Protection », peut vous aider à réduire ce risque en appliquant une Password Policy sur vos environnements Cloud (users Azure AD) mais aussi pour vos infrastructures OnPremise.

 

Configurez votre stratégie AAD Password Protection & Smart Lockout en « Trois Clicks » !

La configuration de l’option de protection de mots de passe Azure AD ainsi que le Smart Lockout se fait en trois clicks. Voyons comment ça marche 🙂

Note importante: il faut savoir que par défaut, toutes les opérations de définition/changement/réinitialition de mots de passe associés aux comptes utilisateurs Azure AD Premium sont configurées pour utiliser l’Azure AD Password Protection. Cette option de protection s’appuie sur une liste de « Banned passwords » définie par défaut et maintenue par l’équipe Azure AD.

La bonne nouvelle c’est que vous avez toujours la possibilité de configurer une liste personnalisée de mots de passe « Interdits » au niveau de votre stratégie Azure AD Password Protection.

Pour ce faire, suivez les instructions suivantes.

 

#Step1 : Configurer la stratégie de protection de password pour votre Tenant Azure Active Directory

Connectez-vous sur le (New) portail Azure : https://portal.azure.com

Une fois authentifié, allez directement à :

Azure Active Directory > Sécurité > Méthodes d’authentification

Vous êtes automatiquement redirigé vers le Blade « GERER » > « Protection par mot de passe (Preview)« .

Sous « Mots de passe interdits personnalisés« , activez l’option « Appliquer la liste personnalisée » en cochant « Oui » et définissez la liste des mots de passe que vous souhaitez interdire au sein de votre tenant Azure AD.

Dans l’exemple suivant, plusieurs dizaines de mots de passes personnalisés « interdits » ont été ajoutés :

eg : HICHAM, Hicham, hicham, h!cham, h!ch@m, PARIS, Paris, paris, P@ris, P@r!s, p@ris, PASSWORD, Password, P@$$w0rd…etc

Note : ces mots de passe sont données juste à titre d’exemple !

Personnalisez donc votre liste de mots de passe et cliquez ensuite sur « Enregister » pour appliquer cette stratégie.

#Step2 : Configurer les options de vérrouillage (Smart Lockout)

Vous avez pu constater que depuis le même Blade, deux options relatives au Smart Lockout sont disponibles :

• Seul de verrouillage : nombre de tentatives échouées aboutissant à un Lockout du compte utilisateur AAD
• Durée du verrouillage en secondes : la durée pendant laquelle le compte reste verrouillé

Comme illustré dans la capture d’écran ci-dessous, mes best practices sont :

Seul de verrouillage : 5

Durée du verrouillage en secondes : 1800 (30 minutes)

Configurez ces options en fonction de vos standards/policies de sécurité et cliquez sur « Enregister » pour que ces modifications soient prises en comptes.

#Step3 : Etendre votre politique de protection de password à votre infrastructure Active Directory locale (OnPrem)

Enfin, sachez que la nouvelle feature Azure AD Password Protection peut également être configurée sur votre infrastructure AD traditionnelle (environnement OnPrem ADDS).

Il suffit de cliquer sur « Oui » au niveau de l’option « Activer la protection par mot de passe sur Windows Server Active Directory »

Notez que deux modes existent lors de la rédaction du présent article :

Mode « Activée /Enforced » : la stratégique est appliquée et poussée sur vos W(ritable) Domain Controller

Mode « Surveillance /Audit Only » : la stratégie est configurée en mode « Audit Only ». Si des mots interdits faisant parti de la liste personnalisée des mots de passe interdits est utilisé, cette information est journalisée et remontera dans les logs AD, ce qui vous permettra de suivre et monitorer l’utilisation des mots de passe par vos network users.

Une fois activées, les mêmes options configurées précédemment sont donc poussées sur votre AD Local, ce qui vous permet d’appliquer les mêmes Security Policies aussi bien sur votre environnement Cloud (Tenant Azure AD) que sur votre infra AD locale.

Notez qu’il existe un certain nombre de prérequis et notamment le déploiement d’un agent sur chaque (Writable) Domain Controller de votre domaine AD local (ou chaque DC de chaque Domaine AD si vous en avez plusieurs).

Cet agent est disponible en téléchargement gratuit ici.

Si l’extension de l’option « Azure AD Password Protection » sur votre environnement AD locale vous intéresse, je vous invite à consulter cet article pour en savoir plus.

[Active Directory – Tip Of The Week] HowTo : Connaitre la date de modification /changement du mot de passe de vos comptes utilisateurs AD via PowerShell

 

Comme vous le savez, Microsoft propose un module PS qui vous  permet de créer, gérer et administrer l’annuaire Active Directory (rôle ADDS) via Windows PowerShell : Il s’agit du module « ActiveDirectory « .

Pour obtenir la liste complète des Cmd-lets fournies avec ce module, exécutez la commande suivante :

Get-Command -Module ActiveDirectory

Pour connaître le nombre exact de Cmd-lets fournies avec le module ActiveDirectory, exécutez la commande suivante :

(Get-Command -Module ActiveDirectory).Count

Comme montré ci-dessus, 147 Cmd-lets au total (au moment de l’écriture de cet article) sont disponibles avec le module ActiveDirectory.

Aujourd’hui, nous allons uniquement nous intéresser à la Cmd-Let « Get-ADUser« .

Celle-ci sera utilisée pour :

Connaître la date de changement de mot de passe des utilisateurs de notre annuaire AD

Lister tous les comptes utilisateurs ayant un mot de passe qui n’expire jamais !

 

Introduction à la Cmd-let « Get-ADUser »

La Cmd-let « Get-ADUser » vous permet de lister un ou plusieurs (Objets) utilisateurs Active Directory.

A l’aide de certains paramètres Get-ADUser, vous pouvez réaliser des requêtes/opérations avancées sur des objets « Utilisateurs » ainsi que leurs propriétés.

Quelques exemples d’utilisation :

• Lister tous les utilisateurs qui ne sont pas connectés depuis 180 jours
• Lister tous les utilisateurs qui font parti du département « Marketing »
• Lister tous les utilisateurs qui ont un mot de passe qui n’expire « Jamais »
• Lister tous les comptes utilisateurs dont le mot de passe expire dans une semaine
• ..

Vous pouvez consulter cet article pour en savoir plus sur la Cmd-let Get-ADUser.

Paramètres associés avec la Cmd-Let « Get-ADUser »

Pour lister tous les paramètres et options disponibles avec la Cmd-Let Get-ADUser, je vous invite à exécuter la commande suivante :

help Get-ADUser

 

HowTo : connaitre la date de modification/changement du mot de passe de vos utilisateurs AD

Pour connaitre la date à laquelle un mot de passe a été changé/modifié, nous allons d’abord récupérer le nom de la propriété qui stocke cette information.

Pour ce faire, je vais dans l’exemple suivant exécuter la commande Get-ADUser -identity hicham.kadiri -properties * pour afficher toutes les propriétés de la Cmd-Let Get-ADUser (ou hicham.kadiri est le nom d’utilisateur de mon compte AD).

Comme illustré dans la capture d’écran précédente, la propriété qui stocke la date de changement du mot de passe est « PasswordLastSet« .

Dans l’exemple suivant, nous allons afficher la date à laquelle le mot de passe du compte utilisateur « hicham.kadiri » a été changé, seules les propriétés « Name » et « PasswordLastSet » sont sélectionnées :

Get-ADUser -identity hicham.kadiri  -Properties Name, PasswordLastSet | Select Name, PasswordLastSet

Pour obtenir la même information mais au niveau de votre domaine AD (tous les comptes utilisateurs du domaine), la commande suivante est exécutée :

Get-ADUser -Filter * -Properties Name, PasswordLastSet | Select Name, PasswordLastSet

Comme vous pouvez le conster, les informations (dates & heures) retournées au niveau de la colonne « PasswordLastSet » ne sont pas triées.

Si vous souhaitez trier ces données (du plus récent au plus ancien dans l’exemple suivant), la commande suivante est utilisée :

Get-ADUser -Filter * -Properties Name, PasswordLastSet | Select Name, PasswordLastSet | Sort PasswordLastSet -Descending

Tip : lister tous les comptes utilisateurs qui ont un mot de passe qui n’expire jamais peut également être utile car si vous avez défini une nouvelle stratégie de mot de passe (au niveau du domaine ou OU via une PSO/FGPP), celle-ci ne s’appliquera jamais sur les comptes utilisateurs ayant l’option « Le mot de passe n’expire jamais » cochée.

Nous allons dans l’exemple suivant lister tous les comptes utilisateurs dont le mot de passe n’expire jamais, et afficher uniquement les trois propriétés suivantes : Nom, PasswordLastSet et PasswordNeverExpires :

Get-ADUser -Filter * -Properties Name, PasswordLastSet, PasswordNeverExpires | Select Name, PasswordLastSet, PasswordNeverExpires | Sort PasswordLastSet -Descending

Enfin, si vous souhaitez exporter ces informations vers un fichier CSV pour les traiter/présenter plus tard, exécutez la commande suivante :

Get-ADUser -Filter * -Properties Name, PasswordLastSet, PasswordNeverExpires | Select Name, PasswordLastSet, PasswordNeverExpires | Sort PasswordLastSet -Descending | Export-csv C:\AuditAD.csv

[Active Directory – Tip of the Week] HowTo : Réinitialiser le mot de passe de restauration d’annuaire AD (DSRM)

HowTo : Réinitialiser le mot de passe DSRM de votre annuaire AD

Le mot de passe de restauration d’annuaire (DSRM : Directory Service Restore Mode)  est particulier. Il est utile dans les situations d’urgence et est rarement utilisé. Il n’est pas identique au mot de passe de l’administrateur du domaine et il peut être différent entre les contrôleurs de domaine. Il est important de mettre ce mot de passe en lieu sûr.

Si vous ne le connaissez pas, vous pouvez utiliser la procédure suivante pour le réinitialiser.
Ouvrez une invite de commande DOS (en tant qu’administrateur si la version est égale ou supérieure à Windows 2008) :

NTDSUtil
Set dsrm password
Reset password on server null
“Nouveau mot de passe”
”Confirmer le mot de passe”
Quit

 

Cet article vous a plu ?

Il s’agit d’un extrait de la Seconde Edition du livre « Active Directory 2016 – Déploiement et Administration en Entreprise ».

Disponible sur BecomeITExpert.com, cliquez sur l’image ci-dessous pour en savoir plus :

[Active Directory – Tool of the Week] 1# : Introduction à l’outil NTDSUtil.exe

Introduction 

« NtDSutil » est un outil de maintenance d’Active Directory et permet entre autres de :

• Nettoyer l’AD et les métadonnées : si un de vos contrôleurs de domaine devait tomber en panne ou que vous ayez un domaine orphelin, vous pouvez utiliser « NTDSUtil » pour nettoyer les métadonnées et supprimer les liens de réplication obsolète. A partir de Windows 2008, les métadonnées sont nettoyées lors de la suppression du compte ordinateur dans « utilisateurs et ordinateurs Active Directory » ou du « NTDSSettings » dans la console « Sites et Services Active Directory ».
• Déplacer vérifier ou défragmenter la base de l’annuaire (ntds.dit) : vous pouvez déplacer la base de données de l’annuaire sur un autre volume. La défragmentation n’est pas une opération que vous devez prévoir fréquemment si vous êtes dans une petite structure.

Note importante : Le déplacement avec « NTDSUtil » ne modifie pas le dossier « SYSVOL » contenant les stratégies de groupes, mais uniquement les fichiers de l’annuaire. La méthode recommandée pour déplacer « SYSVOL » est de rétrograder puis de réinstaller les services de domaine, même si vous trouverez facilement des articles qui expliquent comment effectuer un déplacement manuel.

• Transférer les rôles de maître d’opération (FSMO)

 

HowTo : Utiliser NTDSUtil

Nous allons voir au travers de quelques exemples, l’utilisation de NTDSUtil, comme par exemple déplacer les fichiers de l’annuaire. Pour ce type d’opération il est nécessaire que les services de l’annuaire soient arrêtés.

Pour arrêter les services, utilisez la console « services.msc » et recherchez le service « Service de domaine Active Directory ».

Faites un clic droit sur le nom du service, puis « Arrêter ».

La console vous propose d’arrêter automatiquement les services dépendants.

Pour déplacer la base de données de l’annuaire, ouvrez une « invite de commandes » en tant qu’administrateur sur le contrôleur de domaine et utilisez les commandes :

NTDSUtil

Activate instance NTDS

Files

Move db to D:\nouveau_dossier

Après le déplacement du fichier « NTDS.dit », vous pouvez déplacer les journaux de la base avec la commande :

Move logs to D:\nouveau_dossier

Pour vérifier l’intégrité de la base de données vous pouvez utiliser les commandes « checksum » et « integrity ».

Pour quitter « NTDSutil , saississez « quit » jusqu’à revenir au prompt.

Pour déplacer les rôles de maître d’opération (FSMO) avec « NtDsUtil », vous pouvez utiliser les commandes suivantes :

NTDSUtil

Roles

connections

connect to server “monserveur”

q

Ensuite vous pouvez transférer un ou plusieurs rôles avec les commandes :

transfer pdc

transfer RID master

Transfer infrastructure master

Transfer schema master

Transfer naming master

Si l’ancien contrôleur de domaine disposant du rôle n’est plus disponible, vous devez remplacer « transfer » par « seize » pour forcer la prise de rôle.

Une confirmation vous est demandée, cliquez sur « Oui ».

 

Cet article vous a plu ?

Il s’agit d’un extrait de la Seconde Edition du livre « Active Directory 2016 – Déploiement et Administration en Entreprise ».

Disponible sur BecomeITExpert.com, cliquez sur l’image ci-dessous pour en savoir plus :