Microsoft vient de mettre à jour (6.7.7.0) le pack d’administration ou Management Pack (MP) SCOM pour superviser SQL Server 2008, 2008 R2 et 2012. Il fonctionne avec SCOM 2012 SP1 ou plus. Cette nouvelle version apporte les éléments suivants :

• Correction d’un problème : L’expansion d’une flèche a une couleur de contraste faible quand le groupe de santé est regroupé dans une vue d’instance.
• Correction d’un problème dans la Web Console les tableaux de bord envoie des requêtes en continu à la base de données
• Correction d’un problème : Le premier objet n’est pas sélectionné dans la liste d’objets après l’ouverture de la liste déroulante.
• Correction d’un problème la position de la barre de navigation horizontale est réinitialisée après le rafraîchissement de la vue d’instance.
• Correction d’un problème : Un message « No Data » est affiché sur plusieurs tuiles après la mise à jour du management pack de Dashboards de la version 6.7.2.0 vers une version 6.7.4.0 ou plus
• Restauration de l’ordre correct des groupes dans les vues des dashboard SQL Server Summary.

Télécharger System Center Management Pack for SQL Server

Microsoft vient de publier un Management Pack (1.0) pour superviser Windows Server 2016 Essentials. 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.

Lisez le guide pour implémenter et obtenir plus d’information sur ce qui est supervisé par défaut ou ce qui doit être activé via des overrides.

Télécharger System Center Operations Manager Management Packs for Windows Server 2016 Essentials

Microsoft IT a publié un très bon guide visant à détailler comment déployer et mettre à jour le client Office 365 ProPlus en utilisant System Center Configuration Manager Current Branch. Comme vous le savez Office 365 ProPlus adopte le même principe as-a-Service que Windows 10 et System Center Configuration Manager. Quand Microsoft publie une nouvelle mise à jour du client Office 365 vers l’Office Content Delivery Network (CDN), Microsoft publie aussi le package sur Microsoft Updates. A partir de Configuration Manager 1602, il devient possible de gérer les mises à jour du client Office 365 ProPlus via le processus de mise à jour logiciels.

Le guide détaille le fonctionnement et les différents points d’attention à prendre en compte.

Lire : Deploying and updating Microsoft Office 365 ProPlus

Microsoft a publié un article dans la base de connaissances concernant System Center 2012 R2 Configuration Manager SP1 CU1, les clients sont automatiquement mis à jour avec la version SP1 du client. Ceci est un problème connu où la tâche planifiée Configuration Manager Client Retry est créée sous Microsoft\Microsoft\Configuration Manager. Après qu’il est installé, le client ConfigMgr ne peut supprimer la tâche planifiée qui a été créé dans cet emplacement. Le client est alors réinstallé toutes les 5 heures.

Pour résoudre le problème, vous devez supprimer la tâche sous Microsoft\Microsoft\Configuration Manager.

Plus d’informations sur la KB3123029 Configuration Manager clients are automatically upgraded after a ConfigMgr 2012 R2 update to CU1

Microsoft vient de publier une mise à jour pour Microsoft Advanced Threat Analytics 1.7 (ATA). Depuis maintenant plusieurs mois des cyber-attaques retentissantes se suivent ! Que l’on parle de Sony, Target, Orange, etc. Tous ont été touchés par des attaques suivies par des fuites de données sensibles. Dans 75 % des cas, l’intrusion réseau est due à une compromission des identifiants utilisateurs. Les attaquants ont changé leurs habitudes en utilisant les outils d’administration légitimes plutôt que des logiciels malveillants afin de se rendre invisibles et indétectables. Dans les attaques ciblées, les pirates peuvent mettre au point des logiciels dédiés à l’attaque pour ne pas détecter par les antivirus. Devant cette problématique latente, Microsoft a lancé une solution on-premises pour identifier les attaques de sécurité avancées avant qu’elles ne causent des dommages à l’entreprise. Microsoft Advanced Threat Analytics (ATA) est basée sur la technologie d’Aorato rachetée l’an dernier.

