Configurez O365
Conditions préalables
Pour configurer les applications O365 dans l’application Citrix Workspace, veillez à effectuer les opérations suivantes :
-
Si vous avez un domaine principal disponible dans Azure AD qui n’est pas fédéré avec d’autres services, vous pouvez utiliser ce domaine pour effectuer la fédération vers Citrix Secure Private Access. Assurez-vous que ce domaine, que ce soit son domaine parent ou son domaine enfant, n’est pas déjà fédéré et que son domaine parent n’est pas déjà ajouté dans Azure Active Directory (AAD).
Par exemple, si votre connexion utilisateur utilise user1@demo.citrix.com, demo.citrix.com est le domaine principal, citrix.com est le domaine parent et us.demo.citrix.com est le domaine enfant.
-
Si vous ne pouvez pas fédérer le domaine principal, ajoutez un nouveau domaine à Azure AD et fédérez-le à Citrix Secure Private Access. Créez le domaine et terminez la vérification. Pour plus de détails, consultez https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain.
OU
Vous pouvez ajouter un sous-domaine à Azure AD qui peut être exploité pour fédérer avec Citrix Secure Private Access pour SSO. Pour cela, vous devez ajouter et promouvoir le sous-domaine en domaine racine. Pour plus de détails, consultez https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/domains-verify-custom-subdomain.
Remarque : vous devrez peut-être utiliser Azure AD Graph Explorer au lieu de Microsoft Graph Explorer pour la requête POST visant à transformer un sous-domaine en domaine racine.
Pour savoir pourquoi vous avez besoin d’un domaine fédéré, consultez Comment fonctionne la fédération de domaines.
-
Vérifiez que le nouveau domaine ou le sous-domaine que vous avez ajouté est à l’état « Vérifié » dans Azure AD.
-
Configurez une approbation entre votre fournisseur d’identité SAML et Azure AD. Pour configurer une approbation, vous devez disposer d’un domaine qui est vérifié dans AAD. Lorsqu’une fédération est configurée dans AAD à l’aide d’un domaine, AAD fait confiance au fournisseur SAML pour l’authentification de l’utilisateur auprès d’AAD, même si l’utilisateur appartient à un domaine différent du domaine fédéré. Dans le flux initié par le SP, lorsque AAD doit identifier l’IdP à utiliser pour l’authentification (accélérer l’utilisateur en IdP fédéré), il est identifié à l’aide du
whr query param
oudomain_hint
transmis à l’URL https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-authentication-for-federated-users-portal.L’ajout d’une fédération pour un nouveau domaine n’a aucun impact sur une fédération existante que vous avez dans votre configuration. Si ADFS est déjà fédéré sur un domaine, cela n’est pas affecté car vous fédérez sur un autre domaine qui n’est ni un sous-domaine ni un domaine parent d’un domaine déjà fédéré.
L’authentification unique peut comporter les deux flux suivants :
Flux initié par le fournisseur d’identité : généralement utilisé lorsque vous souhaitez vous connecter au portail Azure AD. Le service Citrix Secure Private Access publie l’assertion SAML dans Azure AD (AAD). AAD le valide en fonction du paramètre de fédération que nous avons défini précédemment. Si la validation est réussie, elle extrait l’attribut
nameid
de SAML. L’attributnameid
doit correspondre à l’utilisateurimmutableId
présent dans l’AAD.Flux initié par le fournisseur de services : Généralement utilisé lorsque vous souhaitez accéder directement à l’application au lieu du portail AAD. Dans ce flux, le service Citrix Secure Private Access charge l’URL configurée dans les paramètres de l’application. L’URL est envoyée à AAD et comme l’URL contient une indication du domaine fédéré, l’utilisateur est redirigé vers le service Citrix Secure Private Access avec une requête SAML et un état de relais. Le service Citrix Secure Private Access publie l’assertion SAML sur AAD avec le même état de relais que celui fourni dans la demande. Une fois que SAML est validé, AAD redirige un utilisateur vers le contexte dans l’état relais et, par conséquent, l’utilisateur atterrit directement sur l’application.
-
Configurez l’application O365 dans le service Citrix Secure Private Access. Pour plus de détails, consultez la section Support pour les applications Software as a Service.
Comment fonctionne la fédération de domaines
La figure suivante illustre un flux typique impliqué après la fin d’une fédération de domaine.
Considérez que vous souhaitez ajouter l’application Office365 dans Citrix Workspace, activer le filigrane et restreindre les téléchargements. Le débit typique est le suivant :
- Vous lancez l’application Office365 dans Citrix Workspace.
- La demande est envoyée au service Citrix Secure Private Access.
- Le service Citrix Secure Private Access crée l’assertion SAML et la transmet à Azure AD.
-
Comme la demande provient d’un fournisseur d’identité SAML approuvé, Azure AD l’identifie via la fédération de domaine qui est créée et transmet l’assertion SAML à l’application Office365.
L’application Office365 est lancée.
Méthodes d’authentification prises en charge pour l’application Office365
Par défaut, Citrix Cloud utilise le fournisseur d’identité Citrix pour gérer les informations d’identité de tous les utilisateurs de votre compte Citrix Cloud.
Citrix Workspace prend en charge les méthodes d’authentification suivantes pour Office365. Okta et Google IdP ne sont actuellement pas pris en charge.
- Répertoire Active Directory local
- Jeton Active Directory plus
-
Azure Active Directory
Remarque : si AAD est utilisé pour s’authentifier auprès de l’espace de travail, 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
- Citrix Secure Private Access
- Active Directory plus RADIUS
Pour plus de détails, consultez la section Gestion des identités et des accès.
Configuration de l’application O365 dans le service Secure Private Access
Voici les étapes de haut niveau pour configurer l’application O365 dans le service Secure Private Access. Pour plus de détails, consultez la section Support pour l’application Software as a Service.
- Accédez au service Secure Private Access dans Citrix Cloud.
- Recherchez Office 365 et choisissez un modèle. Pour plus de détails, consultez la section Support pour les applications Software as a Service.
-
Ajoutez les domaines connexes suivants dans les détails de l’application. Voici la liste des domaines O365. De nouveaux domaines sont ajoutés lorsqu’ils sont disponibles.
- *.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
- Activez des contrôles de sécurité améliorés, si nécessaire.
-
Configurez l’authentification unique.
Remarque : La seule modification que vous devez faire est de vous assurer que « ID de nom » est le GUID Active Directory.
- Assurez-vous que les attributs avancés envoient également
IDPEmail
.- Nom de l’attribut :
IDPEmail
- Format d’attribut : non spécifié
- Valeur d’attribut : Email
- Nom de l’attribut :
- Cliquez sur Métadonnées SAML pour ouvrir un nouvel onglet.
- Copiez « EntityId »
- Copiez « URL de connexion »
- Téléchargez le certificat au format CRT
Configurer la fédération de domaine d’Azure AD vers Citrix Workspace
Pré-requis :
- Activer PowerShell dans Azure AD
- Installez le module Microsoft MSOnline
Voici les commandes PowerShell permettant d’installer les modules requis.
`PS> Install-Module AzureAD -Force`
`PS> Import-Module AzureAD -Force`
`PS> Install-Module MSOnline -Force`
`PS> Import-module MSOnline -Force`
<!--NeedCopy-->
Si les modules sont déjà installés, exécutez la commande suivante.
PS> connect-msolservice
<!--NeedCopy-->
Remarque : Un compte cloud Microsoft est requis pour se connecter à msolservice
. Par exemple, admin.user@onmicrosoft.com
Étapes à suivre pour configurer la fédération de domaine d’Azure AD vers Citrix Workspace
-
Exécutez les commandes suivantes dans PowerShell pour configurer la fédération :
PS> $dom = "ad-domain.com"
Remarque : ad-domain.com est le nouveau domaine ajouté à Azure AD
PS> $IssuerUri = "https://citrix.com/[customerID]"
Remarque : Le CustomerID se trouve aux emplacements suivants :
- Citrix Cloud > Gestion des identités et des accès > Accès aux API
-
Citrix Cloud > Citrix Secure Private Access. l’ID client se trouve dans les détails de configuration de l’application (Single sign > SAML Metadata file > EntityID).
PS> $fedBrandName = “CitrixWorkspace”
PS> $logoffuri = "https://app.netscalergateway.net/cgi/logout"
PS> $uri = "https://app.netscalergateway.net/ngs/[customerID]/saml/login?APPID=[AppID]”
Remarque : $uri peut être copié depuis Citrix Secure Private Access Service > Ajouter un Web/SaaSapp > Single Sign on > URL de connexion ou depuis les métadonnées SAML > Emplacement.
-
PS> $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<location of certificate downloaded from Citrix Secure Private Access service/filename.crt>”)
Par exemple :
PS> $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\cert\saml_idp.crt")
PS> $certData = [system.convert]::tobase64string($cert.rawdata)
-
Exécutez la chaîne PS pour terminer la fédération vers Citrix Secure Private Access :
PS> Set-MsolDomainAuthentication -DomainName $dom –federationBrandName $fedBrandName -Authentication Federated -PassiveLogOnUri $uri -LogOffUri $logoffuri -SigningCertificate $certData -IssuerUri $IssuerUri -PreferredAuthenticationProtocol SAMLP
-
Vérifiez les paramètres de fédération de domaines en exécutant la commande suivante :
Get-MsolDomainFederationSettings -DomainName <domain name>
Fédération de domaine automatisée d’Azure AD vers Citrix Workspace
Dans la fédération de domaine manuelle d’Azure AD vers Citrix Workspace, comme expliqué dans la section Configurer la fédération de domaine d’Azure AD vers Citrix Workspace, les utilisateurs doivent basculer entre le portail cloud et PowerShell pour copier des données et exécuter les scripts. Par exemple ;
- Copiez les données, telles que l’ID client et l’ID d’application, à partir du portail cloud.
- Téléchargez le certificat depuis le portail cloud.
- Exécutez les scripts PowerShell.
Cette action de copier-coller manuelle peut entraîner des erreurs à cause desquelles la fédération risque d’échouer.
Les étapes de fédération d’un domaine sont désormais intégrées dans l’interface utilisateur de Citrix Secure Private Service, ce qui automatise le processus de fédération. Les scripts PowerShell sont exécutés dans le serveur principal lorsque les utilisateurs cliquent sur les liens appropriés dans l’interface. Les utilisateurs n’ont pas besoin de basculer entre le portail cloud et PowerShell.
Étapes à suivre pour fédérer automatiquement un domaine
- Configurez l’application O365. Pour plus de détails, consultez la section Configuration de l’application O365 dans le service Secure Private Access.
-
Dans Connexion unique, sélectionnez SAML.
- Connectez-vous à Azure AD à l’aide de vos informations d’identification.
Lorsque vous cliquez sur Se connecter à Azure AD, vous êtes dirigé vers le portail d’ouverture de session Azure AD pour l’authentification.
- Le protocole OAuth est utilisé pour l’authentification. Une fois l’authentification réussie, vous devez fournir votre consentement pour la fédération du domaine.
- 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 afin d’afficher la liste de tous les domaines.
- Sélectionnez le domaine que vous souhaitez fédérer et cliquez sur Fédérer le domaine.
Remarque :
- Lorsque vous cliquez sur Federate domain, les scripts PowerShell sont exécutés dans le back-end et le domaine est fédéré.
- Vous pouvez également télécharger les scripts PowerShell, si nécessaire, à partir de l’interface. Dans le script PowerShell de fédération de domaines, cliquez sur Télécharger.
Supprimer l’authentification multifacteur (MFA)
Une option est ajoutée aux attributs avancés des applications O365 qui supprime la MFA lorsque l’utilisateur a déjà saisi l’authentification MFA lors de l’authentification de l’utilisateur auprès de Citrix Workspace.
-
Nom de l’attribut : «
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
», -
Valeur d’attribut : «
http://schemas.microsoft.com/claims/multipleauthn
»
Pour que l’AAD accepte cette revendication, fédérez à l’aide de la commande PowerShell suivante :
Set-MsolDomainAuthentication -DomainName $dom –federationBrandName $fedBrandName -Authentication Federated -PassiveLogOnUri $uri -LogOffUri $logoffuri -SigningCertificate $certData -IssuerUri $IssuerUri -PreferredAuthenticationProtocol SAMLP -SupportsMfa $true
Remarque :
le flux initié par l’IdP ne respecte pas l’état du relais. Utilisez le flux initié par le SP pour atterrir directement sur l’application.
Configuration des applications individuelles de la suite Office dans Citrix Workspace
Effectuez les opérations suivantes pour configurer des applications de suite bureautique individuelles :
- Complétez la fédération de domaine comme indiqué dans les sections précédentes.
- Choisissez le modèle O365.
- Changez le nom de l’application, par exemple, MS Word.
- Modifiez l’URL de l’application en conséquence.
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=<federated domain>
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=<federated domain>
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=<federated domain>
CRM/Dynamics en ligne : https://<tenant>.crm.dynamics.com/?whr=<federated domain>
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=<federated domain>
Calendrier Outlook : https://outlook.office.com/owa/?realm=<federated domain>&path=/calendar/view/Month
Outlook Web Access à Exchange Online : https://outlook.com/owa/<federated domain>
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=<federated domain>
É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=<federated domain>
Applications tierces intégrées à Azure AD
Si vous avez intégré des applications tierces telles que Box, Salesforce, ServiceNow, Workday, vous pouvez obtenir les Smart Links pour ces applications auprès d’Azure AD.
Effectuez les étapes suivantes.
-
Connectez-vous à votre portail Azure AD https://portal.azure.com.
-
Sélectionnez Tous les services > Azure Active Directory, puis sélectionnez votre annuaire.
-
Sélectionnez Applications d’entreprise, puis choisissez l’application vers laquelle vous souhaitez générer un lien intelligent.
-
Sélectionnez Propriétés et copiez l’URL d’accès utilisateur.
-
Une fois que vous avez ajouté
whr
à l’URL, les paramètreswhr
s’affichent comme indiqué dans l’exemple d’URL.Exemple d’URL : https://myapps.microsoft.com/signin/Workday/1234567891234567891234567896d64b&whr=ctxnsqa.net
Remarque : Ajoutez
whr
à l’URL afin qu’AAD sache quel IdP utiliser pour authentifier un utilisateur en fonction du paramètre de fédération et rediriger automatiquement vers cet IdP. - Définissez des contrôles de sécurité améliorés.
- Configurez l’authentification unique.
- ID de nom = GUID AD
- Case à cocher Activer le SP
-
URL d’assertion = URL de connexion
Lorsque vous effectuez un flux initié par l’IdP, les utilisateurs sont toujours dirigés vers la page du portail Azure AD. Si vous souhaitez accéder directement à la page de l’application, le flux initié par le SP est nécessaire car il envoie l’état de relais correct dans l’assertion SAML.
Remarque :
- Lorsque la fédération du domaine principal est activée, tous les utilisateurs AAD sont redirigés vers Citrix Workspace lors de l’authentification auprès de n’importe quelle application Office 365. Cela peut provoquer une panne ou un incident pour les clients si cela est fait sans en comprendre l’impact.
Si les utilisateurs ouvrent une session sur Citrix Workspace à l’aide d’AAD, le domaine principal des utilisateurs qui est utilisé pour se connecter ne doit pas être fédéré au NetScaler Gateway Service. Il en résulte une boucle. Dans ce cas, utilisez un autre domaine différent des domaines des utilisateurs qui se connectent à AAD pour fédérer au service Citrix Secure Private Access.
- Si le domaine principal est fédéré au service Citrix Secure Private Access, toutes les connexions utilisateur sur ce domaine dans AAD sont redirigées vers le service Citrix Secure Private Access. Pour le POC, si nécessaire, vous pouvez fédérer un domaine de test avant de fédérer le domaine principal.
- Si la stratégie de localisation d’AAD est activée, les utilisateurs doivent appartenir à la liste des adresses IP autorisées d’un réseau d’entreprise uniquement. Dans ce cas, vous pouvez publier l’application O365 en tant qu’application Web et acheminer son trafic via l’Connector Appliance.
- Lorsque vous vous connectez à l’AAD, si vous souhaitez éviter le message Rester connecté ?, vous pouvez modifier ce paramètre à l’aide de l’AAD. Notez le message important qui s’affiche lorsque vous modifiez le paramètre et revenez en arrière si nécessaire.
Liens de référence
Référence du module Azure PowerShell
Référence des commandes Azure PowerShell
Déployer la synchronisation d’annuaires Office 365 dans Microsoft Azure
Dans cet article
- Conditions préalables
- Comment fonctionne la fédération de domaines
- Méthodes d’authentification prises en charge pour l’application Office365
- Configuration de l’application O365 dans le service Secure Private Access
- Configurer la fédération de domaine d’Azure AD vers Citrix Workspace
- Fédération de domaine automatisée d’Azure AD vers Citrix Workspace
- Supprimer l’authentification multifacteur (MFA)
- Configuration des applications individuelles de la suite Office dans Citrix Workspace
- Applications tierces intégrées à Azure AD