Scénario

Dans un déploiement Exchange hybride, les autorisations de délégation sont définies pour que l'utilisateur puisse créer des réunions Teams. Lorsque nous exécutons Outlook et créons une réunion Teams pour d'autres utilisateurs Exchange onprem, une erreur Microsoft Teams s'affiche avec le message ci-dessous:

La solution est que l'utilisateur doit encore accorder d'autres droits d'accès aux délégués afin que les délégués peuvent envoyer des éléments en votre nom, notamment créer et répondre à des demandes de réunion.

 - Accéder à la boîte aux lettres depuis laquelle les autorisations seront accordées aux délégués puis cliquer sur Paramètres du compte --> Accès délégué

 - Cliquer sur Ajouter puis sélectionner l'utilisateur qui sera le délégué et cliquer sur OK.

- Choisir Auteur (peut lire et créer des éléments) ou Éditeur (peut lire, créer et modifier des éléments) et cliquez sur OK.

- L'utilisateur apparaît dans la liste des délégués, cliquer sur OK.

Vérifier par la suite que le délégué peut créer des réunions Teams dans Outlook. Si l'erreur persiste, fermer Microsoft Teams et Microsoft Outlook. Démarrer d’abord Microsoft Teams et une fois connecté, démarrer Microsoft Outlook ou encore redémarrer la machine.

La mémorisation de l'authentification multifacteur (MFA) pour les appareils et les navigateurs permet aux utilisateurs d'avoir la possibilité de mémoriser la MFA pendant un nombre défini de jours après avoir effectué une connexion réussie à l'aide de la MFA. Cela peut améliorer la convivialité en minimisant le nombre de fois qu'un utilisateur peut avoir besoin d'effectuer une vérification en deux étapes sur le même appareil.

Cependant, si un compte ou un appareil est compromis, le fait de mémoriser la MFA pour les appareils de confiance peut affecter la sécurité.  Dans cet article, vous apprendrez comment désactiver la mémorisation de l'authentification multifacteur sur les appareils de confiance.

Pour désactiver l'option permettant de mémoriser l'authentification multifacteur sur un appareil de confiance, procéder comme suit :

 - Se Connecter au centre d'administration Microsoft Entra puis accéder à Identité --> Utilisateurs --> Tous les utilisateurs

- Sélectionner MFA par utilisateur

 -Sélectionner Paramètres du service sous "Authentification multifacteur par utilisateur" en haut de la page.

- Décocher la case Autoriser les utilisateurs à mémoriser l'authentification multifacteur sur les appareils de confiance puis cliquer sur Enregistrer.

La commande Set-CalendarProcessing permet de modifier les options du traitement du calendrier pour les boîtes aux lettres de ressources, qui incluent l’Assistant Calendrier, l’assistant de réservation de ressources et la configuration du calendriers des BALs de ressources.

Ce script permet d'ajouter les utilisateurs aux autorisations de planification pour les salles de réunion restreintes sans supprimer les utilisateurs existants

$users = @()

$users += (Get-CalendarProcessing -Identity $mbx).BookInPolicy

$anotheruser = Get-Mailbox <person you want to add>

$users += $anotheruser

Set-CalendarProcessing -Identity $mbx -BookInPolicy $users

 Le paramètre BookInPolicy spécifie les utilisateurs ou les groupes autorisés à envoyer des demandes de réunion dans la stratégie à la boîte aux lettres de ressources qui sont automatiquement approuvées. Vous pouvez utiliser n’importe quelle valeur qui identifie l’utilisateur ou le groupe de manière unique. Par exemple :

• Nom
• Alias
• Nom unique
• Nom unique
• Nom unique canonique
• GUID

L’utilisateur disposait auparavant d’un compte utilisateur synchronisé avec une boîte aux lettres Exchange Online. 

Vérifiez que le compte utilisateur à restaurer se trouve bien dans la corbeille Microsoft 365 :

 Se Connecter au centre d'administration Microsoft 365

Cliquer sur Utilisateurs --> Utilisateurs supprimés et Vérifier que l'utilisateur existe dans la liste

Une fois le compte trouvé dans la corbeille O365, il sera restaurer à partir de la corbeille Active Directory sur site.

Restaurer l'utilisateur hybride Microsoft 365 supprimé