Microsoft Advanced Threat Analytics est construit sur l’analyse du comportement combiné avec la détection en temps réel des tactiques, Techniques et Procédures (TTPs) des attaquants. La solution utilise donc la technologie Deep Packet Inspection (DPI) pour analyser le trafic réseau Active Directory ainsi que les informations de sécurité et d’événements (SIEM). L’analyse comportementale ne nécessite pas la création de règles ou de stratégie, ni le déploiement d’agents. L’outil apprend continuellement des analyses effectuées. Ces techniques permettent de construire une carte et des profils pour identifier les comportements anormaux, les attaques avancées et les problèmes de sécurité connus. La solution permet de réduire considérablement les faux positifs liés à des profils définis. Le comportement de l’analyse est contextualisé en fonction des données passées et des différentes phases d’apprentissage.

Cette mise à jour 1 corrige les problèmes suivants :

• Echec de la migration à partir d’ATA v1.6 (1.6.4103) ou ATA v1.6 Update 1 (1.6.4317) pour la version 1.7 ATA (1.7.5402) avec un code d’erreur de 0 x 80070643.
• Une fois que vous avez migrez vers ATA 1.7 (1.7.5402). ATA génère toujours des notifications pour les activités suspectes dont l’état est devenu « dismissed »
• ATA génère un grand nombre d’activités suspicieuses "Reconnaissance using directory services enumeration" après que vous ayez migré ou installé ATA v1.7 (1.7.5402).

Les nouveautés de la version 1.7 sont les suivantes :

• Nouvelles détections : Reconnaissance en utilisant Directory Services Enumeration.
• Amélioration des détections existantes : Amélioration de la détection du Pass-The-Hash, Pass-The-Ticket, et Unusual Protocol Implementation.
• ATA Gateway et Lightweight Gateway supportent maintenant Windows Server 2016 dont Server Core.
• Introduction de Role Based Access Control (RBAC) pour gérer les options de délégation.
• Amélioration de l’expérience de configuration.

Plus d'informations sur : https://blogs.technet.microsoft.com/enterprisemobility/2016/08/31/introducing-advanced-threat-analytics-v1-7/

Télécharger Microsoft Advanced Threat Analytics 1.7 with Update 1 (upgrade only version)

Microsoft a publié un guide de mise en œuvre d’Azure Active Directory Premium. Cet assistant est disponible au travers du portail Office 365. Il donne l’ensemble des étapes nécessaires à la configuration des fonctionnalités souhaitées :

• Réinitialisation du mot de passe,
• Authentification à facteurs multiples
• Etc.

Accéder à l’assistant

Source : https://blogs.technet.microsoft.com/enterprisemobility/2016/07/26/new-step-by-step-azuread-premium-setup-guide/

Si vous utilisez WSUS ou System Center Configuration Manager Current Branch et notamment la fonctionnalité Windows 10 Servicing pour mettre à niveau vos clients vers Windows 10 1607, vous avez peut-être rencontré le problème suivant :

• Vous utilisez WSUS ou System Center Configuration Manager avec le rôle Software Update Point.
• Vous avez installé la mise à jour 3159706 pour permettre le déchiffrement des mises à niveau de Windows 10.
• Vous déployez la mise à niveau Windows 10 1607
• Vous observez que le client SCCM et WSUS détecte et télécharge la mise à niveau dans le cache du client et peuple correctement C:\Windows\SoftwareDistribution\DataStore

Néanmoins lorsque l’installation démarre, les fichiers sont décompressés dans C:\$Windows.~BT mais le processus échoue avec l’erreur : 0xC1800118

Les fichiers Setup.err et Setup.cct renvoie les erreurs :

<Date> <Time>, Error SP CSetupPlatform::ResurrectNewSystem: Cannot resurrect new

