Réseaux Sociaux

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 :

  • Des serveurs ADFS
  • Des serveurs Web Application Proxy
  • Des serveurs Azure AD Connect

Surveillez l’état de l’outil de synchro Azure AD Connect

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 :

Etape 0 : Activer le service Azure AD Connect Health dans le portail Azure

Si vous n’avez pas encore activé le service Connect Health sur votre tenant Azure :

  1. Connectez vous à https://portal.azure.com
  2. Créer une nouvelle ressource Azure AD Connect Health

 

azure ad connect health service

 

 

Note : Pensez à bien lier cette ressource à l’annuaire Azure AD contenant vos objets synchronisés

 

 

directory azure ad connect health

 

 

Etape 1 : Installer la dernière version d’Azure AD Connect

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.

Etape 2 : Configurer l’agent Azure AD Connect Health

  • Ouvrez une console PowerShell en tant qu’administrateur
  • Naviguez dans le dossier contenant le module PowerShell de l’agent :
cd "C:\Program Files\Microsoft Azure AD Connect Health Sync Agent\PowerShell\AzureADConnectHealthSync"
  • Lancez le module PowerShell Azure AD Connect Health :
.\AzureADConnectHealthSync.psd1
  • Lancez la configuration de l’agent avec la commande :
Register-AzureADConnectHealthSyncAgent
  • Dans la fenêtre qui s’affiche, connectez-vous en utilisant les identifiants d’un administrateur Azure :

 

azure ad connect health config

 

  • Vérifiez que la configuration de l’agent se soit bien déroulée :

 

powershell azure ad connect health

 

Les services suivants doivent être démarrés avec succès :
  • Azure AD Connect Health Sync Insights Service
  • Azure AD Connect Health Sync Monitoring Service

 

azure ad connect health services

 

 

Etape 3 : Vérifier le monitoring dans le portail Azure

Pour accéder au service Azure AD Connect Health, il suffit de cliquer sur la tuile appropriée depuis l’accueil du Portail Azure :

 

 

accueil portail azure

 

 

Si l’étape 2 s’est déroulée avec succès, vous devriez pouvoir visualiser le statut de l’outil de synchro :

 

 

azure ad connect health portal

 

 

Il vous suffira de cliquer sur cette tuile pour obtenir plus d’informations sur la synchronisation en place.

 

 

azure ad connect health dashboard

Étiquettes : , , , , , ,

  

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.

 

Etape 1 : Activez l’authenticiation Windows Intégrée sur OWA et ECP

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.

 

exchange owa WIA

 

N’oubliez pas d’effectuer cette opération sur tous les serveurs Exchange, et sur les 2 répertoires OWA et ECP.

 

Etape 2 : Créez une Non-claims Aware Relying Party Trust

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.

 

non claims aware trust

 

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.

 

relying party trust id

 

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.

 

permit all users

 

Validez les dernières étapes pour terminer la configuration de la relation d’approbation.

 

Etape 3 : Créez un enregistrement SPN sur le serveur applicatif

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.

 

spn serveur exchange

 

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

 

Etape 4 : Configurez la délégation Kerberos sur le serveur WAP

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.

 

spn serveur exchange

 

3- Cliquez sur le bouton Add, puis sur Users or Computers. Recherchez le ou les serveurs Exchange de votre organisation et validez.

 

configure kdc

 

4- Validez par OK et vérifiez que le service est bien affiché dans la liste.

 

service delegation kerberos exchange

 

Etape 5 : Redémarrez le serveur WAP

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.

 

Etape 6 : Publiez OWA et ECP dans WAP

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.

 

pre authentication adfs wap

 

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.

 

spn backend server wap

 

Répétez l’opération pour la publication d’ECP.

 

Etape 7 : Testez l’accès à OWA et 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.

Étiquettes : , , , , , ,

  

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 :

Error : Event 12027

Web Application Proxy encountered an unexpected error while processing the request.
Error: No credentials are available in the security package
(0x8009030e).

Warning : Event ID 13019

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).

 

error wap kerberos delegation

Étiquettes : , , , , , , ,

  

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

error web application proxy

 

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.

 

event 422 adfs

 

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.

