Bulletin de sécurité ms15-026

Le bulletin de sécurité MS15-026 a été publié hier, il concerne des vulnérabilités côté OWA sur du cross site scripting (c’est à la mode…).
En attendant un patch, le workaround ne peut être porté que par un parefeu applicatif bloquant certaines chaines particulieres.

Le détail des vulnérabilités n’a pas été publié, cependant les actions de contournement donne une bonne idée des techniques utilisés.

Plus d’information chez Microsoft : https://technet.microsoft.com/en-us/library/security/ms15-026.aspx

Techdays 2015, c’est fini!

Les 3 journées des Techdays 2015 sont terminées, ma toute première sessions aussi devant une salle comble!

En compagnie de Anthony et Guy nous avons présenté une session architecture préférée pour Exchange 2013 en 45mn chrono, celle-ci reprenant les grands concepts présentés par Ross Smith IV au travers du blog EHLO.

Une petite précipitation dans les dernières slides sur la sauvegarde sur le Single Item Recovery et le In-Place Hold, voici la correction :

– le Single Item Recovery ne permet pas de récupérer les éléments supprimés par un utilisateur (c’est la fonctionnalité de dumpster deja présente dans les versions précédentes), mais permet à un administrateur de récupérer les éléments supprimés du dumpster par l’utilisateur ou qui ont été “hard delete” (donc qui ne devraient pas passer par le dumpster). Cette fonctionnalité permet de plus de sauvegarder toutes les versions d’un élément si celui ci est modifié. Les éléments récupérés par le Single Item Recovery conserve leur timestamp d’origine et expire avec le même délai que celui du Dumpster.

– le In-Place Hold va plus loin que le Litigation Hold, il permet d’avoir une meilleur granularité en offrant un filtre sur les messages à conserver ainsi que sur la durée de rétention.

Première session Techdays sur l’architecture préférée Exchange 2013

Cette année j’aurais le plaisir de présenter avec Anthony Costeseque et Guy Groeneveld la session « Préconisation d’architecture type d’Exchange 2013 ».

Dans cette session nous vous donnerons les derniers conseils pour implémenter une architecture Exchange 2013 basée sur les recommandations Microsoft !
Venez nombreux, elle a lieu mercredi 11 février de 12h15 à 13h !

https://techdays.microsoft.fr/programmes/2015/fiche-session.aspx?ID=c19ae9f5-058b-4487-a9ef-c0aeba8530dd

Exchange 2013 : n’oublier pas les mises à jour du schéma de base de données

Lors de chaque mise à jour, Exchange 2013 peut inclure une mise à jour du schéma de la base de données, à ne pas confondre avec la mise à jour du schéma Active Directory. Les modifications effectuées ne sont malheureusement pas documentées, on sait qu’elle concerne la structure des bases ESE, en particulier des tables et des attributs, elle est cependant complémentement transparente pour les utilisateurs.

Chaque base de donnée dispose de la version de son schéma, renseigné directement dans la base de données et non pas dans l’Active Directory. Cette version peut être interrogée par la cmdlet Get-MailboxDatabase -Status en consultant l’attribut CurrentSchemaVersion.

Si le serveur fait partie d’un DAG, lors d’une mise à jour l’attribut MaximumSupportedDatabaseSchemaVersion de chaque copie de base de données hebergée sur le serveur est incrémenté à la version maximale supportée par le CU. Exchange 2013 RTM a commencé à la version 0.121 et nous en sommes à la version 0.128 pour Exchange CU7.

Par contre il ne suffit pas de mettre à jour tous les noeuds d’un DAG pour que les bases de données se mettent à jour automatiquement, celles-ci ont besoin d’être démontées puis remontées.

Pour savoir si une mise à jour est en attente, il faut consulter l’attribut RequestedSchemaVersion obtenu par la cmdlet Get-MailboxDatabase -Status.

Cet attribut correspond à la valeur minimale contenu dans tous les noeuds du DAG pour l’attribut MaximumSupportedDatabaseSchemaVersion, on peut parler de plus grand dénominateur commun. Si il est supérieur à la version courante de la base de données, lors de son prochain redémarrage celle-ci se mettra à jour.

Il suffit alors d’enchainer un Dismount-Database puis un Mount-Database pour que la base se mette à jour.

