Wednesday, December 6, 2017

Office 365 : Exchange Online Protection - éléments de base (FR)

English summary: I present the basic features of Exchange Online Protection (EOP), available with Office 365 plans that include Exchange. I do not address DKIM (DomainKeys Identified Mail) or AMP (Advanced Malware Protection). The first constitutes a subject in itself and the second is not included with Exchange Online Plan 1 (which is what I have). After a brief presentation of each feature, I provide links to Microsoft documentation in English and French.

***

Je compose un nouveau texte de blogue consacré aux options d'Exchange Online Protection ou "EOP". Nous pouvons nous en servir si nous avons un plan Office 365 comprenant Exchange. Tous ces plans comportent au moins les options de base (que je vais passer en revue ici).  Certains plans (E5/G5 par exemple) offrent une protection accrue, notamment l'AMP (Advanced Malware Protection) ou "protection avancée contre les logiciels malveillants). Comme je n'ai pas accès à un tel abonnement, je ne pourrai pas en faire la présentation.

***

Nous accédons aux options EOP dans le Centre d'administration Exchange. La section en question a pour simple titre "protection". Cette section comporte plusieurs sous-sections, visibles dans la capture d'écran plus bas, y compris :
  • filtre anti-programme malveillant (malware filter)
  • filtre de connexion (connection filter)
  • filtrage du courrier indésirable (spam filter)
  • courrier indésirable sortant (outbound spam)
  • quarantaine
  • centre de maintenance (action center)
  • dkim



Remarque : je ne présenterai pas ici DKIM qui constitue un sujet à lui seul.



filtre anti-programme malveillant

EOP fournit un filtre par défaut qui s'appelle "Default" (le mot anglais d'origine). A droite, et sous le titre "Default", les paramètres en sont présentés :



Si nous voulions, nous pourrions créer d'autres filtres, auquel cas le filtre par défaut aurait une priorité relative plus faible (les paramètres des autres filtres s'imposeraient en cas de conflit). Dans le filtre par défaut, ou dans d'autres que nous pourrions être amenés à créer, nous avons la possibilité d'en modifier les paramètres. A priori, le rejet d'un message contenant un programme malveillant ne donne lieu à aucun avertissement au destinataire. Si, au contraire, nous voulons avertir celui-ci, nous pouvons cliquer sur le petit crayon (icône désignée par un point rouge dans notre première capture d'écran) et lui fournir un message, soit un message préfabriqué, soit un message que nous devons composer :





Tenons compte de la nuance entre un programme malveillant dans le corps du message et un tel programme dans une pièce jointe. Dans le premier cas, le message sera supprimé (sans recours, paraît-il). Dans le second cas, le message sera mis en quarantaine mais un administrateur pourrait le libérer. Il faut penser que la pièce jointe elle-même serait supprimée selon la même logique qui veut que le corps du message soit supprimé quand c'est lui qui contient le programme malveillant. Quoi qu'il en soit, si nous voulons que les messages soient libérés seulement à la demande d'un utilisateur qui se porte garant de l'expéditeur, nous aurons besoin de configurer l'envoi d'un avertissement afin qu'on soit au courant de la mise en quarantaine.


Remarque : la section "général" comprend simplement le nom du filtre et une description, le cas échéant :





