I. Présentation

Dans ce tutoriel, nous allons découvrir le logiciel Specops Password Policy. Il va permettre de mettre en place des politiques de mots de passe très flexibles au niveau de l'Active Directory et d'accompagner les utilisateurs pour le renouvellement de leur mot de passe.

La mise en place d'une politique de mots de passe n'est jamais une tâche facile en entreprise. Bien souvent, les utilisateurs sont réticents à la mise en place de contraintes concernant les mots de passe. Pourtant, c'est indispensable, car les mots de passe sont continuellement pris pour cible lorsqu'il s'agit d'attaquer une entreprise. Ce fameux sésame est la clé qui ouvre la porte à une partie du système d'information. Pour lutter contre les attaques de type brute force et password spraying, il n'y a pas de secrets : il faut mettre des mesures de protection en place.

Nativement, l'Active Directory intègre la possibilité de mettre en place une politique de mots de passe pour les comptes des utilisateurs. Même si l'on peut mettre en place les stratégies de mots de passe affinées, cette solution native ne va pas assez loin en matière de sécurité des mots de passe et dans la gestion du renouvellement de ces mêmes mots de passe.

Quand je dis "cette solution native ne va pas assez loin en matière de sécurité des mots de passe", j'entends par là qu'il n'est pas possible d'interdire les mots de passe trop proches, et qu'il n'est pas possible de vérifier si le mot de passe saisi par l'utilisateur fait déjà l'objet d'une fuite de données (et que, potentiellement, il est déjà présent dans un dictionnaire).

Le logiciel payant Specops Password Policy va apporter des fonctionnalités que l'on peut résumer en trois points :

• Définir une politique de mots de passe sur mesure pour les utilisateurs (en s'appuyant sur un groupe de sécurité ou en ciblant une unité d'organisation) en appliquant de nombreuses règles
• Vérifier si le mot de passe est compromis : le mot de passe définit par l'utilisateur est un mot de passe qui est présent dans une fuite de données ou utilisé par des hackers et repéré par Specops grâce à des honeypots
• Notifier les utilisateurs par e-mail et/ou SMS : le mot de passe expire dans X jours ou le mot de passe a été trouvé dans une fuite de données

Avant de commencer, vous devez télécharger Specops Password Policy. En utilisant mon lien, vous pouvez obtenir une version d'essai de 45 jours (contre 30 jours en temps normal) : de quoi prendre le temps de découvrir le logiciel et d'avoir de premiers retours.

II. Installation de Specops Password Policy

L'installation de Specops Password Policy (SPP) s'effectue en plusieurs étapes. Pour cette démonstration, je vais utiliser 3 machines virtuelles pour reproduire l'installation selon les bonnes pratiques de l'éditeur :

• 1 serveur contrôleur de domaine Active Directory - SRV-ADDS-01
• 1 serveur membre Windows Server - SRV-APPLIS
• 1 poste de travail sous Windows 11

En résumé, je vais installer sur le contrôleur de domaine : les outils d'administration de SPP et le composant Sentinel qui doit être installé sur l'ensemble des contrôleurs de domaine. Sur le serveur membre, je vais installer également les outils d'administration de SPP ainsi que le composant Arbiter. Enfin, le poste de travail sous Windows est là pour tester le logiciel en se mettant dans la peau d'un utilisateur.

A. A quoi correspondent les rôles Sentinel et Arbiter ?

Les rôles Sentinel et Arbiter sont propres à Specops Password Policy, donc je vais vous expliquer l'utilité de ces deux composants.

Le rôle Sentinel s'installe sur tous les contrôleurs de domaine et il est là pour s'assurer que les politiques de mots de passe définies dans SPP sont bien respectées. En fait, lorsqu'un utilisateur va modifier son mot de passe il va l'analyser pour vérifier qu'il respecte bien la politique qui s'applique sur cet utilisateur.

Le rôle Arbiter sert de proxy (ou de passerelle si vous préférez) entre le contrôleur de domaine et les services Cloud de Specops. Il s'installe sur un serveur différent, car on considère que le contrôleur de domaine n'a pas d'accès à Internet. Grâce à une clé d'API, il va communiquer avec le service "Breached Password Protection API" de Specops pour vérifier si le nouveau mot de passe de l'utilisateur est présent dans une fuite de données, auquel cas il sera refusé.

Note : la vérification du mot de passe au travers de "Breached Password Protection API" s'effectue de façon sécurisée. Le mot de passe n'est pas envoyé entièrement pour requêter l'API puisque la requête est effectuée avec les quatre premiers caractères du mot de passe. Ensuite, l'API retourne les mots de passe correspondants s'il y en a, et c'est au niveau local que la vérification est effectuée.

B. Préparation du contrôleur de domaine

Au premier lancement, l'exécutable décompresse ses données dans le dossier "C:\Temp\SpecopsPasswordPolicy_Setup_7.6.21182.1", ce qui sera utile pour la suite, vous verrez. Il faut commencer par installer la console de gestion du logiciel, par l'intermédiaire du bouton "Administration Tools".

Ensuite, il faut cliquer sur le bouton "Add menu ext." puis sur le bouton "Install" pour installer les différents composants liés à la gestion du logiciel.

Ensuite, revenez au menu principal de l'installeur. Cliquez sur "Domain Controller Sentinel".

Sélectionnez tous les contrôleurs de domaine de votre infrastructure pour déployer l'agent partout. Pour ma part, il n'y en a qu'un seul. Une fois la sélection effectuée, il faut cliquer sur "Install".

Voilà, nous en avons fini avec le contrôleur de domaine pour le moment.

C. Préparation du serveur membre

À partir du serveur membre, qui s'appelle dans mon cas "SRV-APPLIS", je vais accéder aux sources d'installation située sur mon serveur SRV-ADDS-01.

