Changement effectué sans avertissement pour des raisons de sécurité
Sans aucun avertissement, Microsoft semble avoir introduit une restriction à la cmdlet Set-User dans le module PowerShell de gestion d’Exchange Online. Le changement se produit lorsque vous connectez une nouvelle session PowerShell à Exchange Online et que les cmdlets sont téléchargés dans une session.
Problèmes de sécurité lors de la mise à jour des numéros de travail ou de portable
Toute tentative de mise à jour des numéros de téléphone professionnel ou mobile d’un utilisateur avec Set-User génère désormais une erreur indiquant que, pour des raisons de sécurité, ces propriétés ne peuvent pas être mises à jour via Exchange Online. Au lieu de cela, les administrateurs sont contraints de mettre à jour les propriétés via le centre d’administration Azure AD ou en utilisant le module Azure AD PowerShell.
Set-User -id $User -Phone « +1 454 146 1412 » Le téléphone et le téléphone portable des utilisateurs avec les détails du type de destinataire « UserMailbox » ne peuvent pas être mis à jour dans Exchange Online pour des raisons de sécurité. Veuillez le faire dans Azure Active Directory. + CategoryInfo : NotSpecified : ([email protected]:UserIdParameter) [Set-User], ShouldNotUpdate…eInExoException + FullyQualifiedErrorId : [Server=AM4PR0401MB2289,RequestId=39d0dbcb-05d1-42e6-b8ea-4bc78fc58816,TimeStamp=10/05/2 021 22:22:12] [FailureCategory=Cmdlet-ShouldNotUpdatePhoneMobilePhoneInExoException] 1D58FC00,Microsoft.Exchange.Management.RecipientTasks.SetUser + PSComputerName : outlook.office365.com Set-user -id $User -MobilePhone « +1 464 147 4433 » (en anglais) Le téléphone et le téléphone mobile des utilisateurs avec les détails du type de destinataire « UserMailbox » ne peuvent pas être mis à jour dans Exchange Online pour des raisons de sécurité. pour des raisons de sécurité. Veuillez le faire dans Azure Active Directory. + CategoryInfo : NotSpecified : ([email protected]:UserIdParameter) [Set-User], ShouldNotUpdate…eInExoException + FullyQualifiedErrorId : [Server=AM4PR0401MB2289,RequestId=4cffcdc2-5bc0-4d17-83bf-a4d7bb67d2a5,TimeStamp=10/05/2 021 22:22:21] [FailureCategory=Cmdlet-ShouldNotUpdatePhoneMobilePhoneInExoException] 1D58FC00,Microsoft.Exchange.Management.RecipientTasks.SetUser + PSComputerName : outlook.office365.com
D’autre part, Set-User est toujours capable de mettre à jour d’autres numéros de téléphone, comme le numéro de téléphone ou le numéro alternatif d’un utilisateur. Vous pouvez également mettre à jour le numéro de pager de quelqu’un (s’il en utilise encore un) et son numéro de fax. Le numéro de fax apparaît également comme une propriété pour un compte Azure AD, donc si Microsoft a décidé de bloquer les numéros professionnels et mobiles, il est étrange qu’ils aient laissé le numéro de fax seul.
Disruption des scripts
Set-User fait partie d’Exchange PowerShell depuis Exchange 2007. La cmdlet est une méthode pour mettre à jour les propriétés des comptes stockées dans Active Directory et Azure Active Directory qui sont importantes pour Exchange (car elles apparaissent dans les listes d’adresses). Le changement de comportement sans avertissement est perturbant pour les organisations, car il pourrait avoir un impact sur les scripts utilisés à des fins de production, comme le fait de prendre une alimentation à partir d’un système RH et de mettre à jour les comptes d’utilisateurs. Le message d’erreur de Microsoft implique que le changement s’est produit pour des raisons de sécurité, mais comme ils n’ont pas expliqué en détail pourquoi c’est un problème de sécurité de permettre à Set-User de mettre à jour les numéros de téléphone, il est difficile d’évaluer ce qui se passe ici. Si c’est un problème pour Set-User de mettre à jour les numéros de téléphone, pourquoi est-il OK pour Set-AzureADUser de faire la même chose ?
Set-AzureADUser -ObjectId [email protected] -TelephoneNumber « +1 550 771 1314 » -Mobile « +1 466 146 1453 »
Rôles et autorisations
Les comptes ont besoin de permissions différentes pour exécuter les deux cmdlets. Les comptes détenant le rôle d’administrateur Exchange peuvent mettre à jour les propriétés des boîtes aux lettres (dont certaines se synchronisent avec Azure AD), mais ne peuvent pas le faire à l’aide d’interfaces Azure AD comme le module Azure AD PowerShell. Il se pourrait que Microsoft veuille resserrer la capacité des utilisateurs ayant des rôles spécifiques à la charge de travail à mettre à jour Azure AD. Bien que je ne puisse pas le prouver, je soupçonne que ce resserrement est au cœur des problèmes signalés avec la cmdlet Set-CsUser depuis la sortie de la V2.3.0 du module PowerShell Microsoft Teams le mois dernier (voir ce post de la Microsoft Technical Community pour quelques détails sur les problèmes des utilisateurs).
Échec des communications
Microsoft communique beaucoup mieux les changements au sein d’Office 365 aujourd’hui qu’auparavant, notamment par le biais de la feuille de route Microsoft 365 et des notifications postées sur le centre d’administration Microsoft 365. Ce changement est sorti de nulle part et a atterri sans avertissement. Les gens n’aiment pas les surprises et réagissent toujours mieux si la logique derrière une mise à jour est clairement expliquée. Tout le monde se ralliera à un changement qui contribue à améliorer la sécurité, à moins qu’ils ne le découvrent lorsque leurs scripts cessent de fonctionner.
