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

Les fonctionnalités suivantes sont ajoutées :

Gestion du périphérique

• [Windows] La gestion attachée au Cloud est une nouvelle fonctionnalité qui permet de connecter l’infrastructure Microsoft Endpoint Manager à Microsoft Intune afin de pouvoir remonter des informations et de lancer des actions à partir d’un portail unique celui de Microsoft Endpoint Manager/Microsoft Intune.

Configuration du périphérique

• [macOS] Il est maintenant possible de déployer aisément Microsoft Defender Advanced Threat Protection sur macOS depuis les applications.

Gestion des applications

• [Général] Microsoft Office 365 ProPlus est renommé en Microsoft 365 Apps for enterprise.

 

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

Microsoft propose un Webcast suivi de questions/réponses sur MSIX App Attach avec Windows Virtual Desktop. Cet évènement aura lieu aujourd’hui le 05 Mai à partir de 18h (heure française). Rejoignez Stefan Georgiev et Tanaka Jimha pour une heure d’un événement riche en informations.

L’enregistrement sera disponible à la demande par la suite.

Pour vous inscrire et suivre : https://aka.ms/webcast/MSIXappattach

Source 

Microsoft a introduit un ensemble de nouveautés dans Microsoft Cloud App Security (MCAS), sa solution Cloud Access Security Broker (CASB). Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

La version 172 introduit les changements suivants :

• Amélioration des contrôles d'accès et de session avec n’importe quel fournisseur d’identité (IdP) (Preview). Les contrôles d'accès et de session prennent désormais en charge les applications SAML configurées avec n'importe quel fournisseur d'identité. L'aperçu public de cette nouvelle fonctionnalité est maintenant progressivement mis en place. Pour configurer ces contrôles, voir le guide de déploiement.
• Nouveau processus désanonymisassions en masse des utilisateurs et des machines afin de simplifier le processus sur un ou plusieurs utilisateurs et machines sous investigation

Les versions 173 et 174 regroupent les éléments suivants :

• Nouveau format CEF sur l’agent SEIM pour les alertes. Afin d’enrichir les informations d'alerte fournies dans les fichiers CEF utilisés par les serveurs SIEM génériques, Microsoft a étendu le format pour inclure les champs clients suivants : Adresse IPv4, Adresse IPv6, Localisation de l'adresse IP
• Logique de détection améliorée : Voyage impossible (Impossible travel) afin d'améliorer la précision et de réduire le volume des alertes.

 

Plus d’informations sur : What's new with Microsoft Cloud App Security

Microsoft a introduit un ensemble de nouveautés dans Azure Active Directory en Avril 2020.

Microsoft apporte les nouveautés suivantes :

• Public Preview des unités administratives (Administrative Units) permettant d'accorder des autorisations administratives qui sont limitées à un département, une région ou un autre segment de l’entreprise que vous définissez. Ceci permet d’utiliser les unités administratives pour déléguer des autorisations aux administrateurs régionaux ou pour définir une stratégie à un niveau granulaire. Par exemple, un administrateur de compte d'utilisateur peut mettre à jour les informations de profil, réinitialiser les mots de passe et attribuer des licences pour les utilisateurs uniquement dans son unité administrative.

• Disponibilité Générale de l’expérience combinée d’enregistrement des informations de sécurité pour l’authentification à facteurs multiples (MFA) et la réinitialisation du mode passe en libre-service (SSPR). Lorsque vous déployez la nouvelle expérience pour une entreprise, les utilisateurs peuvent s'inscrire en moins de temps et avec moins d’étapes.

