Guide PoC : Accès sécurisé à Office 365 avec Citrix Secure Private Access

Vue d’ensemble

Comme les utilisateurs accèdent au contenu confidentiel dans Microsoft 365 (Office 365), les organisations doivent être en mesure de simplifier les opérations de connexion des utilisateurs tout en appliquant les normes d’authentification. Les organisations doivent être en mesure de sécuriser Microsoft 365 même s’il existe au-delà des limites du datacenter. Citrix Workspace fournit aux entreprises des contrôles de sécurité améliorés pour Microsoft 365.

Dans ce scénario, un utilisateur s’authentifie auprès de Citrix Workspace en utilisant Active Directory comme annuaire d’utilisateurs principal.

Si le service Citrix Secure Private Access est attribué à l’abonnement Citrix, des stratégies de sécurité renforcées, telles que l’application de filigranes à l’écran, la restriction des actions d’impression/de téléchargement, des restrictions de capture d’écran, l’obscurcissement du clavier et la protection des utilisateurs contre les liens non fiables, sont appliquées en plus des applications Microsoft 365.

L’animation suivante montre un utilisateur accédant à Microsoft 365 avec SSO et sécurisé avec Citrix Secure Private Access.

Cette démonstration montre un flux SSO initié par ID dans lequel l’utilisateur lance l’application à partir de Citrix Workspace. Ce guide PoC prend également en charge un flux SSO initié par SP dans lequel l’utilisateur essaie d’accéder à l’application SaaS directement depuis son navigateur préféré.

Ce guide de validation de concept montre comment :

1. Configuration de Citrix Workspace
2. Intégrer un annuaire d’utilisateurs principal
3. Intégrer l’authentification unique pour les applications SaaS
4. Définir des stratégies de filtrage du site
5. Valider la configuration

Configuration de Citrix Workspace

La première étape de configuration de l’environnement consiste à préparer Citrix Workspace pour l’organisation, qui inclut

1. Configuration de l’URL de l’espace de travail
2. Activation des services appropriés

Définir l’URL d’espace de travail

1. Connectez-vous à Citrix Cloud et connectez-vous en tant que compte administrateur
2. Dans Citrix Workspace, accédez à la Configuration de l’espace de travail à partir du menu supérieur gauche
3. Dans l’onglet Accès, entrez une URL unique pour l’organisation et sélectionnez Activé

Activer les services

Dans l’onglet Intégration des services, activez les services suivants pour prendre en charge l’exemple d’utilisation de l’accès sécurisé aux applications SaaS.

1. Secure Private Access
2. Secure Browser

Vérifier

Citrix Workspace prend quelques instants pour mettre à jour les services et les paramètres d’URL. À partir d’un navigateur, vérifiez que l’URL personnalisée de l’espace de travail est active. Toutefois, l’ouverture de session sera disponible une fois qu’un répertoire utilisateur principal aura été défini et configuré.

Intégrer un annuaire d’utilisateurs principaux

Avant que les utilisateurs puissent s’authentifier auprès de Workspace, un annuaire d’utilisateurs principal doit être configuré. L’annuaire des utilisateurs principal est la seule identité dont l’utilisateur a besoin, car toutes les demandes d’applications dans Workspace utilisent l’authentification unique pour les identités secondaires.

Une organisation peut utiliser l’un des répertoires d’utilisateurs principaux suivants avec Microsoft 365 :

• Active Directory : pour activer l’authentification Active Directory, un Cloud Connector doit être déployé dans le même centre de données qu’un contrôleur de domaine Active Directory en suivant le guide d’installation du Cloud Connector .
• Active Directory avec mot de passe à usage unique basé sur l’heure : l’authentification basée sur Active Directory peut également inclure l’authentification multifacteur avec un mot de passe à usage unique basé sur l’heure (TOTP). Ce guide détaille les étapes requises pour activer cette option d’authentification.
• Azure Active Directory : les utilisateurs peuvent s’authentifier auprès de Citrix Workspace avec une identité Azure Active Directory. Ce guide détaille les étapes requises pour activer cette option d’authentification.

  Remarque

  Lorsque vous utilisez AAD comme répertoire d’authentification principal, vous ne pouvez pas fédérer le domaine principal (domaine de connexion de l’utilisateur) car cela crée une boucle. Dans ce cas, vous devez fédérer un nouveau domaine.

  L’attribut doit être immutableID défini pour les comptes utilisateurs AAD ; sinon, l’authentification échouera avec le message d’erreur suivant : AADSTS51004
  Les comptes synchronisés Azure AD Connect obtiennent cet attribut automatiquement.

