Lors de la migration d’un serveur de fichier, il est probable que vous rencontriez des erreurs de transferts liés aux fichiers dont le répertoire contient plus de 256 caractères. Afin de lister les fichiers qui vont vous poser problèmes vous pouvez exécuter cette commande powershell :
Vous est il déjà arrivé de ne plus pouvoir vous connecter à l’interface de management de votre VCSA ? Cela m’est arrivé ce matin ! Voici la solution en cas de problème de connexion à l’interface VAMI du vCenter.
Dans un premier temps, il faut contrôler si les services sont en cours d’exécution, pour cela connectez vous en ssh sur le vcenter pour voir leur état actuel :
On peut constater que le service applmgmt est arrété, il faut donc le redémarrer avec la commande suivante :
puis recontrôler ensuite que l’ensemble des services sont bien en cours d’exécution Ensuite essayez à nouveau de vous connecter sur l’interface VAMI, si vous y arrivez le problème est résolu 🙂 Pour ma part je n’ai pas réussi mais ai eu un autre message d’erreur :
Il vous arrive d’avoir plus trop d’espace sur le disque système Windows ? Si vous analysez avec TreeSize l’espace utilisé par chaque dossier, vous constaterez que le dossier sous Windows\WinSxS est assez volumineux. Pour le réduire, vous pouvez utiliser la solution suivante :
Exécutez en ligne de commande avec privilège administrateur la commande suivante :
Le dossier WinsXS est un dossier système contenant les fichiers du magasin de composants Windows pour l’utilisation de Windows Update permettant d’installer de nouvelles versions de composants afin de garantir la mise à jour et la sécurité du système.
Microsoft à poussé une mise à jour sur tous ses OS. Cette mise à jour portant le nom de KB4093492 peut entrainer des soucis de connexion RDC sur certains serveurs.
Pour de nombreux clients ce fut le cas, c’est pourquoi que vais vous donner une solution si vous aussi vous rencontrer ce problème.
Lorsque vous lancez la connexion au serveur distant avec l’outil de connexion Bureau à distance, vous obtenez l’erreur suivante :
Si vous rencontrez cette erreur, il y a plusieurs solutions.
Vous pouvez très bien désinstaller le KB4093492, mais nous verrons ici un moyen de contournement plus simple.
Via PowerShell / Regedit
Depuis l’ordinateur impacté, lancer Powershell en admin et taper la commande suivante :
Vous devriez ensuite être en mesure de vous connecter.
Si ce problème impact de nombreux postes, vous pouvez également jouer avec les GPO pour solution votre problème sur tous les ordinateurs du réseau ou d’une OU.
Présentation de l’authentification avec Active Directory sur un pfsense
J’ai remis un peu les mains dans pfSense alors j’en profite pour vous écrire ce tutoriel. Cet outil open source est capable de se connecter à un annuaire LDAP, en l’occurrence ici l’Active Directory de Microsoft, afin de centraliser l’authentification auprès de différents services comme l’accès à l’interface d’administration, l’accès VPN ou encore la connexion au portail captif. Bien que dans certains cas, le point de liaison entre pfSense et l’Active Directory sera Radius. Avec pfSense, il est possible de déclarer la connexion à un AD pour authentifier les utilisateurs (certains utilisateurs, pas tous), pour déléguer l’administration du pare-feu. Par exemple, on va définir un groupe qui aura le droit de configurer la partie portail captif du pare-feu, on va attribuer des droits à un groupe, et ce groupe correspond à un groupe de l’AD. On peut avoir un second groupe qui pourra seulement accéder aux logs du pare-feu, par exemple. On pourrait tout à fait créer des groupes locaux sur pfSense, avec des utilisateurs locaux, mais c’est quand même plus sympa d’interroger directement l’AD pour ne pas avoir à subir les changements de login et/ou de mot de passe. En plus, ce n’est pas monstrueux comme config.
En résumé, on va : – Déclarer l’annuaire Active Directory sur pfSense (on part du principe où vous avez un AD opérationnel) – Tester l’authentification – Déclarer un groupe dans pfSense pour faire le lien avec l’AD – Attribuer des droits à ce groupe – Définir notre serveur AD pour l’authentification – Tester la connexion à la WebGUI avec un compte AD
Déclarer l’annuaire Active Directory sur pfsense
Connectez-vous à la WebGUI de votre pfSense avec un compte administrateur. Cliquez sur le bouton « System » puis « User Manager » qui permet de gérer les utilisateurs et les groupes pfSense, ainsi que de configurer un serveur d’authentification. Cliquez ensuite sur « Authentication Servers« .
Les trois copies d’écran qui suivent font partie de la même page de configuration. Tous les paramètres n’ont pas besoin d’être modifiés, voyons cela ensemble. Descriptive name : Indiquez un nom pour ce serveur, je vous conseille d’indiquer le domaine Type : Indiquez « LDAP » qui est le choix par défaut de pfSense Hostname or IP address : Si le pfSense est capable de résoudre le nom DNS de votre contrôleur de domaine, indiquez le nom FQDN comme je l’ai fait dans mon exemple. Mais, vous pouvez aussi indiquer l’IP simplement. Il n’est pas nécessaire de modifier les autres paramètres, à moins que vous souhaitiez utiliser un certificat pour chiffrer les échanges, ce qui est conseillé bien entendu. C’est tout pour cette première partie.
Voici la suite du paramétrage : Search Scope : Laissez « Entire Subtree » pour le scope de recherche, puis pour la « Base DN » indiquez la racine de votre AD en prenant exemple sur ce que j’ai fait pour le domaine « it-connect.local ». Authentication containers : Indiquez une ou plusieurs OU dans lesquelles pfSense peut regarder pour trouver les utilisateurs qui tentent de se connecter. Remplissez au moins une valeur et ensuite cliquez sur « Select a container » vous pourrez prendre d’autres OU si besoin. Ensuite décochez l’option de « Bind anonymous » on va plutôt s’authentifier pour requête l’AD. Au préalable, j’ai créé un compte dans l’AD qui est simple utilisateur et qui a pour SamAccountName (login) : pfsense.connect Il faut indiquer le DN de cet utilisateur, si l’écriture d’un DN vous semble trop compliqué, ou aussi pour éviter les fautes de saisies… Vous pouvez requêter directement par PowerShell sur votre AD (il suffit d’adapter le login) :
Copiez ensuite la valeur retournée dans le champ « Bind credentials » de la conf pfSense, puis sur le champ juste à droite indiquez le mot de passe associé à ce compte. D’ailleurs, je suis surpris que le mot de passe s’affiche en clair !!! Enfin, dernière partie de la conf, on tient le bon bout ! 🙂 Vous pouvez seulement indiquer « group » à la place de « posixGroup« , et veillez à ne pas cocher l’option « LDAP Server uses RFC 2307 style group membership » sinon pfSense ne pourra pas récupérer le nom du groupe auquel appartient votre utilisateur.
Sauvegardez la configuration avec le bouton « Save ».
Tester l’authentification AD
Avant de tester l’authentification avec l’outil de diag intégré à pfSense, je vous montre une copie d’écran de mon AD, ça peut permettre de mieux visualiser ma config. Vous verrez que j’ai un compte « pfsense.connect » que j’ai utilisé pour que pfSense puisse interroger l’AD, puis le groupe « pfSenseAccess » contient les utilisateurs qui doivent avoir accès à pfSense. Dans le menu « Diagnostics« , cliquez sur « Authentication« .
Cliquez sur « Test », si tout est OK vous devriez obtenir ce message :
Si c’est le cas, bravo ! Vous pouvez passer à la suite.
Déclarer le groupe local dans pfsense
Toujours dans pfSense, il faut que l’on crée un groupe local qui aura le même nom que le groupe Active Directory, ceci permettra à pfSense de faire le lien entre les membres du groupe Active Directory et les droits positionnés sur le groupe pfSense. Dans System, User Manager, accédez à l’onglet « Groups » et cliquez sur « Add ». Nommez ce groupe comme celui de l’AD, donc dans mon cas je note « pfSenseAccess » mais ça n’empêche pas de préciser dans la description qu’il s’agit d’un groupe AD pour le différencier, la description peut être personnalisée. Au niveau du scope, lorsqu’il s’agit d’un groupe Active Directory, il faut normalement indiquer « Remote » à la place de « Local » mais je n’ai pas vu de réelle différence selon le choix du scope. Enfin, n’ajoutez aucun membre dans ce groupe et validez. Maintenant que le groupe est créé, on va lui donner des droits.
Attribuer des droits au groupe local
Toujours dans la gestion des groupes, cliquez sur l’icône en forme de crayon pour éditer le groupe fraîchement créé. Descendez au niveau de la section « Assigned Privileges » et cliquez sur « Add ». Ensuite, toute la liste des privilèges apparaît, vous verrez que c’est vraiment flexible, on peut gérer finement les droits. C’est intéressant pour avoir une délégation précise. Dans cet exemple, si l’on veut que ce groupe soit capable de gérer la partie « Portail Captif », voici ce qu’il faut sélectionner : On aurait pu ajouter d’autres privilèges pour accéder à la partie log du portail captif. Cliquez sur « Save » dès lors que votre sélection est effectuée.
Définir notre serveur Active Directory pour l’authentification
Cette étape de la configuration est indispensable sinon la connexion à pfSense s’appuiera sur la base locale et non sur l’AD. Toujours dans System / User Manager / Settings, définissez votre AD, par exemple « it-connect.local » comme serveur d’authentification. Puis, sauvegardez. Cette étape est déjà terminée et elle clôture la configuration du pfSense, maintenant il va falloir tester cette config.
Tester la connexion à la WebGUI pfsense avec un compte AD
Ouvrez un navigateur et accédez à la page de connexion de pfSense. Ensuite, tentez de vous connecter avec un compte AD : Normalement, une fois connecté, vous devriez avoir accès seulement à la partie « Captive Portal » sous « Services », tous les autres menus sont vides. Voilà, ce tutoriel est terminé, vous pouvez désormais déléguer l’administration de votre pfSense en s’appuyant sur des comptes AD. C’est important d’utiliser des comptes distincts pour l’administration pour savoir qui fait quoi.
Si vous rencontrez cette erreur et que vous êtes bloqué, il va falloir supprimer définitivement l’utilisateur dans AD AZure. Pour réaliser cette opération, sauvegarder tout d’abord l’ensemble des documents éventuels présents dans OneDrive, puis réaliser les opérations suivantes :
Retirer l’utilisateur affecté de la synchronisation Azure AD Connect en le déplaçant dans une OU qui n’est pas synchronisé puis démarrer la synchronisation delta par la commande :
Start-ADSyncSyncCycle -PolicyType Delta
Cela à pour effet de mettre l’utilisateur dans la corbeille d’Azure AD. Vous pouvez contrôler cela en regardant dans Utilisateurs supprimés la présence de l’utilisateur.
Supprimer définitivement l’utilisateur d’AD Azure en se connectant sur AD Azure comme ceci:
Une fois que l’utilisateur n’est plus présent dans Utilisateurs supprimés, vous pouvez placer à nouveau l’utilisateur dans son OU d’origine (celle qui été synchronisée :-)) puis exécuter à nouveau une nouvelle synchronisation delta par la commande :
Start-ADSyncSyncCycle -PolicyType Delta
Une fois l’utilisateur créé dans Azure AD et la licence affectée, vous pouvez relancer la migration depuis votre Exchange.
Si vous rencontrez un problème de migration des boîtes à lettre de ressource de votre Exchange vers Office 365 avec le message d’erreur suivant :
MigrationPermanentException: Le déplacement d’intégration n’a pas pu être créé, car l’utilisateur est déjà en cours de déplacement.
Sur votre Exchange exécuter Exchange Management Shell et contrôler les migrations existantes par la commande :
Get-MoveRequest
Si vous avez des requêtes de migration en status Completed vous pouvez les supprimer en éxécutant la commande PowerShell suivante :
Remove-MoveRequest
avec le nom affiché précédemment d’une requête de migration.
Si le message d’erreur affiche que le domaine ne fait pas partie des domaines acceptés, supprimer l’adresse mail contenant le nom du domaine local vous pourrez, une fois la synchronisation Azure AD Connect, migrer les bals de ressource sans souci.
Rappels : Pour lancer une synchronisation sasn attendre le cycle par défaut de 30 minutes, exécuter la commande suivante :
Exchange Online PowerShell vous permet de gérer vos paramètres Exchange Online à partir de la ligne de commande. Vous utilisez Windows PowerShell sur votre ordinateur local pour créer une session PowerShell distante vers Exchange Online. Il s’agit d’un processus simple en trois étapes dans lequel vous entrez vos informations d’identification Microsoft 365, vous indiquez les paramètres de connexion requis, puis vous importez les cmdlets Exchange Online dans votre session Windows PowerShell locale afin de pouvoir les utiliser.
Exécuter les commandes suivantes en PowerShell :
Set-ExecutionPolicy RemoteSigned
$UserCredential = Get-Credential
Renseigner les identifiants de votre tenant Office 365 :
Voici un script PowerShell qui vous permettra de modifier en masse les attributs ProxyAddresses dans votre Active Directory lorsque vous êtes en mode synchronisé avec AAD Connect et que vous voulez faire des modifications en masse sur vos utilisateurs. Ce script ajoute prénom.nom@votredomaine en alias.
variable à spécifier :
$newproxy : variable correspondant au nom de domaine public de l’alias à ajouter
$userou : l’OU dans laquelle vous voulez faire vos modifications en masse