Nous pouvons configurer encore d'autres options bien que toutes ne soient pas résumées sur ce que j’appellerai la page d'accueil (plus haut dans la première capture d'écran). Par exemple, nous pouvons activer une option qui bloque les pièces jointes d'un certain type (.exe ou .vbs par exemple) :



En cliquant sur le signe "+ ", nous pouvons ajouter encore d'autres types de fichiers.

Notre dernière option dans cette section consiste en la configuration de messages de non remise aux expéditeurs internes, externes, ou les deux, ou bien aux administrateurs. En voici un aperçu :





filtre de connexion

Le filtre de connexion fonctionne par le moyen d'adresses IP que nous pouvons autoriser ou bloquer, et d'une "liste verte". Toutes ces options sont désactivées par défaut :



Dans les propriétés du filtre, nous pouvons activer ces options et mettre les adresses IP de notre choix. Oui, il est possible de spécifier une plage d'adresses. Quant à la "liste verte" (ou "liste fiable" - "safelist" en version anglaise originale), l'infobulle en donne l'explication : il s'agit d'exempter du filtrage certains expéditeurs approuvés qui figurent sur la liste (gérée par Microsoft) :





filtrage du courrier indésirable

Le filtrage du courrier indésirable (spam) nous offre toute une variété d'options...



D'abord, que faire du courrier indésirable ? Nous pouvons le déplacer vers le dossier du même nom (dans Outlook) avec deux jeux d'options distincts selon la probabilité qu'il s'agit effectivement d'un message indésirable. D'autres paramètres sont configurables, comme la durée de conservation des courriers indésirables dans la quarantaine. Certains paramètres sont en gris (désactivés) car ils dépendent des choix en haut de la page. Selon nos choix, nous avons donc plus ou moins d'options activées en bas : 




Selon le choix retenu, d'autres précisions s'affichent :



EOP nous permet de dresser une "liste rouge" des expéditeurs (adresses spécifiques) et des domaines : 



En revanche, il est possible de constituer des "listes vertes" des expéditeurs et des domaines dont nous voulons assurer la remise des messages : 




Bien que des personnes malveillantes puissent lancer des attaques et envoyer des messages indésirables à partir de n'importe quel pays (autre que leur pays d'origine), et dans une variété de langues, nous pouvons tout de même bloquer des courriers selon ces critères :




Enfin, les options avancées nous permettent d'augmenter le taux de mise en quarantaine selon la présence de certaines caractéristiques dans le corps même du message (comme des liens ou un URL) :






courrier indésirable sortant

Il existe des actions spécifiques pour les messages indésirables sortant de notre système de messagerie, soit deux options : envoyer une copie du message à une adresse désignée (ou plusieurs) et envoyer une notification à l'expéditeur :




quarantaine

Comment gérer les messages mis en quarantaine ? Que faire si un utilisateur soumet une demande pour la libération d'un message légitime, bloqué par erreur ? Les administrateurs qui tiennent le rôle "Transport Hygiene" peuvent accéder à la quarantaine et gérer les messages là-dedans. Malheureusement (d'une certaine façon), je n'ai aucun message en quarantaine pour en faire la démonstration.



centre de maintenance

Si un de nos utilisateurs dépasse un certain seuil (non précisé - à ma connaissance) pour l'envoi de messages indésirables, cette personne se retrouvera dans la liste ci-dessous et ne pourra plus envoyer de messages. La documentation Microsoft indique que nous pouvons retirer notre utilisateur de cette liste un certain nombre de fois (non précisé encore une fois). Au-delà de cette limite, nous serions obligés de prendre contact avec l'assistance technique de Microsoft pour sortir notre utilisateur de ce qui fonctionne comme une sorte de quarantaine pour expéditeurs :





Références

Protection anti-courrier indésirable et anti-programme malveillant

Voici l'équivalent en anglais pour ceux qui auraient besoin de se rapporter à la documentation originale :

Anti-spam and anti-malware protection

Monday, November 27, 2017

Office 365 : préparer sa migration avec IdFix (FR)

English summary: I take a look at the IdFix tool that detects potential synchronization problems between Azure Active Directory (Office 365) and our "local" Active Directory. I can safely assume that there were no signficant problems in my test domain, since I have already synchronized it with Azure AD and even migrated some mailboxes. However, I may have a need for IdFix in another context and wanted to become more familiar with it.

***

A première vue, il est bizarre que je présente cet outil après avoir déjà synchronisé mon Active Directory avec Azure Active Directory, et même migré plusieurs boîtes aux lettres vers Exchange Online.