• Citrix Gateway : les entreprises peuvent utiliser une passerelle Citrix Gateway sur site pour agir en tant que fournisseur d’identité pour Citrix Workspace. Ce guide fournit des informations détaillées sur l’intégration.
• Okta : Les organisations peuvent utiliser Okta comme répertoire utilisateur principal pour Citrix Workspace. Ce guide fournit des instructions pour configurer cette option.

Fédérer l’authentification Azure vers Citrix Workspace

Pour réussir à fédérer Microsoft 365 avec Citrix Workspace, l’administrateur doit effectuer les opérations suivantes :

• Configurer l’application SaaS
• Autoriser l’application SaaS
• Vérifier le domaine d’authentification
• Configurer la fédération de domaine

Configurer l’application SaaS

Une fois le domaine vérifié dans Azure, une application Microsoft 365 SaaS peut être configurée dans Citrix Workspace.

• Dans Citrix Cloud, sélectionnez Gérer dans la vignette Secure Private Access.

• Dans le menu Secure Private Access, sélectionnez Applications
• Dans la section Application, sélectionnez Ajouter une application

Applications - Modèle

• Dans l’Assistant Choisir un modèle, sélectionnez Office 365

• Sélectionner Suivant

Applications - Détails de l’application

• Dans la section Détails de l’application, modifiez le nom, l’icôneet la description selon vos besoins tout en laissant les entrées restantes inchangées.

*Remarque : vous pouvez également acheminer le trafic via l’Connector Appliance déployée dans votre centre de données. Par conséquent, vous devez passer de « En dehors de mon réseau d’entreprise » à « Au sein de mon réseau d’entreprise » .*

• Sélectionner Suivant

Applications - Authentification unique

• Dans la fenêtre Single Sign-On, vérifiez Name ID Format=Persistent et Name ID=Active Directory GUID (1)
• Sous Attributs avancés, vérifiez Attribute Name=IDPEmail, Attribute Format=Unspecified, and Attribute Value=Email (2)

Remarque

La deuxième option d’attribut avancé est ajoutée automatiquement pour supprimer la demande d’authentification MFA lorsque l’utilisateur a déjà saisi l’authentification MFA lors de l’authentification utilisateur auprès de Citrix Workspace.

Nom de l’attribut : http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
Format de l’attribut : Unspecified
Valeur de l’attribut : Custom value
Valeur personnalisée : http://schemas.microsoft.com/claims/multipleauthn

Pour qu’Azure AD accepte cette affirmation, nous devons ajouter un paramètre -SupportsMfa $true lors de la configuration de la fédération de domaines.

Il existe deux options pour continuer : configuration manuelle ou automatique de la fédération de domaines.
Si vous souhaitez utiliser le processus automatisé (script PowerShell), rendez-vous dans la section Configuration automatisée de la fédération de domaines.

Configuration manuelle de la fédération de domaines

• Sélectionnez Télécharger pour capturer le certificat basé sur le CRT. (3)
• En regard de l’ URL de connexion, cliquez sur le bouton Copier pour capturer l’URL de connexion. Cette URL sera utilisée ultérieurement. (4)
• Sélectionnez le lien de métadonnées SAML (5)

• Dans le fichier de métadonnées SAML, recherchez EntityID. Copiez l’URL complète et stockez-la pour une utilisation ultérieure. Une fois capturé, le fichier de métadonnées SAML peut être fermé.

• Sélectionner Suivant
• Passez à la section suivante et passez à Applications - Connectivité des applications

Configuration automatisée de la fédération de domaines

