J’ai eu la chance de présenter une session lors des Microsoft Expériences 2016. Cette année, mon thème de présentation était axé sur la sécurisation et le monitoring des identités dans Azure.
Voici ci-dessous les slides utilisés pour cette présentation.
A partir du 15 Septembre 2016, les produits Azure AD Identity Protection et Azure AD Privileged Identity Management ne seront plus intégrés à l’offre de base Azure AD Premium.
En effet, l’offre Azure AD Premium est désormais scindée en deux :
Voici un tableau récapitulatif que je communique souvent à mes clients :
Si vous utilisez déjà ces services en version Preview, vous ne serez pas bloqués dans leur utilisation durant les premiers mois. Seules les nouvelles activations de services en GA, donc à partir du 15 Septembre, seront concernées.
J’ai eu confirmation de ce fonctionnement par l’équipe produit :
For PIM, there is no immediate impact on customers currently in preview. While we will be requiring an Azure AD Premium P2 trial or paid license for NEW tenants that start to use PIM for the first time after Sep 15 GA, PIM will not be performing any license checks on preview tenants that already signed up to PIM during its preview, for the next few months. We will let you know of any future changes for license enforcement.
Update : Les services devraient rester accessibles sans licence Azure AD Premium P2 jusqu’à mi-décembre 2016
Pour utiliser Identity Protection ou Privileged Identity Management en version GA, vous devrez souscrire à Azure AD Premium P2. Une période d’évaluation d’Azure AD Premium P2 sera également disponible pour tester ces produits pendant quelques semaines.
La suite Enterprise Mobility Suite (EMS) a été renommée en Enterprise Mobility + Security, et subira également le même traitement :
Ces modifications permettent, selon Microsoft, d’aligner de manière cohérente les licences Intune, EMS, Office 365 et Azure AD. En cas de doute sur vos licences, n’hésitez pas à vous rapprocher de votre partenaire ou de votre représentant Microsoft.
Sources :
Voici un guide rapide afin de mettre à jour Azure AD Connect en quelques clics.
Depuis la version 1.1.105.0, la planification des synchronisations n’est plus gérée via une tâche planifiée (Task Scheduler), mais directement au travers du service Microsoft Azure AD Sync.
Si vous tentez de modifier la configuration durant un cycle de synchronisation, vous obtiendrez l’erreur suivante :
Vous pouvez soit attendre la fin du cycle en cours, soit forcer l’arrêt de la synchronisation avec les commandes PowerShell suivantes :
Import-Module ADSync Stop-ADSyncSyncCycle
Ouvrez le Task Scheduler, faites un clic-droit sur la tâche planifiée Azure AD Sync Scheduler, puis Disable
Téléchargez la dernière version d’Azure AD Connect ici, puis lancez l’installateur. Vous pourrez vérifier que les sources d’installation correspondent bien à la version que vous installez en consultant le panneau Program and Features :
Lorsque l’assistant de mise à jour d’Azure AD Connect apparaît, cliquez simplement sur Upgrade pour débuter le processus de mise à jour :
La mise à jour peut prendre plusieurs dizaines de minutes selon les ressources de votre serveur et la configuration mise en place.
Lorsque les binaires sont à jour, vous devez entrer vos identifiants administrateur d’Azure Active Directory :
Enfin, cliquez sur le bouton Upgrade pour finaliser la mise à jour de l’outil :
Petit rappel : le support des outils de synchronisation DirSync et Azure AD Sync s’arrête le 13 avril 2017 ! Il est plus que jamais le moment de migrer votre serveur vers la dernière version d’Azure AD Connect.
Pour résumer, Azure AD Connect apporte les nouveautés suivantes :
Suivez ce guide pour mettre à jour Azure AD Connect vers la dernière version disponible.
Si vous ne connaissez pas encore les différences entre ces produits et Azure AD Connect, je vous invite à lire ce guide de comparaison. Pour obtenir plus d’informations sur les méthodes de migration, n’hésitez pas à consulter la documentation officielle de migration à ce sujet !
Bonne migration à tous !
Azure Active Directory Connect Health est un service cloud permettant de monitorer certains services et produits Microsoft au travers d’un agent. Disponible uniquement dans le nouveau Portail Azure, Azure AD Connect Health permet de visualiser en un coup d’oeil l’état de vos services ainsi que les alertes et erreurs potentielles.
Actuellement, Azure AD Connect Health peut monitorer :
Une nouvelle version d’Azure AD Connect (v1.0.9125) a été publiée le 3 Novembre 2015. Cette build inclut l’agent Azure AD Connect Health, et permet donc une remontée des alertes et de l’état du service directement dans le portail Azure.
Voici les étapes à suivre pour monitorer Azure AD Connect dans le nouveau portail Azure :
Si vous n’avez pas encore activé le service Connect Health sur votre tenant Azure :
Note : Pensez à bien lier cette ressource à l’annuaire Azure AD contenant vos objets synchronisés
Vous devez installer la version 1.0.9125 ou supérieur d’Azure AD Connect pour profiter du service. Elle est téléchargeable ici.
Si vous avez déjà l’outil DirSync ou une ancienne version d’Azure AD Connect, il est possible de réinstaller la nouvelle version par-dessus en conservant la configuration actuelle.
cd "C:\Program Files\Microsoft Azure AD Connect Health Sync Agent\PowerShell\AzureADConnectHealthSync"
.\AzureADConnectHealthSync.psd1
Register-AzureADConnectHealthSyncAgent
Grâce à Web Application Proxy, vous pouvez publier les services OWA et ECP sur Internet tout en proposant une expérience d’authentification unique (Single Sign-On) à vos utilisateurs.
Les personnes souhaitant consulter leurs emails devront s’authentifier une seule fois en utilisant leur identifiant / mot de passe sur la page de login ADFS. La délégation contrainte Kerberos (KCD) prendra le relais afin d’utiliser les identifiants de l’utilisateur pour se connecter de maniètre transparente à Outlook Web App.
Attention, votre serveur Web Application Proxy doit obligatoirement être joint au domaine AD afin que la délégation Kerberos puisse se faire.
Si vous ne souhaitez pas joindre WAP au domaine, Exchange 2013 SP1 vous permet également d’utiliser une authentification basée sur des claims ADFS.
Pour que OWA et ECP prennent en charger l’authentification Windows, il est nécessaire de reparaméter chaque répertoire virtuel dans la console d’administration Exchange.
N’oubliez pas d’effectuer cette opération sur tous les serveurs Exchange, et sur les 2 répertoires OWA et ECP.
Pour que la pré-authentification ADFS puisse se faire, il faut créer dans la console AD FS Management une relation d’approbation ne se basant pas sur les claims ADFS.
Dans la partie Non-claims aware relying party trust identifier, vous pouvez spécifier par exemple l’URL d’accès à OWA. Notez que la valeur de cet identifiant n’a pas d’incidence sur l’authentification, il permet juste de savoir sur quelle application on travaille.
A l’étape suivante, laissez la case I don’t want to configure multi-factor authentication settings et cliquez deux fois sur Next puis Close.
Dans la fenêtre qui s’ouvre, cliquez sur Add Rule, puis choisissez Permit All Users.
Validez les dernières étapes pour terminer la configuration de la relation d’approbation.
Dans le cas de la publication d’OWA ou d’ECP, il est nécessaire de créer un enregistrement SPN sur le ou les serveurs Exchange de votre organisation.
Cet enregistrement doit avoir pour valeur HTTP/mail.votredomaine.com, où mail.votredomaine.com est le nom DNS utilisé pour la publication externe du virtual directory.
Vous pouvez également utiliser la commande suivante :
setspn –S http/mail.domaine.com DOMAINE\SERVEUREXCHANGE$
Attention : Si le virtual directory utilise un compte de service du domaine pour fonctionner, vous devrez configurer le SPN sur ce compte et non sur le serveur. Exemple : setspn –S http/mail.domaine.com DOMAINE\svc_account
Il faut ensuite configurer la délégation Kerberos sur le serveur Web Application Proxy, en lui indiquant le SPN que vous avez créé à l’étape précédente :
1- Ouvrez le compte ordinateur du serveur WAP, et allez dans l’onglet Delegation.
2- Sélectionnez Trust this computer for delegation to specified services only, puis Use any authentication protocol.
3- Cliquez sur le bouton Add, puis sur Users or Computers. Recherchez le ou les serveurs Exchange de votre organisation et validez.
4- Validez par OK et vérifiez que le service est bien affiché dans la liste.
Cette étape est essentielle pour que la délégation Kerberos soit bien prise en compte. Si vous n’effectuez pas cette étape, vous pourriez rencontrer une erreur 500 et 0x8009030e lors de l’accès à l’application.
Sur le serveur Web Application Proxy, ouvrez la console Remote Access. Dans le menu Web Application Proxy, cliquez sur le bouton Publish.
Choisissez la méthode de pré-authentification ADFS et cliquez sur Next.
Renseignez les URL internes et externes configurées sur le virtual directory et sélectionnez le certificat SSL approprié. N’oubliez pas de spécifier l’enregistrement SPN.
Répétez l’opération pour la publication d’ECP.
Avec toutes ces étapes, vous devriez être capable de vous authentifier de manière transparente à OWA et ECP au travers de Web Application Proxy.
En cas de problème, je vous conseille cet excellent guide de troubleshooting de Benoit.
Grâce à Web Application Proxy, il est possible d’utiliser la délégation contrainte Kerberos (Kerberos Constrained Delegation ou KCD) afin d’authentifier les utilisateurs de manière transparente sur une application gérant l’authentification Windows Intégrée (Windows Integrated Authentication ou WIA).
Cette méthode permet aux utilisateurs connectés au réseau externe à l’entreprise (hotspot wifi, maison, 4G…) de ne saisir leurs idenfiants qu’une seule fois lors de la pré-authentification ADFS (avec un login / mot de passe). Ils seront ensuite automatiquement connectés à l’application grâce à ses mêmes identifiants.
Pour que l’utilisation de KCD soit possible, votre serveur Web Application Proxy doit être joint au domaine de l’entreprise, et l’application en question doit bien entendu supporter l’authentification WIA.
Même si vous avez configuré toutes les étapes dans les règles de l’art, une erreur 500 peut toutefois survenir lorsque vous essayez d’accéder à l’application. La faute à la configuration de la délégation Kerberos, qui n’est pas totalement finalisée. Vous devrez en effet redémarrer le serveur Web Application Proxy après le rajout d’un SPN dans la liste des services autorisés.
Faute de quoi, vous vous retrouverez avec l’erreur suivante dans l’Event Viewer :
Web Application Proxy cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error: No credentials are available in the security package
(0x8009030e).
Un client m’a récemment contacté suite à une erreur dans l’interface de gestion Web Application Proxy :
Windows could not start Web Application Proxy Service service on Local Computer
Error 0x80072efe: 0x80072efe
Une consultation des logs dans l’Event Viewer a permis de cibler précisément le problème, en identifiant notamment un Event 422 sur le service ADFS, ainsi que l’erreur suivante :
Unable to retrieve proxy configuration data from the Federation Service
System.Net.WebException: The underlying connection was closed. An unexpected error occured on a send
System.IO.IOException: Unable to read data from the transport connection: An existing connection was forfibly closed by the remote host.
En examinant de plus près le thumbprint du certificat utilisé par le service, il ne correspondait à aucun certificat encore en activité sur le serveur ADFS.
Il s’avérait qu’un changement de certificat de type Service Communications, c’est à dire le certificat SSL des pages Web de l’ADFS, avait été récemment effectué depuis l’interface de gestion AD FS Management.
Malheureusement, sélectionner le nouveau certificat et cliquer sur le bouton Set Service Communications Certificate ne suffit pas. Les bindings associés aux différentes applications ADFS ne sont pas modifiés par cette action, comme nous le prouve la commande :
netsh http show sslcert
Pour prendre en compte votre nouveau certificat SSL, il faudra compléter votre configuration en utilisant la commande PowerShell suivante (à taper dans une console en tant qu’administrateur) :
Set-AdfsCertificate -CertificateType "Service-Communications" -Thumbprint "AABBCCDD...."
Note : n’oubliez pas de remplacer le thumbprint par le votre
Redémarrez ensuite le service Active Directory Federation Services sur votre serveur ADFS.
Vous devrez également mettre à jour la configuration de Web Application Proxy pour réparer la relation d’approbation avec le serveur ADFS.
1- Ouvrez une invite de commande en tant qu’administrateur
2- Tapez la commande suivante :
$Cred = Get-Credential
3- Entrez les identifiants d’un administrateur local du serveur ADFS
4- Tapez ensuite la commande suivante pour rétablir la trust :
Install-WebApplicationProxy -FederationServiceName "adfs.home.maximerastello.com" -CertificateThumbprint "AABBCCDD..." -FederationServiceTrustCredential $cred
Note : n’oubliez pas de remplacer le thumbprint et le nom du service ADFS par les votres
Si vous voulez aller encore plus loin, je vous conseille de lire le très bon article de mon collègue Benoit Sautière sur le dépannage d’ADFS et de Web Application Proxy 🙂
Update 16/03/2017 : Cet article est toujours d’actualité, et s’applique également à Exchange 2016.
De nombreux clients choisissent de migrer leur système de messagerie Exchange 2010 ou 2013 vers Exchange Online au travers du mode Exchange hybride. Pour rappel, ce mode permet :
Lors de la mise en place d’une migration Exchange hybride, les administrateurs sont également amenés à configurer :
Lorsque toutles les boites aux lettres sont migrées avec succès dans le cloud, se pose alors la question : comment décommissionner l’infrastructure Exchange on-premises ?
Même s’il n’y a pas de réponse universelle, je souhaiterais éclaircir avec vous certains points, et évoquer notamment les différents impacts que cela pourrait entrainer sur l’administration des boites aux lettres et des utilisateurs.
Dans la tête de beaucoup de clients, la fin d’une migration hybride signifie la suppression de tous les serveurs Exchange on-premises. Dans la réalité, cette suppression est un peu plus délicate à entreprendre.
Rappelez-vous que suite à la synchronisation des identités avec Azure AD Connect, toute modification doit être faite d’abord dans Active Directory : elle sera ensuite répliquée dans Azure Active Directory à la prochaine synchronisation. Ce fonctionnement s’applique à tous les objets synchronisés : utilisateurs, groupes, contacts.
Une telle restriction apparait de manière très concrète dans l’interface d’administration Exchange Online, lorsque par exemple vous modifiez les adresses SMTP d’une boite aux lettres :
L’erreur est claire : vous essayez de modifier dans le cloud un objet qui est synchronisé depuis Active Directory. Ainsi, même lorsque les boites aux lettres sont migrées dans Exchange Online, vous devez continuer à administrer ces boites depuis votre console d’administration Exchange on-premises.
Pour compliquer un peu plus la tâche, certaines actions d’administration échappent quand même à cette règle, et doivent être exécutées dans Exchange Online : c’est notamment le cas des droits de délégation, qui ne sont pas synchronisés.
Pour plus de facilité, voici un tableau récapitulatif des actions d’administration, et où ces dernières doivent être faites :
Pour s’affranchir complètement des serveurs Exchange pour effectuer ces actions d’administration, il convient de trouver une alternative à l’administration Exchange.
Et bien non. Même si quasiment tout ce que l’on peut faire dans l’interface graphique a son équivalent en commande PowerShell Exchange, vous aurez quand même besoin d’un serveur Exchange doté du virtual serveur “PowerShell” pour interpréter vos commandes. Pas de serveur Exchange = pas de commandes PowerShell Exchange.
C’est là où les choses se corsent.
La console d’administration Exchange ne fait que modifier certains attributs Active Directory dédiés. Si mettre à jour manuellement l’attribut proxyAddresses est facile pour rajouter une adresse SMTP, il devient plus difficile de savoir quels attributs modifier lorsqu’on souhaite activer une archive sur une boite.
Gardez au moins serveur Exchange d’administration ! Vous pourrez désactiver sans problème le mode hybride, supprimer tous les connecteurs dédiés et stopper la fédération Exchange, mais vous aurez tout de même besoin d’un serveur Exchange 2010 ou 2013 avec le rôle CAS.
Vous n’êtes pas encore convaincu ? Lisez cet article de l’équipe Exchange Server dédié à Exchange 2010 (mais qui s’applique également à Exchange 2013).
Une solution plus radicale consiste à stopper la synchronisation des identités entre Active Directory et Azure Active Directory. Dans ce cas, vous n’aurez plus d’expérience unifiée entre les deux annuaires :
Pour plus d’informations concernant l’arrêt de la synchronisation Azure AD, je vous conseille de lire cet article officiel.
Update : 07/12/2015 : Microsoft a mis à jour sa documentation pour expliquer également les impacts soulevés dans cet article.
