16 Apr 2019, 00:00

Désactivation et réactivation des services de synchronisation Azure AD Connect

Source principale

Il peut parfois être nécessaire de reconfigurer complètement les services de synchronisation entre un Active Directory local et les services Office 365 (Azure Active Directory Connect).

Pour ceci, il faut les désactiver chez O365 via Powershell, les désinstaller du serveur local, puis réinstaller AAD Connect sur le serveur local.

On ouvre une session Powershell en admin.
Si les outils de gestion PS vers O365 ne sont pas installés, on le fait via

Install-Module -Name MSonline

(si message de commande introuvable, il est nécessaire d’installer les PackageManagement, dispo ici

On initialise la variable de connection via

$msolcred = get-credential

en rentrant les ids d’un admin sur O365.

On établit la connection aux services O365

connect-msolservice -credential $msolcred

Il est ensuite temps de supprimer les applis AAD Connect du serveur local (ajout/suppression de programme).
Une fois désinstallés, on lance la commande PS :

Set-MsolDirSyncEnabled -EnableDirSync $false

et on valide avec Y.

pour obtenir l’état de synchro, on lance la commande

Set-MsolDirSyncEnabled -EnableDirSync $false

qui doit désormais renvoyer “false”.

Il faut plusieurs heures (voire une nuit) à Microsoft Azure pour prendre réellement en compte l’arrêt de la synchro. Lorsque ce sera fait, l’interface d’admin O365 n’affichera plus le status AAD Connect, ni l’état (Synchronisé/Dans le cloud) des Utilisateurs O365. Les utilisateurs anciennement synchronisés seront de facto considérés comme utilisateurs cloud.

Une fois que la suppression de la synchro est bien prise en compte par les serveurs O365, il suffit de réinstaller Azure AD Connect, avec éventuellement une passe préalable de IdFix.
Cf. ce post

La synchro reprend normalement assez rapidement, et quelques heure plus tard, l’état AAD Connect réapparait dans le centre d’administration O365.

28 Jul 2018, 00:00

Divers - Office 365 - Exchange online

Équivalences AD / O365 / EAC si ADConnect paramétré

Globalement, l’autorisation “Gérer” de AD correspond au status “Propriétaire” sous O365.
Ce qui existe dans l’AD est transmis vers O365/EAC, l’inverse n’est pas (forcément) vrai. Si on souhaite avoir les éléments en local, il FAUT les créer en local.
Les autorisations d’envoyer un mail “en tant que” (par ex. en tant qu’un groupe de distribution) se gèrent dans tous les cas dans l’EAC, car dans le setup actuel, il n’y a pas de serveur Exchange en local, seulement sur O365.

Utilisateurs

Un utilisateur créé sous AD apparaîtra dans O365 sous “Utilisateurs actifs” et dans EAC sous “Destinataires -> Boîtes aux lettres”. C’est un utilisateur à part entière avec boîte mail dédiée.

Groupes de sécurité

Un groupe de sécurité créé sous AD peut avoir une adresse mail renseignée ou non.

Si adresse, il apparaîtra dans O365 sous “Groupes” (en tant que “Sécurité avec extension messagerie”) et dans EAC sous “Destinataires -> Groupes” (en tant que “Sécurité à extension courrier”).

Si aucune adresse mail n’est renseignée, il apparaitra sous O365 sous “Groupes” (en tant que “Sécurité”) et n’apparaitra PAS dans EAC.

C’est avant tout un groupe pour l’organisation de l’entreprise (GPO de l’AD, etc.), qui peut également être utilisé pour remettre un courrier à tous les membres de ce groupe.
Si un autre groupe est lui-même membre du groupe, les utilisateurs de cet autre groupe ne recevront le mail QUE SI cet autre groupe a une adresse de messagerie renseignée dans ses propriétés (ceci permet de couper le transfert vers les N+1 par exemple, si on ne met pas d’adresse mail).

Groupes de distribution

Un groupe de distribution créé sous AD apparaitra dans O365 sous “Groupes” en tant que “Liste de distribution” et dans EAC sous “Destinataires -> Groupes” en tant que Liste de distribution. Il faut lui définir une adresse mail, sans quoi son intérêt est très limité (il semble qu’il n’apparaisse as dans EAC si pas d’adresse mail renseignée).

C’est un alias qui va rediriger le courrier envoyé à l’adresse en question vers tous les membres inclus dedans (permet une gestion différente des groupes de sécurité).
Si un sous-groupe est lui-même membre du groupe, les utilisateurs de ce sous-groupe ne recevront le mail QUE SI le sous-groupe a une adresse de messagerie renseignée dans ses propriétés.

L’autorisation “Send As” ne peut être définie que directement dans le EAC. Par contre, si le groupe a été créé sur AD, l’autorisation “Send On Behalf” est définie dans ADSI, sous l’attribut “publicDelegates”. Il faut toujours attendre quelques (dizaines de) minutes pour que les changements soient effectifs sous Exchange.
Dans certains cas, le client Outlook d’un utilisateur peut rester “bloqué” sur l’intention d’envoyer “de la part de” (on behalf), ce qui echouera si la seule autorisation accordée est “send as”. Pour “réinitialiser” le comportement du client, il faut désactiver puis réactiver le mode “en cache” du compte Exchange.

Boîte au lettres partagées

Il s’agit d’une boîte à part entière, avec son propre stockage/quota (quota de 99Go à l’heure de cet article). Elle permet de centraliser des messages partagés par plusieurs utilisateurs, ainsi que le calendrier. Sur l’Outlook de l’utilisateur, la boîte sera distincte de celle de l’utilisateur.
Elle permet également de partager un calendrier entre tous les utilisteurs.

Comme nous n’avons dans le cas présent pas de serveur Exchange en local, il ne me semble pas possible d’en créer une sur l’AD. Elle peut être créée dans l’EAC sous “Destinataires -> Boîte aux lettres partagée”.

Elle n’apparaitra pas dans l’AD, mais dans O365 sous les “Utilisateurs actifs”, et bien sûr dans l’EAC.

Création d’une boite aux lettres partagées avec déploiement automatique (dont calendrier)

Dans le centre d’administration Exchange (EAC), on peut aller dans Recipients -> Shared, et créer une boite aux lettres partagées. Tous les utilisateurs qui sont entrés dans les propriétés de la boite partagée -> Mailbox delegation -> Full access verront la boite mail ainsi que son calendrier se déployer automatiquement sur leur client Outlook (avec toutefois un délai jusqu’à une heure).
Ceci correspond à une vraie boîte mail à part entière, avec son propre espace de stockage (quota de 99Go à l’heure de cet article) et apparaitra sur le client outlook séparée de la boite principale.

Il semblerait que l’ajout d’un groupe de sécurité, même avec adresse mail renseignée, ne déploie pas automatiquement les boites et calendriers chez les membres du groupe.

Liste de distribution (alias) sur EAC

Dans le EAC -> Recipients -> Groups, on peut créer des listes de distributions. Ceci ne correspond pas à une vraie boîte mail, mais plutôt à un alias. Les messages sont transférés à tous les utilisateurs définis dans les propriétés de la liste -> Membership.
Si on souhaite qu’un utilisateur puisse écrire depuis l’adresse de la liste de distribution, il faut ajouter l’utilisateur en question dans les propriétés de la liste -> Group delegation, et ajouter son nom sous Send As (envoi en tant qu’alias) ou bien Send on Behalf (envoi en tant que user au nom de alias).

Pour que l’utilisateur puisse envoyer des messages depuis sont Outlook (version de bureau), il faut ajouter le champ De qui est masqué par défaut. Sous 2016, ceci peut se faire dans la fenêtre de rédaction d’un message, sous l’onglet Options. Ensuite, on ajoute à la main le nom de l’alias qui doit servir à envoyer le message. Si les paramètres serveur sont corrects, l’envoi devrait fonctionner. Sinon, essayer de désactiver puis réactiver le mode “en cache” du compte Exchange.

18 Dec 2017, 00:00

Notes en vrac sur Azure AD Connect et Office 365

Mise en cohérence des domaines

Dans mon cas, l’AD avait été pis en place il y’a longtemps, le domaine local était du genre domain.oldcompany.com, mais les utilsateurs utilisaient aujourd’hui des adresses mail du genre user@newcompany.fr, et l’abonnement O365 avait pour domaine initial unusedcompany.onmicrosoft.com.

Dans ces conditions, la synchro de l’AD vers Azure donnait des identifiants du type nomprenom@unusedcompany.onmicrosoft.com, ce qui rend tout plus pénible, par exemple la connexion à OWA qui ne marche pas avec d’éventuels alias, mais qu’avec cet identifiant.

Comme le domaine initial ne peut être changé, il faut ajouter et vérifier le domaine newcompany.fr dans la gestion des domaines sur le portail O365, connecté en admin de l’abonnement. Pour le vérifier, il faudra aller mettre une preuve TXT dans la zone DNS.
Il faut ensuite ajouter un nouveau suffixe UPN au domaine (Outils d’administration -> Domaines et approbations Active Directory -> Propriétés -> Suffixes UPN), on ajoutera ici newcompany.fr car c’est l’adresse couramment utilisée par l’entreprise. Il faut ensuite modifier les suffixes UPN des utilisateurs dans les Utilisateurs et Ordinateurs AD, pour les passer de p.nom@domaine.oldcompany.fr à p.nom@newcompany.fr. Il est possible de le faire en PowerSehll, par exemple avec ce script

Ainsi, les utilisateurs auront un seul couple adresse/password pour se connecter à tout (Session sur le domaine, OWA, Portail O365 pour télécharger les logiciels etc).

Préparer l’AD local pour la synchro

Pour synchroniser un Active Directory local avec les services Azure Active Directory, il faut commencer par préparer l’AD local (notamment étendre le schéma AD sur un serveur Windows 2012). Cette page de Microsoft détaille beaucoup plus la précédure.

Il faut récupérer une installation d’Exchange 2013, par exemple sur cette page de chez Microsoft. On la décompresse, on lance cmd puis la commande suivante : Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

Une fois que le schéma est préparé, on peut identifier les incohérences dans l’annuaire avant de synchroniser avec O365. Pour ça, on utilise l’outil IdFix (DL). Dans le cas où une offre dediée à O365 a été souscrite, il faut aller dans les paramétres et choisir “Dedicated” au lieu de “Multi-tenants”. On clique sur Query, on le laisse chercher, on vérifie puis acccepte les modifications, on fait Apply et on voit ce que ça donne. Si tout va bien, on peut passer à la synchro avec Azure. Si il y’a des problèmes (par exemple attributs non-existants), revérifier que l’AD a bien été préparé tel qu’indiqué sur le tuto de Microsoft.

Mise en oeuvre Azure AD Connect

Télécharger ici : https://www.microsoft.com/en-us/download/details.aspx?id=47594

Une fois installé et configuré, il est possibmle de sy nchroniser manuellement avec la commande PowerShell start-adsyncsynccycle -policytype delta

PowerShell et Office 365

Envoi en tant que groupe : Set-distributionGroup -Identity “group” -GrantSendOnBeHalfto “user@domain.com”