• Sélectionnez Se connecter à Azure AD, un nouvel onglet s’ouvre et vous êtes redirigé vers le portail Azure AD pour l’authentification. (3)
• Spécifiez un compte utilisateur auquel des autorisations « Administrateur global » sont attribuées.
• Le message suivant devrait s’afficher si la connexion a été réussie

• L’option Sélectionner l’authentification multifacteur de l’utilisateur final est activée par défaut.
• Cliquez sur Cliquez ici pour récupérer les domaines Azure AD pour afficher la liste de tous les domaines. (4)
• Sélectionnez le domaine que vous souhaitez fédérer dans la liste déroulante. (5)
• Cliquez sur Fédérer le domaine (6)

Remarque

• Lorsque vous cliquez sur Fédérer le domaine, les scripts PowerShell s’exécutent dans le back-end et le domaine est fédéré.
• Si nécessaire, téléchargez les scripts PowerShell depuis l’interface. Dans le script PowerShell de fédérationde domaines, entrez le domaine Azure AD (7) et cliquez sur Télécharger (8).

• Sélectionner Suivant

Applications - Connectivité des applications

• Dans la fenêtre App Connectivity, vérifiez comment le trafic doit être acheminé (dans ce cas, directement du client vers l’application SaaS)

• Sélectionner Suivant
• Sélectionnez Terminer pour terminer la configuration des applications SaaS Microsoft Office 365.

Autoriser l’application SaaS et configurer une sécurité renforcée

• Dans le menu Secure Private Access, sélectionnez Stratégies d’accès
• Dans la section Stratégie d’accès, sélectionnez Créer une stratégie

• Dans la liste déroulante Applications, recherchez « Office365 » et sélectionnez-le.
• Ajouter les utilisateurs/groupes appropriés qui sont autorisés à lancer l’application
• Spécifiez si l’accès à l’application est possible avec ou sans sécurité renforcée.
  Aucune sécurité renforcée n’est configurée sur la capture d’écran ci-dessus.
  Si une sécurité renforcée est nécessaire, remplacez « Autoriser l’accès » par « Autoriser avec restrictions » et activez toutes les options qui devraient s’appliquer.

Remarque : pour les premiers tests SSO, il est toujours conseillé de configurer une sécurité renforcée en activant l’option « Ouvrir dans un navigateur distant ».

Vérifier le domaine d’authentification

Azure doit vérifier le nom de domaine complet pour fédérer l’authentification avec Citrix Workspace. Dans le portail Azure, procédez comme suit :

• Accès à Azure Active Directory
• Sélectionnez Noms de domaine personnalisés dans la fenêtre de navigation
• Sélectionnez Ajouter un domaine personnalisé
• Entrez le nom de domaine complet

• Sélectionnez Ajouter un domaine
• Azure fournit des enregistrements à incorporer dans votre bureau d’enregistrement de noms de domaine. Une fois terminé, sélectionnez Vérifier.

• Une fois terminé, le domaine contient une marque vérifiée

Configurer la fédération de domaine

Remarque

Vous pouvez ignorer cette section si la configuration de fédération de domaines automatisée a été utilisée.
Passez à la section Valider .

La configuration finale consiste à faire en charge Azure d’utiliser Citrix Workspace en tant qu’autorité fédérée pour le domaine vérifié. La configuration de la fédération doit être effectuée avec PowerShell.

• Lancer PowerShell
• Ajoutez les modules appropriés avec les commandes suivantes

Install-Module AzureAD -Force
Import-Module AzureAD -Force
Install-Module MSOnline -Force
Import-module MSOnline -Force
<!--NeedCopy-->

• Connectez-vous à Microsoft Online via PowerShell et authentifiez-vous à l’aide d’un compte cloud Microsoft (par exemple, admin.user@onmicrosoft.com)

Connect-MSOLService
<!--NeedCopy-->

• Vérifiez que le domaine est actuellement défini sur Managed dans Azure en exécutant la commande PowerShell suivante

Get-MsolDomain
<!--NeedCopy-->