En effet, IdFix sert à détecter des erreurs dans Active Directory susceptibles d'entraver la synchronisation des répertoires. De plus, nous pourrions nous en servir pour corriger les erreurs trouvées (ou bien recourir à d'autres méthodes pour y parvenir).

Mais voilà : j'envisage une migration à Office 365 dans un autre cadre et je voudrais voir à quel point IdFix pourrait m'y être utile.

***

D'abord, IdFix est disponible par ce lien :

IdFix Directory Synchronization Error Remediation Tool

Selon les apparences, l'outil n'existe qu'en version anglaise. En tout cas, je n'ai pas réussi à le trouver en français.

En revanche, Microsoft fournit un mode d'emploi dans cette langue :


Et voici la version anglaise originale :



Ces articles expliquent assez bien la mise en oeuvre de l'outil et je ne reproduirai pas ici ce que vous pouvez fort bien lire là. Son "installation" se fait comme c'est décrit dans l'article. Je télécharge le fichier zip que je décompresse à l'emplacement de mon choix :





Ensuite, j'exécute le fichier et vois apparaître ce message :



A vrai dire, l'application ne s'installe pas au sens strict. Elle ne s'affiche pas dans "Programmes" par exemple :


Remarque : IdFix nécessite .NET Framework 4.0 ou plus, ce qui est le cas ici.


Pour cette expérience, j'exécute l'outil à un contrôleur de domaine mais il serait possible de l'exécuter ailleurs, à condition d'avoir un accès suffisant à Active Directory, en lecture et en écriture. Je suppose qu'un accès en lecture seule suffirait si on voulait seulement voir les erreurs sans les corriger. Mais je n'ai pas mis cette supposition  à l'épreuve.

Quoi qu'il en soit, lorsque IdFix s'ouvre, nous cliquons sur le mot "Query" et l'outil cherche des éléments qui pourraient bloquer la bonne synchronisation des objets. S'il en trouve, il les affiche et suggère des actions à prendre :



Le seul problème repéré chez moi concerne les "domaines de niveau supérieur" (topleveldomain). De quoi s'agit-il ? Le nom de mon domaine d'essai est "mynet.lan" et par défaut, l'UPN (user principal name) comprend ce suffixe, par exemple : alan.reid@mynet.lan. Cependant, la synchronisation avec Azure Active Directory exige un nom de domaine routable sur l'Internet. Ce n'est pas le cas de .local ou de . lan, selon une révision de RFC2606 :

https://tools.ietf.org/html/draft-chapin-rfc2606bis-00

Je dois donc changer l'UPN. Je pourrais utiliser IdFix mais pour un changement si simple, il suffit de sélectionner tous les utilisateurs, de choisir "Propriétés" et d'ajuster alors le suffixe :



Et nous y sommes !

Pour la synchronisation  en tout cas. Si nous souhaitons migrer des boîtes aux lettres vers Exchange Online, nous devons aussi supprimer toute adresse courriel avec le suffixe @mynet.lan. 

Thursday, November 23, 2017

Office 365 : gérer son compte avec PowerShell - les commandes Get-Msol* (FR)

English summary: We can manage Exchange with PowerShell, in particular by the creation of scripts for the execution of repetitive tasks. In Exchange Online (Office 365), we have many of the same commands (or "cmdlets") at our disposal although some cmdlets, notably those for Exchange server management (Get-MailboxServer or Set-MailboxServer, etc.) will not function in the Cloud. On the other hand, we can use PowerShell to manage not only Exchange Online but also other Office 365 applications and the Office 365 tenant itself.

These commands contain the string "msol": Get-MsolUser, Set-MsolUser, New-MsolDomain, etc.. I explored the different Get-Msol* cmdlets by entering Get-Msol and then displayed the various suffixes using with the tab key. Below, I present some of those I find most useful.

OS: Windows 7 SP1
PowerShell version: 4.0


***


