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

Set-MailboxRegionalConfiguration –Identity "<UserPrincipalName>" –TimeZone "GMT Standard Time"

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 :

$adUser = Get-ADUser "<SamAccountName>" –Properties *

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

Sur le tenant B :

Set-MsolUser –UserPrincipalName "<UserPrincipalName>" –ImmutableID $id

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.

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 :

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.

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

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

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

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/

Contexte

Lors d’un renouvellement de certificat WEB sur une instance SSRS, le mapping du nouveau certificat échoue avec l’erreur suivante :

Microsoft.ReportingServices.WmiProvider.WMIProviderException: An SSL binding already exists for the specified IP address and port combination. The existing binding uses a different certificate from the current request. Only one certificate can be used for each IP address and port combination. To correct the problem, either use the same certificate as the existing binding, or remove the existing SSL binding and create a new binding using the certificate of the current request.

Explication

Le message d’erreur précise que la combinaison IP:Port est déjà mappée à un certificat existant (celui que l’on tente de renouveler).

La commande suivante permet de visualiser le binding existant :

netsh http show sslcert

On remarque que le certificat que l’on tente de renouveller est mappé à la combinaison IP:Port suivante : [::]:443

Résolution

A l’aide de la commande précédemment citée, récupérer la combinaison IP:Port utilisée par le certificat que l’on tente de renouveler, puis supprimer le mappage à l’aide de la commande suivante :

netsh http delete sslcert ipport=[::]:443

Contexte

Depuis une console lancée en tant qu’administrateur du domaine il est impossible de supprimer une zone DNS existante, une erreur de type “AccessDenied” est retournée :

Explication

En investiguant sur la cause de cette erreur, on remarque qu’une ACE refuse au groupe Tout le Monde de supprimer cet objet :

Cette ACE est en fait créée automatiquement lorsque la protection contre la suppression accidentelle est activée.

Résolution

Après la suppression de cette entrée, il est possible de supprimer l’objet sans erreurs.

Contexte

La mise en miroir des bases de données est une solution de haute-disponibilité fournie par SQL Server depuis la version 2005. Cette fonctionnalité s’implémente au niveau de chaque base de donnée.

L’avantage de cette solution est de disposer d’une base de donnée active en tout temps, ce qui permet de réaliser des maintenances sur un serveur sans interrompre l’accès aux bases utilisées par des application clientes.

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez à la place Groupes de disponibilité Always On.

Cause

Voici les principales causes provoquant une interruption de la replication Mirroring :

• Les serveurs partner (+ eventuellement witness) ne communiquent pas correctemment,
• Erreur d’espace disque sur l’un des serveurs partner,
• Changement du recovery model sur le serveur principal (le mirroring requière le recovery model Full).

Résolution

La commande suivante exécutée sur l’un des serveur partner permet de rétablir la réplication :

ALTER DATABASE DATABASE SET PARTNER RESUME

Contexte

Dans Office 365 lorsque vous activez une fonctionnalité qui déclenche un mail automatique (exemple : activation de l’UM, activation du PSTN calling…) le mail est rédigé dans la langue du tenant et non dans celle de l’utilisateur.

Explications et solution

Par défaut l’ensemble des mails envoyés automatiquement utilise la langue sélectionnée lors de la création du tenant. Donc si votre tenant a été créé en Français l’ensemble des mails sont envoyé en Français.

Pour changer la langue, en anglais par exemple, il faut que l’utilisateur possède l’attribut PreferredLanguage de renseigné sur son compte Active Directory. Pour l’anglais il est possible de mettre “EN-US” ou “EN-GB”.

La liste des code possibles est disponible au lien suivant https://technet.microsoft.com/en-us/library/ee825488.aspx.

Une fois la valeur modifiée (et après avoir effectué une synchronisation AzureADConnect) le mail envoyé est en anglais !

Script de modification de l’attribut PreferredLanguage dans l’AD

Si vous souhaitez modifier en masse l'ensemble des utilisateurs vous pouvez utiliser le script PowerShell ci-dessous.

$users = Get-ADUser -Filter * -SearchBase "DC=MONDOMAINE,DC=COM" -SearchScope Subtree
$actual=1
$total = $users.count
foreach($user in $users)
{ 
   $sam = $user.SamAccountName
   Write-Progress -Id 1 -Activity ("Working...Please wait") -PercentComplete ($actual / $total * 100) -Status ("Working on {0} - {1} / {2}" -f $sam, $actual, $total)
   Set-ADUser $sam -add @{PreferredLanguage="EN-GB"}
   $actual++
}

Tous les admins SCOM vous le diront : créer des nouvelles règles dans la console classique peut s’avérer terriblement frustrant, en particulier par son manque de flexibilité et de liberté.

Un exemple particulièrement récurrent est l’impossibilité d’utiliser autre chose que le Visual Basic pour créer des règles ou moniteurs scriptés, alors qu’il est parfaitement possible d’utiliser Powershell en passant par des outils tiers (MP Author de Silect, voire VisualStudio).

Une première tentative de simplifier les choses avait été réalisée par Wei Lim, avec un management pack qui apportait un wizard permettant la création de moniteurs en powershell directement dans la console SCOM : https://blogs.msdn.microsoft.com/wei_out_there_with_system_center/2015/07/09/opsmgr-new-sample-wizard-to-create-powershell-monitors-in-the-ops-console/

Cela restait cependant assez limité, il n’était par exemple pas possible de passer de paramètres aux scripts au début (ce qui fut corrigé dans une release ultérieure) et seule la création de moniteurs à 2 états était possible.