\\SRV-ADDS-01\c$\Temp\

Ensuite, j'exécute l'assistant d'installation.

Cette fois-ci, je sélectionne le rôle "Specops Arbiter". Il est à noter que l'éditeur recommande d'installer au minimum deux serveurs avec le rôle Arbiter pour assurer la redondance. Que vous installiez un seul ou plusieurs serveurs Arbiter, le coût reste le même.

Cliquez sur le bouton "Install" et suivez l'assistant.

Comme sur l'autre serveur, installez la console en cliquant sur "Administration Tools", puis cliquez directement sur "Install".

Vous pouvez fermer l'assistant d'installation. Sur votre serveur, vous pouvez ouvrir la console "Specops Password Policy Domain Administration" pour commencer à configurer le logiciel.

Accédez à l'onglet "Domain Settings" : le message "The group has not been created, click Create" apparaît. Cliquez sur le bouton "Create" puis sur "OK". Cela va permettre de créer un groupe nommé "Specops Password Policy Custom Expiration Readers" dans l'Active Directory.

Ensuite, accédez à l'onglet "Breached Password Protection" afin d'enregistrer notre serveur Arbiter ("Register new Arbiter") auprès de l'API Breached Password Protection. Ce qui est indispensable pour utiliser cette fonctionnalité (que nous découvrirons par la suite).

Voilà, laissez la console de côté un instant, nous allons préparer le poste client. Ce sera fait et nous aurons plus à nous occuper de la partie installation.

D. Préparation du poste client

Sur les postes clients, il est recommandé de déployer un agent Specops. Pourquoi ? Cet agent est utile lors de la réinitialisation d'un mot de passe depuis le poste client. Il va permettre d'afficher à l'utilisateur les conditions à respecter pour définir son nouveau mot de passe. Sachez malgré tout que l'installation du logiciel sur les postes clients est facultatif (vous verrez par la suite l'intérêt de ce client).

Cet agent est disponible au format MSI, ce qui va permettre de le déployer facilement par GPO ou avec un logiciel de déploiement. Il est disponible en version 32 bits et 64 bits. La bonne nouvelle, c'est qu'il s'installe très facilement, sans configuration particulière.

Pour ma part, j'ai procédé à l'installation du package "Specops.Authentication.Client-x64.msi" sur une machine Windows 11.

Nous verrons dans la suite de ce tutoriel à quoi ressemble l'intégration au sein du poste client.

III. Création de sa première politique de mots de passe renforcée

Il est temps de créer notre première politique de mots de passe renforcée et surtout une politique sur mesure, que l'on va configurer aux petits oignons, comme on dit.

En haut à gauche, cliquez sur "Password policies". Ensuite, le logiciel va lister les politiques de mots de passe actuelles, y compris celle native de l'Active Directory. Pour notre part, nous allons créer une nouvelle politique : cliquez sur "Create new Password Policy".

Note : pour modifier une politique existante et créée avec Specops, il suffit de la sélectionner et de cliquer sur le bouton "Edit Policy".

Ensuite, la liste de vos GPOs s'affiche. Cliquez sur "New Group Policy object" pour créer une nouvelle GPO qui va utiliser l'extension Specops. Pour ma part, je nomme cette GPO "Password_Policy".

Pendant le processus de création de la GPO, il est nécessaire de sélectionner l'OU sur laquelle appliquer la GPO (et donc la politique de mots de passe). Tout en sachant que la politique s'applique sur les utilisateurs. Une alternative consiste à s'appuyer sur un groupe de sécurité pour appliquer les politiques du logiciel Specops, c'est au choix.

Note : la liaison de la GPO liée à Specops sur les OUs peut être effectuée à partir de la console standard de gestion des GPOs.

Ensuite, vous avez plusieurs choix pour créer votre politique :

• Custom : une politique sur mesure que vous personnalisez entièrement
• Microsoft recommendation : politique de mots de passe basée sur les recommandations de Microsoft
• NCSC recommendation : politique de mots de passe basée sur les recommandations du NCSC (National Cyber Security Centre, équivalent de l'ANSSI au Royaume-Uni
• NIST recommendation : politique de mots de passe basée sur les recommandations du NIST (National Institute of Standards and Technology, États unis)
• NSA recommendation : politique de mots de passe basée sur les recommandations de la NSA (National Security Agency, Etats-Unis)

Ce serait intéressant que l'ANSSI entre en contact avec Specops (ou l'inverse) pour intégrer les recommandations de l'ANSSI au logiciel. Ce serait une bonne évolution pour aiguiller les entreprises lors de la création d'une politique.

Pour notre part, nous allons choisir "Custom" pour voir les différentes options proposées par ce logiciel. Le fait d'utiliser une politique qui suit les recommandations permet de partir d'une base, mais vous pouvez ajuster la politique malgré tout.

Nous pouvons définir une politique de mots de passe et une politique de passphrase ("phrase secrète"), que l'on peut considérer comme des mots de passe constitués d'une suite de mots et avec une longueur plus importante que les mots de passe standards. Nous pouvons faire choisir les deux, c'est ce que nous allons faire : choisissez "Enable Both".

Commençons par le premier onglet "General Settings". Au sein de cet onglet, nous allons retrouver les paramètres globaux, notamment au sujet de l'historique des mots de passe.

Note : le message "The password policy is incompatible with the built-in domain password policy...." s'affiche si la politique que vous êtes en train de créer "est plus faible" que la politique de mots de passe intégrée à l'Active Directory. Dans ce cas, il faut ajuster la politique existante pour faire disparaître le message.

Pour être plus précis sur la partie historique des mots de passe :

L'option "Disallow incremental passwords" permet de désactiver l'incrémentation des mots de passe. Je m'explique : un utilisateur avec le mot de passe "Bonjour1" ne pourra pas définir "Bonjour2" ni "Bonjour5" comme mot de passe. Quant à l'option "Number of remembered passwords", elle permet d'indiquer le nombre de mots de passe mémorisés et sur lequel se base l'historique de mots de passe de l'utilisateur.

Il est déconseillé d'utiliser les options "Minimum number of changed characters" (Minimum de caractères différents entre l'ancien et le nouveau mot de passe) et "Disallow reusing part of current password" (Désactiver la réutilisation d'une partie du mot de passe actuel), car, bien qu'elle puisse sembler pertinente, elles nécessitent d'activer le chiffrement réversible au sein de l'Active Directory. Pour des raisons évidentes de sécurité, on évitera et on se contentera des comparaisons basées sur les hash.

Ce que j'aime bien au sein de l'interface de SPP, c'est le panneau d'aide sur la droite. En fait, lorsque l'on positionne la souris sur une option, il y a l'aide concernant cette option qui s'affiche sur la droite. C'est très pratique.

Passons à l'étape suivante : "Password Expiration". Elle va permettre de configurer la politique d'expiration des mots de passe et de paramétrer les notifications associées.

• Password expiration

En configurant la politique, on peut adopter la logique suivante : plus le mot de passe est long, plus l'utilisateur peut le conserver longtemps. Tout cela est ajustable et on crée des "niveaux d'expiration". Une bonne manière de motiver les utilisateurs pour qu'ils définissent un mot de passe plus long car en général ils n'aiment pas changer leur mot de passe.

Dans l'exemple ci-dessous, il y a trois niveaux d'expiration, mais on peut en créer plus que cela. Un utilisateur qui définit un mot de passe compris entre 10 et 14 caractères devra le changer au bout de 30 jours maximum, tandis qu'un utilisateur avec un mot de passe compris entre 15 et 19 caractères devra le changer au bout de 365 jours maximum.

• Password expiration notifications

Il est possible de notifier l'utilisateur que son mot de passe arrive à expiration. Cette notification s'effectue par e-mail et vous pouvez choisir combien de jours avant l'expiration du mot de passe vous souhaitez notifier l'utilisateur.

Pour les notifications, l'e-mail est entièrement personnalisable et vous pouvez inclure certaines variables. Ces valeurs dynamiques vont permettre d'intégrer le nom d'utilisateur, le nom d'affichage, l'adresse e-mail ou encore l'adresse e-mail du responsable (si c'est renseigné dans l'AD).

Passons à l'étape "Password Rules". Comme son nom l'indique, cette section va permettre de définir les règles pour les mots de passe, notamment la longueur, les types de caractères, etc.

L'option "Number of required character groups" sert à définir le nombre de types de caractères différents requis pour le mot de passe. Par exemple, si vous définissez "3", vous devez sélectionner au minimum trois types de caractères (la sélection s'effectue en dessous) et pour chaque type, vous pouvez indiquer le nombre minimal. Cela permet d'affiner très précisément.

