Microsoft vient de publier une nouvelle version (1.0.5.10) du pack d’administration ou Management Pack (MP) pour Microsoft Azure Stack Hub. Ce Management Pack vient remplacer les précédents pour Windows Azure. System Center Operations Manager (SCOM) fait partie de la gamme System Center, il propose une supervision souple et évolutive de l’exploitation au niveau de toute l’entreprise, réduisant la complexité liée à l’administration d’un environnement informatique, et diminuant ainsi le coût d’exploitation. Ce logiciel permet une gestion complète des événements, des contrôles proactifs et des alertes, et assure une gestion des services de bout en bout. Il établit des analyses de tendance et des rapports, et contient une base de connaissances sur les applications et le système.

Cette version apporte les éléments suivants :

• Support d'une nouvelle version de l'API de sauvegarde (la nouvelle version prise en charge est le 2018-09-01)
• Support d'une nouvelle version de l'API de performance de stockage (la nouvelle version prise en charge est le 2018-01-01)
• Mise en œuvre du tableau de bord des performances de stockage des pages Blob
• Ajout du support pour TLS 1.2.

Ce management pack fournit les fonctionnalités suivantes :

• Supervision de la disponibilité de l’infrastructure Azure Stack
• Découverte à distance et collecte des informations comme les déploiements, les régions, et les alertes.

Notez que ce Management Pack nécessite System Center 2012 R2 Operations Manager ou ultérieur

Télécharger System Center Management Pack for Microsoft Azure Stack

Microsoft vient de publier un nouveau pack d’administration ou Management Pack (MP) (1.8.0.2) pour Microsoft Azure. Pour rappel, System Center Operations Manager (SCOM) fait partie de la gamme System Center, il propose une supervision souple et évolutive de l’exploitation au niveau de toute l’entreprise, réduisant la complexité liée à l’administration d’un environnement informatique, et diminuant ainsi le coût d’exploitation. Ce logiciel permet une gestion complète des événements, des contrôles proactifs et des alertes, et assure une gestion des services de bout en bout. Il établit des analyses de tendance et des rapports, et contient une base de connaissances sur les applications et le système.

La mise à jour est supportée depuis les versions v1.6.0.7, v1.7.0.0 et v1.8.0.1.

Ce management pack fournit les fonctionnalités suivantes :

• Découverte des services : Application Insights, Automation, Backup, Biztalk, Cloud Service, Data Factory, DocumentDB, Logic App, Media Services, Mobile Services, Networks, Notification Hubs, Operational Insights, Redis Cache, SCheduler, Search, Service Bus, SQL Azure, Storage Accounts, Traffic Manager, Virtual Machines, et Websites
• Collecte de performance pour : Cloud Services, Data Factory, DocumentDB, Mobile Services, Redis Cache, SQL Azure, Virtual Machines, Websites

Cette version comprend :

• H5Dashboard - De nouveaux tableaux de bord HTML5 sont créés pour Azure MP afin de faciliter le filtrage et la navigation dans la console Web. Plus d’informations sur : SCOM Management pack for Azure gets new dashboards !
• Changement de la sévérité des alertes : Changement de l'état d'alerte et de l'état de santé en fonction de la gravité de l'alerte Azure
• Corrections de bugs :
  • Échec du test AzureMP-Web dans SCOM - App Insights
  • Fermeture des alertes SQR et Activity Log depuis la console SCOM

 

Notez que ce pack d’administration nécessite System Center 2012 Service Pack 1 (SP1) – Operations Manager, System Center 2012 R2 Operations Manager, System Center 2016 Operations Manager ou System Center 2019 Operations Manager

Télécharger Microsoft System Center Management Pack for Microsoft Azure

A l’heure du télétravail et de la crise du COVID-19, Microsoft a tenu un webcast à destination des professionnels de l’informatique sur la configuration et la sécurisation des périphériques iOS, Android et Windows personnels.

La vidéo revient sur les grands concepts :

• Gestion des périphériques mobiles (MDM)
  • Les différents modes de gestion sur iOS (User Enrollment, Device Enrollment, Automated Device Enrollment)
  • Les différents modes de gestion sur Android (Work Profile, Device Owner, etc.)
• Gestion des applications mobiles (MAM)
• Stratégies de protection applicatives (APP)
• Windows Information Protection

Voir la vidéo et obtenir plus d’informations

L'un des principaux avantages d’Azure AD Password Protection est d’aider à se défendre contre les attaques par pulvérisation de mots de passe (password spray). La plupart des attaques par pulvérisation de mots de passe ne tentent pas d'attaquer un compte individuel plus d'une fois, car un tel comportement augmente considérablement la probabilité de détection, que ce soit par verrouillage de compte ou d'autres moyens. La majorité des attaques par pulvérisation de mots de passe reposent donc sur la soumission d'un petit nombre seulement des mots de passe les plus faibles connus pour chacun des comptes d'une entreprise. Cette technique permet à l'attaquant de rechercher rapidement un compte facilement compromis tout en évitant les seuils de détection potentiels.

Azure AD Password Protection est conçu pour bloquer efficacement tous les mots de passe faibles connus qui sont susceptibles d'être utilisés lors d'attaques par pulvérisation de mots de passe, selon la base des données de télémétrie de sécurité d’Azure AD. Microsoft est au courant de sites Web tiers qui énumèrent des millions de mots de passe qui ont été compromis lors de failles de sécurité connues du public. Les produits de validation de mots de passe de tierces sont basés sur une comparaison brute par rapport à ces millions de mots de passe. Microsoft estime que de telles techniques ne sont pas le meilleur moyen d'améliorer la force globale des mots de passe étant donné les stratégies typiques utilisées par les attaquants par pulvérisation de mots de passe.

Azure AD Password Protection peut être utilisé à la fois dans Azure Active Directory mais aussi sur l’annuaire Active Directory On-Premises.

Présentation des composants

Le diagramme suivant montre comment les composants de base de la protection par mot de passe Azure AD opèrent ensemble dans un environnement Active Directory local.

 

(source : docs.microsoft.com)

 

La solution regroupe plusieurs éléments :

• Les contrôleurs de domaine en lecture/écriture qui comporte l’agent du service Azure AD Password Protection où sont écrits les stratégies de mot de passe et éventuellement répliquées aux autres contrôleurs de domaine.  C’est aussi l’agent DC qui valide les mots de passe lors des demandes de changement effectués par les utilisateurs ou administrateurs.
• Les serveurs hébergeant le proxy du service Azure AD Password Protection qui font le lien entre les contrôleurs de domaine et le service Azure AD Password Protection de manière à récupérer les stratégies de protection de mot de passe. Choisissez un ou plusieurs serveurs pour héberger le service proxy de protection par mot de passe. Chacun de ces services fournit uniquement des stratégies de mot de passe pour une forêt unique. La machine hôte doit être jointe à un domaine dans cette forêt. Les domaines racine et enfant sont tous deux pris en charge. Une connectivité réseau est nécessaire entre au moins un contrôleur de domaine dans chaque domaine de la forêt et la machine de protection de mot de passe.

 

Il n’y a pas de limitations pour gérer plusieurs forêts. Chaque forêt est configurée indépendamment comme décrit dans cet article. Chaque proxy de protection par mot de passe ne peut prendre en charge que les contrôleurs de domaine de la forêt à laquelle il est relié. Vous devez donc installer un proxy par forêt.

 

D’un point de vue sécurité, la solution répond aux grands concepts de préservation de la sécurité et de la vie privée :

• Les contrôleurs de domaine n'ont jamais à communiquer directement avec Internet.
• Aucun nouveau port réseau n'est ouvert sur les contrôleurs de domaine.
• Aucune modification de schéma Active Directory n'est nécessaire. Le service utilise le conteneur Active Directory existant et les objets de schéma serviceConnectionPoint.
• Aucun changement du niveau fonctionnel de forêt ou de domaine n'est requis.
• Le service ne crée ni n'exige de comptes dans les domaines Active Directory qu'il protège.
• Les mots de passe en texte clair de l'utilisateur ne quittent jamais le contrôleur de domaine, que ce soit pendant les opérations de validation du mot de passe ou à tout autre moment.
• Le service ne dépend pas d'autres fonctions d'Azure AD ; par exemple, la synchronisation du hachage du mot de passe d'Azure AD n'est pas liée et n'est pas nécessaire pour que la protection par mot de passe Azure AD fonctionne.
• Le déploiement incrémental est pris en charge, mais la stratégie de mot de passe n'est appliquée que lorsque l'agent de contrôleur de domaine (DC Agent) est installé sur le contrôleur de domaine utilisé pour l’opération de changement de mot de passe.

 

Processus de récupération des stratégies

Chaque instance du service Proxy d’Azure AD Password Protection s’enregistre sur les contrôleurs de domaine dans la forêt en créant un objet serviceConnectionPoint dans Active Directory.

Chaque service Agent DC d’Azure AD Password Protection crée également un objet serviceConnectionPoint dans Active Directory. Cet objet est principalement utilisé pour le reporting et le diagnostic.

Le service Agent DC est responsable d'initier le téléchargement d'une nouvelle stratégie de mots de passe à partir d'Azure AD. La première étape consiste à localiser un service proxy Azure AD Password Protection Proxy en interrogeant la forêt pour les objets proxy serviceConnectionPoint. Lorsqu'un service de proxy disponible est trouvé, l'agent DC envoie une demande de téléchargement de stratégie de mot de passe au service de proxy. Le service proxy envoie à son tour la demande à Azure AD. Le service proxy retourne ensuite la réponse au service d’agent DC.

Après que le service Agent DC reçoit une nouvelle stratégie de mot de passe d'Azure AD, le service stocke la stratégie dans un dossier dédié à la racine de son dossier sysvol domaine partagé. Le service Agent DC surveille également ce dossier au cas où des stratégies plus récentes se répliqueraient à partir d'autres services Agent DC dans le domaine.