system.: Win32Exception: \\?\C:\$Windows.~BT\Sources\NewSystem.dat: The system cannot find

the file specified. [0x00000002] __cdecl UnBCL::FileStream::FileStream(const class

UnBCL::String *,enum UnBCL::FileMode,enum UnBCL::FileAccess,enum UnBCL::FileShare,unsigned

long) [gle=0x00000002]

<Date> <Time>, Error CONX Windows::Compat::Appraiser::SetupAppraiser:

:StopEtlLogger (2884): Waiting on generaltel process failed: [258].[gle=0x00000102]

<Date> <Time>, Error MOUPG RecoverCrypto: File is encrypted, but no key was

provided.

<Date> <Time>, Error MOUPG CDlpActionRecoverCrypto::DoCrypto(1713):

Result = 0xC1800118

<Date> <Time>, Error MOUPG CDlpActionRecoverCrypto::ExecuteRoutine(2465):

Result = 0xC1800118

<Date> <Time>, Error MOUPG CDlpActionImpl<class CDlpErrorImpl<class

CDlpObjectInternalImpl<class CUnknownImpl<class IDlpAction> > > >:

:Execute(441): Result = 0xC1800118

Le problème survient si la mise à niveau Windows 10 1607 est chiffrée bien qu’elle apparaît comme non chiffrée dans la base de données WSUS. Ceci survient lorsque les mises à jour ont été synchronisées avant l’application de la KB3159706.

Pour corriger le problème, vous pouvez suivre les inscriptions de la KB3194588 "0xc1800118" error when you push Windows 10 Version 1607 by using WSUS

Microsoft a publié un correctif pour débloquer les utilisateurs du programme Windows Insiders qui n’arrivaient pas à installer la KB3194496 correspondant à la mise à jour cumulative 14393.222 de Windows 10.

Télécharger Windows 10 1607 Script fix to unblock update for Windows Insiders

L’équipe produit a annoncé le support de .NET Framework 4.6.1 et 4.6.2 par System Center 2012 R2 Virtual Machine Manager (SCVMM). Microsoft a aussi validé le Windows Management Framework 5.0 (WMF 5.0) avec Windows Server 2012 R2.

Source : https://blogs.technet.microsoft.com/scvmm/2016/09/27/microsoft-virtual-machine-manager-and-support-for-net-framework/

Avec l’arrivée de Windows 10 1607, Microsoft a amélioré la fonctionnalité AppLocker visant à restreindre l’usage d’applications conformément à certaines règles. On peut apparenter ceci à une liste blanche d’applications. Auparavant, vous deviez définir une liste fixe qui pouvait parfois être difficile à maintenir. Avec Windows 10 1607, il est possible d’utiliser une nouvelle règle permettant d’autoriser l’exécution des applications installées par une certaine source/autorité. Vous pouvez donc déployer vos applications avec ConfigMgr tout en les faisant automatiquement approuvée par le système cible.

Dune Desormeaux (ConfigMgr PM – MSFT) a écrit un article pour détailler comment mettre en œuvre cette solution en utilisant System Center Configuration Manager 1606.

Je vous invite à lire son billet : https://blogs.technet.microsoft.com/enterprisemobility/2016/06/20/configmgr-as-a-managed-installer-with-win10/

Vous utilisez le connecteur Exchange de System Center Configuration Manager ou Microsoft Intune pour gérer des périphériques qui ne peuvent pas être enregistrés avec Microsoft Intune. Il existe un scénario où ce dernier peut ne rien découvrir lorsque vous ciblez une infrastructure Exchange On-Premises.

Ceci survient si vous êtes en train d’effectuer une migration de boite aux lettres. En effet le connecteur peut ne pas découvrir les périphériques si l’attribut ServerName de la boite aux lettres ne reflète pas le nom du serveur de boite aux lettres. Vous pouvez valider la valeur en utilisant la cmdlet Get-CASMailbox.