Microsoft, ses employés et Technet

Le second tour des réductions d’effectif de Microsoft vient de se terminer, celui-ci impacte malheureusement aussi la communauté Exchange.

Dans les postes fermés se trouvent plusieurs Technical Writer, ces personnes qui alimentent les articles Technet et le blog EHLO. En particulier j’ai appris avec beaucoup de surprise le départ d’une personnalité bien connue qui faisait le déplacement exprès à Paris pour les TechDays. Ses sessions, bien qu’en anglais, faisaient toujours salle comble et attiraient beaucoup de professionnels liés à Exchange, et il était l’une des rares personnes qui prenait le temps de lire et répondre à nos emails.

On se doute qu’avec la volonté affichée de déplacer ses clients vers le Cloud et Office 365, la documentation On-Premise est de moins en moins nécessaire, alors que c’était l’une des plus belles documentations fournies par un éditeur. De nombreux composants d’Exchange restent encore aujourd’hui mystérieux, par exemple le ManagedAvailability et les Workload, qui reste pourtant pour moi les plus grandes innovations d’Exchange 2013, et il faut craindre que ceux-ci restent des boites noires par la suite.

Tout cela confirme encore le focus donné par Microsoft sur ses services Cloud. Il est inutile de savoir comment cela marche, c’est dans les nuages…

Cas d’usage : la réversibilité d’Office 365

Grâce à l’un de mes clients, j’ai pu valider la réversibilité d’Office 365 vers une offre On-Premise.

Le client avait migré l’ensemble de son infrastructure Exchange 2003 vers une offre BPOS (alors basée sur Exchange 2007), il avait alors suivi les différentes évolutions de la plateforme BPOS jusqu’à l’offre O365 actuelle basée sur Exchange 2013. Les orientations stratégiques qui l’avaient amené dans le Cloud ayant changés avec le temps, celui-ci souhaitait ré internaliser sa messagerie dans une organisation Exchange 2013 On-Premise.

Nous lui avons proposé un chemin de migration personnalisé prenant en compte ses particularités, avec la création d’une organisation locale Exchange 2013, puis la migration des différentes ressources depuis O365 vers Exchange.

Dans un environnement Active Directory relativement simple, l’installation d’Exchange 2013 ne pose pas de problème à partir du moment où l’on prend en compte la création d’un point de configuration Autodiscover, celui-ci doit être géré pour éviter que les clients internes ne soient redirigés automatiquement vers Exchange 2013 dès la fin de l’installation. Plusieurs méthodes permettent de contourner ce problème, pour ma part j’ai choisi de créer manuellement un SCP pointant vers le service Autodiscover O365. Alternativement, on peut changer le SCP du premier serveur installé via la cmdlet Set-ClientAccessServer, mais dans ce cas il est souhaitable de réaliser l’installation du premier serveur en heure non ouvrée. Dans cette configuration, les clients Outlook récupèrent le SCP le plus ancien, ce qui permet de travailler tranquillement par la suite.

Il est nécessaire de changer le mode de synchronisation de DirSync si celui-ci n’est pas en mode de coexistence, une partie des attributs O365 sont alors synchronisés avec l’annuaire local. Il faut cependant rattraper une partie des attributs AD, ceux-ci ne sont pas dans l’état attendu du mode Hybride, il faudra alors rattraper un certain nombre d’attributs, tel que l’ExchangeGUID qui servira lors des déplacements de boîtes aux lettres. La conversion des utilisateurs en RemoteMailbox permet d’arriver dans un état relativement proche de la cible, il est cependant souhaitable de sauvegarder l’ensemble des attributs AD locaux liés à Exchange avant de travailler sur la partie DirSync et le rattrapage.

Il est important d’avoir à minima une synchronisation des mots de passes avec 0365 et des UPN correspondants à l’adresse email, ce qui permet d’avoir une authentification identique sur les deux organisations. C’est d’autant plus pertinent qu’il faudra tôt ou tard basculer les services Autodiscover depuis O365 vers Exchange, avec à la fois une authentification vers Exchange, puis vers O365 pour les clients Outlooks. Accessoirement, cela permet de régler de façon transparente certains problèmes liés au Credential Manager apparu depuis Windows 7.