• Utilisez le code suivant dans un script PowerShell pour rendre ce domaine fédéré en modifiant les variables à aligner avec votre environnement

 $dom = "workspaces.wwco.net" # The fully qualified domain name verified within Azure
 $fedBrandName = "CitrixWorkspaceSAMLIdP" # A name to help remember the configuration purpose
 $uri = "https://app.netscalergateway.net/ngs/[entityID]/saml/login?APPID=[APPID]" # The Login URL from the Office365 app configuration
 $logoffuri = "https://app.netscalergateway.net/cgi/logout" # Standard entry for all. Do not change
 $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("<location of certificate downloaded from Citrix Secure Private Access service/filename.crt>") # Path to the downloaded certificate file from Office 365 app configuration (e.g., C:\temp\filename.crt)
 $certData = [system.convert]::tobase64string($cert.rawdata)
 $IssuerUri = "https://citrix.com/[entityID]" # The entityID taken from the Office365 app configuration SAML Metadata file

 Set-MsolDomainAuthentication `
     -DomainName $dom `
     –federationBrandName $fedBrandName `
     -Authentication Federated `
     -PassiveLogOnUri $uri `
     -LogOffUri $logoffuri `
     -SigningCertificate $certData `
     -IssuerUri $IssuerUri `
     -PreferredAuthenticationProtocol SAMLP