Vous pouvez appliquer des restrictions au niveau du mot de passe : l'option "Disallow consecutive identical characters" égale à "3" empêche l'utilisation de 3 caractères identiques à la suite. Dans le même esprit, si l'on coche "Disallow full user name in password", l'utilisateur ne pourra pas utiliser son nom d'utilisateur dans le mot de passe.

Il est à noter la présence de la section "Use custom dictionaries". En cliquant sur le bouton "Manage", on a la possibilité de créer un nouveau dictionnaire ou d'en importer un existant.

Par exemple, si l'on crée un nouveau dictionnaire soi-même, il faudra saisir les mots à interdire. La chose que l'on peut faire, c'est indiquer le nom de son entreprise pour empêcher que le nom soit utilisé dans les mots de passe. Indispensable selon moi, car c'est très très courant !

En spécifiant "Connect" en référence à "IT-Connect", cela va bloquer "Connect", "CONNECT", mais aussi "connect" et même "C0nnect" (un zéro à la place du "o"). Le logiciel va prendre en charge les variantes pour renforcer l'interdiction.

Si votre entreprise dispose déjà d'un dictionnaire de mots à bloquer, il est possible de l'importer très facilement grâce à l'option "Import Password File".

Chaque dictionnaire est configurable, notamment pour bloquer les caractères de substitution lors de l'utilisation d'un mot du dictionnaire. Cela correspond à l'option "Character substitution (leet speak)".

Poursuivons la configuration sur notre lancée : rendez-vous dans l'onglet "Passphrase". Dans le cas où l'utilisateur souhaite définir un mot de passe très long, on parlera plus de passphrase. Dans ce cas, une stratégie différente peut s'appliquer afin de choisir la longueur, les types de caractères que vous souhaitez, etc.

Le logiciel va très loin puisque l'on peut créer ses propres règles pour les prérequis, en s'appuyant sur des expressions régulières (RegEx).

Par exemple, si l'on veut imposer une passphrase composée de 3 mots de 6 caractères séparés par un espace, on utilisera cette RegEx :

^\S{6,}\s+\S{6,}\s+\S{6,}$

De la même façon, on peut bloquer les mots identiques :

^(?!.*\b(\w+)\s\1\b).*$

Ainsi que l'utilisation de caractères consécutifs identiques :

^(?!.*(.)\1\1).*$

Ensuite, on peut tester ses règles, au fur et à mesure de préférence, via la zone de saisie "Sample Passphrase". Grâce à nos règles, un utilisateur ne pourra pas utiliser "111111 222222 333333" ni "111111 111111 22222" comme passphrase.