Dans certains cas, nous pourrions préférer gérer Exchange avec PowerShell, en particulier pour l'exécution des tâches répétées avec des scripts. Si nous faisons le saut à Office 365, nous aurons à notre disposition beaucoup des mêmes commandes (ou "cmdlets") que nous avons utilisées pour gérer Exchange sur place ("on-site"). D'autres commandes, notamment celles qui ciblent les serveurs (Get-MailboxServer par exemple), ne fonctionneront plus dans ce nouveau cadre. En revanche, nous pouvons utiliser PowerShell non seulement pour Exchange mais aussi pour d'autres applications Office 365 et même l'administration générale de notre compte. Ce dernier aspect est le sujet de ce texte.

Les commandes en question contiennent la séquence "msol" ce qui signifie en toute vraisemblance "Microsoft OnLine".

Voici des exemples :
  • Get-MsolUser
  • Set-MsolUser
  • New-MsolDomain
Je suis parti à la découverte des commandes Get-Msol* en appuyant sur la touche tabulation ("Tab") pour les afficher en succession. Je vais présenter ci-dessous celles que j'ai trouvées les plus utiles.

Note : Je me sers de Windows 7 SP1 et de PowerShell 4.0.


Avant d'ouvrir PowerShell et de découvrir les commandes pour Office 365, nous devons installer au préalable deux logiciels dans l'ordre suivant :

Microsoft Online Services Sign-in Assistant

Nom de fichier : msoidcli_64.msi

Azure Active Directory Module pour PowerShell

Nom de fichier : AdministrationConfig-V1.1.166.0-GA.msi


Ensuite, nous pouvons accéder à notre compte Office 365 en ouvrant PowerShell et en saisissant ce qui suit :

$Cred = Get-Credential
Connect-MsolService -Credential $Cred

Il vous sera demandé de fournir vos informations de connexion :



Note : utilisant la version de PowerShell et les fichiers indiqués plus haut, je n'ai pas eu besoin de saisir la commande "Import-Module MSOnline".

Et nous voilà prêts à essayer quelques commandes.



PS C:\> Get-MsolAccountSku | ft -auto

Cette commande montre les types de plan Office 365 auxquels nous sommes abonnés ainsi que le nombre d'unités (units) disponibles et utilisées.

Comme l'affichage des données copiées et collées se présente mal, et par discrétion du reste, je vais m'en tenir au strict minimum et ne pas montrer nécessairement tous les détails de mon compte à moi :

AccountSkuId                                  ActiveUnits WarningUnits ConsumedUnits
------------                                           ----------- ------------ -------------
mondomaine:EXCHANGESTANDARD         2           0            2
mondomaine:O365_BUSINESS_PREMIUM  1           0            1




PS C:\> Get-MsolSubscription | ft skupart*,status,TotalLicenses -auto

SkuPartNumber                Status    TotalLicenses
-------------                          ------       -------------
EXCHANGESTANDARD         Enabled        2
O365_BUSINESS_PREMIUM  Enabled        1

Cette commande offre une autre perspective de notre abonnement. Le terme "license" s'utilise ici au lieu d'unité, comme nous avons vu plus haut.

Note : nous pouvons parfois afficher plus de détails avec la commande format-list ou "fl". Encore une fois, je m'en tiens à ce que je crois essentiel en préférant l'option format-table ou "ft", et les propriétés spécifiques qui m'intéressent.



PS C:\> Get-MsolCompanyInformation

Cette commande affiche des renseignements sur l'entreprise hébergée en Office 365 ainsi que des détails sur la synchronisation avec le domaine local :




PS C:\> Get-MsolUser | ft DisplayName,isLicensed -auto

Cette commande montre les utilisateurs et leur statut vis-à-vis des licences. En particulier, les utilisateurs dont la boîte aux lettres a été migrée vers Exchange Online devraient se voir accorder une licence, sans quoi leur BAL sera purgée après un certain temps. Au contraire, les utilisateurs dont la BAL réside toujours sur place n'en ont pas besoin. Cet affichage permet d'en tenir compte. 




