Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Office 365 migration tenant-to-tenant – Retour d’expérience 3/3

Contexte

Cet article divisé en trois parties est un retour d’expérience sur une migration Office 365 tenant-to-tenant.. Voici la dernière partie qui traitera des problèmes rencontrés lors de la migration.

Problèmes rencontrés et solutions

Eléments de calendrier non-migrés

Un point important pour que la migration des calendrier se fasse, la time-zone de la boite aux lettres de destination doit être renseignée. La commande PowerShell suivante permet de mettre à jour cet attribut

<pre class="wp-block-syntaxhighlighter-code">Set-MailboxRegionalConfiguration –Identity "<UserPrincipalName>" –TimeZone "GMT Standard Time"</pre>

Les valeurs possibles de la time-zone sont indiqués ici : https://support.microsoft.com/en-us/help/973627/microsoft-time-zone-index-values.

Migration OneDrive

Tout comme la migration des éléments de calendrier, la partie OneDrive nécessite une initialisation des comptes cibles pour que la migration s’effectue.

Lors de cette migration j’ai utilisé le script présent à l’adresse suivante pour initialiser l’ensemble des comptes.

https://support.office.com/fr-fr/article/Comment-configurer-des-sites-utilisateur-dans-OneDrive-entreprise-ceef6623-f54f-404d-8ee3-3ce1e338db07

Mauvaise synchronisation des comptes Active Directory

Au moment de la synchronisation de l’Active Directory A vers le tenant B, il est possible que certains comptes ne fusionnent pas avec leur compte cloud correspondant et que des doublons soient présent.

Il peut y avoir diverses raisons à cela :

  • Une erreur dans l’UPN du compte cloud
  • Un contact déjà présent dans le tenant B avec l’adresse email du compte A
  • Un compte invité dans le tenant B avec l’adresse email du compte A

Dans ce cas, il faut tout d’abord supprimer l’objet (le contact ou le compte invité) du tenant B (en le supprimant également de la corbeille O365). Ensuite il faut désynchroniser le compte AD (en déplaçant le compte dans un OU non-synchronisée). Une fois le compte désynchronisé il faut supprimer ce compte de la corbeille O365. Lancer une nouvelle synchronisation pour que la métaverse de l’AD Connect prenne en compte la modification. Enfin resynchroniser le compte AD. Il doit alors fusionner correctement.

Si ce n’est pas le cas, il est possible que le compte cloud ne récupère par l’attribut ImmutableID. Cet attribut est le « lien » entre le compte dans l’Active Directory (et donc celui de la métaverse AD Connect) et le compte cloud O365.

Pour modifier l’attribut il faut de nouveau désynchroniser le compte AD et le supprimer de la corbeille O365 puis il faut utiliser les commandes PowerShell suivantes.

Sur l’Active Directory A :

<pre class="wp-block-syntaxhighlighter-code">$adUser = Get-ADUser "<SamAccountName>" –Properties *

$id= $adUser.ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($adUser.ObjectGUID)).tobytearray())}</pre>

Sur le tenant B :

<pre class="wp-block-syntaxhighlighter-code">Set-MsolUser –UserPrincipalName "<UserPrincipalName>" –ImmutableID $id</pre>

Resynchroniser le compte AD.

Conclusion

Ce billet termine mon retour d’expérience sur cette migration tenant-to-tenant. J’espère qu’il vous a été utile.

Active Directory : Réparer le Secure Channel

Bonjour à tous,

Aujourd’hui nous allons aborder la problématique du Secure Channel (canal sécurisé) dans une infrastructure Active Directory.

Qu’est ce que le Secure Channel ?

Le Secure Channel ou Canal Sécurisé est un élément vital dans une infrastructure Active Directory. En effet, toute communication entre une station de travail et un contrôleur de domaine AD doit passer via un canal sécurisé.

Il est à noter que le canal sécurisé est également utilisé pour les communications entre deux contrôleurs de domaine.

Quand le canal sécurisé est cassé, toutes les opérations Active Directory liées au canal sont en échec (Tickets Kerberos, stratégies de groupes, …).

Quand le Secure Channel est cassé

Le signe le plus flagrant d’un problème de canal sécurisé entre un poste et un contrôleur de domaine est le message suivant au démarrage du poste : « The trust relationship between this workstation and the primary domain failed ».

La plupart du temps, ceci est du au fait que le mot de passe en usage pour établir le Secure Channel sur le poste concerné est différent du mot de passe du compte ordinateur stocké dans l’AD.

Réparer le Secure Channel

Habituellement, l’étape de réparation passe par les étapes suivantes :

  1. Sortie du poste du domaine pour un retour en Workgroup
  2. Réinitialisation du compte ordinateur correspondant dans l’Active Directory
  3. Réintégration du poste dans le domaine

L’ancienne méthode

Une méthode, plus propre, et qui vous épargnera un redémarrage consiste à réparer le canal sécurisé directement avec une invite de commande.

La commande à utiliser est netdom resetpwd /s:domaincontroller /ud:domain\User /pd:*

La nouvelle méthode

Avec l’avènement de Powershell, une nouvelle commande a fait son apparition : Test-ComputerSecureChannel.

Si la commande renvoie True, c’est que le Secure Channel est fonctionnel entre le poste et le contrôleur de domaine concerné.

Si elle renvoie False, c’est que le Secure Channel n’est plus fonctionnel entre le poste et le contrôleur de domaine concerné.

Il faut l’utiliser avec l’option Repair afin de réparer le Secure Channel.

Le retour de la commande, True ou False, indique le succès ou non de la réparation du Canal Sécurisé.

A noter qu’à partir de Powershell v4.0, l’option Credential permet de préciser les identifiants à utiliser pour réparer le canal sécurisé.

Version Windows 7 / Windows Server 2008 R2 :

Version Windows 8 / Windows Server 2012 R2 :

Azure–Présentation d’Azure ADDS

Présentation

Les services de domaine Azure Active Directory fournissent des services de domaine gérés tels que la jonction de domaine, la stratégie de groupe, le protocole LDAP, etc. Vous pouvez utiliser ces services sans avoir à déployer gérer et apporter des correctifs aux contrôleurs de domaine.

Microsoft à créé ce service pour faciliter aux entreprises la création d’un environnement full cloud dans Azure et de répondre aux différents besoins qui sont principalement le coût et la surcharge administrative.

image

Configuration

La particularité d’Azure ADDS est qu’on ne peux pas manager l’AD depuis son interface. Il faut obligatoirement passer par d’autres services, par exemple :

  • Pour la gestion des comptes il faut passer par le service Azure AD ou un AD On-Prémisse synchronisé.

image

  • Pour la gestion des GPO, des OU il faut passer par une VM du domaine et y installer les outils d’administrations.

image

Voici un schéma qui résume l’esprit d’Azure ADDS :

aadds-overview-onpremise

Information

Pour la création de VM Azure il est conseillé d’utiliser la série B. Cette série est une nouvelle offre qui a pour avantage d’être la plus basse car elle s’appuie sur un système de crédit. Elle est prévu en majorité pour des charges de travail ne sollicitant pas en permanences le processeur comme par exemple un serveur web ou un environnement de test. Ces machines sont disponibles dans les régions : US – West 2, US – East, Europe – West, et Asia Pacific – Southeast.

Pour plus d’information concernant la configuration d’Azure ADDS, Consulter le lien suivant : https://azure.microsoft.com/en-us/services/active-directory-ds/