2 votes

Empêcher les utilisateurs de donner aux applications tierces l'accès à leurs boîtes aux lettres en utilisant OAuth ou l'authentification de base

Mes utilisateurs transmettent leurs identifiants O365 à un service Web CRM tiers pour la synchronisation du calendrier et des e-mails.
Le service Web s'authentifie en utilisant soit l'authentification de base soit OAuth.
Je veux empêcher cela, sauf pour un utilisateur dédié.
J'ai pensé à créer une Règle d'accès client mais je ne peux pas comprendre lequel des -AnyOfProtocols utiliser, les options sont :

ExchangeActiveSync
ExchangeAdminCenter
ExchangeWebServices
IMAP4
OfflineAddressBook
OutlookAnywhere
OutlookWebApp
POP3
PowerShellWebServices
RemotePowerShell
REST
UniversalOutlook (Mail and Calendar app)

Si je regarde dans Azure AD / Azure Active Directory / Monitoring > Sign-ins, que j'ai trouvé ici, je peux voir quand une application s'authentifie et cela montre ce qui suit :
Application : webCRM.Calendar.Exchange
Ressource : Office 365 Exchange Online

Peut-être ExchangeWebServices?

Des suggestions sur comment accomplir cela d'autres manières?

MISE À JOUR :
OAuth ne supporte que les protocoles suivants ExchangeActiveSync, IMAP4, POP3 (LIEN) alors ExchangeWebServices n'est pas possible.

J'ai essayé cette règle

New-ClientAccessRule -Name "Bloquer les applications tierces pour l'authentification" -Action DenyAccess -UsernameMatchesAnyOfPatterns "*MonID*" -Priority 6 -AnyOfProtocols ExchangeActiveSync, IMAP4 -AnyOfAuthenticationTypes OAuthAuthentication 

Malheureusement, le service Web pouvait encore se connecter à la boîte aux lettres en utilisant OAuth avec l'utilisateur "MonID".

1voto

MrCalvin Points 267

Ma solution a été de souscrire à l'abonnement Azure AD Premium P1 (environ 6$ par mois)
Cela vous donnera accès à Conditional Access où vous pourrez créer des politiques pour bloquer/autoriser des applications et autoriser/refuser des utilisateurs/groupes.

entrer la description de l'image ici

Plutôt intuitif, même s'il semble possible d'utiliser Powershell, New-AzureADMSConditionalAccessPolicy (lien) à partir du module AzureAD.

Lorsque vous sélectionnez quelles applications autoriser/bloquer, vous obtenez une liste d'applications connues parmi lesquelles choisir et cette application CRM tierce était en fait sur la liste, à ma grande surprise. Apparemment, AD enregistre et se souvient des applications auxquelles vos utilisateurs se connectent!

Dans ce cas, il n'était pas vraiment possible d'utiliser des règles d'accès client si votre application s'authentifie en utilisant l'authentification MS moderne, car cela n'utilise aucun des protocoles que vous pouvez autoriser/bloquer.
Et il semble que l'authentification réelle soit effectuée à partir DE VOTRE adresse IP et DE VOTRE navigateur, et non du serveur d'application distant!. Je suppose que cela crée un jeton qui est remis au serveur d'application distant qui le sauvegarde afin de pouvoir l'utiliser pour des connexions/synchronisations futures.

J'ai créé un utilisateur O365 fictif auquel ont été attribuées des autorisations d'éditeur pour les dossiers de calendrier des utilisateurs de l'organisation qui ont besoin de synchroniser leur calendrier avec ce système CRM. C'est le seul utilisateur O365 qui a accès pour s'authentifier avec cette application. Maintenant, le système CRM n'a accès qu'aux dossiers de calendrier, ce qui est déjà assez mauvais, mais pas aussi grave que l'accès aux dossiers de messagerie, beurk!

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X