• L'évaluation continue de l'accès (Continuous Access Evaluation) est une nouvelle fonction de sécurité qui permet l'application en temps quasi réel des stratégies aux éléments qui consomment des jetons d'accès Azure AD lorsque des événements se produisent dans Azure AD (comme la suppression d'un compte utilisateur). Microsoft propose d’abord cette fonction pour Teams et les clients Outlook.
• Les employés sur le terrain peuvent se connecter avec des applications utilisant l’authentification sans moderne, simplement avec leur numéro de téléphone et sans mot de passe. Ce mécanisme dans les applications Office s'adresse aux entreprises qui n'utilisent pas l’email comme principal moyen de communication. Ce projet permettra à des employés de se connecter à des applications professionnelles en entrant un numéro de téléphone et en tapant un code.

• L’expérience du portail d’administration Azure AD donne accès à des actions en masse et de téléchargement sur les utilisateurs et groupes. Vous pouvez uploader un fichier CSV pour créer, supprimer, inviter des utilisateurs ou supprimer et ajouter des membres à un groupe.

• On retrouve quatre nouveaux rôles RBAC dans Azure Active Directory :
  • Printer Administrator : Les utilisateurs ayant ce rôle peuvent enregistrer des imprimantes et gérer tous les aspects de toutes les configurations d'imprimantes dans la solution Universal Print, y compris les paramètres du connecteur Universal Print. Ils peuvent consentir à toutes les demandes d'autorisation d'impression déléguées. Les administrateurs d'imprimantes ont également accès aux rapports d'impression.
  • Printer Technician : Les utilisateurs ayant ce rôle peuvent enregistrer des imprimantes et gérer le statut des imprimantes dans la solution Universal Print. Ils peuvent également lire toutes les informations relatives aux connecteurs. Les principales tâches qu'un technicien en impression ne peut pas effectuer sont la définition des autorisations d'utilisateur sur les imprimantes et le partage des imprimantes.
  • Hybrid Identity Admin : Les utilisateurs dans ce rôle peuvent activer, configurer et gérer les services et les paramètres liés à l'activation de l'identité hybride dans Azure AD. Ce rôle donne la possibilité de configurer Azure AD pour l'une des trois méthodes d'authentification prises en charge – Password Hash Synchronization (PHS), Passthrough Authentication (PTA) ou fédération (AD FS ou fournisseur de fédération tiers) - et de déployer l'infrastructure On-Premise correspondante pour les activer.
  • Network Administrator : Les utilisateurs ayant ce rôle peuvent examiner les recommandations de Microsoft en matière d'architecture de périmètre de réseau qui sont basées sur la télémétrie de réseau à partir de leurs emplacements d'utilisateur. Ce rôle permet d'éditer les emplacements des utilisateurs découverts et de configurer les paramètres du réseau pour ces emplacements afin de faciliter l'amélioration des mesures de télémétrie et des recommandations de conception.
• Nous étendons la capacité d'invitation B2B pour permettre aux comptes internes existants d'être invités à utiliser des identifiants de collaboration B2B à l'avenir. Cela se fait en passant l'objet utilisateur à l'API d'invitation en plus des paramètres typiques comme l'adresse électronique invitée. L'ID de l'objet de l'utilisateur, l'UPN, l'appartenance à un groupe, l'attribution d'une application, etc. restent intacts, mais à l'avenir, l'utilisateur utilisera le B2B pour s'authentifier avec ses références de tenant plutôt qu'avec les références internes qu'il utilisait avant l'invitation.
• Le mode "Report-only" pour l'accès conditionnel à Azure AD vous permet d'évaluer le résultat d'une stratégie sans avoir à appliquer des contrôles d'accès. Au cours des derniers mois, Microsoft a constaté une forte adoption du mode Report-only, avec plus de 26 millions d'utilisateurs déjà concernés par une stratégie de Report-only. Avec cette annonce, de nouvelles stratégies d'accès conditionnel Azure AD seront créées par défaut en mode Report-only. Il est aussi possible de gérer les stratégies de type " Report-only " par GraphAPI.

• Disponibilité Générale du workbook Conditional Access insights and reporting qui donne une vue d'ensemble de l'accès conditionnel Azure AD. Il est possible de sélectionner une stratégie individuelle permettant aux administrateurs de mieux comprendre les effets de chaque stratégie et suivre les changements en temps réel. Le workbook transmet en continu les données stockées dans Azure Monitor.

• Public Preview de la nouvelle tuile de détail des stratégies affichant les affectations, les conditions et les contrôles qui ont été satisfaits lors de l'évaluation de la stratégie d'accès conditionnel. Vous pouvez accéder à la tuile en sélectionnant une ligne dans les onglets Conditional Access ou Report-only dans Sign-in details.
• 31 nouvelles applications fédérées sont ajoutées à la galerie d’applications Azure AD avec notamment : SincroPool Apps, SmartDB, Float, LMS365, IWT Procurement Suite, Lunni, EasySSO for Jira, Virtual Training Academy, Meraki Dashboard, Office 365 Mover, Speaker Engage, Honestly, Ally, DutyFlow, AlertMedia, gr8 People, Pendo, HighGround, Harmony, Timetabling Solutions, SynchroNet CLICK, empower, Fortes Change Cloud, Litmus, GroupTalk, Frontify, MongoDB Cloud, TickitLMS Learn, COCO, Nitro Productivity Suite , Trend Micro Web Security(TMWS)
• Disponibilité Générale de la configuration des tokens : Azure AD émet des tokensavec un ensemble de claims par défaut. La configuration des tokens permet de personnaliser les tokens d'accès, les tokens d'identification et les tokens SAML afin d'inclure des claims supplémentaires. Ces claims supplémentaires vous permettent d'obtenir plus de détails sur un utilisateur lorsqu'il est authentifié dans votre application.
• Disponibilité Générale du chiffrement des tokens SAML : Azure AD envoie déjà des tokens SAML sur un canal de transport HTTPS chiffré. Vous pouvez maintenant aussi configurer le chiffrement des tokens SAML afin d'obtenir une assurance supplémentaire, le cas échéant, que le contenu du token ne peut pas être intercepté et que les données personnelles ou d'entreprise ne peuvent pas être compromises.
• My Staff permet aux responsables sur le terrain de s'assurer que le personnel peut accéder à leurs comptes Azure AD. Au lieu de dépendre d'un service d'assistance central, les entreprises peuvent déléguer des tâches communes, telles que la réinitialisation des mots de passe ou la modification des numéros de téléphone, à un responsable de première ligne. Avec My Staff, un utilisateur qui n'a pas accès à son compte peut y accéder à nouveau en quelques clics seulement, sans qu'il soit nécessaire de faire appel à un service d'assistance ou à du personnel informatique.
• Public Preview du support des requêtes incrémentale Microsoft Graph pour
  • oAuth2PermissionGrant afin de traquer les changements sans avoir à interroger continuellement Microsoft Graph.
  • Les unités administratives (Administrative Units) afin de traquer les changements sans avoir à interroger continuellement Microsoft Graph.
• Disponibilité Générale de la recherche incrémentale pour
  • Les contacts organisationnels afin de suivre les changements dans les applications de production sans avoir à interroger continuellement Microsoft Graph.
  • Les applications afin de suivre les changements sur les applications de production sans avoir à interroger continuellement Microsoft Graph.
• Vous pouvez gérer les numéros de téléphone d’authentification et d’autres éléments des méthodes d’authentification dans les nouvelles APIs de Microsoft Graph Beta.

 

On retrouve les modifications de service suivantes :

• Public Preview de la validation des règles des groupes dynamiques. Un onglet Validate rules, vous pouvez valider votre règle dynamique par rapport aux membres du groupe d'échantillons pour confirmer que la règle fonctionne comme prévu. Lors de la création ou de la mise à jour de règles de groupe dynamiques, les administrateurs veulent savoir si un utilisateur ou un périphérique sera membre du groupe.

• Identity Secure Score – Mise à jour des actions d’amélioration pour la sécurité par défaut et le MFA.
• Microsoft a mis à jour l'expérience des évaluateurs pour Access Reviews à Azure AD dans le portail My Apps. A la fin du mois d'avril, les évaluateurs verront une bannière qui leur permettra d'essayer la nouvelle expérience dans My Access. Cette expérience est la même que l'expérience actuelle, mais avec une interface utilisateur améliorée en plus de nouvelles capacités. En juillet, les évaluateurs seront automatiquement dirigés vers My Access pour effectuer des évaluations d'accès.
• Les applications de provisionnement et de reprise des utilisateurs de Workday prennent désormais en charge les dernières versions de l'API des services Web Workday.
• Microsoft a remis à jour l’expérience en matière d'approvisionnement afin de créer une vision plus ciblée de la gestion. Lorsque vous naviguez vers la tuile de provisionnement d'une application d'entreprise déjà configurée, vous pouvez facilement suivre la progression du provisionnement et gérer des actions telles que le démarrage, l'arrêt et le redémarrage du provisionnement.

Plus d’informations sur : What’s new Azure AD

Voici un résumé des changements et fonctionnalités apportés à Microsoft Defender Advanced Threat Protection (ATP) introduit dans le mois.

• Exécutez les appels API liés à la gestion des menaces et des vulnérabilités (Threat & Vulnerability Management), par exemple pour obtenir le score d'exposition aux menaces ou le score de sécurité des périphériques, l'inventaire des vulnérabilités des logiciels et des machines, la distribution des versions de logiciels, les informations sur la vulnérabilité des machines, les informations sur les recommandations de sécurité.
• Microsoft a introduit un tag COVID-19 dans les recommandations de sécurité de la fonctionnalité de gestion des vulnérabilités et des menaces (TVM) de Microsoft Defender ATP. Ce tag permet d’identifier les actions à réaliser sur les machines qui sont relatives à la crise du COVID-19 et des différentes menaces qui ont émergés.

• Public Preview de la fonctionnalité Live Response pour des versions antérieures de Windows 10 incluant Windows 10 1709, 1803 et 1809. Certaines mises à jour doivent être installés sur ces systèmes pour permettre le support.

• Toujours sur la fonctionnalité Live Response, il est possible de télécharger des fichiers en fond de tâches via la commande download <chemin du fichier> puis CTRL + Z.

• Disponibilité Générale des APIs de gestion des vulnérabilités et des menaces (TVM). Ceci vous permettra de créer des rapports et des interfaces personnalisés ou des mécanismes d’automatisation.

Plus d’informations sur : What’s new in Microsoft Defender ATP

Microsoft vient de mettre à disposition la Technical Preview 2004 (5.0.8991.1000) de Microsoft Endpoint Manager Configuration Manager. Pour rappel, Microsoft a annoncé le renommage de System Center Configuration Manager pour faire partie d’une même suite avec Microsoft Intune, Desktop Analytics, Autopilot, etc. sous le nom Microsoft Endpoint Manager. L’outil ne fait donc plus parti de la gamme System Center. Si vous souhaitez installer cette Technical Preview, vous devez installer la Technical Preview 2003 puis utiliser la fonctionnalité Updates and Servicing (nom de code Easy Setup).

System Center Configuration Manager TP 2004 comprend les nouveautés suivantes :

Administration

• Vous pouvez maintenant choisir de recevoir des notifications de Microsoft dans la console d’administration. Ces notifications vous permettent de rester informé des nouvelles fonctionnalités ou des mises à jour, des modifications apportées à ConfigMgr et aux services qui y sont associés, ainsi que des problèmes qui nécessitent une action pour y remédier.

• Basé sur UserVoice, vous pouvez maintenant copier les données de découverte des périphériques et des utilisateurs dans la console. Ces nouvelles actions vous permettent d'obtenir plus facilement et rapidement ces données depuis la console. Par exemple, vous pouvez copier l'adresse MAC d'un périphérique avant de le redéployer.

• La bibliothèque de cmdlets PowerShell Configuration Manager offre maintenant un support pour PowerShell 7. Le support de PowerShell 7 est Preview, et n'est pas destiné à être utilisé dans des environnements de production.

• On retrouve de nouvelles règles Management Insight pour le déploiement de système d’exploitation afin de gérer la taille des séquences de tâches. Lorsque la taille de la stratégie de séquence de tâches dépasse 32 Mo, le client ne parvient pas à exécuter le déploiement de la séquence de tâches. On en retrouve deux :
  • Large task sequences may contribute to exceeding maximum policy size : Si vous déployez ces séquences de tâches, les clients peuvent ne pas être en mesure de traiter les grands objets. Réduisez la taille de la séquence de tâches pour éviter les problèmes potentiels de traitement des stratégies.
  • Total policy size for task sequences exceeds policy limit : Les clients ne peuvent pas traiter la stratégie pour ces séquences de tâches parce qu'elle est trop importante. Réduisez la taille de la stratégie de séquence de tâches pour permettre au déploiement de fonctionner sur les clients.

 

Cloud and Tenant-Attach

• Vous pouvez maintenant voir les détails du client, y compris les collections, l'appartenance à un groupe de limites (uniquement si vous utilisez un site primaire autonome) et les informations client en temps réel pour un appareil spécifique dans le centre d'administration de Microsoft Endpoint Manager.

 

Inventaires et Reporting

• Microsoft a ajouté la possibilité d'exécuter CMPivot à partir d'un périphérique individuel ou de plusieurs périphériques à partir du nœud de périphériques sans avoir besoin de sélectionner une collection de périphériques. Cette amélioration facilite la création de requêtes CMPivot pour des périphériques spécifiques en dehors d'une collection pré-créée.
• Microsoft a également fait converger CMPivot autonome et CMPivot lancé depuis la console d'administration. Lorsque vous lancez CMPivot à partir de la console d'administration, il utilise la même technologie sous-jacente que CMPivot autonome pour vous donner la parité des scénarios.

 

Déploiement de système d’exploitation

• Basé sur UserVoice, vous pouvez utiliser une variable de séquence de tâches pour spécifier la cible de la tâche Format and Partition Disk. Cette nouvelle option de variable prend en charge des séquences de tâches plus complexes avec des comportements dynamiques. Par exemple, un script personnalisé peut détecter le disque et définir la variable en fonction du type de matériel. Vous pouvez ensuite utiliser plusieurs instances de cette étape pour configurer différents types de matériel et de partitions.
  • Vous pouvez maintenant utiliser PowerShell pour créer et configurer des séquences de tâches comme un type de déploiement de modèle d'application via Add-CMTaskSequenceDeploymentType et Set-CMTaskSequenceDeploymentType

 

Plus d’informations sur : https://docs.microsoft.com/en-us/sccm/core/get-started/2019/technical-preview-2004

J’ai plusieurs labs de machines virtuelles hébergés dans Microsoft Azure. Comme je les arrête dès que je ne m’en sers pas, les adresses IP publiques changent systématiquement. Dès que je les allume, je dois systématiquement retélécharger les fichiers RDP à partir du portail Azure. Fatigué de toujours retélécharger ces fichiers, j’ai cherché à savoir si Royal TS s’interconnectait directement à Microsoft Azure pour générer des connexions sur les machines virtuelles. Malheureusement, ce très bon outil de gestion des connexions, ne le fait pas et il n’existe aucun plugin ou extensions le permettant. En cherchant sur Internet, je suis tombé sur le projet Ryan Hoffman permettant via un script PowerShell de générer un document avec toutes les machines virtuelles.

Aujourd’hui ce script ne fonctionne que pour des machines virtuelles ASM. Vous devez comme moi utiliser Azure Resource Manager (ARM) pour générer les machines virtuelles ce qui rend le script obsolète. J’ai décidé de passer une petite heure pour le revoir et compléter.

Il génère donc un document Royal TS à partir des abonnements Azure pour des machines virtuelles Windows uniquement (à date).

Parmi les prérequis nécessaires :

• PowerShell 5.1
• Import-Module RoyalDocument.PowerShell
• Import-Module AzureRM.Compute
• Import-Module AzureRM.Network
• Les droits sur les abonnements/subscriptions

Basiquement, il :

• Liste tous les abonnements et recherche les VMs et leurs adresses IP publiques
• Créé un document Royal TS
• Recrée la hiérarchie de dossiers sur la base des abonnements Azure
• Crée un identifiant générique
• Crée une connexion RDP pour chaque VM ayant une adresse IP publique
• Lie l’identifiant générique à chaque connexion RDP créé

Ce qu’il ne fait pas :

• Gérer Azure Bastion
• Gérer les VMs Linux avec SSH
• Gérer les VMs sans adresse IP publique
• Gérer différentss identifiants de connexion selon la machine virtuelle ou des groupes de VMs
• Gérer la personnalisation du port RDP. J'ai mis le port 3389 par défaut mais il est possible de le changer dans le script. Je n’ai pas poussé le script jusqu’à chercher une règle RDP dans les NSG afin d’en récupérer le port RDP.
• Gérer toute une série d’exceptions et de scénarios auxquels je n’ai pas pensé
• Etc

Bien entendu, il y a la place pour de l’évolution et de l’amélioration pour ceux qui seraient intéressés.

En pratique, vous pouvez :

• Récupérer le script
• Changer les variables essentielles (chemin du fichier, port, nom du document, etc.)
• Créer un lien Windows que vous mettez sur votre bureau et qui pointe sur le script PowerShell dans un dossier dédié en exécutant la commande : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "& '<chemin vers le script> \AzureToRoyalTS.PS1'

Lors de l’exécution, ce sont les informations que vous obtenez :

 

Le script génère un fichier qui, une fois ouvert, comprend toutes les machines virtuelles ayant une adresse IP :

 

Télécharger AzureToRoyalTS

Microsoft vient de communiquer un problème touchant Microsoft Intune et qu'un paramètre de configuration de MacOS FileVault chiffre les périphériques malgré le fait qu'il soit réglé pour permettre le contournement.

Ce problème a une incidence que si vous définissez ou prévoyez de définir le chiffrement pour les périphériques MacOS. Vous pouvez voir si vous avez configuré cette politique en allant dans Devices > macOS | Configuration profiles > Endpoint protection > enable Full Disk Encryption using XTS-AES 128 with FileVault 2 > Number of times allowed to bypass > No limit, always prompt.

Le chiffrement se produit lorsque le périphérique reçoit la stratégie et que l'utilisateur effectue la connexion suivante, malgré l'intention de l'administrateur de demander et de permettre à l'utilisateur final de décider du meilleur moment pour chiffrer un périphérique.

Si vous voulez toujours inviter l'utilisateur à chiffrer mais sans jamais exiger que le périphérique le fasse, une fois la correction apportée, vous devez revenir à votre stratégie FileVault existante et changer la valeur de "0", qui est une nouvelle valeur, à " No limit, always prompt". Pour les stratégies FileVault nouvelles et existantes, après la version de juin, vous verrez les valeurs correctes et le comportement correspondant.

Microsoft teste un correctif et devrait le déployer dans la version de juin d'Intune.

Microsoft vient de publier une nouvelle version (10.1.0.0) le pack d’administration ou Management Pack (MP) SCOM pour la fonctionnalité de Cluster. Cette version a complétement été réécrite pour l’arrivée de Windows Server 2016 et Windows Server 1709 ou plus. 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.

Cette version apporte les versions localisées du Management Pack.

Lisez le guide associé au Management Pack pour mettre en œuvre la supervision et activer les règles nécessaires.

Télécharger Microsoft System Center Management Pack for Windows Server Cluster 2016 and 1709 Plus

Microsoft prépare un changement dans l’expérience de changements des mots de passe liés à une stratégie de mot de passe appliquée par Microsoft Intune sur les périphériques macOS. Le workflow actuel comprend un bug pour lequel Microsoft va effectuer un changement qui dépend de la version de macOS :

• Les périphériques macOS qui exécutent la version 10.13x à 10.14x :
  • Le mot de passe devra toujours être modifié si le périphérique détecte un changement de politique de mot de passe :
    • Cela se produit lorsque des utilisateurs sont déplacés d'un groupe avec une stratégie de mot de passe à un autre et même si la stratégie est la même.
    • Cela se produit lorsque la stratégie de mot de passe est mise à jour de quelque manière que ce soit et envoyée au périphérique.
    • Ce comportement se poursuivra à partir de mai 2020, à moins que le périphérique ne soit mis à jour à la version 10.15 ou plus.
  • A partir de mai 2020, tous les périphériques macOS fonctionnant sous 10.15-10.15.x - Après une mise à jour quelconque de la stratégie de mots de passe, l'appareil ne doit pas demander de changement de mot de passe.
    • Toutefois, le péripéhrique peut se révéler non conforme jusqu'à ce que le mot de passe soit mis à jour manuellement par l'utilisateur final.
    • C'est le cas à partir de mai, quelle que soit la version du périphérique Mac (10.12, 10.13, 10.14, etc.)
    • Tous les paramètres du mot de passe s'appliqueront toujours au périphérique. Si l'administrateur fixe une expiration de 30 jours à la stratégie, l'utilisateur final sera toujours invité à changer son mot de passe tous les 30 jours.
  • À partir de macOS 10.16 (pas encore publié à date), tout changement ou mise à jour de la politique de code d'accès obligera une fois de plus l'utilisateur à mettre à jour son mot de passe sur le péripéhrique.

Vous devez prévenir le support informatique que vous ne pouvez pas forcer les périphériques macOS 10.15 à mettre à jour leurs mots de passe par la seule mise à jour de la stratégie des mots de passe. Sachez que les utilisateurs de macOS peuvent subir des réinitialisations de mot de passe lorsque vous les faites entrer ou sortir de différents groupes.

Plus d’infos

Si vous utilisez Azure Advanced Threat Protection (AATP) et Azure AD Connect pour synchroniser vos objets et identités dans Azure AD, il existe certaines considérations afin de ne pas générer des alertes non justifiées. C’est notamment le cas lorsque vous utilisez les fonctions de réécriture (writeback) de périphérique, de mot de passe, de groupe, etc. Dans ce scénario, les serveurs Azure AD Connect génèrent une demande de réplication sur les contrôleurs de domaine afin de modifier et répliquer les changements. Les serveurs n’étant pas des contrôleurs de domaine, Azure ATP pense à une attaque et génère une alerte de type Suspected DCSync attack (replication of directory services)

Dans ce cas de figure, vous devez créer une exclusion en naviguant dans paramètres (la roue crantée) puis Exclusions (sous Détection).

 

Cherchez ensuite l’alerte Suspected DCSync attack (replication of directory services) puis ajoutez les différents comptes MSOL_<XXXX> utilisés par vos serveurs Azure AD Connect. En outre, ajoutez les serveurs Azure AD Connect dans la liste des ordinateurs :

Cliquez ensuite sur Enregistrer en bas de la page.

 

En retournant sur la chronologie, vous pouvez observer que les alertes en question, ont été fermées :

Il y a quelques jours, je vous communiquais des informations relatives au support des plateformes par le MDM Office 365. Un complément d’informations a été apporté qui est applicable au MDM Office 365 et à Microsoft Intune. Celui-ci concerne les périphériques équipés d’Android 9 ou d’une version ultérieure :

• Il ne sera pas possible de gérer les paramètres de mot de passe excepté sur les périphériques Samsung Knox
• Il ne sera pas possible de désactiver la caméra excepté sur les périphériques Samsung Knox

 

Ces limitations sont relatives à la plateforme et non à la solution MDM.

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.