Terminons par la configuration de l'onglet "Breached Password Protection". Grâce à cette fonctionnalité (vendue en complément sous le nom de "Breached Password Protection"), le logiciel SPP va comparer les mots de passe définis par les utilisateurs avec les mots de passe contenus dans les fuites de données connues ou collectés par Specops. On parlera de "leaked password", sans oublier les mots de passe collectés par Specops via les serveurs honeypots. Pour effectuer cette comparaison, le logiciel s'appuie sur le hash des mots de passe, car il ne connaît pas le mot de passe des utilisateurs.

Cette section se découpe en deux zones :

• Express List : l'analyse est effectuée à partir de la base de mots de passe téléchargée en local (environ 5 Go) sur le serveur et qui contient environ 750 millions de mots de passe (mise à jour tous les deux mois).
• Complete API : l'analyse est effectuée via API sur la base de mots de passe hébergée en ligne et qui contient 2,5 milliards de mots de passe (mise à jour quotidienne). Par exemple, la base intègre les mots de passe présent dans la fuite de données qui a touchée Fortinet récemment.

Dans le cas où un mot de passe est trouvé dans une fuite de données, l'utilisateur sera averti afin qu'il puisse changer son mot de passe. Cette notification sera envoyée par e-mail, ou par SMS (gratuit/inclus). Le texte de la notification sera en français puisque c'est le message configuré dans Specops qui est repris.

Il y a une option qui permet de forcer la réinitialisation du mot de passe s'il est trouvé dans une fuite ("Continuously check for leaked passwords and force users to change them"). C'est intéressant, mais cela peut poser des problèmes de connexion aux utilisateurs en télétravail (notamment à cause du cache local des identifiants).

Comme je le disais, les notifications sont personnalisables au niveau du texte. Pour envoyer la notification par e-mail, le logiciel reprend l'adresse e-mail de l'utilisateur au niveau de l'Active Directory. Idem pour le numéro de téléphone afin d'envoyer le SMS (ce qui nécessite d'avoir un annuaire bien renseigné).

Nous sommes à la fin de l'assistant de création d'une nouvelle stratégie ! Cliquez sur "OK" pour sauvegarder et nous allons tester le bon fonctionnement de notre politique.

Comme vous avez pu le constater, l'interface de ce logiciel de chez Specops est en anglais, mais la bonne nouvelle c'est que les notifications sont en français. Pour la partie configuration en anglais, cela ne devrait pas vous effrayer en tant que sysadmin.

IV. Tester la politique Specops Password Policy

Avant de passer aux tests, je tenais à vous préciser que le contenu de la stratégie SPP est visible également à partir de l'Editeur de gestion des stratégies de groupe. Il suffit de modifier la GPO et d'accéder à l'emplacement suivant : Configuration utilisateur > Stratégies > Paramètres Windows > Specops Password Policy.

Faisons un test. On va réinitialiser le mot de passe de l'utilisateur "Guy Mauve" à partir du contrôleur de domaine. Bien sûr, la politique Specops que j'ai créée précédemment s'applique sur cet utilisateur. Il suffit de faire un clic droit sur le compte puis de cliquer sur "Réinitialiser le mot de passe". On saisit un mot de passe, par exemple "Connect123!".

On obtient alors une erreur, car le mot de passe ne respecte la politique. Si l'on regarde l'observateur d'événements du serveur (Journaux Windows > Application), on peut voir qu'il y a des événements générés par Specops Password Policy.

Cet échec de réinitialisation de mot de passe a créé un événement : "Password AdminReset for user 'GUY.MAUVE' rejected". Ensuite, on sait que notre mot de passe ne respecte pas les prérequis de la politique "Password_Policy" et en regardant le détail, on peut savoir quels sont les prérequis non respectés.

Si je recommence avec un mot de passe qui respecte tous les prérequis, cela va fonctionner bien entendu.

Maintenant, je vais basculer sur mon poste client où j'ai déployé le client Specops Password Policy... Je me connecte avec l'utilisateur "guy.mauve" et je décide de changer le mot de passe de ce compte (CTRL+ALT+SUPPR > Modifier un mot de passe).

Voici l'écran qui s'affiche :

Un panneau latéral indique quels sont les prérequis à respecter que ce soit pour le mot de passe ou la passphrase (phrase secrète). Lorsque l'utilisateur saisit son mot de passe, les prérequis changent d'état dynamiquement pour que l'utilisateur sache d'où vient le problème si le mot de passe n'est pas accepté.

Note : dans le cas où le client Specops Password Policy n'est pas installé sur le poste client, cela va fonctionner malgré tout. Cependant, le panneau latéral avec les indications ne s'affichera pas.

Dans le cas où l'utilisateur définit un mot de passe qui est repéré dans la base des mots de passe compromis, une notification est envoyée et un événement ajouté au journal (Observateur d'événements > Journaux des applications et des services > Specops).

Voici par exemple le SMS que j'ai reçu puisque c'est mon numéro qui est renseigné dans la fiche Active Directory de l'utilisateur "guy.mauve". Je vous rappelle que le message peut être défini en français, il suffit de modifier le texte de la notification au sein de la politique.

Quoi qu'il en soit, cette démonstration dans la peau d'un utilisateur permet de se rendre compte de l'utilité du client Specops Password Policy sur les postes et du système de notifications.

V. Analyse des résultats avec Specops Password Auditor

Après avoir mis en place Specops Password Policy, il est intéressant de relancer une nouvelle analyse avec Specops Password Auditor pour voir l'impact de cette nouvelle configuration. Si vous aviez de nombreux mots de passe vulnérables avant la mise en œuvre de SPP, les choses ont dû évoluer dans le bon sens désormais.

Si vous souhaitez découvrir Specops Password Auditor (logiciel gratuit), je vous invite à regarder ma vidéo à ce sujet.