Pour résoudre le problème, vous devez mettre à jour la valeur de l’attribut ServerName pour refléter le bon Mailbox Server. Vous pouvez utiliser le script suivant : https://blogs.technet.microsoft.com/rmilne/2014/12/04/exchange-servername-points-to-wrong-or-decommissioned-server/

Si vous êtes au milieu d’une migration, vous devez faire pointer le connecteur Exchange sur un serveur CAS spécifique.

Source : https://blogs.technet.microsoft.com/karanrustagi/2016/06/20/exchange-connector-does-not-discover-mobile-devices-from-on-premises-exchange-server/

Mise à jour : Microsoft a publié une révision à cette mise à jour pour corriger des problèmes dans la logique d'installation.

Microsoft vient d’annoncer la publication d’une mise à jour (4.10.205.0) pour sa plateforme anti logiciels malveillants. Cette mise à jour concerne les clients System Center 2012 EndPoint Protection SP1/SP2/R2/R2 SP1 et System Center Configuration Manager Current Branch qu’ils soient gérés ou non. La mise à jour est publiée à travers Microsoft Updates sous la catégorie Critical Updates et le produit Forefront EndPoint Protection.

Que fait cette mise à jour ?

• Meilleur suppot de l’usage d’un Proxy Pac pour les connectivités à Microsoft Active Protection Service (MAPS) et à la protection Cloud. L’administrateur peut configurer l’URL d’un fichier .Pac en utilisant des stratégies de groupe.
• La plateforme anti logiciels malveillants avait introduit une fonctionnalité Network Real-time Inspection (NRI) pour améliorer les capacités de détection réseau du client. Par défaut, elle était désactivée. Le peu d’usage de la fonctionnalité a amené Microsoft à la supprimer.

Plus d’informations sur la KB3188693 : September 2016 anti-malware platform update for Endpoint Protection clients

Il y a quelques jours, un client me demandait où était le Management Pack de System Center Operations Manager pour Exchange Server 2016 ? N’ayant pas eu à implémenter la supervision de ce dernier, je ne m’étais pas penché sur le sujet. En regardant de plus près, Microsoft n’a pas pour objectif de sortir un Management Pack.

La raison est que le Management Pack pour Exchange Server 2013 avait été complétement retravaillé pour utiliser le concept Managed Availability. Du coup c’est Exchange qui gère la supervision et le Management Pack n’est qu’une interface entre SCOM et l’infrastructure.

Ainsi si vous souhaitez supervision Exchange Server 2016, il vous suffit d’utiliser le Management Pack Exchange Server 2013.

Source : https://blogs.technet.microsoft.com/exchange/2016/06/13/monitoring-exchange-server-2016-with-system-center-operations-manager/

Scott Breen (MSFT) a publié un script PowerShell visant à lister les consoles connectées à une infrastructure System Center Configuration Manager Current Branch. Cette fonctionnalité a été introduite à partir de la version 1602 et propose notamment une table v_CMConsoleUsageData. La procédure spCMUpsertConsoleUsageData est appelée pour mettre à jour les informations de télémétrie.

Son script liste les éléments de la table dont notamment :

• Le nom de la machine,
• Le nom de l’utilisateur,
• La date et l’heure de connexion
• Le code de site conencté
• La version du système
• L’architecture
• La version de la console
• La mémoire
• Les packs de langue
• Etc

Télécharger Get Configuration Manager Connected Consoles (Script)

Aujourd’hui, je vous propose un tour d’horizon d’un nouveau service appelé Azure Active Directory Identity Protection. Ce service est disponible dans les abonnements :

• Azure Active Directory Premium P2
• Enterpise Mobility + Security E5 (EMS)