PS C:\> Get-MsolUser -UserPrincipalName alex.heyne@mondomaine.net | fl *name*,*address*

Cette commande affiche les propriétés de l'utilisateur en question et notamment ses adresses :


Note : oui, vous pouvez cliquer sur l'image pour l'agrandir.




PS C:\> Get-MsolDirSyncConfiguration | fl

PS C:\> Get-MsolDirSyncFeatures | ft DirSyncFeature,Enabled -auto

Si nous utilisons DirSync (désormais "Azure AD Connect"), les deux commandes ci-dessus peuvent se révéler utiles. Voici ce qu'elles donnent :




PS C:\> Get-MsolDomain | ft -auto

Cette commande affiche les domaines associés à notre compte Office 365 :



PS C:\> Get-MsolGroup | ft DisplayName,GroupType -auto

Comme pour les utilisateurs, nous pouvons afficher nos groupes synchronisés avec Azure Active Directory : 





PS C:\> Get-MsolPasswordPolicy -DomainName mondomaine.net | fl

Cette commande nous dévoile la stratégie de mot de passe en vigueur pour notre compte Office 365 et notamment la période de validité :




PS C:\> Get-MsolRole | fl Name,Description

Au lieu de faire de chacun de nos techniciens un "administrateur global", nous avons l'option de déléguer certains rôles à des administrateurs avec le pouvoir d'agir seulement dans ces domaines. La commande Get-MsolRole affiche ces rôles avec une description. Comme la liste des différents rôles est assez longue, la capture d'écran ci-dessous n'en montre que les premiers :




***


Nous devrions garder à l'esprit que nous ne pouvons pas exécuter des commandes spécifiques à Exchange Online dans ce cadre. Cela donnerait des erreurs de ce genre :


Pour cela, il faudrait plutôt saisir l'ensemble des commandes suivantes :

$Cred = Get-credential

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

Import-PSSession $Session -DisableNameChecking -AllowClobber


***

Cette présentation n'était qu'un survol qui m'a permis de connaître un peu mieux les options de gestion de mon compte Office 365 avec PowerShell. Je me suis contenté d'ailleurs de ne présenter que des exemples des commandes Get-Msol*.

Nous pouvons voir toutes les commandes Get-Msol* avec cette commande :

Get-Command Get-Msol*

Ou en abrégé :

gcm Get-Msol*

Nous pouvons faire de même pour afficher les commandes Set-Msol* (etc.).

De plus, vous pouvez consulter la documentation Microsoft à ce sujet ici :

Gérer Office 365 avec Office 365 PowerShell


Wednesday, November 15, 2017

Windows 10 and Office 2016 : Deployment

In a previous blog post, I installed ADMX and langauge specific ADML files that allow me to manage settings for Windows 10 and Office 2016 through Group Policy. However, I had no Windows 10 clients and no installation of Office 2016 (the Outlook mail client in particular).

That has changed. I have added a Windows 10 Pro client to my test network and purchased an Office 365 Business Premium license, which grants me the right to download and install the full version of "Office 2016 ProPlus". Among other applications, this package includes Word, Excel, PowerPoint and especially Outlook.

I had never used the downloadable version of Office 2016 before and thought I would find a download link at this location:



But only the Office versions for Macintosh are available:




What if you use Windows?


***

For Windows, we have to download the Office Deployment Tool (ODT) that will, in turn, allow us to download Office 2016 files to a shared folder from which we can deploy the application itself by a variety of methods (Group Policy with a simple installation script, System Center Configuration Manager, etc.).

So I create a shared folder on a server, download the ODT and extract the tool to that location.

This is what the downloaded executable looks like:



I extract the content to this folder, shared with the following UNC path:

\\ADCONNECT1\Shared\O365



Besides the setup.exe file, we have a sample .xml file that I have already modified and renamed. I have also created a subfolder named "SAC" that will hold the downloaded Office 2016 files.

