Nous vous proposons de vous accompagner pour la migration de votre solution de Booking, vers cette deuxième solution, en suivant les prérequis Microsoft assurant une plus grande sécurité pour l’accès à vos données.
Pour cela nous avons besoin qu’un administrateur Azure de votre Office365, avec des droits de « global Administrator » fasse certaines modifications qui sont indiquées ci-dessous.
Une fois ces modifications apportées, merci de revenir vers nous avec les informations demandées, afin que nous puissions mettre à jour votre solution de Booking TVTools.
Référence technique sur l’arrêt du support de l’impersonation :
https://techcommunity.microsoft.com/blog/exchange/critical-update-applicationimpersonation-rbac-role-deprecation-in-exchange-onlin/4295762
Intérêt de cette nouvelle procédure :
- Plus besoin d’un compte de service Office 365, qui avait une licence, donc une licence de gagnée
- Gestion beaucoup plus simple des salles : il suffit de les mettre dans un groupe Office365 pour qu’elles soient gérées par le système. Aucune configuration supplémentaire
- Sécurité accrue : l’application TVTools n’a accès qu’aux ressources nécessaires
Procédure à effectuer sur votre domaine O365
Votre organisation utilise une solution de roombooking TVTools pour afficher le calendrier de certaines de vos ressources Office365.
Pour accéder à vos données TVTools utilise un accès EWS autorisée par une application Azure, avec les droits suivants
le client ID de votre application : xxxx-xxxx-x-xxxx-xxx à renseigner à partir des valeurs dans le TVTScheduler
la méthode actuellement utilisée nécessite des droits d’impersonation pour l’accès à vos calendriers.
cette méthode ne sera plus fonctionnelle à partir du mois de Février (date exacte inconnue)
https://techcommunity.microsoft.com/blog/exchange/critical-update-applicationimpersonation-rbac-role-deprecation-in-exchange-onlin/4295762
Nous devons passer le droit délégué « EWS.AccessAsUser.All » en droit d’application EWS.AccessAsApp
Ce dernier droit donne des privilèges exorbitants à l’application, et il n’est pas recommandé de l’assigner de manière globale à l’application (qui obtiendrait tout le contrôle sur votre Exchange)
Afin de ne donner ce droit qu’aux ressources nécessaires, et suivant les préconisations de Microsoft, il faut mettre en place une stratégie RBAC,
comme indiqué dans le lien ci-dessus :
Pour avoir des infos en français sur le RBAC :
https://learn.microsoft.com/fr-fr/azure/role-based-access-control/overview
Pour avoir un exemple de déploiement :
https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac
Tuto en Anglais pour explication de la procédure
https://practical365.com/migrate-from-ews-application-access-policy-to-rbac-for-applications/
Procédure
But : assigner un rôle d’application EWS.AccessAsApp à l’application Azure « TVTools Calendars » pour les membres du groupe Azure « TVTools Group »
ensuite, il suffira de mettre les salles dans le groupe « TVTools Group » pour que l’application de Booking TVTools fonctionne.
Attention : nous parlons ici d’un « group office 365 », pas d’un groupe de sécurité. Le groupe de sécurité ne fonctionnera pas.
Soit vous modifiez l’application Azure actuelle, mais dans ce cas, jusqu’à ce que la solution TVTools soit mise à jour, vos solutions de booking ne seront plus fonctionnelles (des changements devant être faits de notre côté)
Soit vous créez une nouvelle application Microsoft Entra ID, que vous pouvez tester, puis vous nous transmettez : Client ID, Secret Value, Tenant Id de cette nouvelle application, afin que nous puissions mettre à jour votre solution.
Nous vous proposons une méthode pour cette deuxième solution
1- Mettre les ressources (salles) auxquelles TVTools doit avoir accès dans un groupe Azure : dans la suite ce groupe s’appellera par exemple « TVTools Group »
(pourquoi le faire au début : le temps de propagation des modifications RBAC : 2h… donc si vous voulez faire des tests immédiats, il faut que les salles soient déjà membres du groupe)
2- Dans l’administration Entra, créer une nouvelle application Microsoft Entra ID, appelons là : « TVTools Calendars ». Créer un secret, gardez sa valeur dans un bloc note, notez le Client Id, Secret Value et Tenant ID
Ajouter un droit d’application User.Read.All, donner votre consentement
pas d’autre configuration.
3- Creation d’un ServicePrincipal pour l’application Entra Id «TVTools Calendars»
$SP = Get-MgServicePrincipal -All
$ServicePrincipalId = $SP | Where-Object {$_.displayName -eq « TVTools Calendars »} | Select-Object -ExpandProperty Id
$AppId = $SP | Where-Object {$_.displayName -eq « TVTools Calendars »} | Select-Object -ExpandProperty AppId
Write-Host (« AppId is {0} and Service Principal Id is {1} » -f $AppId, $ServicePrincipalId)
New-ServicePrincipal -AppId $AppId -ServiceId $ServicePrincipalId -DisplayName ‘PS RBAC TVTools Calendars’
Vérification
Get-ServicePrincipal | ? AppId -EQ $AppId | fl
si AppId est null ou vide, merci d’essayer
$SP=Get-MgServicePrincipal -ConsistencyLevel eventual -Count spCount -Filter « startsWith(DisplayName, ‘TVTools Calendars’) »
$SP
si $SP est cette fois ci bien défini, continuer avec
$ServicePrincipalId = $SP | Where-Object {$_.displayName -eq « TVTools Calendars »} | Select-Object -ExpandProperty Id
$AppId = $SP | Where-Object {$_.displayName -eq « TVTools Calendars »} | Select-Object -ExpandProperty AppId
Write-Host (« AppId is {0} and Service Principal Id is {1} » -f $AppId, $ServicePrincipalId)
et verifier ensuite que
Get-ServicePrincipal | ? AppId -EQ $AppId | fl
ne retourne pas d’erreur avec une AppId non null ni vide
4- Creation d’un “scope” pour le groupe “TVTools Group”
$scopedGroup = Get-Group ‘TVTools Group’
New-ManagementScope « TVTools Scope » -RecipientRestrictionFilter « MemberOfGroup -eq ‘$($scopedGroup.DistinguishedName)' »
verification
Get-ManagementScope « TVTools Scope » | fl
5- assignation d’un role “EWS.AccessAsApp” au scope
New-ManagementRoleAssignment -App $AppId -CustomResourceScope ‘TVTools Scope’ -Role ‘Application EWS.AccessAsApp’
vérification
Get-ManagementRoleAssignment -Role ‘Application EWS.AccessAsApp’ | fl
6- vérification du fonctionnement :
dans la console admin de Office365 (https://admin.microsoft.com/)
mettre la salle Delta@tvtools.info dans le groupe Azure TVTools
ne pas mettre par exemple Omega@tvtools.info
la salle delta@tvtools.info est dans notre groupe « TVTools Group »
Test-ServicePrincipalAuthorization -Identity $AppId -Resource delta@tvtools.info à doit être OK
la salle omega@tvtools.info ne fait pas partie du groupe « TVTools Group »
Test-ServicePrincipalAuthorization -Identity $AppId -Resource omega@tvtools.info à ne doit pas être OK
7- confirmation du fonctionnement : récupération des événements d’un calendrier de salle.
$appId = « xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx mettre le client Id de votre application Entra Id »
$clientSecret = « mettre la valeur du secret de votre application »
$tenantId = « mettre le tenant de votre organisation »
$clientSecretCredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $appId, (ConvertTo-SecureString -String $clientSecret -AsPlainText -Force)
Connect-MgGraph -ClientSecretCredential $clientSecretCredential -TenantId $tenantId
$user=Get-MgUser -Filter « mail eq ‘delta@tvtools.info' » | select
$userId=$user.Id
$events = Get-MgUserEvent -UserId $userId
exemple de résultat pour une salle delta@tvtools.info qui est membre du group « TVTools Group »
exemple de résultat pour un compte rc@tvtools.eu qui n’est pas membre du group « TVTools Group »
8- Merci de transmettre à Tecsoft, les Client Id, secret Value et Tenant Id de votre Application Microsoft ID
une fois cette procédure validée.
9- Remarque : les modifications que vous apportez à votre service principal, scope, role, membre du groupe « TVTools Group »
peuvent être prises en compte uniquement au bout de 2h… c’est très pénalisant pour les tests….
https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac
Si besoin, contactez le support.