Depuis peu, SquaredUp (société bien connue pour son excellente console web éponyme, nous en reparlerons surement un jour) propose également un management pack gratuit, qui apporte enfin à la console SCOM les fonctionnalités que nous étions en droit d’attendre : création de moniteurs à 2 et 3 états, de tous types de règles, de tâches… en powershell, à l’aide de wizards fort bien concus !

Le Management Pack est disponible ici : https://squaredup.com/free-powershell-management-pack/

Description

Sophos Central vous permet de gérer les politiques de sécurité et d’administrer plusieurs produits depuis une seule interface Web. Aucune installation ou déploiement de serveurs de gestion ne sont requis. Vos serveurs et appareils se connecteront directement à Sophos Central pour recevoir les nouveaux paramètres, envoyer des alertes et partager l’intelligence contextuelle de sécurité.

Installation

Pour pourvoir manager vos appareils il faut dans un premier temps ajouter les comptes utilisateurs dans la console Sophos Central. Pour ce faire il existe deux méthodes soit :

• Ajouter les comptes à la manuellement, en remplissant les informations suivantes :

• Synchroniser les comptes Active Directory de votre entreprise avec l’outil « AD Sync Settings/Status ».

Nous allons nous attarder sur la deuxième méthode.

Tout d’abord il faut se rendre dans l’onglet « Global Settings » et télécharger l’outil.

Lancer l’exécutable sur un Contrôleur de Domaine puis un assistant va apparaître pour configurer la synchronisation.

Mettre votre compte Sophos Central.

Cocher l’option “SSL” puis remplir les informations suivantes.

Note : utiliser un compte de service pour effectuer la synchronisation.

Choisir le ou les domaines puis les “OU” à synchroniser.

Il ne reste plus qu’a définir quand s’effectuera la synchronisation.

Une fois fini cliquer sur « Finished » et l’utilitaire ce synchronisera à l’heure que vous avez indiquez. Pour lancer une première synchronisation il faut cliquer sur « preview and sync ».

Les comptes sont maintenant ajoutés dans Sophos Central.

La dernière étape est d’installer les agents sur les appareils clients. Une des méthodes est de leurs envoyer un mail d’instruction expliquant les différentes étapes d’installation depuis la console Sophos.

Configuration

Dans l’onglet “Endpoint Protection” puis “Policies” vous pouvez configurer les règles de sécurité des utilisateurs.

Il ne reste plus qu’a créer vos règles en fonction de vos besoins.

Information :

Pour plus d’information concernant la configuration, je vous invite à consulter le lien suivant : http://docs.sophos.com/sophos-cloud/help/fr-fr/PDF/scloud_hfra.pdf

Lors de la finalisation d’une migration side by side SCOM 2007 vers SCOM 2012 R2, j’ai rencontré un problème assez inattendu : il ne restait alors plus que quelques agents Windows 2003 à déployer et quelques autres à mettre à jour avec le dernier UR, et je n’anticipais pas de problème particulier dans cette phase déjà réalisée à maintes reprises sur d’autres serveurs de cet environnement ainsi que sur d’autres environnements.

J’ai donc eu la mauvaise surprise de constater que ces agents s’arrêtaient dès leur démarrage, parfois sans aucun message d’erreur (arrêt « propre » matérialisé par les événements 103 puis 101), parfois avec un message d’erreur assez peu parlant (événement 1000 après l’événement 103) :

Faulting application healthservice.exe, version 7.1.10292.0, stamp 585161d0, faulting module unknown, version 0.0.0.0, stamp 00000000, debug ? 0, fault address 0x000c9ba0.

J’ai alors décidé de prendre une trace de l’agent, afin d’obtenir un diagnostic plus poussé (cf. https://blog.piservices.fr/post/2017/09/30/SCOM-Prendre-une-trace-de-lagent1).

Fort heureusement le problème était très simple à reproduire (un simple démarrage de l’agent…), et m’a permis d’obtenir l’erreur suivante :

Unable to create self-signed certificate : -2146893816(NTE_BAD_ALGID).

L’agent échoue donc à créer un certificat auto-signé lors de son démarrage, et plante dans la foulée.

Mais pourquoi chercherait-il à générer un certificat ? Comme le précise Stefan Roth dans cet article très détaillé (https://stefanroth.net/2016/03/02/scom-how-data-is-encrypted/), ce certificat est utilisé lorsque le Management Server transmet un RunAs Account à un agent afin d’apporter un niveau de chiffrement supplémentaire.

Ce certificat est donc créé lors du premier démarrage de l’agent, ainsi que lorsqu’il expire (sa durée de vie est d’un an) :

Nous constatons sur la capture ci-dessus que le certificat est bel et bien présent dans le magasin.

Pourquoi l’agent cherche-t-il a le régénérer, et pourquoi échoue-t-il ?

La réponse à la première question se trouve (de façon assez peu claire il est vrai) dans les release notes de l’UR12 de SCOM 2012 R2 :

• SHA2 support for certificates:  SHA1 is deprecated for the System Center 2012 R2 Operations Manager Agent and SHA2 is now supported.

Autrement dit, le certificat auto-signé de l’agent est maintenant signé avec l’algorithme SHA2 (SHA256RSA) et non plus avec SHA1.

Tant mieux pour la sécurité, SHA1 est aujourd’hui considéré comme déprécié et ne devrait plus être utilisé.

La réponse à la seconde question se trouve encore une fois chez Microsoft : Windows 2003 (et par extension Windows XP) ne supporte pas les algorithmes de la famille SHA2 sans un hotfix qui n’a jamais été intégré aux mises à jour régulières, comme l’indique la KB suivante : http://support.microsoft.com/kb/938397

Une fois le hotfix installé et le serveur redémarré, on constate que l’agent démarre sans encombre et qu’un certificat signé en SHA256 est généré :

Et voilà, problème réglé !