Un logiciel que vous pouvez télécharger gratuitement via cette page : Télécharger Specops Password Auditor.

L'analyse effectuée par Specops Password Auditor suite à la mise en place de Specops Password Policy doit donner des résultats satisfaisants : pas d'utilisateurs sans mot de passe, pas de mots de passe compromis, etc.

Si l'on regarde la conformité de notre politique "Password_Policy" vis-à-vis des recommandations des différents organismes de sécurité, on peut voir qu'elle s'en sort bien également.

Avant de mettre en œuvre SPP, je vous recommande d'effectuer une analyse avec Specops Password Auditor afin de voir la valeur ajoutée de SPP après quelque temps d'utilisation.

Cette découverte de Specops Password Policy touche à sa fin ! N'hésitez pas à tester le logiciel de votre côté et à poster un commentaire si vous avez des questions.

Je vous laisse avec le lien de téléchargement qui vous permettra d'obtenir une version d'essai de 45 jours tout en sachant que le coût de la licence dépend du nombre d'utilisateurs à protéger avec Specops Password Policy :

Télécharger Specops Password Policy

The post Améliorez la gestion des mots de passe dans l’AD avec Specops Password Policy first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons voir comment fusionner un compte utilisateur de l'Active Directory local avec un compte utilisateur d'Office 365, en s'appuyant sur Azure AD Connect.

Prenons un cas classique : un tenant Office 365 d'un côté, avec des utilisateurs existants et actifs, créés directement dans le Cloud. Un annuaire Active Directory de l'autre, sur les serveurs de l'entreprise, avec des comptes pour les utilisateurs.

Et là, vous souhaitez mettre en place l'outil Azure AD Connect pour synchroniser les comptes de l'annuaire Active Directory on-premise avec Office 365. Une bonne idée puisque cela permet de synchroniser de nombreux attributs, dont le nom, le prénom, l'identifiant, l'e-mail, les alias ainsi que le mot de passe. Oui, mais comment procéder lorsque l'on a déjà les utilisateurs dans les deux annuaires et que l'on souhaite fusionner les comptes plutôt que de sacrifier les comptes de l'un des deux annuaires ? C'est ce que nous allons voir dans cet article.

II. Environnement et prérequis

Pour commencer, je vais décrire mon environnement et le point de départ de ce tutoriel pour éviter les ambiguïtés. Il peut y avoir plusieurs scénarios, d'où l'intérêt de préciser.

Je dispose de :

• Un tenant Office 365 pour le domaine it-connect.fr
• Un domaine Active Directory pour le domaine it-connect.local

L'outil Azure AD Connect est déjà installé et il est configuré de manière à synchroniser seulement certaines OUs de mon annuaire Active Directory local vers Office 365.

Pour le moment, les unités d'organisation à synchroniser sont vides ! Autrement dit, les utilisateurs à fusionner ne doivent pas être dans le périmètre des OUs synchronisées via Azure AD Connect (sauf si vous avez un filtre supplémentaire avec un groupe de sécurité).

Si vous avez besoin d'aide pour installer Azure AD Connect, suivez ce tutoriel : Installation d'Azure AD Connect.

L'objectif est de fusionner le compte Office 365 qui se nomme "[email protected]" avec le compte Active Directory de "[email protected]". Remarquez la subtilité entre le ".fr" et le ".local", c'est important.

Avant de pouvoir synchroniser ce compte dans le but de le fusionner, il va falloir effectuer quelques vérifications, voire modifications !

III. Fusion des comptes AD / Office 365 : les étapes

Pour que l'outil Azure AD Connect soit en mesure de faire la correspondance entre les deux comptes existants, et donc faire une fusion, il va comparer les attributs des objets. Comme l'explique Microsoft dans sa documentation, il y a trois attributs utilisés pour faire la correspondance entre des comptes existants : userPrincipalName, proxyAddresses et sourceAnchor/immutableID.

Il y a deux types de correspondances :

• Soft-match : correspondance basée sur les attributs userPrincipalName et proxyAddresses
• Hard-match : correspondance basée sur l'attribut sourceAnchor

Dans notre cas, nous allons miser sur le soft-match puisque la synchronisation sera nouvelle pour ces comptes : nous allons devoir traiter avec une grande attention les attributs userPrincipalName et proxyAddresses de notre utilisateur.

A. Mise à jour de l'attribut userPrincipalName

Nous devons avoir la même valeur pour l'attribut userPrincipalName (appelé UPN) aussi bien dans l'Active Directory que dans Office 365. Pour rappel, cet attribut correspond au nom d'utilisateur dans Office 365 (utilisé pour se connecter) et au "Nom d'ouverture de session de l'utilisateur" dans l'AD.

Pour récupérer la valeur userPrincipalName dans Office 365, on peut regarder dans les "Utilisateurs actifs", à partir du portail Web. Comme ceci :

Note : sur le portail Web, tout à droite de la ligne vous pouvez constater que l'utilisateur est bien de type "Dans le cloud" en regardant la valeur de la colonne "Etat de synchronisation".