Note: SAC means "semi annual channel". The concept of channel is related to the frequency at which Microsoft releases updates for the Office product. Enterprise customers may not want too frequent updates as the possible changes may affect productivity. This article explains the options in greater detail (and instructions for configuring the deployment folders):

Deploy Office 365 ProPlus from a local source


I need to say a word on the configuration .xml file. This file defines certain deployment parameters such as the deployment location, the version of Office 2016 to be deployed, the Office components we may want to exclude (optional), and the frequency of updates. Below is the content of my configuration.xml file:

<Configuration> 
  <Add SourcePath="\\ADCONNECT1\shared\O365\SAC" OfficeClientEdition="64" Channel="Broad"> 
   <Product ID="O365BusinessRetail"> 
     <Language ID="en-us" /> 
     <ExcludeApp ID="Access" />    
     <ExcludeApp ID="Publisher" />
   </Product> 
  </Add> 
  <Updates Enabled="TRUE" UpdatePath="" Channel="Broad" />  
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>


These articles provide additional information on the options mentioned above:

Configuration options for the Office 2016 Deployment Tool

Product IDs that are supported by the Office Deployment Tool for Click-to-Run

Overview of update channels for Office 365 ProPlus


But I still do not have the Office 2016 installation files!

So how do I procure those files?

At the command prompt, I run setup.exe in download mode, referencing my .xml configuration file:

This is the example given in the Microsoft documentation:

\\server\share\O365\setup.exe /download \\server\share\O365\config-group1-SAC.xml

In my case, it looks like this:


Note: you can click on the image to enlarge.

The files should begin downloading to the location designated in the .xml file, for example:

\\ADCONNECT1\shared\O365\SAC




Note: if problems are encountered, you can consult the log file in the %temp% directory.



***


We have made some progress. The Office 2016 (ProPlus) installation files have been copied to one of our local servers. But how do we install Office on our client machines?

There are a number of options including System Center Configuration Manager (SCCM). I will use a more simple method that may or may not be sufficient for your production environment: software deployment via Group Policy.

First, I enter the following command in notepad.exe and save it as a .bat file:

start /wait \\adconnect1\shared\O365\setup.exe /configure \\adconnect1\shared\O365\config-group-SAC.xml

Of course, you would adjust the script to match your own environment (changing server names and so forth). The script references both the setup.exe file and the .xml file for customization.

Next, I add the batch file to the the scripts section of a GPO to be linked to the OU (organisational unit) containing the user's client machine. One remark: I will assume that the reader is capable of creating and managing a GPO and will not review that process here.

So, I open the GPO for editing, go to the "Scripts (Startup/Shutdown)" section and click on the "Show Files" button:





Once this window is open, I can copy the batch file from its current location to the startup folder:




But that is not enough. I still have to click on the Add button and then browse to the startup folder (opened by default) to add the script to the GPO:




If the GPO is linked to the OU correctly and I restart the client machine (it may require a second reboot), the script should install Office 2016 ProPlus, taking into account the customization settings in the .xml file. Besides the presence of Office icons in the start menu, we should see entries in the Event Viewer (Application log) related to the installation. If Office does not install correctly, the entries here may be useful for troubleshooting:





What happens next?

I log on as user Alan Reid and open Word (we'll see Outlook later). Almost immediately, I am prompted to "Activate Office". I assume it will attempt to associate this copy of Office with the license I purchased. So I enter the email address of Alan Reid (although not shown in the screenshot below) and click on "Next"...






"Alan Reid" is prompted to sign in:




And encounters this error:




As I suspected, I cannot use Office 2016 ProPlus until I assign the logged on user a proper license. 

So I connect to my Office 365 tenant and go to the "Active users" section where I assign the license to Alan Reid:

A.



B.


C.




Now when I connect as Alan Reid, and open Word, the product activates without further ado.

As far as Outlook 2016 goes, autodiscover functions perfectly and configures the mailbox of Alan Reid without a problem:

D.



E.


F.





G.