Aller au contenu principal

Office 365 – Granularité de l’administration et stratégies (policies)

19 janvier 2011

Arnaud Alcabez

Parmi beaucoup d’autres nouvelles fonctionnalités, il est intéressant de s’attarder sur le saut quantique que Microsoft Office365 réalise en termes d’administration et de stratégies d’accès. Précédemment, la configuration d’administration de BPOS se limitait à indiquer quel utilisateur était administrateur de la plateforme, et lequel était utilisateur. Il faut aussi considérer le compte Windows Live ID avec lequel vous vous connectiez la première fois à l’interface et qui avait accès exclusivement aux données concernant la facturation.

Pour faire simple, disons qu’avant Microsoft Office365, il était difficile d’appliquer un réel découpage des rôles administratifs, et configurer ne serait-ce qu’un minimum de sécurité d’accès consistait à devenir presque intime🙂 avec les personnes des équipes du support technique.

Un accès aux services de base intuitif

Dès que vous serez en mesure de vous connecter à Office365, vous verrez que les fonctions d’accès aux services sont assez intuitives (par exemple, le type de service que vous fournirez à un utilisateur – ou plan en anglais, mais aussi les accès aux sites SharePoint ou l’autorisation pour Lync de se connecter ou non aux réseaux externes pour la messagerie instantanée).

Toutefois, avec Microsoft Office365, on dispose de deux nouvelles grandes fonctionnalitéss, diaboliquement efficaces et qu’il vous faudra connaître pour configurer le service avec précision: Les RBAC et les Policies.

Office365 et les RBAC pour l’accès aux fonctions du portail

Les RBAC (Role Based Access Control) sont déjà connus des administrateurs d’Exchange Server 2010. Ceux-ci permettent de définir des groupes de stratégies pour des utilisateurs afin qu’ils puissent administrer une partie du système. Dans Office365, on dispose par défaut des rôles RBAC pré-définis suivants:

  • Administrateur d’entreprise
  • Administrateur de facturation
  • Administrateur de compte utilisateur
  • Help Desk
  • Support

A cela, il faut ajouter un RBAC spécifique, destiné à l’administrateur partenaire de l’enregistrement (POR): Administrateur de la part de. Celui-ci correspond à une forte attente des partenaires BPOS dont l’accompagnement dans le support du service était fortement limité jusqu’à présent.

Enfin, au-delà des RBAC fournis par défaut, vous pourrez personnaliser l’administration en créant des rôles spécifiques à certaines opérations, ou limité à une population donnée.

Des permissions d’accès indigènes aux niveaux des applications Exchange Online et SharePoint Online

Ne confondez pas les RBAC du service Office365 avec les permissions d’accès dans les application. Au niveau des applications, vous retrouverez également des systèmes de gestion des permissions à mettre en oeuvre. Si vous avez déjà eu à administrer un serveur Exchange Server 2010 ou un SharePoint Server 2010, vous ne serez pas trop désorientés. Chaque application dispose de sa propre logique de configuration des permissions. Par exemple, pour Exchange, dans la configuration de l’organisation, vous retrouverez des rôles (des RBAC Exchange) pour les administrateurs et pour les utilisateurs. Voici un exemple des RBAC pour Exchange Server 2010 que vous devriez retrouver dans l’interface d’Exchange Online d’Office365.

Les stratégies (policies)

Encore une fois, cela n’est pas forcément nouveau si vous avez déjà eu l’habitude d’utiliser Exchange Server 2010, mais pour une majorité d’entre-vous, je suppose que cela sera une découverte. Au niveau d’Exchange, il existe la possibilité de définir des stratégies personnalisées pour la configuration d’un composant. Les stratégies affectent:

  • Outlook Web App (OWA)
  • Exchange ActiveSync
  • Federated Calendar Sharing
  • User Role Assignement (le même que dans la capture d’écran ci-dessus)
  • Mail retention
  • FOPE (FrontFront Online Protection for Exchange)
  • UM
  • Throttling

Plutôt que d’entrer dans le détail de chaque stratégie, le mieux est de vous présenter un exemple concrêt.

La première opération consiste à se connecter avec PowerShell à votre environnement Office365 et d’invoquer le jeu de cmdlets d’Office365:

Pour OWA, par exemple, il existe une stratégie par défaut, nommée « Default ». Pour en avoir son contenu, il suffit de frapper Get-OwaMailboxPolicy – Identity « Default ». Vous devriez avoir un résultat listant la configuration de chaque paramètre de la stratégie. Je vous fais grâce de la capture pour éviter de vous affoler sur le nombre de paramètres d’une part (mais sachez qu’il y en a beaucoup), et que d’autre part, la liste pourrait évoluer d’ici la disponibilité d’Office365.

Imaginons que je veuille limiter pour un utilisateur donné (moi-même) son interface afin qu’il n’ait pas la possibilité de gérer un agenda via OWA. Cela donne :

a) Créer une stratégie OWA personnalisée

New-OwaMailboxPolicy -Name « SecureOWAWithoutCalendar »

Notez que la nouvelle stratégie est créée sur la base de la stratégie par défaut.

b) Configurer la stratégie afin qu’elle retire l’accès au calendrier

Set-OwaMailboxPolicy -Identity « SecureOWAWithoutCalendar » -CalendarEnabled $False

c) Appliquer la stratégie sur ma boîte aux lettres

Set-CASMailbox -Identity arnaud.alcabez -OwaMailboxPolicy « SecureOWAWithoutCalendar »

La stratégie s’applique immédiatement et sera effective dès lors que l’utilisateur accèdera de nouveau à OWA. Voici ci-après le résultat en image :

En conclusion

Comme vous avez pu vous en rendre compte au long de cet article, Office365 apporte un niveau de finesse et de paramètrage inconnus jusqu’à présent. Chez Capgemini, cela nous donne la possibilité d’accompagner nos clients sur une mise en oeuvre et une intégration plus fine d’Office365 en conformité avec les équipes administratives en place.

Dans l’ordonnancement de votre projet, je ne saurai vous conseiller, surtout si SharePoint 2010 et Exchange 2010 ne vous sont pas familliers et que vous n’avez pas dans votre culture de travailler directement avec les équipes métiers, de plutôt réaliser la mise en oeuvre vers BPOS ou Office365, qui peut tout à fait être utilisé tel quel, out-of-the-box, puis d’affiner la granularité de votre solution après coup.

Toutefois, dans le cadre des grands projets de migration, cette étape est un fondamental de l’étude fonctionnelle et un élément différentiateur de l’approche d’Office365 par rapport à BPOS, qui devra être présenté puis être conduit en phase pilote ou de preuve de conception avant la mise en production et la migration des utilisateurs vers Office365.

Les commentaires sont fermés.

%d blogueurs aiment cette page :