On peut aussi procéder avec PowerShell via le module MSOnline (ou un autre module qui permet d'interroger la base de compte Azure AD).

On se connecte à son tenant :

Connect-MsolService

On recherche l'utilisateur, en précisant son nom pour le paramètre -SearchString, par exemple.

Get-MsolUser -All -SearchString "Office"

La console va retourner :

UserPrincipalName             DisplayName         isLicensed
-----------------             -----------         ----------
[email protected]    Florian Office 365  True

Cela confirme qu'au niveau d'Office 365, le userPrincipalName est bien "[email protected]".

Pour rappel, pour récupérer la liste de tous vos utilisateurs Office 365, il suffit de faire :

Get-MsolUser -All

Maintenant, l'idée c'est de reporter la valeur "[email protected]" dans l'Active Directory pour l'utilisateur correspondant.

Rendez-vous dans l'Active Directory... Dans les propriétés de l'utilisateur. Voici ce que j'ai au sein de l'onglet "Compte".

Mauvaise nouvelle : la valeur n'est pas bonne, car le domaine ne correspond pas. Il faut donc modifier le domaine @it-connect.local par @it-connect.fr. Si vous ne pouvez pas changer de domaine, vous devez déclarer un nouveau suffixe UPN correspondant à votre domaine de message.

• Ajouter un suffixe UPN à l'Active Directory

Ensuite, il suffit de modifier le compte Active Directory avec le bon domaine puisque la première partie de l'identifiant est correcte. Voici le résultat.

Note : si vos utilisateurs se connectent sur les postes avec le nom court (sans @domaine.local), ce changement n'aura pas d'impact. Par contre, un utilisateur qui se connecte sur un PC avec son UPN sera perturbé et vous devez l'avertir de ce changement.

Pour finir avant de passer à l'attribut proxyAddresses, voici comment effectuer les vérifications de l'UPN avec PowerShell (et le module Active Directory).

Get-ADUser -Identity <login>
Get-ADUser -Identity florian.o365

Cette commande retourne bien la valeur de l'UPN :

Pour le modifier en PowerShell, il faudra faire :

Set-ADUser -Identity "florian.o365" -UserPrincipalName "[email protected]"

Voilà, le tour est joué !

B. Mise à jour de l'attribut proxyAddresses

Le champ proxyAddresses est caché dans l'onglet "Editeur d'attributs" de chaque compte utilisateur de l'Active Directory. Parfois méconnu, il est pourtant très important ! Il sert à définir l'adresse e-mail principale d'un utilisateur, mais aussi ses éventuels alias de messagerie.

Dans un scénario comme celui-ci, il est fort possible que cette valeur soit vide, car il n'y avait pas d'intérêt à compléter ce champ. En tout cas, ça c'était avant, car maintenant nous en avons besoin.

Si l'on reprend le compte "[email protected]", on sait que l'adresse de messagerie de cet utilisateur est "[email protected]" (identique à l'UPN, mais ce n'est pas une obligation). On peut récupérer cette information via le portail Web, mais aussi en PowerShell :

Get-MsolUser -UserPrincipalName "[email protected]" | Ft userPrincipalName,proxyAddresses

ou

(Get-MsolUser -UserPrincipalName "[email protected]").proxyAddresses

Il va falloir que l'on injecte cette valeur dans l'attribut proxyAddresses, au niveau de l'AD. Rendez-vous dans les propriétés du compte : Editeur d'attributs (nécessite d'activer : Affichage > Fonctionnalités avancées dans le menu de la console) > proxyAddresses > Modifier.

Pour déclarer l'adresse e-mail principale du compte, il faut utiliser cette syntaxe :

SMTP:[email protected]

C'est important d'écrire "SMTP" en majuscules pour dire qu'il s'agit de l'e-mail principale. Si l'on écrit "smtp" en minuscules, cela sert à déclarer un alias. Pour la fusion, c'est bien l'adresse e-mail principale qui est utile.

Voici un exemple :

Comme tout à l'heure, on peut le faire en PowerShell. Lire la valeur actuelle :

Get-ADUser -Identity "florian.o365" -Properties proxyAddresses | Format-Table userPrincipalName,proxyAddresses

Injecter la nouvelle valeur pour cet attribut en écrasant une éventuelle valeur existante :

Set-ADUser -Identity "florian.o365" -Replace @{proxyAddresses="SMTP:[email protected]"}

Je vous recommande aussi de mettre à jour l'attribut "mail" qui contient l'adresse e-mail. En fait, cela facilite la configuration d'Outlook pour remonter l'adresse e-mail directement, c'est plus agréable pour l'utilisateur final.

Voici la commande PowerShell :

Set-ADUser -Identity "florian.o365" -EmailAddress "[email protected]"

Voilà, le compte de notre utilisateur est prêt ! Nous allons pouvoir le synchroniser pour qu'il soit fusionné avec le compte Office 365 !

C. Déclencher la fusion du compte utilisateur

Dernière étape du processus : la synchronisation qui doit donner lieu à la fusion. Avant de poursuive, lisez ce qui suit : les informations du compte de l'Active Directory local vont venir écraser les informations du compte côté Office 365 au moment de la fusion. Cela signifie que le mot de passe du compte AD local va devenir le mot de passe de l'utilisateur côté Office 365 également.

Si c'est OK pour vous, prenez le compte utilisateur dans l'AD et déplacez-le dans une OU qui est synchronisée avec Azure AD Connect. Une fois que c'est fait, rendez-vous sur le serveur où est installé Azure AD Connect pour forcer une synchronisation, cela évitera d'attendre :

Start-ADSyncSyncCycle -PolicyType Delta

Vous n'avez plus qu'à regarder sur le portail Web d'Office 365 pour voir ce que ça donne. Quand le compte sera fusionné, l'icône va changer : le petit nuage va laisser place à l'icône de synchronisation. Et comme ça fonctionne, c'est vous qui êtes sur un petit nuage.

Sans plus attendre, vérifiez les différentes valeurs pour voir si tout est bien conforme. Vérifiez également que la connexion au compte fonctionne : autant tout tester jusqu'au bout pour ce premier essai.

Si la correspondance n'est pas complète (UPN pas égaux, par exemple), la fusion pourra s'effectuer malgré tout, mais ce ne sera pas concluant. Par exemple, vous pouvez vous retrouver avec un nom d'utilisateur Office 365 qui prend le domaine "votre-domaine.onmicrosoft.com".

Avant d'effectuer la fusion sur un ou plusieurs comptes, je vous recommande fortement d'effectuer un essai avec un utilisateur de test pour valider le processus. Voilà, c'était le mot de la fin.

The post Comment fusionner un utilisateur de l’AD local avec un compte Office 365 ? first appeared on IT-Connect.

I. Présentation

Lorsque l'on travaille sur une infrastructure avec plusieurs domaines Active Directory, situés dans des forêts distinctes, mais liés par une relation d'approbation, on peut avoir besoin de configurer le routage d'un suffixe UPN entre ces domaines. C'est ce que nous allons voir dans ce tutoriel.

Prenons un exemple : un domaine A (it-connect.local) dans une forêt X et un domaine B (florian.local) dans une forêt Y, tous les deux connectés par une relation d'approbation bidirectionnelle. Ainsi, un utilisateur du domaine A peut se connecter sur une machine du domaine B, et inversement.

Oui, mais voilà, dans le domaine A, on aime bien se connecter sur les postes avec son UPN qui utilise un domaine différent : "it-connect.fr", qui est un alias du suffixe UPN principal. De ce fait, l'utilisateur-1 se connecte avec "[email protected]", qui est son UPN au niveau de l'objet AD, et non "[email protected]".

Problème : l'ouverture de session fonctionne sur un poste du domaine A, mais pas sur un poste du domaine B, malgré la présence de la relation d'approbation. Pourtant, l'utilisateur peut ouvrir une session en spécifiant le nom court (NETBIOS) du domaine : ITCONNECT\utilisateur-1. Que faire ? La réponse dans la suite de ce tutoriel...

• Comment ajouter un suffixe UPN dans l'Active Directory ?

II. Active Directory - Configurer le routage d'un suffixe UPN

Pour effectuer la configuration, il faut se connecter sur le contrôleur de domaine de florian.local (là où l'on souhaite se connecter avec un UPN spécifique du domaine approuvé).

Ensuite, il faut ouvrir la console "Domaines et approbations Active Directory". Effectuez un clic droit sur le nom du domaine, pour ma part "florian.local" et cliquez sur "Propriétés".

Accédez à l'onglet "Approbations", et dans la liste des domaines, choisissez le second domaine. Si vous avez plusieurs relations d'approbations, à vous de faire le bon choix. Pour ma part, ce sera "it-connect.local" bien entendu.

Note : que vous sélectionniez le domaine dans les approbations sortantes ou les approbations entrantes, cela n'a pas d'importance, il faut faire qu'une seule fois la manipulation.

Cliquez ensuite sur "Propriétés" : une seconde fenêtre va s'afficher. Accédez à l'onglet "Routage des suffixes de noms" et vous devriez voir tous les suffixes UPN du domaine. Pour ma part, je vois bien "it-connect.local", avec le routage déjà actif et "it-connect.fr" avec le routage désactivé. Il suffit de cliquer sur l'UPN dans la liste puis de cliquer sur le bouton "Activer".

Il ne reste plus qu'à valider pour que la configuration soit prise en compte. Il n'y a rien de plus à faire, si ce n'est d'aller sur un poste de travail et d'effectuer un test de connexion. Cette fois-ci, depuis le domaine "florian.local", je peux me connecter en indiquant "[email protected]".

La manipulation en elle-même est simple, mais il faut savoir où chercher !

The post Active Directory – comment router un suffixe UPN entre plusieurs domaines ? first appeared on IT-Connect.

GPOZaurr and other tools help you with consolidation in the short-to-medium term, but as you move forward, there are other changes you can make that will make things much simpler and easier to manage. To make a significant difference to these user KPIs, there are two areas that must be concentrated on—folder redirection and loopback policy processing. This is my third post in my series about Group Policy consolidation.

The post Consolidating Group Policy, part 3: Loopback policy processing and folder redirection first appeared on 4sysops.

When a new domain controller (DC) is installed remotely, the initial replication traffic for synchronizing all directory objects can be significant. However, bandwidth can still be limited for businesses maintaining remote locations. Using the "install from media" (IFM) option significantly reduces the amount of data replicated after setting up a new DC.

The post Install a secondary domain controller using Install from Media (IFM) first appeared on 4sysops.

GPOZaurr from Evotec IT is a PowerShell module that is very useful for consolidating and managing Group Policy. In this post, I will demonstrate how you can use GPOZaurr to create Group Policy reports and deal with broken, disabled, invalid, or inapplicable GPOs. This is the second post in my series about Group Policy consolidation.

The post Consolidating Group Policy, part 2: GPOZaurr first appeared on 4sysops.

Chromium-based Edge has been part of Windows 10 since 20H2. Internet Explorer (IE) is still on board, but its support ends in June 2022. If you want to replace it with a managed Edge, you will have to deal with tasks such as configuring GPOs and updates or redirecting legacy websites to IE.

The post Migration from Internet Explorer to Microsoft Edge: Managing GPOs, security baselines, updates, and compatibility first appeared on 4sysops.

Each Windows PC contains its own set of administrative templates for group policies. However, they can be better managed in a central location. This is all the more true when ADMX files are added for several applications. Updating templates in the Group Policy Central Store can be tricky, though.

The post Create and update the Group Policy Central Store for ADMX templates first appeared on 4sysops.

Businesses need to migrate from the deprecated SHA-1 to SHA-2 to bolster their cybersecurity posture. They may still be running Active Directory Certificate Services (AD CS) using the SHA-1 cryptographic hash, along with the weaker Cryptographic Service Provider (CSP). In my previous post I discussed considerations when migrating AD certificate services to SHA-2. Let's look at how to replace them with SHA-2 and Key Storage Provider (KSP).

The post How to migrate Active Directory Certificate Services to SHA-2 and Key Storage Provider first appeared on 4sysops.

Une nouvelle attaque connue sous le nom de PetitPotam fait parler d'elle ces derniers jours. Cette attaque exploite la méthode de relais NTLM et permet à un attaquant de voler des identifiants Windows, ce qui peut lui permettre de prendre le contrôle d'un domaine Active Directory.

Le mois dernier, le chercheur en sécurité français Lionel GILLES, alias Topotam, a découvert une nouvelle attaque qui cible les machines Windows. Baptisée PetitPotam, cette attaque permet de forcer une machine Windows à s'authentifier sur un serveur malveillant qui joue le rôle de relais NTLM, en s'appuyant sur le protocole Microsoft Encrypting File System Remote (EFSRPC) . Cette attaque fonctionne également sur les contrôleurs de domaine, ce qui la rend particulièrement dangereuse.

Le serveur NTLM relais va rediriger la requête d'authentification et jouer le rôle d'intermédiaire, ce qui lui permet de récupérer des informations d'authentification, et au final de réaliser un dump des identifiants et de prendre le contrôle du domaine Active Directory.

Vous êtes vulnérable à l'attaque PetitPotam si vous utilisez un serveur avec le rôle ADCS (Active Directory Certificate Services), qui permet d'avoir une autorité de certification d'entreprise, avec l'un des deux rôles suivants :

• Certificate Authority Web Enrollment
• Certificate Enrollment Web Service

Concrètement, l'attaque PetitPotam tire profit d'un serveur ADCS qui ne serait pas bien configuré pour vous protéger contre les attaques basées sur l'utilisation d'un serveur relais NTLM.

Microsoft a publié sur son site Internet des informations pour vous expliquer comment configurer le serveur IIS de votre serveur ADCS pour vous protéger. La méthode décrite par Microsoft consiste à activer des fonctions pour renforcer l'authentification, notamment l'EPA (Extended Protection for Authentication), et l'obligation d'utiliser des connexions HTTPS.

Plutôt que d'appliquer cette configuration proposée par Microsoft, des chercheurs en sécurité ont trouvé une autre méthode qui consiste à appliquer un filtre au niveau de la machine, via netsh. Le chercheur en sécurité Craig Kirby explique que ce filtre netsh rpc bloque l'accès à distance à l'API MS-EFSRPC.

De son côté, Benjamin Delpy, le créateur de Mimikatz, explique comment mettre en place ce filtre, voici les instructions à appliquer sur votre serveur ADCS.

1 - Créer un fichier nommé "block_efsr.txt" (ou autre) et insérer le contenu suivant :

rpc
filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quit

2 - Enregistrer le fichier sur le Bureau de votre session

3 - Importer les règles netsh à partir du fichier créé précédemment :

netsh -f %userprofile%\desktop\block_efsr.txt

4 - Vérifier que les filtres sont bien importés avec la commande suivante :

netsh rpc filter show filter

Concrètement, voici le nom des deux filtres créés : c681d488-d850-11d0-8c52-00c04fd90f7e et df1941c5-fe89-4e79-bf10-463657acf44d. Grâce à eux, le vecteur d'attaque de PetitPotam est bloqué et le serveur relais NTLM malveillant ne pourra plus tromper vos machines.

Pour finir, je tiens à préciser que cette vulnérabilité affecte toutes les versions de Windows Server, y compris lorsque le serveur est installé en mode core.

[Mise à jour du 12 août 2021]

Suite à la publication du Patch Tuesday d'août 2021, Microsoft a intégré un patch de sécurité pour empêcher l'exploitation de la vulnérabilité PetitPotam. Ce correctif est intégré directement au sein du patch cumulatif d'août 2021.

Plus d'informations sur cette page : Microsoft - PetitPotam

Source

The post Windows – ADCS : comment bloquer les attaques PetitPotam ? first appeared on IT-Connect.

Since Windows 10 1909, Microsoft has displayed a widget in the taskbar that shows content from MSN, such as weather or stock quotes. These "news and interests" are probably not required or desired in most professional environments. They can be deactivated via Group Policy.

The post Deactivate Windows 10 widget "News and interests" with Group Policy first appeared on 4sysops.

The use of unencrypted LDAP poses a risk. It allows attackers to exploit a vulnerability to gain elevated privileges. These, in turn, can be used for man-in-the-middle attacks. Several LDAP settings can help admins protect their systems against these threats.

The post Secure domain controllers with LDAP channel binding and LDAP signing first appeared on 4sysops.

As businesses look at phasing out legacy Windows Server versions, core services may need to be moved or migrated to new Windows Server versions. One service you may need to move is Active Directory Certificate Services (AD CS). Let's see how to migrate AD CS from Windows Server 2008 R2 to 2019.

The post Migrate AD certificate services to a new server first appeared on 4sysops.

D'après Gartner, d’ici à 2024, 50 % des organisations qui auront implémenté un modèle d'accès à privilèges éliminant les privilèges non définis éviteront 80 % des failles de sécurité par rapport à celles qui ne sont pas équipées en outil de gestion des accès à privilèges. Ces derniers sont en effet de plus en plus ciblés par les cybercriminels, qui se contentent rarement de leur ancrage initial une fois dans le réseau.

The post Cybersécurité : comprendre le déplacement latéral et l’escalade des privilèges first appeared on UnderNews.

Microsoft's Conditional Access is an Azure Active Directory (AAD) feature that increases security with remote and "work from anywhere" employees. Businesses can restrict access to cloud resources depending on the conditions of a remote worker's connection. This article will show you how to define such policies.

The post Conditional Access: Create policies to secure cloud resources using AAD authentication first appeared on 4sysops.