Le service Agent DC demande toujours une nouvelle stratégie au démarrage du service. Après le démarrage du service Agent DC, il vérifie l'âge de la stratégie disponible localement toutes les heures. Si la stratégie a plus d'une heure, l’agent DC demande une nouvelle stratégie à Azure AD via le service proxy, comme décrit précédemment. Si la stratégie actuelle ne date pas de plus d'une heure, l'agent DC continue d'utiliser cette stratégie.

Chaque fois qu'une stratégie d’Azure AD Password Protection est téléchargée, cette stratégie est spécifique à un tenant. En d'autres termes, les règles de mot de passe sont toujours une combinaison de la liste globale des mots de passe bannis de Microsoft et de la liste personnalisée des mots de passe bannis dans le tenant.

L’agent DC communique avec le service proxy via RPC sur TCP. Le service proxy écoute ces appels sur un port RPC dynamique ou statique, selon la configuration. L'agent DC n'écoute jamais sur un port réseau disponible. Le service proxy n'appelle jamais le service d'agent de DC. Le service proxy ne met jamais en cache les stratégies ou tout autre état téléchargé depuis Azure.

 

Validation des mots de passe

Cette partie décrit à la fois le processus de validation de mot de passe ainsi que le fonctionnement de l’algorithme utilisé pour valider le mot de passe.

Processus de validation des mots de passe

La validation des mots de passe a lieu comme suit :

• La DLL du filtre de mot de passe de l'agent DC reçoit les demandes de validation de mot de passe utilisateur du système d'exploitation. Il les transmet au service Agent DC qui s'exécute localement sur le contrôleur de domaine.
• Le service Agent DC d’Azure AD Password Protection reçoit les demandes de validation de mot de passe de la DLL du filtre de mot de passe de DC Agent. Il les traite en utilisant la stratégie de mot de passe courante (disponible localement) et retourne le résultat : succès ou échec.

 

Le service Agent DC utilise toujours la stratégie de mot de passe la plus récente disponible localement pour évaluer le mot de passe d'un utilisateur. Azure AD Password Protection agit comme un complément aux stratégies de mot de passe d'Active Directory existantes, et non comme un remplacement. Ceci inclut toute autre DLL de filtre de mot de passe tierce qui peut être installée. Active Directory exige toujours que tous les composants de validation de mot de passe soient d'accord avant d'accepter un mot de passe.

 

Note : Si aucune stratégie de mot de passe n'est disponible sur le DC local, le mot de passe est automatiquement accepté. Lorsque cela se produit, un message d'événement est enregistré pour avertir l'administrateur

Les listes de mots de passe bannis

Il est important d'avoir de bonnes recommandations, mais même avec cela, des utilisateurs finiront par choisir des mots de passe avec un niveau de sécurité faible. Azure AD Password Protection protège l’entreprise en détectant et en bloquant les mots de passe faibles connus et leurs variantes, ainsi qu'en bloquant éventuellement les termes faibles supplémentaires spécifiques à l’entreprise.

 

Azure AD Password Protection fournit donc deux listes de mots de passe faibles :