Attention lorsque vous changez le certificat HTTPS de votre 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.

 

change service communication certificate adfs

 

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

 

netsh bindings sslcert

 

Etape 1 : sur l’ADFS

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.

 

Etape 2 : sur le WAP

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 :)

 

Étiquettes : , , , , , , , , , , , , ,

  

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 :

  • De migrer les boites des utilisateurs au fil de l’eau
  • De conserver la même expérience utilisateur lors de la migration : statut free/busy, règles propres à l’organisation Exchange…
  • Une migration transparente pour l’utilisateur : conservation du profil Outlook, les mails ne sont donc pas re-téléchargés depuis le serveur après migration
  • De rapatrier une boite migrée vers les serveurs on-premises en cas de besoin

Lors de la mise en place d’une migration Exchange hybride, les administrateurs sont également amenés à configurer :

  • La synchronisation des identités de l’annuaire Active Directory vers Azure Active Directory, au travers de l’outil Azure Active Directory Connect.
  • La fédération des identités avec ADFS. Bien que l’utilisation d’ADFS n’est pas un prérequis à la migration hybride, elle permet aux utilisateurs connectés au réseau interne de s’authentifier de manière transparente aux services Office 365 (portail Office 365, Outlook Web App, et même Outlook ou Skype for Business).

 

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.

Impact sur l’administration Exchange

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.

Attention à la synchronisation des objets

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 :

 

error exchange online sync

 

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 :

 

Action A exécuter dans
Boite aux lettres
Ajouter/supprimer une BaL Exchange on-premises
Modifier la configuration d’une BaL Exchange on-premises
Ajouter/supprimer un alias Exchange on-premises
Gestion des permissions Send As Exchange Online
Gestion des permissions Full Access Exchange Online
Gestion des permissions Send On-Behalf Exchange Online
Activer/désactiver l’archive d’une BaL Exchange on-premises
Calendrier
Gestion des permissions de partage Exchange Online (PowerShell)
Contact
Ajouter/supprimer un contact Exchange on-premises
Modifier la configuration d’un contact Exchange on-premises
Salle
Ajouter/supprimer une salle Exchange on-premises
Modifier la configuration d’une salle Exchange on-premises
Ajouter/supprimer un alias Exchange on-premises
Gestion des permissions Send As Exchange Online
Gestion des permissions Full Access Exchange Online
Gestion des permissions Send On-Behalf Exchange Online
Modifier la liste des salles Exchange Online (PowerShell)
Boite partagée
Ajouter/supprimer une BaL partagée Exchange on-premises
Modifier la configuration d’une BaL partagée Exchange on-premises
Ajouter/supprimer un alias Exchange on-premises
Gestion des permissions Send As Exchange Online
Gestion des permissions Full Access Exchange Online
Gestion des permissions Send On-Behalf Exchange Online
Groupe de distribution
Ajouter/supprimer un groupe Exchange on-premises
Modifier la configuration d’un groupe Exchange on-premises
Ajouter/supprimer un alias Exchange on-premises
Ajouter/supprimer des membres Exchange on-premises

Pour s’affranchir complètement des serveurs Exchange pour effectuer ces actions d’administration, il convient de trouver une alternative à l’administration Exchange.

Et PowerShell ?

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.

Les solutions de contournement

Solution 1 : gardez un serveur Exchange (conseillé)

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).

Solution 2 : Arrêtez la synchronisation des identités (déconseillé)

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 :

  • Les comptes AD et Azure AD seront considérés comme deux identités distinctes, avec chacun ses propres paramètres et son mot de passe. A chaque modification, les administrateurs devront modifier les deux identités de chaque côté pour garder une certaine cohérence, et chaque utilisateur pourra avoir un mot de passe différent pour chaque compte.
  • La fédération ADFS ne fonctionnera plus. En effet, la synchronisation est essentielle à la fédération d’identité. L’utilisateur connecté au réseau interne ne bénéficiera plus de SSO, et devra s’authentifier auprès d’Azure Active Directory de manière explicite avec son login Azure AD et son mot de passe cloud.

Pour plus d’informations concernant l’arrêt de la synchronisation Azure AD, je vous conseille de lire cet article officiel.

Étiquettes : , , , , , ,