La solution vous donne un aperçu de l’usage des différentes identités de votre entreprise et vous permet d’identifier les menaces, les événements, les risques, les vulnérabilités et éventuellement mettre en œuvre des stratégies adaptives. Azure AD Identity Protection est la transposition des mécanismes de sécurité utilisés par Microsoft pour les identités publiques dans le Cloud depuis une dizaine d’années. Microsoft utilise aussi des algorithmes de Machine Learning pour apprendre le comportement des utilisateurs et adapter la réponse aux différentes opérations d’identification. Le service peut être utilisé pour des identités Cloud, synchronisées ou fédérées.

On retrouve les types d’événements à risque suivants :

• Les identifiants volés sont identifiés avec un risque élevé. Ceci survient si les chercheurs des équipes de sécurité Microsoft ont retrouvés les identifiants dans le DarkNet. Ceci signifie alors clairement que l’identifiant a été compromis. Le rapport Azure AD Users with leaked credentials permet d’avoir un aperçu de ces événements.
• Les voyages impossibles vers des emplacements non communs sont identifiés avec un risque moyen. Ils surviennent quand deux connexions sont originaires depuis des emplacements géographiques distincts ne permettant pas le déplacement entre l’intervalle de connexion. Ceci indique d’un utilisateur différent a utilisé les identifiants et que ces derniers peuvent avoir été compromis. Le Machine Learning est utilisé pour ignorer les faux positifs comme les connexions depuis des VPNs ou des emplacements connus pour d’autres utilisateurs de l’organisation. La période d’apprentissage initiale est de 14 jours. Le rapport Azure AD Irregular sign-in activity donne une vision sur ces événements.
• Les connexions à partir des périphériques infectés par un logiciel malveillant connus pour dialoguer avec un serveur Bot. Microsoft utilise alors les adresses IP utilisées pour établir la connexion avec les adresses IPs connues pour dialoguer avec des Bots. La détection est donc basée sur l’adresse IP et classée comme faible dû au fait que cette dernière peut héberger plusieurs machines dont certaines ne sont pas infectées par le logiciel malveillant. Le rapport Azure AD Sign-ins from possibly infected devices liste les événements de ce type.
• Les connexions à partir des adresses IP anonymes sont identifiées avec un risque moyen. C’est le cas lors que la connexion à lieu à partir d’une adresse IP reconnues comme adresses IP proxy anonyme. C’est le cas par exemple pour les adresses IP du réseau Tor. Le rapport Azure AD Sign-ins from unknown sources donne la liste des événements correspondant.
• Les connexions à partir des adresses IP avec des activités suspicieuses sont identifiées avec un risque moyen. Ces adresses IP sont tagguées ainsi lorsqu’un grand nombre de tentatives de connexions en échec ont été détectées avec plusieurs comptes utilisateurs sur une période de temps courte. Ceci indique qu’un attaquant peut avoir compromis des comptes ou effectue des tentatives de brute force sur les comptes d’une organisation. L’algorithme de Machine Learning exclut les adresses IP qui sont régulièrement utilisées par les autres utilisateurs de l’entreprise. La période initiale d’apprentissage est de 14 jours. Le rapport Azure AD Sign-ins from IP addresses with suspicious activity donne la visibilité sur ces événements.
• Les connexions depuis des emplacements non communs sont identifiées avec un risque moyen. Ce type d’événements peut survenir si la connexion a lieu depuis une adresse IP ou un emplacement (latitude, longitude) correspondant à un nouvel emplacement de connexion. Le système garde ainsi un historique des emplacements connus de connexion pour un utilisateur. La période initiale d’apprentissage est de 14 jours.

L’ensemble de ces événements peuvent indiqués que l’identifiant a été compromis. Le risque spécifié pour chaque événement est calculé en fonction de la sévérité et de la confiance de l’information recueillie. Par exemple, une connexion à partir d’une adresse IP avec des activités suspicieuses ne veut pas nécessairement dire que la connexion à lieu depuis la machine qui effectue ces activités suspicieuses puisque l’adresse IP publique peut cacher des centaines de machines.

Création de l’environnement