Une fois Exchange installé j’ai choisi d’utiliser l’assistant du mode Hybride pour créer automatiquement la configuration nécessaire, bien qu’il soit tout à fait possible de configurer manuellement chacun des aspects du mode Hybride :
– le routage des emails entre O365 et Exchange On-Premise
– la création d’une relation de Fédération, qui servira entre autre à partager les informations de disponibilité
– l’accès aux WebServices On-Premise (autodiscover, disponibilité, migration des BAL)

Les déplacements de données sont réalisés via le proxy MRS, la création d’un « Migration Endpoint » doit donc être prévue côté O365. Une fois celui-ci en place, les déplacements se font par lot via des fichiers CSV, très confortable, avec une étape de finalisation à la main de l’administrateur. Les mêmes limitations que celles liés à une migration Exchange vers O365 existent, en particulier les accès aux ressources partagées ou la configuration des périphériques ActiveSync.

Dans le cas de notre client, le processus de migration devait respecter une limite de temps stricte, la migration des 800 boites aux lettres a été réalisée en moins d’un mois.

Exchange 2013 : les cycles de mise à jour par Cumulative Update

Dans le modèle de mise à jour d’Exchange 2013, chaque Cumulative Update (CU) comprend l’intégralité des binaires d’installation d’Exchange, un Cumulative Update peut donc aussi bien servir à installer un nouveau serveur Exchange, comme mettre à jour un serveur existant.

On peut s’attendre à la sortie d’environ 4 Cumulative Update par an (un tous les 3 mois environ), dont l’un est classé Service Pack. Il n’y a pas de différence fondamental entre un Cumulative Update et un Service Pack, la dénomination Service Pack est utilisée dans le modèle du cycle de vie du produit. Certains partenaires qui garantissent la compatibilité de leurs propres produits avec Exchange ne peuvent pas suivre le cycle des Cumulative Update, trop rapide, et garantissent la supportablité par rapport aux Service Pack.

Il est possible de mettre à jour un serveur Exchange 2013 RTM directement avec le dernier Cumulative Update en date, cependant il faut prendre en compte un autre facteur, moins connu mais très important : les Cumulative Update ne sont supportés que jusqu’à la version N-2. La mise à jour vers le Cumulative Update 5 par exemple n’est supportée et surtout testée que pour les 2 précédant Cumulative Update, soit le Cumulative Update 4 (qui correspondant au Service Pack 1) et le Cumulative Update 3. Rien n’empêche de réaliser une mise à jour depuis la RTM, le Cumulative Update 1 ou 2, cependant ces chemins de mise à jour n’ont pas été validés par Microsoft. Dans la pratique, cela peut engendrer un certain nombre de problèmes, des étapes portées par les Cumulative Update intermédiaires ne sont pas forcément joués comme prévus.

Il existe des patchs indépendants, en général liés à des problèmes critiques, et qui sont intégrés dans le prochain Cumulative Update.

Pour la mise à jour de l’infrastructure, il n’y a pas d’ordre particulier, les nouveaux rôles Exchange 2013 n’ont presque pas d’affinités avec la version utilisée, un FrontEnd en CU4 peut toujours communiquer avec un BackEnd CU5 par exemple.

Un seul cas particulier à ma connaissance, si vous avez un DAG mise à jour vers un CU particulier, vous pouvez toujours joindre à ce DAG un serveur dans un CU inférieur, mais si il y a une mise à jour du schéma des bases de données entre les deux versions, le nouveau membre n’arrivera pas à répliquer les bases.

Powershell : une fonction de log

J’utilise cette fonction de log pour la plupart de mes scripts, elle permet à la fois d’avoir un rendu visuel en couleur, mais surtout crée un tableau d’objets contenant les logs, ce tableau peut ensuite être sauvegarde en CSV, HTLM, XML, etc. J’apprecie encore plus la fonction Out-GridView pour visualiser rapidement le résultat d’un script complexe.

Il suffit d’appeller la fonction à chaque fois que l’on souhaite enregister un évenement :

Out-Log -Name "TacheA" -Msg "La tâche s'est déroulée avec succès" -Type INFO

Les logs sont enregistrés dans un tableau de portée global : $Global:journal, je prefère le mettre en scope Global pour pouvoir le consulter en mémoire hors des scripts.

Le code est disponible dans le ScriptCenter Technet : Out-Log