Pour restaurer un utilisateur hybride Microsoft 365 supprimé (un compte d'utilisateur qui a été synchronisé depuis AD sur site vers Microsoft 365/Microsoft Entra ID), les étapes ci-dessous sont à suivre:

1. Se connecter sur le contrôleur de domaine puis sur le centre d'administration Active Directory

2. Sélectionner le domaine puis le conteneur "Objets supprimés" et rechercher l'utilisateur à restaurer

3. Faire un clic droit sur l'utilisateur et cliquez sur "Restaurer" pour restaurer l'objet utilisateur dans son conteneur/OU d'origine

4.Vérifier que l'utilisateur est de nouveau dans l'unité d'organisation qui doit être se synchronisée avec Microsoft 365 via Microsoft Entra Connect Sync.

Synchroniser l'utilisateur avec Microsoft 365

Vous pouvez attendre 30 minutes pour que le prochain cycle de synchronisation Microsoft Entra Connect démarre ou forcer la synchronisation en suivant les étapes ci-dessous :

 Se Connecter sur le serveur Microsoft Entra Connect Sync

 Démarrer Windows PowerShell et exécuter la commande ci-dessous pour forcer la synchronisation de Microsoft Entra Connect

Start-ADSyncSyncCycle -PolicyType Delta

 Vérifier le compte utilisateur dans Microsoft 365

Vérifier que l'utilisateur n'apparaît plus dans la corbeille Microsoft 365:

 - Se Connecter au centre d'administration Microsoft 365

- Cliquer sur Utilisateurs --> Utilisateurs supprimés et Vérifier que l'utilisateur n'apparaît plus dans la liste

Vérifier l'accès de connexion de l'utilisateur

Enfin, vérifier que l'utilisateur peut se connecter avec succès à sa messagerie et que toutes ses données sont restaurées.

Suppression d’un Contrôleur de domaine HS

L'ajout ou la suppression incomplète d'un contrôleur de domaine peut entraîner une incohérence dans les données en raison de la présence d'un contrôleur de domaine existant, mais qui n'est pas entièrement fonctionnel. Cela entrave d’autres processus et un nettoyage complet s'impose.

1-      Depuis l'invite de commande

Les étapes suivantes décrivent comment nettoyer les métadonnées avec l'outil NTDSUTIL d'un serveur contrôleur de domaine HS et qui ne répond plus sur le réseau.

 - Ouvrons une « invite de commande » et saisissons :

Ntdsutil

Metadata cleanup

connections

Connect to server <servername> 

<servername> est le nom d'un contrôleur de domaine (Un contrôleur de domaine bien fonctionnel dans le même domaine) à partir duquel nous prévoyons faire le nettoyage des métadonnées du contrôleur de domaine défaillant. 

- Appuyons sur Entrée après avoir tapé le nom du serveur DC. 

- Nous allons devoir par la suite sélectionner le domaine puis le site ou se trouve le serveur HS et enfin le serveur, tapons alors dans l'invite de commande:

Quit

Select operation target

List domains (Ceci répertorie tous les domaines de la forêt avec un numéro associé à chacun)

Select domain 0

List sites

Select site 0 (ici nous n’avons qu’un seul site, si vous en avez plus de sites, sélectionner le numéro de site correspondant)

List servers in site

Select server 2                                                                                         

Quit   (pour revenir au prompt "metadata cleanup" et sortir du menu de sélection )

- Une fois le serveur est sélectionné, exécutons la commande:

Remove selected server

- Cliquons sur Oui lorsque le message demandant la confirmation de suppression et indiquant que le serveur doit être définitivement déconnecté apparaisse.

 2-      Depuis la console graphique

Depuis la console « Sites et services Active Directory », si nous essayons de supprimer directement le serveur nous obtenons une erreur.

En effet il est nécessaire de supprimer la partie « NTDS settings » avant de supprimer le serveur.

Nous constatons que le serveur a perdu ses propriétés NTDS, comme pour un serveur rétrogradé manuellement le nom du serveur apparaît encore. Il faudra donc le supprimer manuellement.

  3 - Post suppression

Il faudra vérifier et supprimer certains enregistrements DNS manuellement :

• Supprimer le serveur en tant que serveur de nom des zones DNS.
• Vérifier que les DCs restant répliquent (il est possible de vérifier la réplication par repadmin /showrepl) 
• Exécuter un « dcdiag » sur les DC restants et « dnslint /ad /s localhost » 

Les verrouillages de compte AD sont un problème courant rencontré par les utilisateurs d'Active Directory. Les causes courantes de verrouillage de compte AD:

• L'utilisateur a oublié qu'il a changé son mot de passe et continue à saisir le mauvais mot de passe, même après avoir déverrouillé le compte.
• Lorsque votre utilisateur modifie son mot de passe sur son poste de travail mais oublie de le mettre à jour sur ses appareils mobiles, l'appareil continuera à envoyer une requête ping au réseau, finissant (assez rapidement) par verrouiller le compte.
• Tâche planifiée configurée avec des informations d'identification de domaine pour s'exécuter. Si vous avez configuré des scripts ou d'autres processus pour qu'ils s'exécutent à l'aide des informations d'identification du domaine, vous pouvez vous retrouver avec un compte verrouillé si cette tâche n'est pas mise à jour lorsque vous modifiez le mot de passe.

• Parfois, lorsque le logiciel est installé, il installe des services qui s'exécutent sous certains comptes d'utilisateurs de domaine. Si vous modifiez le mot de passe utilisé par le compte dans Active Directory mais ne mettez pas à jour les services, ce service envoie une requête ping au domaine à chaque fois qu'il tente de s'authentifier et verrouille le compte.

• Sessions des services Terminal Serve: Il est possible, en absence des politiques appropriées, que les comptes restent connectés à RDP, RemoteApp, Citrix et à d'autres sessions basées sur les services Terminal Server. Un compte qui reste connecté ailleurs sur le domaine lorsque vous modifiez un mot de passe peut provoquer des verrouillages car le compte continuera à accéder au domaine pour se réauthentifier.

Dans ce qui suit, nous passerons en revue de l'outil ALTools (LockoutStatus.exe) permettant d':

• Identifier la source du verrouillage du compte.
• Obtenir des informations sur le mot de passe d’un utilisateur (dernier changement, validité, dernier mot de passe erroné, …)
• Obtenir des informations sur l’état de verrouillage d’un compte (date, DC d’origine, …)
• Faire une recherche dans les journaux d’évènements sur plusieurs DC en parallèle

LockoutStatus.exe est une combinaison de ligne de commande et d'outil graphique qui affiche des informations de verrouillage sur un compte d'utilisateur particulier à télécharger depuis https://www.microsoft.com/en-us/download/details.aspx?id=18465 

1. Ouvrir le dossier dans lequel l'extraction ALTools a été faite et lancer .exe.

2. Accéder à File et cliquer sur Select Target.

3. Saisir le nom du compte qui continue à se verrouiller dans le champ Target User Name

4. Saisir le nom de domaine dans le champ Target Domain Name puis cliquer sur OK

Examiner les Résultats:

La fenêtre des résultats s'ouvre:

--> Examinez chaque ligne pour déterminer le contrôleur de domaine sur lequel l'authentification du compte de l'utilisateur a échoué.

--> Regardez la fin de chaque ligne pour déterminer la dernière fois où le compte n'a pas réussi à s'authentifier (heure de verrouillage).

 Rechercher l'événement de connexion pour déterminer l'ordinateur source

- Se connecter au contrôleur de domaine qui a été répertorié dans l'outil LockoutStatus, accéder à l'Observateur d'événements "Sécurité" et cliquer sur Filtrer le journal actuel puis taper 4740 dans les ID d'événement 

- Ouvrir l'un des événements et rechercher le nom de l'ordinateur source sous Informations supplémentaires. Cela vous indiquera de quelle machine proviennent les verrouillages de compte (Noter l'horodatage de cet événement)

Rechercher l'événement de connexion sur l'ordinateur source (Caller Computer)

- Se connecter à l'Observateur d'événements à l'ordinateur répertorié comme ordinateur source (Caller Computer)

- Ouvrir les journaux de sécurité et rechercher l'événement qui correspond à l'horodatage déjà noté ci-dessus.

- Ouvrir l'événement (Event ID 4625) et rechercher la raison d'échec ainsi que le nom du processus appelant. 

Lorsqu'aucun ordinateur source n'est répertorié

Parfois, vous ne verrez pas un appelant répertorié. Cela se produit lorsqu'un élément hors domaine est à l'origine du problème, par exemple un appareil mobile tel qu'un téléphone portable ou une tablette essayant de se connecter à un compte de messagerie ou à une application de services de terminal. Ces appareils peuvent être difficiles à localiser via des réseaux, car ils arrivent généralement via Internet .

Il est important de comprendre la différence entre les attributs de connexion, car ils sont utilisés pour différentes raisons. Lorsque vous utilisez PowerShell (Get-ADUser $user ), vous verrez trois propriétés lastlogon différentes: LastLogon , LastLogonTimeStamp , LastLogonDate

LastLogon 

lorsqu'un utilisateur se connecte, cet attribut est mis à jour sur le contrôleur de domaine qui a fourni UNIQUEMENT l'authentification. 

--> L'attribut lastlogon n'est pas répliqué entre les contrôleurs de domaine. Vous devez donc vérifier la valeur sur le contrôleur de domaine auquel l'utilisateur est connecté pour obtenir la bonne valeur.

 LastLogonTimeStamp

pour résumer cet attribut, il s'agit de la version répliquée de l'attribut LastLogon. Il est conçu pour aider à identifier les comptes inactifs et a généralement une latence de réplication allant jusqu'à 14 jours afin de réduire le trafic de réplication. Par conséquent, l'heure exacte de la dernière connexion n'est pas toujours à jour et les informations sont également stockées au format horaire NT qui doit être converti dans un format convivial.

--> L'attribut lastlogontimestamp est répliqué mais ne reflète pas la date et l'heure réelles de la dernière connexion.

LastLogonDate

Ce n'est pas un attribut, c'est plutôt c'est la valeur calculée du LastLogonTimeStamp lors de l'utilisation en PowerShell si vous souhaitez un format facile à lire du LastLogonTimeStamp.

Dans Active Directory (AD), la date de la dernière connexion est mise à jour lorsqu'un utilisateur ou un compte de service interagit avec le domaine d'une manière qui nécessite une authentification. Cela inclut la connexion à un ordinateur, l'accès aux ressources réseau ou l'utilisation de services tels que la messagerie électronique qui s'authentifient auprès d'Active Directory. Cette valeur est mise à jour dans un format convivial.

Si vous recevez un rapport de non-remise lors de l’envoi de mail avec le code d'erreur 5.1.8 et le texte suivant "Your message couldn't be delivered because you weren't recognized as a valid sender. The most common reason for this is that your email address is suspected of sending spam and it's no longer allowed to send email. Contact your email admin for assistance. Remote Server returned '550 5.1.8 Access denied, bad outbound sender" c'est que votre compte a été ajouté aux Entités restreintes au niveau du portail Microsoft Defender d'Office 365.

Cette notification d’échec de remise est générée si vous tentez d’envoyer un e-mail et que vous dépassez la limite d’envoi ou si vous êtes signalé par les filtres anti-spam de Microsoft. Vous ne pouvez pas envoyer d'e-mails, mais vous pouvez toujours en recevoir. 

Afin de débloquer un utilisateur, suivez les étapes indiquées ci-dessous:

1. Connectez-vous au portail Microsoft 365 Defender (https://security.microsoft.com/)

2. Une fois connecté, accédez à la page Utilisateurs restreints en cliquant sur ce lien direct : https://security.microsoft.com/restrictedusers   

3.  Repérer l'utilisateur à débloquer en faisant défiler la liste ou en utilisant le champ de recherche.   

4. Affichez les détails sur l'utilisateur en cliquant sur le nom de l'utilisateur pour afficher plus de détails sur son blocage. La page « Détails de l'utilisateur » vous montrera la raison du blocage.

5. Débloquer l'utilisateur en cliquant sur le bouton "Débloquer l'utilisateur" sur la page "Détails de l'utilisateur". Un message de confirmation apparaîtra vous demandant de confirmer l'action. Cliquez sur "Oui" pour procéder au déblocage de l'utilisateur.   

6. Vérifiez que l'utilisateur est débloqué: Après confirmation, l'utilisateur sera supprimé de la liste restreinte et pourra envoyer de nouveau des messages.

Scénario

Les autorisations d'accès total pour une boîte aux lettres partagée ont été supprimées mais la boîte aux lettres est toujours visible dans Outlook. Dans les paramètres du compte Outlook de l'utilisateur, la boîte aux lettres partagée n'apparaît pas comme une boîte aux lettres supplémentaire.

La raison pour laquelle la boîte aux lettres partagée apparaît dans Outlook, mais n'apparaît pas dans les paramètres du compte Outlook, est que le mappage automatique est activé par défaut lorsqu'un utilisateur a accès à une boîte aux lettres partagée ou à la boîte aux lettres d'un autre utilisateur. Lorsque le mappage automatique est activé, Outlook reçoit des informations supplémentaires dans la réponse de découverte automatique qui lui indiquent d'ouvrir la boîte aux lettres supplémentaire.

Résolution

1. Supprimer l'autorisation d'accès complet à la boîte aux lettres

Supprimez l’autorisation d’accès complet à la boîte aux lettres avec la commande Remove-MailboxPermission. Si vous avez déjà supprimé l'autorisation d'accès complet, passez à l'étape suivante. 

Exemple: Remove-MailboxPermission -Identity "test@contoso.com" -User "user@contoso.com" -AccessRights FullAccess'.

2. Ajouter le mappage automatique des autorisations de boîte aux lettres à accès complet

Le paramètre -AutoMapping spécifie s'il faut activer ou désactiver la fonctionnalité de mappage automatique dans Microsoft Outlook. Il utilise la découverte automatique pour ouvrir d'autres boîtes aux lettres pour l'utilisateur. Les valeurs possibles de ce paramètre sont :

$true : Outlook ouvre automatiquement la boîte aux lettres dans laquelle l'utilisateur dispose d'une autorisation d'accès complet. Il s'agit de la valeur par défaut.

$false : Outlook n'ouvre pas automatiquement la boîte aux lettres dans laquelle l'utilisateur dispose d'une autorisation d'accès complet.

Utilisez la cmdlet Add-MailboxPermission pour ajouter une autorisation de boîte aux lettres d’accès complet. Seulement cette fois, ajoutez le paramètre -AutoMapping, y compris la valeur false. Cela empêchera Outlook d'ouvrir la boîte aux lettres d'informations lorsque l'utilisateur ouvrira Outlook.

Exemple: Add-MailboxPermission -Identity "test@contoso.com" -User "user@contoso.com" -AccessRights FullAccess -AutoMapping $false'

3. Supprimer l'autorisation d'accès complet à la boîte aux lettres

Encore une fois, supprimez l’autorisation d’accès complet à la boîte aux lettres via la cmdlet Remove-MailboxPermission

4. Vérifier la boîte aux lettres non visible dans Outlook

Après les actions effectuées ci-dessus, vous verrez que la boîte aux lettres n'apparaît plus dans un délai de maximum une heure..

Scénario

Après la migration d'une boîte aux lettres vers Exchange Online et au démarrage de Microsoft Outlook, Outlook reste bloqué sur l'écran de chargement pendant quelques minutes, puis demande un mot de passe.

cela peut se produire si :

•  Microsoft Outlook se connecte à la boîte aux lettres principale sur un serveur Exchange onprem à l'aide de RPC et se connecte également à une autre boîte aux lettres située dans Office 365.
• La boîte aux lettres est migrée vers Office 365 à partir d'un serveur Exchange auquel Outlook se connecte à l'aide de RPC.

Outlook n'utilise pas l'authentification moderne pour se connecter à Office 365. La solution consiste à:

- Activer l'authentification moderne dans Microsoft 365

- Ajouter une clé de registre sur les ordinateurs pour forcer Outlook à utiliser la méthode d'authentification la plus récente

Activer l'authentification moderne dans le centre d'administration Microsoft 365

- Se connecter au centre d'administration Microsoft 365, développer Paramètres et cliquer sur Paramètres de l'organisation

- Cliquer sur Services dans la barre supérieure et choisir Authentification moderne 

- Cocher la case Activer l'authentification moderne pour Outlook 2013 pour Windows et versions ultérieures (recommandé) et cliquer sur Enregistrer

 Ajouter la clé de registre AlwaysUseMSOAuthForAutoDiscover

- Démarrer l'Éditeur du Registre sur le poste de travail qui rencontre le problème puis accéder au chemin HKEY_CURRENT_USER\Software\Microsoft\Exchange

- Ajouter une nouvelle valeur DWORD (32 bits) AlwaysUseMSOAuthForAutoDiscover avec la valeur data 1 et cliquez sur OK

Une fois la modification appliquée, démarrer Outlook. Le client Outlook ne demande plus de mot de passe et se connecte immédiatement.