Dans mon travail, malheureusement, il m’arrive de devoir administrer du Microsoft. Pendant les vacances, en équipe réduites, j’ai donc parfois des tâches à mener sur un serveur exchange ou autre, car les admins habituellement dévolus à cette maintenance se reposent (iels ont bien raison) ! Me voici donc ce jour à répondre à une demande de mon support niveau 1 somme-toute très classique (que je suis naïf)
« Oui, peux-tu donner les droits à la Boîte aux lettres partagée « SERVICE T.R.U.C. » (service.truc@domain.tld) à Mme Jeanne Michelle.* ? Elle est nouvelle dans le service, sa cheffe de service vient de nous le demander. »
HelpDesk niveau 1
Le moi plein d’entrain : » Oh oui, pas de soucis, je vais le faire dans la console d’administration exchange, je sais le faire, ça va prendre 10 secondes, je l’ai déjà fait ça. » À ces mots, je m’élance sur mon URLExchange.tld/ecp, je me rends dans le menu des boîtes aux lettres partagées, et vient rechercher le nom « Michelle » dans la fenêtre de droits. Je fais bien attention à chercher mon login « j-michelle » car je sais que le login LDAP « michelle » est déjà pris par Monsieur Patrick Michelle*, le fameux homonyme. Je sélectionne donc mon user dans le champ « contrôle total » et « envoyer en tant que » de l’administration du serveur Exchange (2016) on-premise; puis content de moi, j’annonce à ma technicienne help-desk « c’est fait ! » et reprends ma journée de R&D.
Le début d’après-midi arrive, et revoilà ma technicienne qui revient vers moi avec ce souci :
La Cheffe de Mme Michelle a rappelé, apparemment Jeanne Michelle n’arrive pas à ouvrir la boîte « SERVICE TRUC », l’accès lui est refusé, elle demande si tu a bien fait attention de ne pas confondre avec Patrick Michelle ?
Je confirme que j’ai bien fait attention, ayant connaissance de cette homonymie, et non, j’ai bien sélectionné le login « j-michelle ». Par acquit de conscience, toutefois, je vais vérifier sur l’ECP. Là, grande surprise, je trouve notre grand ami Patrick (Michelle, l’homonyme donc, essayez de suivre, je ne vais pas le répéter à chaque fois, c’est long pour rien) avec les droits sur la boîte partagée « SERVICE TRUC », pourtant il ne travaille pas du tout là. Ce n’est donc pas un droit historique, et pas moyen de trouver Jeanne de toutes manières !
Aurais-je raté ? Je rouvre donc les droits, sélectionne avec précaution le compte-utilisatrice « j-michelle » je vérifie que c’est son nom qui s’affiche dans le menu, et je valide. La page recharge et PAF ! revoilà Patrick ! et Jeanne n’apparaît toujours pas ! Je grommelle, insultes un peu Microsoft dans le chat d’entreprise, puis j’annonce donc « eh bah, c’est nul, il prend l’homonyme sans que je me trompe, je vais donc le faire en PowerShell, ça va passer ».
Quelques minutes plus tard, connecté sur l’exchange en console de management exchange PowerShell, me voilà en train de découvrir/apprendre les commandes, et quelques instants plus tard, je saisis :Add-mailboxPermission -Identity "service.truc" -accessrights fullaccess -user j-michelle
Je me dis « bon, ok, c’était pas trop galère à faire, alors j’ai plus qu’à ajouter le droit « envoyer en tant que ». Pour ce faire, je me dis que powershell est logique (ai-je dit que je suis naïf ?), plus qu’à construire ça :Add-mailboxPermission -Identity "service.truc" -accessrights SendAs -user j-michelle
Et là PATATRAC powershell se met à m’insulter copieusement (en rouge ! ) : il n’y a pas d’autorisation « envoyer en tant que » (pourtant il l’a compris puisqu’il me la traduit) pour la boîte aux lettres, ajoutez l’autorisation « Envoyer en tant que » à l’aide de la cmdlet Add-ADPermission.
Je ne m’offusque peu, je trouve ça étrange d’utiliser 2 commandes différentes, mais en soi la configuration d’Exchange est stockée directement dans leur LDAP (ActiveDirectory) donc je me dis « Why not ? ». Je reconstruis donc quelque chose de similaire avec la nouvelle commande suggérée par ma console, soit :Add-AdPermission -Identity "service.truc" -AccessRights SendAs -user j-michelle
Raté, exchange me jette, apparemment li ne connaît pas le droit « SendAs » dans l’argument « AccesRights » !
« ZUT DE ZUT », je peste vers ma console powershell, « c’est toi qui m’as dit d’utiliser cette commande ! ».
Du coup, je repars faire quelques recherches, le bilan (de MicroSoft) étant « ah non, c’est un droit étendu, il faut utiliser la formulation pour droits étendus », bon, ne me demandez pas ce qu’est un droit étendu, et pourquoi Micro$oft aime se compliquer la tâche sans raison perceptible, en tout cas, je ponds donc la formulation adaptée :Add-AdPermission -Identity "service.truc" -AccessRights ExtendedRight -ExtendedRights "Send As" -user j-michelle
Et là, ça fonctionne ?
Hahahahahahaha ! (Vous aussi, vous êtes naïfs ?!)
Bien évidemment que non !
Voilà la console qui me dit « wesh frère, je ne trouve pas ton ‘service.truc’ » (en effet, je paraphrase de plus en plus librement, mais vous avez l’idée). Vous aurez noté que jusque-là, pour les commandes précédentes, ça ne marchait pas, mais il le trouvait quand même mon service !
Enfin, la solution était, pour le droit étendu, il fallait utiliser…… le NOM D’AFFICHAGE BIEN SÛR. Oui oui, ce nom renseigné dans l’Active Directory en tant que « Nom Complet », celui qui s’affiche si on se connecte à un poste client Windows. […] c’est bien cela, celui qui peut contenir des espaces ou des caractères spéciaux -.-‘
Donc finalement, la commande qui a enfin pu octroyer le droit « envoyer en tant que » sur une boîte partagée exchange était :
Add-AdPermission -Identity "Service T.R.U.C. - Trouvailles Récupération Urgences et Choses-diverses" -AccessRights ExtendedRight -ExtendedRights "Send As" -user j-michelle
En bref ? je déteste toujours Micro$oft…
*pour l'anonymisation, ces noms ont été modifiés XD C'est ce qui m'a empêché de vous mettre de jolis screenshots du powershell tout rouge tout énervé.