Afin de créer l’environnement, vous devez disposer d’un annuaire Azure Active Directory et d’une licence Azure AD Premium P2 ou Entreprise Mobility + Security E5.
Connectez-vous au nouveau portail Microsoft Azure. Allez dans le MarketPlace et ajoutez Azure AD Identity Protection. Une fois ajouté, ouvrez la solution. La partie Getting started vous donne la liste des étapes à mettre en œuvre. Cliquez sur Onboard. Choisissez l’annuaire et cliquez sur Create pour activer la solution.

D’une manière générale, une fois la création de l’environnement effectuée, il est conseillé d’attendre une période d’au moins 14 jours pour commencer à créer des stratégies de gestion du risque.

Exploitation des données

Une fois l’environnement créé, vous commencez à obtenir des informations sur les utilisateurs de l’annuaire Azure Active Directory utilisé. La partie Overview donne cette vision avec le nombre d’utilisateur marqués comme à risque ou sécurisé. Vous retrouvez aussi les différents événements avec leur niveau ainsi que les vulnérabilités détectées sur votre environnement :

Une partie importante constitue l’investigation. Vous pouvez pour cela utiliser la partie Users flagged for risk pour obtenir une visibilité des utilisateurs à risque, le nombre d’événements, le statut et si l’utilisateur a une authentification à facteurs multiples configurées.

Vous pouvez obtenir plus de détails (la liste des types d’événement, les adresses IP, la date, le niveau de risque) sur chaque utilisateur en cliquant dessus. Vous pouvez voir l’ensemble des connexions de l’utilisateur, acquitter les événements à risque ou réinitialiser le mot de passe de l’utilisateur.

La vue Risk Events donne une visibilité non pas tournée sur les utilisateurs mais sur les différents types d’événements découverts en ayant le type de détection, le niveau de risque et le nombre. Pour chaque type d’événements, vous pouvez obtenir la liste des événements et utilisateurs concernés :

A partir de ces vues, vous pouvez gérer les différents événements en les marquant comme résolu (Resolve), faux positif (Mark as false positive), ignoré (Ignore), ou réactivé (Reactive).

La vue Vulnerabilities affiche la liste des vulnérabilités de votre environnement pour chaque utilisateur. Les vulnérabilités sont des faiblesses de votre environnement qui peuvent être exploitées par n attaquant. On retrouve notamment des vulnérabilités :

• Si l’enregistrement d’une authentification à facteurs multiples n’est pas configuré. Ce mode permet d’ajouter un second niveau de sécurité lors de l’authentification des utilisateurs
• Si vous avez des applications Cloud non gérées. Ces informations sont récupérées si vous utilisez le service Azure AD Cloud App Discovery pour découvrir les applications SaaS utilisées au sein de votre entreprise. Les applications remontées sont celles pour lesquelles vous ne fournissez pas de fédération via Azure Active Directory. Ceci peut potentiellement mener à de la fuite de données
• Si des alertes sont remontées depuis le service Azure AD Privileged Identity Management. Ce service permet de découvrir et résoudre des problèmes liés aux identités à privilèges. On retrouve par exemple des alertes si on retrouve un trop grand nombre d’utilisateurs avec le rôle Global Administrator, si vous avez des authentifications faibles pour certains rôles, etc.

Configuration pour limiter les risques

Une fois les données collectées, Azure AD Identity Protection permet la configuration de nombreuses stratégies visant à limiter les risques.

Il est par exemple possible de forcer l’enregistrement d’une authentification à facteurs multiples via la partie Multi-factor authentication registration policy. Vous devez commencer par définir quels utilisateurs seront ciblés (par défaut tous les utilisateurs) et quels utilisateurs doivent être exclus. Vous devez choisir le contrôle qui doit être appliqué à savoir autoriser l’accès mais demander un enregistrement à Azure MFA.

Une partie Estimated Impact vous permet de voir le nombre d’utilisateurs impactés :