• La liste globale des mots de passe bannis : L'équipe d'Azure AD Identity Protection analyse constamment les données de télémétrie de sécurité d'Azure AD à la recherche de mots de passe faibles ou compromis couramment utilisés, ou plus spécifiquement, les termes de base faibles qui sont souvent utilisés comme base des mots de passe faibles. Lorsque des termes aussi faibles sont trouvés, ils sont ajoutés à la liste globale des mots de passe interdits. Le contenu de la liste globale des mots de passe interdits ne repose sur aucune source de données externe. La liste mondiale des mots de passe interdits est entièrement basée sur les résultats de l'analyse et de la télémétrie de sécurité d'Azure AD.
• La liste personnalisée des mots de passe bannis : Il peut être intéressant d’améliorer encore davantage la sécurité en ajoutant des personnalisations via la liste des mots de passe bannis personnalisés. Microsoft recommande que les termes ajoutés à cette liste soient principalement axés sur des termes propres à l’entreprise, tels que :
  • Marques
  • Noms de produits
  • Lieux (par exemple, le siège social de l'entreprise)
  • Conditions internes spécifiques à l'entreprise
  • Noms d’équipe
  • Abréviations qui ont une signification spécifique pour l'entreprise.

Une fois les termes ajoutés à la liste des mots de passe bannis personnalisés, ils seront combinés avec les termes de la liste globale des mots de passe bannis lors de la validation des mots de passe.

Note : La liste lobale des mots de passe bannis par Microsoft n’est pas publiée publiquement pour ne pas informer les attaquants. Aujourd’hui cette liste comprend principalement des mots de passe et termes anglais, c’est pourquoi, il est primordial de correctement configurer la liste personnalisée des mots de passe. La liste des mots de passe personnalisés bannis est limitée à un maximum de 1000 termes.

 

Algorithme de validation des mots de passe

L’algorithme de validation des mots de passe a été conçu pour prendre en compte de nombreuses variations des mots de passe via des mécanismes de normalisation et de calcul de la difficulté.

Par exemple, si vous bannissez le terme : windows ; tous les mots de passe suivants seront bannis :

• windows18
• Windows18
• W1ndows18
• windowsTH
• W1nd0w$18
• Etc.

 

Chaque fois qu'un utilisateur change ou réinitialise son mot de passe, la complexité du nouveau mot de passe est vérifiée en le validant par rapport à la liste combinée des termes de la liste globale et de la liste personnalisée des mots de passe bannis.

Même si le mot de passe d'un utilisateur contient un mot de passe interdit, le mot de passe peut toujours être accepté si le mot de passe global est suffisamment fort sinon. Un mot de passe nouvellement configuré passera par les étapes suivantes pour évaluer sa force globale afin de déterminer s'il doit être accepté ou rejeté.

 

L’algorithme agit selon les étapes suivantes :

Etape 1 : La normalisation

Un nouveau mot de passe est d'abord soumis à un processus de normalisation. Cette technique permet de mapper un petit ensemble de mots de passe interdits à un ensemble beaucoup plus important de mots de passe potentiellement faibles.

La normalisation comporte deux parties. Tout d'abord, toutes les lettres majuscules sont remplacées par des minuscules. Deuxièmement, des substitutions de caractères communs sont effectuées, par exemple : 0 en o, 1 en l, $ en s, @ en a, etc.

Ainsi le mot de passe Micr0$0ft est normalisé en microsoft.

 

Etape 2 : Vérification si le mot de passe est considéré comme banni par les 3 moyens suivants:

L’appariement flou est utilisé sur le mot de passe normalisé pour identifier s'il contient un mot de passe trouvé sur la liste des mots de passe globaux ou personnalisés bannis. Le processus d'appariement est basé sur une différence d’un caractère. Par exemple : supposons que le mot de passe "microsoft" est interdit, et qu'un utilisateur essaie de changer son mot de passe pour un des suivants : microosft", "mircosoft" ; " microsoft1", "microsof".

Chacun des mots de passe ci-dessus ne correspond pas spécifiquement au mot de passe interdit "microsoft". Cependant, comme chaque exemple se trouve à une distance d'édition de 1 du terme interdit microsoft, ils sont tous considérés comme une correspondance avec microsoft.

 

La correspondant de la sous chaine est utilisée sur le mot de passe normalisé pour vérifier le prénom et le nom de l'utilisateur. Par exemple : supposons que nous avons un utilisateur, David, qui veut réinitialiser son mot de passe à "David123A". Après normalisation, ce mot de passe deviendrait "david123a". La correspondance des sous-chaînes indique que le mot de passe contient le prénom de l'utilisateur "David". Même si " David123A " ne figurait pas spécifiquement sur la liste des mots de passe interdits, la correspondance de sous-chaîne a trouvé "David" dans le mot de passe. Par conséquent, ce mot de passe serait rejeté.

 

Enfin le calcul du score (Score Calculation) est redoutable ! Il consiste à identifier toutes les occurrences de mots de passe bannis dans le nouveau mot de passe normalisé de l'utilisateur et déterminer un score calculé sur la base :

1. Chaque mot de passe banni qui se trouve dans le mot de passe d'un utilisateur reçoit un point.
2. Chaque caractère unique restant reçoit un point.
3. Un mot de passe doit avoir au moins cinq (5) points pour être accepté.

 

Supposons que "touch" fasse parti de la liste personnalisée. Supposons également que "microsoft" figure sur la liste globale. 

• Exemple : un utilisateur change son mot de passe en "MicrosoftTouch18".

Après normalisation, ce mot de passe devient "microsofttouch18". Le processus d'appariement trouve que ce mot de passe contient deux mots de passe interdits : microsoft et touch. Le mot de passe se voit alors attribuer un score : [microsoft] +[rhonetouch +[1] +[8] = 4 points. Comme le score de ce mot de passe est inférieur à 5 points, il sera rejeté.

• Exemple : un utilisateur change son mot de passe en "Micr0$0ftT0uch18!

Après normalisation, ce mot de passe devient "microsofttouch18!". Le processus d'appariement trouve que ce mot de passe contient deux mots de passe interdits : microsoft et touch. Ce mot de passe se voit alors attribuer un score : [microsoft] +[touch]+[1] +[8] + [!] = 5 points. Puisque ce mot de passe est d'au moins 5 points, il est accepté.

 

Cet algorithme est appliqué à chaque réinitialisation ou changement de mot de passe selon la liste globale et personnalisée.

 

Configuration des prérequis

Cette partie décrit les prérequis à mettre en œuvre pour mettre œuvre la sécurisation des mots de passe avec Azure Active Directory Password Protection.

Les prérequis suivantes s’appliquent :

• Licences :
  • Soit : Azure AD Premium (P1)
  • Soit : Enterprise Mobility + Security (EMS) E3
  • Soit : Microsoft 365 E3
• Les domaines Active Directory qui exécutent l’agent DC doivent utiliser la réplication du système de fichiers distribué (DFSR) pour la réplication sysvol.
• Le service de distribution de clés doit être activé sur tous les contrôleurs de domaine figurant dans le domaine qui exécutent Windows Server 2012.
• Tous les contrôleurs de domaine sur lesquels le service d’agent d’Azure AD Password Protection est installé doivent :
  • Exécuter Windows Server 2012 ou version ultérieure. Cette exigence n’implique pas que le domaine ou la forêt Active Directory doive également être au niveau fonctionnel du domaine ou de la forêt Windows Server 2012. Afin d’assurer une protection cohérente, il est nécessaire que tous les contrôleurs de domaine qui peuvent être utilisés pour les opérations de changement de mot de passe, soient équipés de l’agent DC et donc hébergés sur Windows Server 2012 ou plus.
  • Avoir le .NET Framework 4.5 ou plus installé
  • Avoir le Runtime C Universel

Note : Il n’est pas nécessaire d’installer l’agent sur les contrôleurs de domaine en lecture seul (RODC).

• Un ou plusieurs serveurs hébergeant le service proxy d’Azure AD Password Protection et répondant aux prérequis suivants :
  • Windows Server 2012 R2 ou plus.
  • .Net Framework 4.7+ installé
  • Runtime C Universel installé
  • Être connecté à Internet
  • Le trafic HTTP TLS 1.2 sortant doit être autorisé
• Un compte d’administrateur général pour inscrire la forêt et le service proxy de protection par mot de passe auprès d’Azure AD.
• Un compte disposant des privilèges d’administrateur de domaine Active Directory dans le domaine racine de la forêt pour inscrire la forêt Windows Server Active Directory auprès d’Azure AD.

 

Les prérequis réseaux suivants s’appliquent :

Source	Sens	Destination	Protocole
Azure AD Password Protection DC Agent	=>	Azure AD Password Protection Proxy Server	RPC (135) RPC DYNAMIC
Azure AD Password Protection Proxy Server	=>	Internet : https://login.microsoftonline.com https://enterpriseregistration.windows.net	HTTP (TCP/443)

 

Installation et Configuration du proxy Azure AD Password Protection

Cette partie décrit l’installation et la configuration du proxy Azure AD Password Protection. Pour rappel, ce rôle fait office de relais pour récupérer les stratégies de mot de passe utilisées par les contrôleurs de domaine pour valider les mots de passe soumis.

Pour rappel, voici les prérequis du serveur hébergeant ce rôle :

• Windows Server 2012 R2 ou plus.
• .Net Framework 4.7+ installé
• Runtime C Universel installé
• Être connecté à Internet
• Le trafic HTTP TLS 1.2 sortant doit être autorisé

 

Installation du proxy Azure AD Password Protection

Cette sous-partie décrit l’installation et la configuration du proxy Azure AD Password Protection.

Commencez par installer le .Net Framework 4.7+.

Une fois le Framework installé, téléchargez les sources du proxy Azure AD Password Protection. Depuis les sources, lancez l’installation du proxy en tant qu’administrateur.
La fenêtre d’installation se lance. Acceptez les termes du contrat et cliquez sur Install

 

Une fois l’installation terminée avec succès, cliquez sur Close

Vérifiez l’installation et la présence du service en lancant une invite de commande PowerShell et en exécutant :

Get-Service azureadpasswordprotectionproxy

 

L’état doit être en cours d’exécution / Running.

Note : Si vous utilisez un proxy Internet, je vous invite à consulter la documentation pour opérer sa configuration.

 

Enregistrement du proxy avec le tenant Azure AD

L’étape qui suit revient à enregistrer le proxy fraichement installé avec le tenant Azure Active Directory.
Pour ce faire, sur le serveur proxy, exécutez une invite de commande PowerShell en tant qu’administrateur.

Exécutez la commande suivante pour importer le module utilisé pour l’enregistrement :

Import-Module azureadpasswordprotection

 

Puis tapez : $get=get-credential

Renseignez les /mot de passe de l’administrateur global du tenant Azure Active Directory.

Tapez ensuite la commande :

Register-AzureADPasswordProtectionProxy -azurecredential $cred

Note : Ce mode ne fonctionne pas si une authentification à est nécessaire pour le compte utilisé. Dans ce cas, utilisez la commande :

Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'

 

 

Enregistrement de la forêt

Vous devez initialiser la forêt Active Directory locale avec les informations d’identification nécessaires pour communiquer avec Azure. L’inscription de la forêt Active Directory est requise une seule fois au cours de la durée de vie de la forêt. Après cela, les agents du contrôleur de domaine dans la forêt effectuent automatiquement toutes les autres tâches de maintenance nécessaires.

Pour ce faire toujours sur le proxy, exécutez une invite de commande PowerShell en tant qu’administrateur.

Exécutez ensuite la commande suivante :

Register-AzureADPasswordProtectionForest -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'

La forêt est maintenant enregistrée sur le proxy.

Note : La forêt ne doit être inscrite qu’une seule fois et la commande ne doit être exécutée qu’une seule fois. sont installés dans votre environnement, peu importe le serveur proxy que vous utilisez pour inscrire la forêt.

 

 

Installation de l’agent DC d’Azure AD Password Protection

Cette partie décrit l’installation de l’agent Azure AD Password Protection. Pour rappel, ce rôle s’intègre à l’annuaire et au contrôleur de domaine pour intercepter les changements de mots de passe et interroger le proxy pour savoir si la demande répond aux exigences.

 

Pour rappel, voici les prérequis du serveur hébergeant ce rôle :

• Exécuter Windows Server 2012 ou version ultérieure. Cette exigence n’implique pas que le domaine ou la forêt Active Directory doive également être au niveau fonctionnel du domaine ou de la forêt Windows Server 2012. Afin d’assurer une protection cohérente, il est nécessaire que tous les contrôleurs de domaine qui peuvent être utilisés pour les opérations de changement de mot de passe, soient équipés de l’agent DC et donc hébergés sur Windows Server 2012 ou plus.
• Avoir le .NET Framework 4.5 ou plus installé
• Avoir le Runtime C Universel

 

Note : Il n’est pas nécessaire d’installer l’agent sur les contrôleurs de domaine en lecture seul (RODC).

 

Commencez par installer le .Net Framework 4.5 via le gestionnaire de serveur (Server Manager). Une fois le Framework installé, téléchargez les sources de l’agent Azure AD Password Protection

Depuis les sources, lancez l’installation du proxy en tant qu’administrateur. Sur l’écran, acceptez le contrat de licence et cliquez sur Install :

Note : Vous pouvez installer le service d’agent DC sur une machine qui n’est pas encore un contrôleur de domaine. Dans ce cas, le service démarre et s’exécute, mais reste inactif jusqu’à ce que la machine soit promue comme contrôleur de domaine

Cliquez sur Finish :

 

La fenêtre suivante, vous invite à redémarrer le contrôleur de domaine :

Attention ! L’installation ou la désinstallation de l’agent DC, nécessite un redémarrage. Cela est dû au fait que les DLL de filtrage de mots de passe sont uniquement chargées ou déchargées par un redémarrage.

 

Vérification de l’infrastructure

Il est possible de vérifier l’infrastructure en utilisant des cmdlets PowerShell sur .

Pour ce faire connectez-vous à ce serveur et ouvrez une invite PowerShell.

Chargez le module via : Import-Module azureadpasswordprotection

 

Exécutez la commande :

Get-AzureADPasswordProtectionDCAgent

La commande doit renvoyer tous les agents de contrôleur de domaine avec :

• La version de l’agent
• La forêt et le domaine
• Le tenant Azure
• La date de dernier rechargement de la stratégie de mot de passe
• La date de dernière pulsation de l’état de santé

 

En outre, la commande Get-AzureADPasswordProtectionSummaryReport permet d’obtenir des statistiques sur l’utilisation du service par contrôleur de domaine :

 

 

 

Test d’Azure AD Password Protection

Cette partie décrit l’évaluation du service de protection des mots de passe proposé par Azure Active Directory. Nous évaluerons deux fonctionnalités :

• Le verrouillage dynamique des comptes lors des authentifications Cloud (Azure AD Smart Lockout).
• La liste des mots de passe interdits (Azure AD Banned Password). Ce test se fera en deux temps :
  • Evaluation dans un mode Audit
  • Evaluation dans un mode Appliqué bloquant les changements de mot de passe ne répondant pas aux critères.

 

 

Azure AD Smart Lockout

Tout comme sur l’annuaire Active Directory, Azure Active Directory propose un mécanisme de verrouillage/déverrouillage dynamique des mots de passe en fonction des échecs. Cette fonctionnalité ne requiert d’ailleurs pas de niveau de licence spécifique Azure Active Directory.

 

Configuration du tenant

Pour modifier la configuration du verrouillage intelligent, ouvrez le portail Azure Active Directory et naviguez dans Méthodes d’authentification (sous partie Sécurité). Cliquez ensuite sur Protection par mot de passe.

 

Modifiez les valeurs :

• Lockout Threshold étant le seuil à partir de combien de mot de passe érroné, le compte se voit verrouillé.
• Lockout duration in seconds étant le temps pendant lequel le compte sera vérrouillé.

 

Note : Il est recommandé de reporter la configuration de votre annuaire Active Directory.

 

Validation de la configuration

Pour évaluer la configuration du verrouillage intelligent des comptes, il suffit de procéder à la connexion d’un utilisateur sur les services Office 365. Nous procédons donc à la réalisation de 5 connexions infructueuses. Ceci renvoi un état de verrouillage :

Après 15 minutes, l’utilisateur peut se réauthentifier sur les services Cloud utilisant l’identité Azure Active Directory :

Azure AD Banned Password

La fonctionnalité Banned Password permet d’enrichir les stratégies de protection des mots de passe proposés par Active Directory en bannissant les mots de passe communs ou les mots de passe pouvant être facilement devinés car liés à l’image de l’entreprise.

Note : Cette fonctionnalité requiert à minima Azure AD Premium 1 (P1).

 

Configuration du tenant en mode Audit

Maintenant que les rôles nécessaires au service ont été installés dans l’infrastructure, nous pouvons procéder à la configuration de la stratégie de protection des mots de passe sur le tenant.

Pour ce faire, ouvrez le portail Azure Active Directory et naviguez dans Méthodes d’authentification (sous partie Sécurité).

Cliquez ensuite sur Protection par mot de passe.

Passez l’option Appliquer la liste personnalisée à Oui puis renseignez les mots de passe personnalisés à exclure.

Pour rappel, le service normalise les mots de passe des utilisateurs. Il n’est ainsi pas nécessaire de rentrer toutes les occurrences attendues (par exemple : password, P@ss0rd, P@$$w0rd, etc.). Vous pouvez simplement renseigner la version simple du mot de passe.  En outre, le service inclut une liste de mot de passe générique par défaut (par exemple password). Cette liste est pour l’heure centrée sur des occurrences anglophone.

 

Dans la partie Protection par mot de passe pour Windows Server Active Directory, vérifiez que la protection est activée.

Passez le mode en Audit.

Note : Nous passerons le mode en Appliqué / Enforced une fois que nous aurons validé le comportement. C’est d’ailleurs la recommandation de Microsoft pour ne pas impacter de manière trop importante vos utilisateurs.

 

Attention ! Tout changement sur la configuration (ajouts de mot de passe ou passage en mode Audit/Appliqué) peut prendre plusieurs heures pour être effectif.

 

Evaluation et Audit de la stratégie

Les événements suivants peuvent être utilisés pour évaluer l’impact de la stratégie en mode Audit :

	Modification de mot de passe (Utilisateur)	Définition de mot de passe (Administrateur
Réussite	10014	10015
Réussite à cause du mode Audit (aurait échoué avec la stratégie de mot de passe client)	10024, 30008	10025, 30007
Réussite à cause du mode Audit (aurait échoué avec la stratégie de mot de passe Microsoft)	10024, 30010	10025, 30009
Réussite à cause du mode Audit (aurait échoué avec les stratégies de mot de passe combinées Microsoft et client)	10024, 30028	10025, 30029

 

Maintenant que le tenant a été configuré en mode Audit, vous pouvez tenter de réaliser un changement de mot de passe sur une machine cliente.

Vous pouvez réaliser un essai avec l’un des mots de passe défini.

Connectez-vous en suite sur le proxy Azure AD Password Protection en utilisant des cmdlets PowerShell et chargez le module via : Import-Module azureadpasswordprotection

 

Exécutez la commande Get-AzureADPasswordProtectionSummaryReport.

 

Vous pouvez constater qu’un changement de mot de passe n’a pas répondu aux exigences.

Vous pouvez apprendre plus de détails dans les journaux d’événements du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent - Admin

Nous retrouvons les événements : 10024 et 30010 indiquant que le changement de mot de passe aurait dû être rejeté :

 

Configuration du tenant en mode Appliqué (Blocage)

Maintenant que nous avons testé le mode Audit, nous pouvons procéder au blocage des changements et réinitialisation de mot de passe qui ne répondent pas aux exigences.

Pour ce faire, ouvrez le portail Azure Active Directory et naviguez dans Méthodes d’authentification (sous partie Sécurité).

Cliquez ensuite sur Protection par mot de passe.

Dans la partie Protection par mot de passe pour Windows Server Active Directory, vérifiez que la protection est activée.

Passez le mode en Appliqué / Enforced.

 

Attention ! Tout changement sur la configuration (ajouts de mot de passe ou passage en mode Audit/Appliqué) peut prendre plusieurs heures pour être effectif.

 

Application de la stratégie (Blocage)

Dans cette partie, nous nous attardons un peu plus en détails sur les tests avec les scénarios suivants :

1. Evaluation du blocage du changement d’un mot de passe générique issu de la chaine de caractère password
2. Evaluation du blocage du changement d’un mot de passe issu de la liste des mots de passe personnalisés du département
3. Evaluation de l’autorisation du changement d’un mot de passe répondant aux critères et à l’algorithme malgré la source initiale du mot de passe
4. Evaluation du blocage de la réinitialisation d’un mot de passe issu de la liste des mots de passe personnalisés du Département par un administrateur via Active Directory

 

Les événéments suivants peuvent être utilisés pour évaluer l’impact de la stratégie en mode Appliqué / Enforced :

	Modification de mot de passe (Utilisateur)	Définition de mot de passe (Administrateur)
Réussite	10014	10015
Échec (à cause de la stratégie de mot de passe client)	10016, 30002	10017, 30003
Échec (à cause de la stratégie de mot de passe Microsoft)	10016, 30004	10017, 30005
Échec (à cause des stratégies de mot de passe combinées Microsoft et client)	10016, 30026	10017, 30027

 

Blocage à cause de la stratégie de mot de passe Microsoft

Cette partie vise à valider que le blocage est effectif pour les mots de passe identifiés comme communs par Microsoft. Nous testerons donc la configuration d’un mot de passe issu de la chaine de caractère : password.

Note : Il n’est pas possible de modifier la liste des mots de passe de Microsoft.

Vous pouvez réaliser cet essai sur un poste Windows 10 avec le mot de passe P@ssw0rd :

 

L’utilisateur reçoit le message : Impossible de mettre à jour le mot de passe. Le nouveau mot de passe entré ne respecte pas les spécifications de longueur, de complexité ou d'historique du domaine.

 

Vous pouvez constater qu’un changement de mot de passe n’a pas répondu aux exigences.

Vous pouvez apprendre plus de détails dans les journaux d’événéments du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent – Admin. Nous retrouvons les événements : 10016 et 30004 indiquant que le changement de mot de passe a été rejeté par la stratégie de mot de passe Azure :

 

Blocage à cause de la stratégie de mot de passe du Département

Cette partie vise à valider que le blocage est effectif pour les mots de passe renseignés par le Département dans la liste personnalisée. Nous testerons donc la configuration d’un mot de passe issu de la chaine de caractère : windows.

Vous pouvez réaliser cet essai sur un poste Windows 10 avec le mot de passe Wind0w$18 :

 

L’utilisateur reçoit le message : Impossible de mettre à jour le mot de passe. Le nouveau mot de passe entré ne respecte pas les spécifications de longueur, de complexité ou d'historique du domaine.

 

Vous pouvez constater qu’un changement de mot de passe n’a pas répondu aux exigences.

Vous pouvez apprendre plus de détails dans les journaux d’événéments du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent – Admin. Nous retrouvons les événements : 10016 et 30002 indiquant que le changement de mot de passe a été rejeté par la stratégie de mot de passe du tenant Azure 

 

 

Changement d’un mot de passe répondant aux critères et à l’algorithme malgré la source initiale du mot de passe

Cette partie vise à valider que la capacité de changement de mot de passe pour un mot de passe issu de la souche mais avec une complexité dépassant les attentes de l’algorithme (5 points de différences). Nous testerons donc la configuration d’un mot de passe issu de la chaine de caractère : windows.

Vous pouvez réaliser cet essai sur un poste Windows 10 avec le mot de passe Wind0w$T0uch123! :

 

Cette fois, l’utilisateur peut changer le mot de passe car il est jugé non commun par l’algorithme.

Vous pouvez apprendre plus de détails dans les journaux d’événéments du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent – Admin. Nous retrouvons l’événement 10014 indiquant que le changement de mot de passe a été autorisé

 

 

Blocage de la réinitialisation d’un mot de passe par l’administrateur

Le dernier test vise à démontrer que les stratégies s’appliquent aussi aux réinitialisations de mot de passe faites par des administrateurs via la console Active Directory. Pour ce faire, nous testerons donc la configuration d’un mot de passe issu de la chaine de caractère : password.

Nous réalisons cet essai via la console Active Directory sur l’utilisateur avec le mot de passe P@ssw0rd :

 

La console renvoi le message d’erreur :

Ce mot de passe ne correspond pas aux critères de stratégie de mot de passe. Vérifiez la longueur du mot de passe minimale, la complexité du mot de passe et l’historique des critères de mot de passe.

 

Vous pouvez constater qu’un changement de mot de passe n’a pas répondu aux exigences.

Vous pouvez apprendre plus de détails dans les journaux d’événements du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent – Admin. Nous retrouvons les événements : 10017 et 30005 indiquant que la réinitialisation de mot de passe a été rejetée par la stratégie de mot de passe Azure :

 

 

Supervision du service

Microsoft offre différents moyens de superviser le service Azure AD Password Protection

Les journaux d’événéments

• Sur le Proxy d’Azure AD Passsword Protection:
  • \Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Admin
  • \Applications and Services\Logs\Microsoft\AzureADPasswordProtection\ProxyService\Operational
  • \Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Trace

Composant	Plage d’identifiant d’événements
Proxy service hosting process	10000-19999
Proxy service core business logic	20000-29999
PowerShell cmdlets	30000-39999

 

• Sur l’agent DC d’Azure AD Password Protection :
  • \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin permet d‘obtenir des informations sur les validations de mot de passe réalisées sur ce contrôleur de domaine et le résultat associé.

	Modification de mot de passe (Utilisateur)	Définition de mot de passe (Administrateur)
Réussite	10014	10015
Échec (à cause de la stratégie de mot de passe client)	10016, 30002	10017, 30003
Échec (à cause de la stratégie de mot de passe Microsoft)	10016, 30004	10017, 30005
Échec (à cause des stratégies de mot de passe combinées Microsoft et client)	10016, 30026	10017, 30027
Réussite à cause du mode Audit (aurait échoué avec la stratégie de mot de passe client)	10024, 30008	10025, 30007
Réussite à cause du mode Audit (aurait échoué avec la stratégie de mot de passe Microsoft)	10024, 30010	10025, 30009
Réussite à cause du mode Audit (aurait échoué avec les stratégies de mot de passe combinées Microsoft et client)	10024, 30028	10025, 30029

 

Correspondance des événéments avec le résultat de la Cmdlets Get-AzureADPasswordProtectionSummaryReport :

Propriété Get-AzureADPasswordProtectionSummaryReport	Evénément correpsondant
PasswordChangesValidated	10014
PasswordSetsValidated	10015
PasswordChangesRejected	10016
PasswordSetsRejected	10017
PasswordChangeAuditOnlyFailures	10024
PasswordSetAuditOnlyFailures	10025
PasswordChangeErrors	10012
PasswordSetErrors	10013

 

• \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Operational permet d’obtenir des éléments sur l’agent en lui-même dont :

Composant	Plage d’identifiant d’événements
DC Agent password filter dll	10000-19999
DC agent service hosting process	20000-29999
DC agent service policy validation logic	30000-39999

 

• \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Trace

 

Les Cmdlets PowerShell

Par import du module Azure AD Password Protection (AzureADPasswordProtection), vous obtenez les cmdlets suivantes :

• Get-AzureADPasswordProtectionSummaryReport offrant un rapport détaillé sur les validations de mot de passe réalisées par les contrôleurs de domaine.
• Get-AzureADPasswordProtectionDCAgent liste tous les agents DC et l’état associé (forêt, domaine, date de dernière mise à joru de la stratégie, etc.)
• Get-AzureADPasswordProtectionProxy liste les informations basiques sur les proxy de la forêt et d’un domaine.

 

Les compteurs de performance

L’agent DC d’Azure AD Password Protection installe les compteurs de performance suivants :

Nom du compteur	Description
Passwords processed	Ce compteur affiche le nombre total de mots de passe traités (acceptés ou refusés) depuis le dernier redémarrage.
Passwords accepted	Ce compteur affiche le nombre total de mots de passe acceptés depuis le dernier redémarrage.
Passwords rejected	Ce compteur affiche le nombre total de mots de passe qui ont été refusés depuis le dernier redémarrage.
Password filter requests in progress	Ce compteur affiche le nombre de demandes de filtre de mot de passe en cours.
Peak password filter requests	Ce compteur affiche le nombre maximum de demandes de filtre de mot de passe simultanées depuis le dernier redémarrage.
Password filter request errors	Ce compteur affiche le nombre total de demandes de filtre de mot de passe qui ont échoué en raison d'une erreur depuis le dernier redémarrage. Des erreurs peuvent se produire lorsque le service d'agent DC d'Azure AD Password Protection n'est pas exécuté.
Password filter requests/sec	Ce compteur affiche la vitesse à laquelle les mots de passe sont traités.
Password filter request processing time	Ce compteur affiche le temps moyen requis pour traiter une demande de filtre de mot de passe.
Peak password filter request processing time	Ce compteur affiche le temps de traitement des demandes de filtre de mot de passe de pointe depuis le dernier redémarrage.
Passwords accepted due to audit mode	Ce compteur affiche le nombre total de mots de passe qui auraient normalement été rejetés, mais qui ont été acceptés parce que la stratégie de mot de passe a été configurée pour être en mode audit (depuis le dernier redémarrage).

 

Ces compteurs peuvent être utilisés dans des outils de supervision de performance ou de sécurité.

Bonne sécurisation !

A chaque nouvelle version de SQL Server, les mêmes questions se posent systématiquement : Est-ce que ce produit/service supporte cette nouvelle version de SQL Server ? C’est particulièrement le cas pour System Center Configuration Manager (SCCM) ou Microsoft Endpoint Manager Configuration Manager (MEM CM). Ce produit annonce assez rapidement le support ; ce qui pose la même question pour la base de données de WSUS puis cette dernière est souvent hébergée sur le même serveur et la même instance.

Microsoft vient de fermer le débat en annonçant le support par WSUS de toutes les versions de SQL Server en cours de support.

Source

Microsoft vient de publier l’Update Rollup 9 pour les produits System Center 2016. Avant d’appliquer cet UR, lisez bien les articles de la base de connaissances associés. Vous pouvez les déployer manuellement en récupérant les CAB ou via Windows Update/WSUS.

Celui-ci apporte les fonctionnalités et corrige les problèmes suivants : 

System Center 2016 Operations Manager (KB4546986)

• Correctif : Sur la vue Windows Computer de la console SCOM, les requêtes sont optimisées pour de meilleures performances.
• Correctif: Microsoft a mis à jour une SPROC pour gérer les noms de chemin source d'alerte dont la longueur est supérieure à 512. Il y avait un problème lorsque la table qui alimentait la base de données permettait des chaînes de caractères plus longues alors que la table qui était alimentée dans cette vue ne prenait que 512 caractères. Cela a entraîné une troncature des données et, par la suite, un crash de la console.
• Correctif: Modification du paramètre d'adresse IP pour prendre en charge les clusters Windows IPv4 et IPv6.
• Correctif: Correction du problème de conversion des données inférieures à 0.01 qui étaient générées par la règle ou le moniteur. Les données étaient transformées en une mauvaise (grosse) valeur sur les systèmes dont le langage local du système d'exploitation comporte une virgule (",") au lieu d'un point (".") comme format décimal.
• Correctif: Dans un scénario où SCOM surveille des centaines de machines virtuelles hébergées sur un seul serveur Hyper-v ; toutes les heures, le MonitoringHost.exe de chaque machine virtuelle écrit simultanément dans le fichier de la page VM. En raison de cette pagination simultanée, toutes les heures, les entrées/sorties de disque augmentent et la base de données ne répond plus. Le HealthService.exe a maintenant la fonction de découpage de la mémoire activée par défaut selon un horaire planifié. Une clé de registre est fournie pour désactiver le découpage de la mémoire et contrôler la durée.
• Correctif: La durée des downtime sera calculée correctement pour le format de temps non américain dans le rapport sur les downtime.
• Correctif: fn_MPVersionDependentId crée un ID pour chaque MP installé. L'ID est un hachage SHA1 de la chaîne "MPName, Version, Schema". Lorsque la partie "Schema" est omise, elle génère un hachage différent qui ne correspond pas à la valeur attendue. Dans la correction, la partie "Schema=2" est réajoutée dans fn_MPVersionDependentId.
• Correctif: Nous avons fait en sorte que la date de fin correcte pour les détails de disponibilité, de santé et de performance soit indiquée dans les rapports.
• Activation de la prise en charge du pilote MSOLEDBSQL afin que les utilisateurs puissent passer du client natif au serveur SQL. Il est recommandé d'installer le pilote Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) pour activer la prise en charge du pilote OLE DB Driver.

 

System Center 2016 Data Protection Manager (KB4534063)

• Dans certains cas, l'échec des travaux de nettoyage entraîne un gonflement du stockage.
• Une couche supplémentaire d'authentification est ajoutée pour les opérations critiques. Vous serez invité à saisir un code PIN de sécurité lorsque vous effectuerez des opérations de d’arrêt de la protection avec suppression de données.
• Ajout d'un nouveau paramètre -CheckReplicaFragmentation dans la cmdlet Copy-DPMDatasourceReplica. Le nouveau paramètre calcule le pourcentage de fragmentation pour un réplica

 

System Center 2016 Service Manager (KB4546987)

• Permet la prise en charge du pilote MSOLEDBSQL afin que les clients puissent passer de SQL Native Client. Des étapes manuelles sont nécessaires pour utiliser le pilote MSOLEDBSQL avec SQL Server Analysis Services (SSAS), qui sont fournies dans la KB.
• Correction d'un problème où les résultats de la requête n'étaient pas localisés si la langue du portail n'est pas l'anglais
• Correction d'un problème où l'utilisateur n'était pas en mesure de soumettre une demande de service si l'une des listes contenait un élément avec un signe plus "+".
• Le premier élément des listes lors de la soumission d'une demande de service n'est désormais plus sélectionné par défaut. Cela garantit que l'utilisateur sélectionne la bonne catégorie d'élément.
• Correction d'un problème qui empêchait quelques utilisateurs de soumettre des demandes via le portail, avec une erreur "La clé donnée n'était pas présente dans le dictionnaire".
• Support des versions 1806, 1810, 1902, 1906 et 1910 de SCCM. Toutefois, la taille des périphérique pris en charge par le SCCM doit être inférieure à 2 PB.

 

System Center 2016 Virtual Machine Manager (KB4549434)

• Le rafraîchissement du fournisseur de stockage échoue lorsque la carte réseau n'a pas de MAC.
• Les données de compteur de performance extraites à l'aide de la règle "Micrososft.SystemCenter.VirtualMahcineManager.2016.CLoudUsageCollection" ne sont pas stockées correctement dans la base de données OperationsManagerDW.
• Affichage incorrect de la version du système d'exploitation pour les VM du contrôleur de domaine WS 2019.
• Avec VMM2016 UR9, vous pouvez déployer des machines virtuelles Ubuntu 18.04.
• La prise en charge de la connexion à la VM Console via une "session améliorée" a été ajoutée.

 

Source

Azure Active Directory intègre un mécanisme natif permettant de configurer des administrateurs locaux supplémentaires sur les machines jointes à Azure Active Directory. Ce mécanisme est néanmoins très limité puisqu’il comprend les contraintes suivantes :

• Il n’est possible d’ajouter que des utilisateurs (pas de groupes)
• Les membres sont ajoutés pour l’ensemble des machines du tenant (pas de régionalisation, etc.)

Ceci rend donc la fonctionnalité inutilisable pour les moyennes et grandes entreprises.

En outre, apparu avec Windows 10 1803, le Configuration Service Provider (CSP) RestrictedGroups permet comme pour les stratégies de groupe de configurer les groupes locaux selon vos contraintes. Depuis cette version, le CSP ne permettait de configurer que les utilisateurs Azure Active Directory et les utilisateurs ou groupes locaux.

En effet, Windows 10 ne savait pas résoudre les SID de groupes Azure Active Directory.

Sur indication de Michael Niehaus (MSFT), ceci a changé avec Windows 10 2004 qui interprète maintenant les SID des groupes Azure Active Directory pour interroger Azure Active Directory et en connaître les membres.
Il devient donc possible de gérer les administrateurs locaux via des groupes Azure AD ouvrant la voie à plus de flexibilité pour gérer les scénarios d’administration et de régionalisation avec différentes équipes/acteurs.

Les prérequis suivants s’appliquent :

• Un tenant Azure Active Directory et Microsoft Intune
• Les machines doivent utiliser Windows 10 2004 ou plus.
  Note : Les machines antérieures se verront attribuer les SID mais sans disposer du mécanisme d’interprétation et d’interrogation de l’annuaire Azure AD.
• Les machines doivent être jointes à Azure AD
  Note : Les machines Hybrid Azure AD ne permettent pas la connexion de comptes Azure AD. Vous devez donc ajouter des groupes Active Directory.
• Les machines doivent être gérées par Microsoft Intune
• Des groupes Azure AD à ajouter dans les groupes locaux

 

Commencez par récupérer les SID des groupes Azure Active Directory.
Pour cela, ouvrez une invite PowerShell et installez le module PowerShell AzureAD via
install-module AzureAD

Connectez-vous au tenant via la commande :
Connect-AzureAD

Chargez ensuite la fonction suivante permettant de convertir les ObjectID en SID:
function Convert-ObjectIdToSid
{
    param([String] $ObjectId)
    $d=[UInt32[]]::new(4);[Buffer]::BlockCopy([Guid]::Parse($ObjectId).ToByteArray(),0,$d,0,16);"S-1-12-1-$d".Replace(' ','-')
}

 

Recherchez ensuite les groupes choisis via la commande :

Get-AzureADGroup -SearchString "<Mot clé>" | ForEach { [pscustomobject] @{ Name= $_.DisplayName; Sid=Convert-ObjectIdToSid($_.ObjectId)}}

 

Une fois les SID des groupes récupérés, ouvrez le portail Microsoft Endpoint Manager Microsoft Intune et naviguez dans Devices – Configuration Profiles.
Cliquez sur Create Profile puis sélectionnez la plateforme Windows 10 puis le type de profil Custom puis cliquez sur Create.

Nommez le profil selon votre convention de nommage habituelle :

Sur l’écran suivant cliquez sur Add pour ajouter un paramétrage OMA-URI.
Sur la page qui s’affiche :

• Renseignez le nom du paramétrage (par exemple : RestrictedGroups – Membership)
• L’OMA-URI suivant : ./Device/Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership
• Le type de données : String
• La valeur doit être construite de la façon suivante :

<groupmembership>

               <accessgroup desc = "<Groupe Local>">

                              <member name = "<Utilisateur local>" />

                              <member name = "<SID Groupe Azure AD 1>" />

                              <member name = "<SID Groupe Azure AD 2>" />

               </accessgroup>

</groupmembership>

 

Par exemple :

<groupmembership>

               <accessgroup desc = "Administrators">

                              <member name = "Administrator" />

                              <member name = "S-1-12-1-69815829-1178405001-4035617042-2681907508" />

                              <member name = "S-1-12-1-1169101219-1256535172-115196936-1640945877" />

                              <member name = "S-1-5-21-2736761267-2422631571-249973318-500" />

                              <member name = "S-1-12-1-1056520221-1108734488-981220086-1973936364" />

               </accessgroup>

</groupmembership>

 

Cliquez sur Add

 

Une fois revenu sur l’écran de configuration, cliquez sur Next

 

Configurez les étendues selon votre modèle de délégation :

 

Sur l’écran Assignements, ajoutez les groupes de machines (de préférence pour faciliter le déploiement) cibles de paramétrage :

 

 

 

 

Configurez les éventuelles règles d’applicabilité (par exemple pour demander à minima la build de la version 2004) :

 

Validez l’écran de résumé et cliquez sur Create

 

Une fois déployé, vous pouvez constater la configuration par différents moyens.

La console MEM permet d’avoir le statut

• Global en naviguant dans Devices – Configuration Profiles - <le profil de configuration>
• Pour une machine en naviguant Devices – All Devices - <le périphérique> - Device configuration

Sur le périphérique, vous pouvez ouvrir le rapport de diagnostic MDM en naviguant dans l’application Settings/Paramètres puis Accounts/Comptes puis Access work or school/Accès professionnel ou scolaire. Cliquez ensuite sur le compte de l’entreprise puis Info/Information.
Choisissez Create report/Créer le rapport puis Export/Exporter

Ouvrez ensuite le rapport dans votre navigateur et recherchez le mot clé RestrictedGroups :

 

Enfin, vous pouvez constater l’ajout des membres directement dans le groupe choisi via le gestionnaire d’ordinateur :

 

Vous pouvez faire l’essai en ouvrant une session avec un compte Azure AD inclus dans les groupes Azure AD. Vous pouvez ensuite constater ses droits par exemple en allant dans la page d’information du compte et visualiser qu’il est administrateur comme souhaité.

 

Bonne configuration !

L’équipe du support Microsoft Intune vient de publier un billet pour un problème connu concernant les périphériques macOS 10.15.4. Il semble que ces derniers, constatent des messages d'invite ou à des blocages d'accès inattendus à des applications telles que le client mail natif.

Vous êtes dans ce scénario :

• Le périphérique macOS a été enregistré dans Intune
• Il y a une stratégie d'accès conditionnel exigeant un périphérique conforme.

En travaillant avec Apple, Microsoft a découvert que la mise à jour vers macOS 10.15.4 exposait un bug dans l'authentification pour plusieurs applications dont Mail et Calendar.

Microsoft et Apple travaillent sur une résolution.

Source

Bon nombre de clients utilisent toujours Microsoft BitLocker Administration and Monitoring (MBAM) pour gérer le chiffrement BitLocker sur els machines en attendant une migration vers le Cloud ou l’utilisation de System Center Configuration Manager (SCCM). Microsoft a repoussé la date de fin de support étendu au 14 Avril 2026.

Beaucoup de clients vont continuer d’utiliser MBAM en mode autonome. Microsoft a alors publié une procédure permettant de :

• Désactiver TLS 1.0 et 1.1 sur les serveurs MBAM
• Forcer TLS 1.2 sur les serveurs MBAM

Vous devez

1. Installer .NET Framework 4.8
2. Exécuter des scripts PowerShell de configuration

Plus d’informations sur : Steps to disable the TLS 1.0 and 1.1 on the MBAM Servers and force the use of TLS 1.2

Le 7 Avril 2020, Microsoft a tenu un Webinar sur le l’audit avancé proposé au travers de Microsoft 365. La solution donne une visibilité sur de nombreux types d'activités auditées dans de nombreux services différents de Microsoft 365.

Vous pouvez revoir le Webinar

Le 15 Avril 2020, Microsoft a tenu un Webinar sur le Compliance Score proposé au travers du centre de conformité de Microsoft 365. La solution calcule un score basé sur le risque mesurant vos progrès dans la réalisation des actions qui contribuent à réduire les risques autour de la protection des données et des normes réglementaires.

Vous pouvez revoir le Webinar

Microsoft vient de publier une mise à jour (1.5.29.0) à Azure AD Connect. Azure Active Directory Connect (AADC) est anciennement DirSync et Azure Active Directory Sync (AAD Sync). Pour rappel, l’outil a été développé afin de fournir aux utilisateurs une identité hybride commune à travers les services on-premises et cloud en utilisant Active Directory connecté à Azure Active Directory. Ainsi, les utilisateurs peuvent bénéficier d’une identité commune pour les comptes à travers Office 365, Intune, des applications SaaS et des applications tierces.

Elle corrige un problème où les administrateurs du tenant soumis à l’authentification multi facteurs (MFA) ne pouvaient pas activer Directory Seamless Single Sign-On (DSSO).

 

En temps une version 1.5.22.0 a aussi été publié pour corriger un problème si vous avez cloné la règle In from AD - Group Join sans avoir cloné In from AD - Group Common.

Plus d’informations sur les fonctionnalités et les différences : https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history#15290

Télécharger Microsoft Azure Active Directory Connect

Microsoft a annoncé que la prochaine version du client Unified Labeling d’Azure Information Protection ne supporterait que TLS 1.2 ou ultérieur. Les entreprises qui n’ont pas la configuration adéquate, ne pourront utiliser les stratégies, les tokens, l’audit ou la protection d’Azure Information Protection.

Ce changement est prévu pour Juin 2020.

Microsoft s’apprête à tenir un Webinar sur le télétravail et la protection des données avec Information Protection. Ceci inclut : Microsoft Information Protection, Azure Information Protection, Data Loss Prevention d’Office 365, etc. Il aura lieu le 27 Avril 2020 de 18h à 19h30 (heure française)

L’agenda est le suivant :

• Limiter les expériences de Teams pour les invités et les personnes extérieures à l’organisation - comment les entreprises peuvent utiliser les labels de confidentialité pour protéger le contenu des Teams, des groupes Office 365 et des sites SharePoint Online.
• Appliquer la prévention des pertes de données dans Teams
• Appliquer des labels de confidentialité pour protéger les données sensibles
• Réduire le risque interne grâce à Insider Risk Management, à Communications Compliance, et à Information Barriers
• Permettre des stratégies de rétention simples
• Questions et réponses

Pour ajouter le rendez-vous à votre calendrier

Pour rejoindre le Webinar

Après quelques semaines, vous vous demandez peut-être si vous pouvez déployer Microsoft Endpoint Manager Configuration Manager 2002 (SCCM) dans sa version Early Wave. Microsoft propose un résumé des principaux problèmes et pour la version 2002, il existe un problème où une séquence de tâches ne peut s’exécuter sur une machine qui communique avec la Cloud Management Gateway (CMG).

Ceci survient dans les scénarios suivants :

• Vous configurez le site pour fonctionner en mode Enhanced HTTP et le Management Point est configuré pour fonctionner en HTTP. Microsoft recommande de configurer le Management Point en HTTPS.
• Vous avez installé et enregistré le client avec un token d’enregistrement en masse pour l’authentification. Pour résoudre ce problème, vous pouvez utiliser une des méthodes suivantes :
  • Pré-enregistrer le périphérique sur le réseau interne
  • Configurer le périphérique avec un certificat d’authentification client
  • Joindre la machine à Azure AD

Le scénario numéro 1 est celui que vous avez le plus de chance de rencontrer. Dans ce cas, vous pouvez attendre un correctif sur la version finale 2002.

Source : Release notes for Configuration Manager

Il semble qu’un problème touche System Center Configuration Manager 1902, 1906, 1910, 2002 où vous utilisez une Cloud Management Gateway (CMG) pour gérer des clients Intranet. Vous êtes dans le scénario suivant :

• Le client est sur le réseau Interne ou connecté via un VPN.
• Le client est géré via une Cloud Management Gateway en lieu et place d’un Management Point comme défini dans les Boundary Groups.
• L’authentification utilisée se fait via le token Azure AD (pas de PKI)

Le fichier SCClient affiche des erreurs comme suit :

Using endpoint Url: https://*********.CLOUDAPP.NET/CCM_Proxy_MutualAuth/72057594037927951:443/CMUserService_WindowsAuth, Windows authentication (Microsoft.SoftwareCenter.Client.Data.ACDataSource+<>c at <RefreshLocalSettingsAsync>b__16_0)

GetApplicationsAsync: The HTTP request was forbidden with client authentication scheme 'Negotiate'.. Unable to fetch user categories, unknown communication problem.      (Microsoft.SoftwareCenter.Client.ViewModels.SoftwareListViewModel+<LoadAppCatalogApplicationsAsync>d__164 at MoveNext)

Il semble qu’un client n’utilise pas l’authentification Azure AD comme cela est prévu pour parler à la CMG lorsqu’il est en mode Intranet. La solution de contournement revient à spécifier un Management Point dans les Boundary Groups (du VPN ou du site distant) en lieu et place d’une éventuelle CMG.

Note : Ceci n'affecte pas la gestion des clients Internet via un CMG

Source

En décembre dernier, Microsoft a publié les bonnes pratiques et paramétrages recommandés pour Exchange Online Protection (EOP) ainsi qu’Office 365 Advanced Threat Protection (ATP). Au travers d’un article, Microsoft recommande deux niveaux de sécurité : Standard et Strict. Le sujet couvre :

• La protection anti-spam d’Exchange Online Protection,
• La protection anti-malware d’Exchange Online Protection,
• La protection anti-phishing d’Exchange Online Protection,
• Les strategies anti-phishing d’Office ATP
• Les paramétrages Safe Links
• Les paramétrages Safe Attachments

En outre, Microsoft a publié un module PowerShell permettant d’évaluer voter configuration : Office 365 Advanced Threat Protection Recommended Configuration Analyzer (ORCA)
Vous pouvez l’installer via la commande : Install-Module -Name ORCA

Ensuite :

• Connectez-vous à Exchange Online avec les commandes :

$credential = Get-Credential

$exosession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid -Credential $credential -Authentication Basic –AllowRedirection

Import-PSSession $exosession

• Puis exécutez la commande : Get-ORCAReport

Cela donne un résultat comme suit et vous explique comment remédier les différentes règles selon les recommandations :

 

Lire Recommended settings for EOP and Office 365 ATP security

Microsoft vient de finaliser la version 1.2020.402.0 de son outil de packaging (MSIX Packing Tool). Cet outil permet de prendre un package d’application Win32 existant et de la convertir au format MSIX. Vous utilisez pour cela une machine de référence pour exécuter l’outil et obtenir le package MSIX que vous pouvez ensuite déployer à la main, par votre outil de télédistribution ou depuis le Microsoft Store.

Pour rappel, le format MSIX est un nouveau format standardisé lancé par Microsoft pour remplacer l’ensemble des formats de packaging existants tout en bénéficiant des avancés des différentes solutions : Click-To-Run (C2R), App-V, APPX et plus généralement du Framework d’applications universelles (UWP). Il offre donc des mécanismes de conteneurisation et les bénéfices des applications universelles avec une installation, mise à jour et désinstallation aisée sans laisser aucune trace sur le système. Il fournit aussi des mécanismes de sécurisation avancés permettant de valider l’intégrité du code exécuté. Ce format permet aussi de créer des personnalisations pour les applications packagées et de les faire perdurer au travers des différentes mises à jour de l’application.

Cette version apporte les éléments suivants :

• Le paramètre "Package Integrity" est activé par défaut
• Possibilité d'ajouter automatiquement le support MSIX Core à un MSIX
• Possibilité d'importer ou d'exporter des fichiers de registre (.reg) dans l'éditeur de paquets
• La page "Create package" affiche maintenant l'emplacement de sauvegarde par défaut.
• Ajout de l'extension InstalledLocationVirtualization
• Amélioration de la qualité des icônes extraites
• Amélioration de l'extraction des icônes à partir des raccourcis
• Validation du format du manifest après édition
• Faire passer un message plus clair en cas d'échec de la première tâche de lancement
• Interdire les chemins relatifs pour l’Unpack
• Mise à jour des filtres de fichiers afin qu'ils indiquent les formats valables (par exemple, pour les installateurs, il était dit . et maintenant *.msi, *.exe, ...)
• Correction de la conversion des espaces dans les chemins d'accès en "%20" lors de l’Unpack
• Corrections de bugs

Pour accéder à l’outil, vous devez :

• Participer au programme Windows Insider Fast ou Slow Ring
• Avoir Windows 10 17701 ou plus
• Avoir les droits d’administrateur sur la machine
• Avoir un compte Microsoft pour accéder au Microsoft Store.

Plus d'éléments sur le format MSIX sur MSIX Intro

Télécharger MSIX Packing Tool

Saaswedo a mis à jour son service de gestion des dépenses télécom (TEM) Datalert. Pour rappel, ce service de Telecom Expenses Management s’intègre à Microsoft Intune. Cette mise à jour v1.8.4.4 propose les améliorations suivantes :

• Les réglages sont désormais plus simples. Il inclut les dernières modifications de la notification d'arrière-plan Apple.
• Nouvelle application iOS (1.6.2) incluant de nouvelles règles d'Apple pour la gestion des activités de fond

Note la version 1.6.3 est attendue pour le 21 Avril avec :

• Une adaptation à la taille de l'écran de l'iPhone X et +
• iOS en mode sombre géré et affichera correctement les informations dans les paramètres de Datalert

 

Plus d’informations sur le site de Saaswedo.

Microsoft vient d’annoncer la mise à disposition d’un nouvel ensemble de fonctionnalités pour Microsoft Intune.

Les fonctionnalités suivantes sont ajoutées :

Enregistrement des périphériques

• [iOS/iPadOS/macOS] Auparavant, vous ne pouviez pas supprimer un profil par défaut, ce qui signifiait que vous ne pouviez pas supprimer le jeton Automated Device Enrollment qui lui était associé. Maintenant, vous pouvez supprimer le jeton quand aucun appareil n'est attribué au jeton et qu’un profil par défaut est présent Pour ce faire, supprimez le profil par défaut, puis supprimez le jeton associé.
• [iOS/iPadOS/macOS] Intune supporte jusqu'à 1000 profils d'inscription par jeton, 2000 jetons d'inscription automatique de périphériques (anciennement appelés DEP) par compte Intune, et 75 000 périphériques par jeton. Il n'y a pas de limite spécifique pour les périphériques par profil d'inscription, en dessous du nombre maximum de périphériques par jeton. Intune supporte désormais jusqu'à 1000 profils Apple Configurator 2.

Gestion du périphérique

• [Général] Sur la page All Devices, les entrées de la colonne Managed by ont changé :
  • Intune est maintenant affiché à la place de MDM
  • Co-managed est maintenant affiché à la place de MDM/ConfigMgr Agent

Les valeurs d'exportation sont inchangées.

• [Général] Vous pouvez cibler les paramètres dans le volet de personnalisation sur des groupes d'utilisateurs. Pour trouver ces paramètres dans Intune, sélectionnez Tenant administration > Customization.

• [General] Vous pouvez configurer une notification "push" à envoyer à vos utilisateurs Android et iOS lorsque le type de propriétaire de leur périphérique a été modifié de "Personnel" à "Entreprise" par souci de confidentialité. Cette notification push est désactivée par défaut. Vous trouverez ce paramètre en sélectionnant Tenant administration > Customization.

• [Général] Vous pouvez maintenant voir le numéro de version de TPM sur la page du matériel d'un périphérique (Devices > choisissez un périphérique > Hardware > Regarder dans System enclosure).

 

Configuration du périphérique

• [iOS/iPadOS/macOS] Vous pouvez utiliser plusieurs règles VPN à la demande dans le même profil VPN avec l'action Evaluer chaque tentative de connexion (Devices > Configuration profiles > Create profile > iOS/iPadOS ou macOS comme plateforme > VPN pour profil > Automatic VPN > On-demand). Chaque règle est évaluée dans l'ordre où elle apparaît dans la liste des règles à la demande.

• [iOS/iPadOS] Sur les périphériques iOS/iPadOS, vous pouvez :
  • Dans les profils SSO (Devices > Configuration profiles > Create profile > iOS/iPadOS comme plateforme > Device features pour profil > Single sign-on), vous pouvez définir le nom principal Kerberos comme étant le nom de compte Security Account Manager (SAM) dans les profils SSO.
  • Dans les profils d'extension d'application SSO (Devices > Configuration profiles > Create profile > iOS/iPadOS pour plateforme > Device features comme profil > Single sign-on app extension), vous pouvez configurer l'extension Microsoft Azure AD iOS/iPadOS en moins de clics en utilisant un nouveau type d'extension d'application SSO. Vous pouvez activer l'extension Azure AD pour les périphériques en mode partagé et envoyer des données spécifiques à l'extension.
• [macOS] De nouveaux paramétrages de script Shell sont disponible sur macOS avec notamment :
  • Cacher les notifications de script sur les périphériques
  • Fréquence de script
  • Nombre maximum de tentative si le script échoue

 

Gestion des applications

• [Android Enterprise] Les entreprises qui utilisent les test tracks de Google Play pour tester les applications en préversion peuvent gérer ces tracks avec Intune. Vous pouvez assigner de manière sélective les applications qui sont publiées sur les tracks de pré-production de Google Play à des groupes de pilotes afin d'effectuer des tests. Dans Intune, vous pouvez voir si une track de test de pré-production d'une application a été publiée, et vous pouvez également attribuer cette track à des groupes. Cette fonctionnalité est disponible pour tous les scénarios Android Enterprise (work profile, fully managed, et dedicated). Plus d'informations.
• [Android Enterprise] Vous pouvez utiliser les stratégies de configuration d'application (Apps > App configuration policies > Add > Managed devices) pour gérer le paramètre S/MIME pour Outlook sur les périphériques Android Enterprise. Vous pouvez également choisir d'autoriser ou non les utilisateurs de l'appareil à activer ou à désactiver S/MIME dans les paramètres d'Outlook.

• [Android Enterprise] Les stratégies de configuration des applications Android ont été mises à jour pour permettre aux administrateurs de sélectionner le type d'inscription avant de créer un profil de configuration de l'application. La fonctionnalité est ajoutée pour tenir compte des profils de certificat qui sont basés sur le type d'inscription (Work profile ou Device Owner). Cette mise à jour apporte les éléments suivants :
  • Si un nouveau profil est créé et que le profil Work Profile et Device Owner sont sélectionnés pour le type d'inscription, vous ne pourrez pas associer un profil de certificat à la stratégie de configuration de l'application.
  • Si un nouveau profil est créé et que le profil Work Profile uniquement est sélectionné, les stratégies de certificat du Work Profile créées, peuvent être utilisées.
  • Si un nouveau profil est créé et que l'option Device Owner uniquement est sélectionnée, les stratégies de certificat du Device Owner créées, peuvent être utilisées.

Les stratégies existantes créées avant la publication de cette fonctionnalité (Avril 2020 - 2004) qui n'ont pas de profils de certificat associés à la stratégie seront par défaut le profil Work Profile et Device Owner pour le type d'inscription. De même, les stratégies existantes créées avant la mise en place de cette fonctionnalité et auxquelles sont associés des profils de certificat seront par défaut uniquement Work Profile.

• [Android Enterprise] Microsoft ajoute les profils de configuration Email Gmail et Nine qui fonctionneront à la fois pour les types d'inscription "Work Profile" et "Device Owner", y compris l'utilisation de profils de certificat sur les deux types de configuration Email. Toutes les stratégies Gmail ou Nine que vous avez créées sous Device Configuration pour les Work Profile continueront à s'appliquer aux périphériques et il n'est pas nécessaire de les déplacer vers les stratégies de configuration des applications.

• [macOS] Microsoft Teams est désormais inclus dans la suite Office 365 pour macOS. Intune reconnaîtra les périphériques Mac existants sur lesquels sont installées les autres applications Office pour macOS et tentera d'installer les Microsoft Teams la prochaine fois que le périphérique se connectera à Intune.

 

Supervision et Dépannage

• [macOS] Vous pouvez désormais collecter des journaux pour améliorer le dépannage des scripts attribués aux périphériques MacOS. Vous pouvez collecter des journaux jusqu'à 60 Mo (compressés) ou 25 fichiers, selon ce qui se produit en premier.

 

Sécurité

• [Android Enterprise] Intune supporte l'utilisation de derived credentials comme méthode d'authentification pour les périphériques Android. Les Derived Credentials sont une implémentation de la norme 800-157 du National Institute of Standards and Technology (NIST) pour le déploiement de certificats sur les périphériques. Vous pouvez utiliser les Derived Credentials comme méthode d'authentification pour les profils de configuration des périphériques pour le VPN et le WiFi. Vous pouvez également les utiliser pour l'authentification des applications, ainsi que pour la signature et le chiffrement S/MIME. Intune supporte les fournisseurs Derived Credentials suivants avec Android : Entrust Datacard et Intercedez. Un troisième fournisseur, DISA Purebred, sera disponible pour Android dans une prochaine version.

Plus d’informations sur : https://docs.microsoft.com/en-us/intune/whats-new

Microsoft vient d’annoncer la version finale des baselines de paramétrages de sécurité pour Microsoft Edge v81. Ces dernières s’utilisent avec Security Compliance Toolkit (SCT). Les lignes de base permettent de vérifier la conformité d’une application vis-à-vis des bonnes pratiques et recommandations

Cette version 80 comprend 15 nouveaux paramètres de configuration machine et utilisateur. :

• Allow importing of Cookies
• Allow importing of extensions
• Allow importing of shortcuts
• Allow the audio sandbox to run
• Configure automatic sign in with an Active Directory domain account when there is no Azure AD domain account
• Enable a TLS 1.3 security feature for local trust anchors.
• Enable Ambient Authentication for InPrivate and Guest profiles
• Enable globally scoped HTTP auth cache
• Enable Microsoft Search in Bing suggestions in the address bar
• Enable stricter treatment for mixed content
• Specify how "in-page" navigations to unconfigured sites behave when started from Internet Explorer mode pages
• Use a default referrer policy of no-referrer-when-downgrade. (deprecated)

 

Voici un document présentant les différences entre la version 81 et 80

Plus d’informations sur l’article suivant :  https://techcommunity.microsoft.com/t5/microsoft-security-baselines/security-baseline-for-microsoft-edge-v81/ba-p/1303621

Télécharger Security Compliance Toolkit

Microsoft vient d’annoncer la version finale des baselines de paramétrages de sécurité pour Microsoft Edge v80. Ces dernières s’utilisent avec Security Compliance Toolkit (SCT). Les lignes de base permettent de vérifier la conformité d’une application vis-à-vis des bonnes pratiques et recommandations

Les paramétrages sont similaires à ceux recommandés pour la version 79 avec l’ajout du paramétrage "Configure Microsoft Defender SmartScreen to block potentially unwanted apps”. Les applications potentiellement non souhaitées (PUA) ne sont pas considérées comme des virus, des logiciels malveillants ou d'autres types de menaces, mais elles peuvent effectuer des actions sur les périphériques qui nuisent à leurs performances ou à leur utilisation (comme les logiciels publicitaires ou autres applications de faible réputation, etc).  À partir de Microsoft Edge 80, vous pouvez désormais bloquer les téléchargements PUA et les URL de ressources associées. 

Cette version 80 comprend 270 paramètres de configuration machine et 254 paramètres de configuration utilisateur.

 

Plus d’informations sur l’article suivant :  https://techcommunity.microsoft.com/t5/microsoft-security-baselines/security-baseline-for-microsoft-edge-v80/ba-p/1233193

Télécharger Security Compliance Toolkit

Je poste ce billet couvrant un bug dans Microsoft Intune lors de l’utilisation du portail d’entreprise en version 2.2.191101 pour les enregistrements des périphériques macOS. Normalement le bug n’est plus présent si l’utilisateur a mis à jour vers une version 2.2.191201 ou ultérieure. Le bug ne touche que le workflow Device Enrollement et n’impacte pas si le périphérique est enregistré au travers d’Apple Business Manager (ou DEP).

La version 2.2.191101 du portail d’entreprise publiée le 13 novembre 2019, comportait un bug d’enregistrement qui affectait la livraison des applications du programme d'achat en volume (VPP) sous licence utilisateur et des liens internet sur les périphériques Mac. Microsoft vous a normalement prévenu au travers du tableau de bord de santé via un bulletin IT199560.

Les utilisateurs finaux qui tentent de s’enregistrer avec la version concernée voient le message "We cannot enroll your device with this version of the Company Portal. To get an updated version of the Company Portal, download the latest version of the Company Portal app"

Microsoft vient d’annoncer la Public Preview de la classification automatique avec les labels/étiquettes de confidentialité avec Microsoft Information Protection pour les documents stockés sur OneDrive et SharePoint Online et pour les emails en transit dans Exchange Online.

Vous pouvez maintenant configurer des étiquettes de confidentialité à appliquer automatiquement aux fichiers Office (par exemple, PowerPoint, Excel, Word, etc.) et aux emails en fonction des stratégies de l’entreprise. Vous pouvez donc configurer des stratégies de classification automatique dans les services Microsoft 365 comme OneDrive, SharePoint Online et Exchange Online.

Pour plus d’informations sur la Preview : https://aka.ms/MIPC/O365AutolabelingPublicPreview

Source : Office 365 service-based auto-labeling for EXO (Data in transit) and SPO/OD (Data at rest) preview

Je vous partage un problème connu concernant Microsoft Information Protection et Azure Information Protection où les labels/étiquettes de confidentialité (Sensitivity) ne sont pas affichés sur Office Online ou Outlook Web. Ce problème survient quand les stratégies de labels ou d’étiquettes sont assignés à un ou plusieurs groupes imbriqués.

Un correctif est encore de préparation pour corriger ce problème. Dans l’immédiation, Microsoft recommande de ne pas utiliser les groupes imbriqués.

Source : https://support.microsoft.com/en-us/office/known-issues-with-sensitivity-labels-in-office-b169d687-2bbd-4e21-a440-7da1b2743edc?ui=en-us&rs=en-us&ad=us#ID0EBBAAA=Online