To suppress an MFA authentication request when the user has already entered the MFA during user authentication to Citrix Workspace, use the following command:

 Set-MsolDomainAuthentication `
     -DomainName $dom `
     –federationBrandName $fedBrandName `
     -Authentication Federated `
     -PassiveLogOnUri $uri `
     -LogOffUri $logoffuri `
     -SigningCertificate $certData `
     -IssuerUri $IssuerUri `
     -PreferredAuthenticationProtocol SAMLP `
     -SupportsMfa $true
<!--NeedCopy-->

• Vérifiez que le domaine est actuellement défini sur Federated dans Azure en exécutant la commande PowerShell suivante

Get-MsolDomain
<!--NeedCopy-->

• Vérifiez les paramètres de fédération dans Azure en exécutant la commande PowerShell suivante

Get-MsolDomainFederationSettings -DomainName $dom
<!--NeedCopy-->

Remarque

Si les paramètres de fédération doivent être supprimés, exécutez la commande PowerShell suivante :
Set-MsolDomainAuthentication -DomainName $dom -Authentication Managed

Valider

Validation initiée par l’IdP

• Connectez-vous à Citrix Workspace en tant qu’utilisateur
• Sélectionnez l’application Office365
• Observez l’URL pour la voir brièvement rediriger via Azure
• Le portail Office365 est lancé avec succès

Validation initiée par SP

• Lancer un navigateur
• Accédez à l’URL définie par l’entreprise pour l’application SaaS
• Le navigateur redirige vers Azure Active Directory, puis vers Citrix Workspace pour l’authentification.
• Une fois que l’utilisateur s’est authentifié auprès de l’annuaire des utilisateurs principal, l’application SaaS se lance avec Citrix fournissant une authentification unique

Définir des stratégies de filtrage du site

Citrix Secure Private Access permet de filtrer les sites Web dans les applications SaaS et Web afin de protéger les utilisateurs contre les attaques de phishing. La section suivante montre comment configurer des stratégies de filtrage de site Web.

• À partir de Citrix Cloud, gérez dans la vignette Accès privé sécurisé

• Si ce guide est suivi, les étapes de configuration de l’authentification de l’utilisateur final et de configuration de l’accès des utilisateurs finaux aux applications SaaS, Web et virtuelles sont terminées. Sélectionnez les paramètres
• Passez à l’onglet Filtrage Web
• Sélectionner Modifier
• Activer l’option Filtrer les catégories du site
• Dans la zone Catégories bloquées, sélectionnez Ajouter
• Sélectionnez les catégories pour empêcher les utilisateurs d’accéder

• Lorsque toutes les catégories applicables sont sélectionnées, sélectionnez Ajouter

• Faites de même pour les catégories autorisées
• Faites de même pour les catégories redirigées. Ces catégories redirigent vers une instance Secure Browser
• Si nécessaire, les administrateurs peuvent filtrer les actions refusées, autorisées et redirigées pour des URL spécifiques en suivant le même processus que celui utilisé pour définir les catégories. Les URL des sites Web ont priorité sur les catégories.

Valider la configuration

Validation initiée par l’IdP

• Connectez-vous à Citrix Workspace en tant qu’utilisateur
• Sélectionnez Office365.
  Si la sécurité renforcée est désactivée, l’application se lance dans le navigateur local. Dans le cas contraire, le navigateur d’entreprise est utilisé.
• L’utilisateur se connecte automatiquement à l’application
• Les stratégies de sécurité améliorées appropriées sont appliquées
• Si elle est configurée, sélectionnez une URL dans l’application SaaS qui se trouve dans les catégories bloquées, autorisées et redirigées
• Si elle est configurée, sélectionnez une URL dans l’application SaaS qui se trouve dans les URL bloquées, autorisées et redirigées
• Le lancement de l’application SaaS

Validation initiée par SP

• Lancer un navigateur
• Accédez au site Web Office 365 et sélectionnez Connexion
• Entrez le nom d’utilisateur
• Le navigateur redirige le navigateur vers Citrix Workspace pour l’authentification
• Une fois que l’utilisateur s’est authentifié auprès de l’annuaire utilisateur principal, Office365 se lance dans le navigateur local si la sécurité renforcée est désactivée.
  Si la sécurité renforcée est activée, une instance Secure Browser lance Office365.

Domaines associés à Microsoft 365

Un champ de domaine associé est disponible lors de la création d’une nouvelle application dans le service Citrix Secure Private. Les stratégies de sécurité améliorées utilisent ces domaines associés pour déterminer quand appliquer la stratégie.

La liste suivante répertorie les domaines actuellement associés aux applications Microsoft 365.

*Remarque : ces domaines peuvent changer à tout moment*

• *.office.com
• *.office365.com
• *.sharepoint.com
• *.live.com
• *.onenote.com
• *.microsoft.com
• *.powerbi.com
• *.dynamics.com
• *.microsoftstream.com
• *.powerapps.com
• *.yammer.com
• *.windowsazure.com
• *.msauth.net
• *.msauthimages.net
• *.msocdn.com
• *.microsoftonline.com
• *.windows.net
• *.microsoftonline-p.com
• *.akamaihd.net
• *.sharepointonline.com
• *.officescriptsservice.com
• *.live.net
• *.office.net
• *.msftauth.net

Applications Microsoft 365

Supposons qu’il soit préférable de lancer une application Microsoft 365 spécifique (Word, PowerPoint ou Excel) au lieu du portail Microsoft 365. Dans ce cas, l’administrateur doit créer une instance d’application distincte dans le service Citrix Secure Private Access pour chaque application. Chaque application possède une URL unique, qui doit inclure la valeur correcte pour le domaine fédéré configuré dans ce guide. L’entrée de domaine fédéré informe Azure de rediriger vers la configuration de domaine fédéré correcte.

Remarque : le flux initié par l’IDP ne respecte pas l’état du relais. Utilisez le flux initié par SP pour atterrir directement sur l’application.

• Word : https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2Fwww.office.com%2Flaunch%2FWord%3Fauth%3D2&whr=domaine fédéré
• PowerPoint : https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2Fwww.office.com%2Flaunch%2Fpowerpoint%3Fauth%3D2&whr=domaine fédéré
• Excel : https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2Fwww.office.com%2Flaunch%2FExcel%3Fauth%3D2&whr=domaine fédéré
• CRM/Dynamics Online : https://<tenant>.crm.dynamics.com/?whr=domaine fédéré
• OneDrive Entreprise : https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2F<tenant>-my.sharepoint.com%2F&whr=domaine fédéré
• Calendrier Outlook : https://outlook.office.com/owa/?realm=domaine fédéré&path=/calendar/view/Month
• Outlook Web Access to Exchange Online : https://outlook.com/owa/domaine fédéré
• SharePoint Online : https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2F<tenant>.sharepoint.com%2F&whr=domaine fédéré
• Équipes : https://login.microsoftonline.com/common/oauth2/authorize?client_id=cc15fd57-2c6c-4117-a88c-83b1d56b4bbe&response_mode=form_post&response_type=code+id_token&scope=openid+profile&redirect_uri=https%3a%2f%2fteams.microsoft.com%2f&domain_hint=domaine fédéré

Rester connecté

Dans la configuration par défaut, Azure Active Directory affiche une boîte de dialogue pendant le processus d’ouverture de session permettant aux utilisateurs de rester connectés.

Il s’agit d’un paramètre Azure qui peut être facilement modifié en procédant comme suit :

• Dans Azure, sélectionnez Azure Active Directory
• Sélectionner la marque de l’entreprise
• Sélectionnez les paramètres régionaux activés
• Dans le volet Modifier la marque de l’entreprise, sélectionnez Non dans l’ option Afficher pour rester connecté

• Sélectionnez Enregistrer

Résolution des problèmes

Compte d’utilisateur n’existe pas dans l’annuaire

Lors de la tentative de lancement de Microsoft 365, l’utilisateur peut recevoir le message d’erreur suivant :
AADSTS51004: The user account "account name" does not exist in the "GUID" directory. To sign into this application, the account must be added to the directory.

Voici des suggestions sur la façon de résoudre ce problème :

• Vérifiez que l’utilisateur dispose d’une licence lui permettant d’utiliser Microsoft 365 dans la console d’administration Microsoft 365
• Vérifiez que l’adresse e-mail identifiée dans l’erreur correspond à l’annuaire utilisateur principal, Azure Active Directory et Microsoft 365.

• Vérifiez que l’attribut immutableId est défini au niveau de l’objet utilisateur. (Ce n’est pas le cas dans les environnements AAD purs !)
  immutableId peut être facilement calculé et défini à l’aide des commandes PowerShell suivantes :

   $userUPN="john.doh@company.com"  #change the userPricipalName before executing
   Install-Module AzureAD -Force
   Import-Module AzureAD -Force
   Install-Module MSOnline -Force
   Import-module MSOnline -Force
   Connect-MsolService
   $userObjectID=(Get-MsolUser -UserPrincipalName $userUPN).objectId
   $userImmutableId=[System.Convert]::ToBase64String([System.Guid]::New($userObjectID).ToByteArray())
   Set-MsolUser -UserPrincipalName $userUPN -ImmutableId $userImmutableId
   <!--NeedCopy-->
  

Federation, objet Domaine

Lors de la validation, un utilisateur peut recevoir l’erreur suivante :
AADSTS50107: The requested federation realm object 'https://<ADFShostname>/adfs/services/trust' does not exist.

Cela est souvent dû au fait que le domaine n’est pas vérifié ou correctement fédéré. Passez en revue les sections suivantes du guide de PDC :

• Vérifier le domaine d’authentification
• Configurer la fédération de domaine

Échec des stratégies de sécurité améliorées

Les utilisateurs peuvent rencontrer un échec de la stratégie de sécurité renforcée (filigrane, impression ou accès au bloc-notes). Généralement, cela se produit parce que l’application SaaS utilise plusieurs noms de domaine. Dans les paramètres de configuration de l’application SaaS, il y avait une entrée pour les domaines associés.

Les stratégies de sécurité améliorées sont appliquées à ces domaines connexes. La section Domaines associés Microsoft 365 de ce guide PoC contient l’ensemble initial de domaines associés, que Microsoft peut modifier à tout moment.

Un domaine associé doit encore être ajouté si les stratégies de sécurité renforcées ne fonctionnent pas dans certaines sections de l’application. Pour identifier les noms de domaine manquants, un administrateur peut accéder à l’application SaaS à l’aide d’un navigateur local et effectuer les opérations suivantes :

• Accédez à la section de l’application où les stratégies échouent
• Dans Google Chrome et Microsoft Edge (version Chromium), sélectionnez les trois points en haut à droite du navigateur pour afficher un écran de menu.
• Sélectionnez Plus d’outils.
• Sélectionner les outilsde développement
• Dans les outils de développement, sélectionnez Sources. Cela fournit une liste des noms de domaine d’accès pour cette section d’application. Pour activer les stratégies de sécurité améliorées pour cette partie de l’application, ces noms de domaine doivent être saisis dans le champ domaines associés de la configuration de l’application. Les domaines associés sont ajoutés comme *.domain.com