Enfin l’option Enforce Policy vous permet de valider que vous appliquez bien la stratégie configurée.

Parmi les autres stratégies disponibles, on retrouve User risk Policy proposant une stratégie d’accès conditionnel qui évalue le risque d’un utilisateur spécifique et applique une action de remédiation. Cette stratégie s’applique lorsqu’un utilisateur a été marqué comme à risque et lorsqu’il a déjà eu des connexions à risque.
Comme précédemment, vous devez commencer par définir quels utilisateurs seront ciblés (par défaut tous les utilisateurs) et quels utilisateurs doivent être exclus. Vous devez ensuite choisir les conditions ; c’est-à-dire le niveau de risque auquel appliquer la stratégie parmi des types d’événements marqués comme faible ou plus, moyen ou plus, ou simplement élevé.
Vous devez ensuite choisir quel contrôle d’accès appliquer. Vous pouvez choisir de :

• Bloquer l’accès
• Autoriser l’accès mais demander un changement de mot de passe

Comme pour toute stratégie, une partie Estimated Impact vous permet de voir le nombre d’utilisateurs impactés à une instant t. Enfin l’option Enforce Policy vous permet de valider que vous appliquez bien la stratégie configurée.

Enfin la dernière stratégie Sign-in risk policy s’applique lorsqu’un utilisateur effectue une connexion à risque. Elle intervient dans tous types d’événements décrits plus haut dans l’article et donc bien avant qu’un utilisateur soit marqué à risque.
Comme précédemment, vous devez commencer par définir quels utilisateurs seront ciblés (par défaut tous les utilisateurs) et quels utilisateurs doivent être exclus. Vous devez ensuite choisir les conditions ; c’est-à-dire le niveau de risque auquel appliquer la stratégie parmi des types d’événements marqués comme faible ou plus, moyen ou plus, ou simplement élevé.
Le contrôle d’accès appliqué à cette stratégie revient à demander une authentification à facteurs multiples afin d’autoriser l’authentification.

Note : Vous devez valider que les utilisateurs ont enregistré une méthode d’authentification à facteurs multiples. Ceci peut être forcé notamment par la stratégie associée et décrite plus haut. Ceci constitue une bonne pratique.

Comme pour toute stratégie, une partie Estimated Impact vous permet de voir le nombre d’utilisateurs impactés à une instant t.

Enfin l’option Enforce Policy vous permet de valider que vous appliquez bien la stratégie configurée.

L’ensemble des stratégies décrites doivent vous permettre de minimiser l’impact en termes de sécurité sur les identités de l’entreprise (vol d’identifiants, etc.)

Configuration additionnelles

Outre les stratégies, on retrouve différentes configurations comme la configuration :

• De bulletins hebdomadaires (Weekly Digest) envoyés par email afin de résumer la situation
• De notifications (Alerts) par email en cas de détection de types d’événements d’un niveau de risque choisi.

Comportement lors des connexions

Lorsque l’utilisateur se connecte et est ciblé par une stratégie qui bloque sa connexion, il reçoit un message comme suit :

Lorsque l’utilisateur est ciblé par la stratégie d’enregistrement d’une authentification à facteurs multiples, la page suivante est proposée :

Il peut alors choisir un type d’authentification comme l’usage d’un téléphone :

Lorsque le système détecte une connexion inhabituelle, la page suivante est proposée :

Il devra alors répondre aux exigences de la règle d’accès conditionnel associée (par exemple faire appel à une authentification à facteurs multiples).

Microsoft IT a publié une étude de cas visant à expliquer comment ils ont couplé l’accès à distance avec Windows Hello for Business de Windows 10. Le but est de fournir une solution VPN unique pour les 180 000 utilisateurs. L’architecture comprend :

• Une infrastructure System Center Configuration Manager couplée à Microsoft Intune avec le Certificate Registration Point, NDES et une autorité de certification.
• Des serveurs RADIUS et Network Policy Server
• Des serveurs VPN avec RRAS et EAP-TLS.

