L’accès privé Microsoft Entra apporte un accès conditionnel à la répertoire actif sur site

Les attaquants ciblent de plus en plus les ressources cloud, mais cela ne signifie pas qu’ils ne voient plus nos installations Active Directory sur site comme d’excellentes cibles pour avoir accès à nos réseaux. Les entités gouvernementales, par exemple, comptent souvent sur de nombreux serveurs sur site ainsi que sur des ordinateurs de bureau traditionnels qui font des cibles juteuses.

En conséquence, Microsoft a commencé à tester comment ajouter des capacités accrues de contrôle d’accès de Microsoft ENTRA aux systèmes sur site pour permettre aux organisations d’établir des options d’accès conditionnel et d’authentification multi-facteurs (MFA) pour ces ressources. Initialement, le déploiement incluait la prise en charge de la connexion à des ressources telles que les contrôleurs de domaine Active Directory à l’aide du cadre d’accès au réseau Zero Trust (ZTNA) d’identité d’identité (ZTNA).

En juillet, la documentation officielle de Microsoft comprenait des détails sur la configuration de ce que l’entreprise appelle «l’accès privé ENTRA pour les contrôleurs de domaine Active Directory», indiquant que ces fonctionnalités sont en version traditionnelle et disponibles pour une utilisation en production.

Il y a un obstacle majeur à surmonter avant de pouvoir déployer cette capacité: vous devrez vous assurer que votre réseau est sans NTLM et ne prend en charge que l’authentification de Kerberos avec vos contrôleurs de domaine. L’objectif de l’accès privé ENTRA est de remplacer les VPN hérités et les ressources internes Active Directory.

Préparer vos systèmes pour l’accès privé ENTRA

Alors que l’accès privé ENTRA est généralement disponible depuis novembre 2024, l’intégration et la documentation complète du contrôleur de domaine Active Directory n’ont été disponibles que le mois dernier.

Pour configurer le service, vous devez avoir le rôle mondial de l’administrateur d’accès sécurisé dans l’ID Microsoft ENTRA. Le produit nécessite également des licences, mais vous pouvez utiliser des licences d’essai pour tester le déploiement dans une preuve de concept.

Vous devez également vous assurer que les machines clients exécutent Windows 10 ou plus et qu’ils sont des appareils joints à Microsoft Entra ou hybrides. Les machines clients doivent également avoir une ligne de vue vers les ressources privées et le contrôleur de domaine. En d’autres termes, l’utilisateur doit être dans le réseau d’entreprise, accédant aux ressources locales.

Pour les règles du pare-feu, vous devez ouvrir le port TCP entrant 1337 dans le pare-feu Windows sur les contrôleurs de domaine. Vous devez également identifier les noms principaux de service (SPN) des applications privées que vous souhaitez protéger et les ajouter à la stratégie des capteurs d’accès privé installé sur les contrôleurs de domaine.

Microsoft recommande d’abord de tester cette fonctionnalité avec votre application privée. Vous pouvez appliquer MFA au contrôleur de domaine en utilisant le SPN de l’application privée, mais le faire à un stade ultérieur peut vous aider à éviter tout problème de verrouillage d’administration, rapporte Microsoft.

Comme pour de nombreux déploiements, les problèmes commencent souvent par le dépannage des différentes pièces nécessaires à l’installation. Je vous recommande de consulter les ressources du Global Secure Access Community Resources Hub et de créer une preuve de concept.

À l’heure actuelle, les clients qui peuvent être protégés comprennent Windows 10 et 11 et Android. Les fenêtres sur ARM, MACOS et iOS sont en avant-première pour le moment.

Mettre l’accès privé ENTRA au travail

Avant de pouvoir déployer ces paramètres de sécurité supplémentaires, vous devez être en bonne voie pour supprimer le NTLM de votre réseau. Vous devrez d’abord auditer votre environnement pour identifier où le NTLM est utilisé.

Pour ce faire, accédez à Computer Configuration Polities Windows Settings Security Settings Local Stratégies Options de sécurité.

Le niveau d’audit le plus profond, y compris les tentatives d’authentification des groupes de travail et du domaine qui utilisent NTLM, peuvent être réalisés par le réglage:

• Sécurité du réseau: restreindre le NTLM: trafic NTLM sortant vers des serveurs distants = Audit Tous
• Sécurité du réseau: restreindre NTLM: Audit Authentification NTLM dans ce domaine = Activer tout
• Sécurité du réseau: restreindre NTLM: Audit Trafic NTLM entrant = Activer l’audit pour tous les comptes

Notez que le réglage de «l’authentification NTLM d’audit dans ce domaine» doit être défini uniquement pour les contrôleurs de domaine. L’audit du «trafic NTLM sortant vers des serveurs distants» et «Audit le trafic NTLM entrant» devraient être définis sur tous les ordinateurs.

Asseyez-vous maintenant et passez en revue vos fichiers journaux situés dans l’événement Viewer (local) Applications and Services Journals Microsoft Windows NTLM Operational.

Identifiez les applications et les processus qui communiquent sur un protocole très précaire. Même si vous ne déploiez pas l’accès privé ENTRA, prenez le temps de l’audit de l’utilisation de NTLM dans votre réseau, car cela vous aidera également à défendre contre les attaques de ransomwares.

Une fois que vous avez identifié l’utilisation de NTLM dans vos applications et vos processus, vous voudrez bloquer NTLM V1 et commencer la transition pour appliquer et restreindre NTLM V2 en définissant la stratégie suivante:

• Accédez à Configuration de l’ordinateur> Politiques> Paramètres Windows> Paramètres de sécurité> Politiques locales> Options de sécurité.
• Trouvez la sécurité du réseau: niveau d’authentification LAN Manager et définissez-le pour envoyer uniquement la réponse NTLMV2. Refuser LM & NTLM. Cela applique l’utilisation de Kerberos et n’autorise que NTLMV2 comme une secours est absolument nécessaire.

Encore une fois, passez en revue les résultats et déterminez les applications et les segments de réseau affectés. Pour les applications profondément affectées, vous pouvez évaluer vos options, car certaines applications peuvent devoir être retirées ou mises à jour vers des versions plus récentes pour éliminer le NTLM.

Si vous ne dépendez plus de NTLM, vous pouvez bloquer en toute sécurité son utilisation dans le domaine.

Pour ce faire, dans le cadre de la stratégie de groupe, configurez la sécurité du réseau en sélectionnant les politiques: «restreindre NTLM: Authentification NTLM dans ce domaine». Vous pouvez choisir parmi «nier pour les comptes de domaine aux serveurs de domaine» pour «nier tout» pour le blocage total.

Pour toutes les applications de votre réseau, révisez pour vous assurer qu’elles ne sont pas codées en dur pour NTLM. Vérifiez spécifiquement les éléments suivants:

• Appels à la AcquireCredentialsHandle fonction qui passe dans la chaîne codée en dur ntlm – Remplacez ces instances par negotiate
• Appels à la RpcBindingSetAuthInfo Fonction – Remplacer RPC_C_AUTHN_DEFAULT avec RPC_C_AUTHN_GSS_NEGOTIATE.

La suppression de NTLM de votre réseau n’est pas impossible, mais cela peut être difficile. Prenez le temps et les ressources pour revoir vos options afin que vous puissiez ajouter plus de techniques de sécurité du cloud et les intégrer dans votre répertoire actif local.