L’étude de cas revient sur les différents composants et configurations.

Lire:

• Enabling remote access with Windows Hello for Business in Windows 10
• Implementing strong user authentication with Windows Hello for Business
  

A l’occasion de l’Ignite, Microsoft annonce la disponibilité générale d’Azure Service Fabric pour Windows Server. Service Fabric est une plateforme d'application mature de type microservices avec un support intégré pour la gestion du cycle de vie. Cette plateforme est disponible en téléchargement sans coût afin de vous permettre de déployer vos propres clusters Service Fabric dans vos Datacenters. Microsoft a aussi annoncé la previex de Service Fabric sur Linux.

Plus d’informations sur : https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cluster-creation-for-windows-server/

Télécharger Service Fabric for Windows Server 2012 R2 and above

Source : https://azure.microsoft.com/fr-fr/blog/azure-service-fabric-for-windows-server-now-ga/

L'équipe Exchange vient de mettre à jour l'outil Exchange Server Role Requirements Calculator dans sa version 8.3. Cet outil est composé de feuilles Excel permettant d'entrer des données relatives à votre architecture. Cette nouvelle version prend en compte les améliorations du CU3 d’Exchange Server 2016 qui réduit la bande passante requise entre des copies active et passive. En outre, le calculateur supporte la capacité d’automatiquement calculer le nombre de DAGs et le nombre de serveurs Mailbox associés.

Le calculateur vous donnera les prérequis de :

• Rôles
• LUN
• Design du stockage
• Input
• Backup
• Log Replication

Plus d’informations sur : https://blogs.technet.microsoft.com/exchange/2016/09/20/released-exchange-server-role-requirements-calculator-8-3/

Télécharger Exchange Server Role Requirements Calculator

Microsoft a publié un article pour décrire un plan d’actions visant à sécuriser les accès privilégiés. Depuis plusieurs mois, les attaques sur les annuaires d’entreprise (Active Directory) ont été de plus en plus importantes avec notamment l’exploitation de failles Pass-The-Hash et Pass-The-Ticket.

Microsoft propose un plan en trois phases :

1. Phase 1 : 2 à 4 semaines :
   1. Séparer les comptes administrateurs pour les tâches administratives
   2. Privileged Access Workstations (PAW) : http://aka.ms/CyberPAW
   3. Configuration d’un mot de passe d’administrateur local unique pour les stations de travail. http://aka.ms/LAPS
   4. Configuration d’un mot de passe d’administrateur local unique pour les serveurs. http://aka.ms/LAPS
2. Phase 2 : 1 à 3 mois :
   1. Privileged Access Workstations (PAW) : Implémentation de stations de travail dédiées pour tous les employés avec des accès privilégiés : http://aka.ms/CyberPAW
   2. Utilisation du concept des privilèges Just-In-Time à durée limitée en utilisant MIM ou Azure AD Privileged Identity Management.
   3. Utilisation de l’authentification à facteurs multiples pour les élévations de priviléges.
   4. Implémentation de Just Enough Admin (JEA) pour la maintenance des contrôleurs de domaine.
   5. Abaisser la surface d’attaque du domaine et des contrôles de domaine.
   6. Détecter les attaques avec Microsoft Advanced Threat Analytics (ATA).
3. Phase 3 : 6 mois ou plus :
   1. Moderniser le modèle de délégation et les rôles
   2. Authentification avec SmartCard ou Microsoft Passport pour tous les administrateurs
   3. Création d’une forêt d’administration
   4. Implémentation des stratégies d’intégrité du code pour les contrôleurs de domaine (Windows Server 2016)
   5. Implémentation des machines virtuelles protégées (Shielded VMs) pour les contrôleurs de domaine virtuels.

Pour en apprendre plus, lisez : https://technet.microsoft.com/windows-server-docs/security/securing-privileged-access/securing-privileged-access