PoC Guide: Secure Access to Office 365 with Citrix Secure Private Access

Overview

As users access confidential content within Microsoft 365 (Office 365), organizations must be able to simplify user login operations while still enforcing authentication standards. Organizations must be able to secure Microsoft 365 even though it exists beyond the confines of the data center. Citrix Workspace provides organizations with enhanced security controls for Microsoft 365.

In this scenario, a user authenticates to Citrix Workspace using either Active Directory as the primary user directory.

如果Citrix安全的私人访问服务的屁股igned to the Citrix subscription, enhanced security policies, ranging from applying screen-based watermarks, restricting printing/downloading actions, screen grabbing restrictions, keyboard obfuscation, and protecting users from untrustworthy links, are applied on top of the Microsoft 365 applications.

The following animation shows a user accessing Microsoft 365 with SSO and secured with Citrix Secure Private Access.

This demonstration shows an IdP-initiated SSO flow where the user launches the application from within Citrix Workspace. This PoC guide also supports an SP-initiated SSO flow where the user tries to access the SaaS app directly from their preferred browser.

This proof of concept guide demonstrates how to:

1. Setup Citrix Workspace
2. Integrate a primary user directory
3. Incorporate Single Sign-On for SaaS applications
4. Define website filtering policies
5. Validate the configuration

Setup Citrix Workspace

The initial steps for setting up the environment is to get Citrix Workspace prepared for the organization, which includes

1. Setting up the Workspace URL
2. Enabling the appropriate services

Set Workspace URL

1. Connect toCitrix Cloudand log in as your administrator account
2. Within Citrix Workspace, accessWorkspace Configurationfrom the upper-left menu
3. From theAccesstab, enter a unique URL for the organization and select Enabled

Enable Services

From theService Integrationtab, enable the following services to support the secure access to SaaS apps use case.

1. Secure Private Access
2. Secure Browser

Verify

Citrix Workspace takes a few moments to update services and URL settings. From a browser, verify that the custom Workspace URL is active. However, logon will be available once a primary user directory gets defined and configured.

Integrate a Primary User Directory

Before users can authenticate to Workspace, aprimary user directorymust be configured. The primary user directory is the only identity the user requires as all requests for apps within Workspace utilize single sign-on to secondary identities.

An organization can use any one of the following primary user directories with Microsoft 365:

• Active Directory: To enable Active Directory authentication, a cloud connector must be deployed within the same data center as an Active Directory domain controller by following theCloud Connector Installationguide.
• Active Directory with Time-Based One Time Password: Active Directory-based authentication can also include multifactor authentication with a Time-based One Time Password (TOTP). Thisguidedetails the required steps to enable this authentication option.
• Azure Active Directory: Users can authenticate to Citrix Workspace with an Azure Active Directory identity. Thisguidedetails the required steps to enable this authentication option.

  Note

  When using AAD as your primary authentication directory, you cannot federate the primary domain (user’s login domain) because this creates a loop. In such cases,you must federate a new domain.

  AAD user accounts must have the attributeimmutableIDset; otherwise, the authentication will fail with the error message:AADSTS51004
  Azure AD Connect synchronized accounts get this attribute set automatically.

• Citrix Gateway:组织可以利用一个本地CitrixGateway to act as an identity provider for Citrix Workspace. Thisguideprovides details on the integration.
• Okta: Organizations can use Okta as the primary user directory for Citrix Workspace. Thisguideprovides instructions for configuring this option.

Federate Azure Authentication to Citrix Workspace

To successfully federate Microsoft 365 with Citrix Workspace, the administrator needs to do the following:

• Configure SaaS App
• Authorize SaaS App
• Verify Authentication Domain
• Configure Domain Federation

Configure SaaS App

With the domain verified within Azure, a Microsoft 365 SaaS app can get configured within Citrix Workspace.

• Within Citrix Cloud, selectManagefrom the Secure Private Access tile.

• Within Secure Private Access menu, selectApplications
• In the Application section, selectAdd an app

Applications - Template

• In the Choose a template wizard, selectOffice 365

• SelectNext

Applications - App details

• In theApp detailssection, change theName,Icon, andDescriptionas needed while leaving all remaining entries unchanged.

Note: You can also route the traffic through the Connector Appliance deployed in your data center. Therefore you need to switch from “Outside my corporate network” to “Inside my corporate network”.

• SelectNext

Applications - Single Sign-On

• In theSingle Sign-Onwindow, verify theName ID Format=PersistentandName ID=Active Directory GUID(1)
• Under Advanced attributes, verifyAttribute Name=IDPEmail,Attribute Format=Unspecified, andAttribute Value=Email(2)

Note

The second Advanced attribute option is added automatically to suppress the MFA authentication request when the user has already entered the MFA during user authentication to Citrix Workspace.

Attribute Name:http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
Attribute Format:Unspecified
Attribute Value:Custom value
Custom Value:http://schemas.microsoft.com/claims/multipleauthn

For Azure AD to accept this claim, we must add a parameter-SupportsMfa $truewhen setting up the domain federation.

There are two options to proceed, manual or automated domain federation configuration.
If you want to use the automated process(PowerShell script), go to the sectionAutomated domain federation configuration.

Manual domain federation configuration

• SelectDownloadto capture theCRT-basedcertificate. (3)
• Next to theLogin URL, select theCopybutton to capture the Login URL. This URL gets used later. (4)
• Select theSAML Metadatalink (5)

• Within the SAML Metadata file, look forEntityID. Please copy the entire URL and store it for later use. Once captured, the SAML Metadata file can be closed.

• SelectNext
• Skip the next section and proceed withApplications - App Connectivity

Automated domain federation configuration

• SelectLog in to Azure AD, a new tab opens, and you are directed to the Azure AD portal for authentication. (3)
• Specify a user account that has “Global Administrator” permissions assigned.
• You should see the following message if the login was successful

• Select end user MFA optionis enabled, by default.
• ClickClick here to retrieve Azure AD domainsto view the list of all domains. (4)
• Select the domain that you want to federate from the drop-down list. (5)
• ClickFederate domain(6)

Note

• When you clickFederate domain, the PowerShell scripts are running in the back end, and the domain is federated.
• If necessary, download the PowerShell scripts from the interface. InDomain federation PowerShell script, enter the Azure AD Domain (7) and clickDownload(8).

• SelectNext

Applications - App Connectivity

• In theApp Connectivitywindow, verify how the traffic should be routed (in this case, direct from the client to the SaaS application)

• SelectNext
• SelectFinishto complete the configuration of the Microsoft Office 365 SaaS apps.

Authorize SaaS App and configure enhanced security

• Within Secure Private Access menu, selectAccess Policies
• In the Access Policy section, selectCreate policy

• In theApplicationsdrop-down list, search for “Office365” and select it.
• Add the appropriate users/groups who are authorized to launch the app
• Specify if the app can be accessed with or without enhanced security.
  The above screenshot has no enhanced security configured.
  If enhanced security is needed, change “Allow access” to “Allow with restrictions” and enable all that should apply.

Note: For initial SSO testing, it is always a good idea to configure enhanced security with the option “Open in remote browser” set.

Verify Authentication Domain

Azure must verify the fully qualified domain name to federate authentication to Citrix Workspace. Within the Azure Portal, do the following:

• Access Azure Active Directory
• SelectCustom domain namesin the navigation window
• SelectAdd custom domain
• Enter the fully qualified domain name

• SelectAdd domain
• Azure provides records to incorporate into your domain name registrar. Once done, selectVerify.

• Once complete, the domain contains a verified mark

Configure Domain Federation

Note

You can skip this section if theAutomated domain federation configurationwas used.
Proceed to theValidatesection.

The final configuration is to have Azure use Citrix Workspace as the federated authority for the verified domain. Configuring federation must be done with PowerShell.

• Launch PowerShell
• Add the appropriate modules with the following commands

Install-Module AzureAD -Force Import-Module AzureAD -Force Install-Module MSOnline -Force Import-module MSOnline -Force 

• Connect to Microsoft Online via PowerShell and authenticate using a Microsoft cloud account (e.g.,admin.user@onmicrosoft.com)

Connect-MSOLService 

• Verify the domain is currently set toManagedwithin Azure by running the following PowerShell command

Get-MsolDomain 

• Use the following code in a PowerShell script to make this domainFederatedby changing the variables to align with your environment

dom美元= " workspaces.wwco.net " #的完全限定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("") # Path to the downloaded certificate file from Office 365 app configuration (e.g., C:\temp\filename.crt) $certData = [system.convert]::tobase64string($cert.rawdata) $IssuerUri = "//m.giftsix.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 

• Verify the domain is currently set toFederatedwithin Azure by running the following PowerShell command

Get-MsolDomain 

• Verify the federation settings in Azure by running the following PowerShell command

Get-MsolDomainFederationSettings -DomainName $dom 

Note

If the federation settings need to be removed, run the following PowerShell command:
Set-MsolDomainAuthentication -DomainName $dom -Authentication Managed

Validate

IdP-Initiated Validation

• Log into Citrix Workspace as a user
• Select the Office365 application
• Observe the URL to see it briefly redirect through Azure
• The Office365 portal successfully launches

SP-Initiated Validation

• Launch a browser
• Go to the company-defined URL for the SaaS application
• The browser redirects to Azure Active Directory and then to Citrix Workspace for authentication
• Once the user authenticates with the primary user directory, the SaaS app launches with Citrix providing single sign-on

Define website filtering policies

Citrix Secure Private Access provides website filtering within SaaS and Web apps to help protect users from phishing attacks. The following shows how to set up website filtering policies.

• From Citrix Cloud,Managewithin the Secure Private Access tile

• If this guide was followed, theSet up end-user authenticationstep and theConfigure end-user access to SaaS, web and virtual applicationssteps are complete. SelectSettings
• Switch to the tabWeb Filtering
• SelectEdit
• EnabletheFilter website categoriesoption
• Within theBlocked categoriesbox, selectAdd
• Select the categories to block users from accessing

• When all applicable categories are selected, selectAdd

• Do the same for allowed categories
• Do the same for redirected categories. These categories redirect to a Secure Browser instance
• If needed, admins can filter denied, allowed, and redirected actions for specific URLs following the same process used for defining categories. Website URLs take precedence over categories.

Validate the Configuration

IdP-Initiated Validation

• Log into Citrix Workspace as a user
• Select Office365.
  If enhanced security is disabled, the app launches within the local browser. Otherwise, the enterprise browser is used.
• The user automatically signs on to the app
• The appropriate enhanced security policies are applied
• If configured, select a URL within the SaaS app that is in the blocked, allowed, and redirected categories
• If configured, select a URL within the SaaS app that is in the blocked, allowed, and redirected URLs
• The SaaS App successfully launches

SP-Initiated Validation

• Launch a browser
• Go to theOffice 365website and selectSign In
• Enter the user name
• The browser redirects the browser to Citrix Workspace for authentication
• Once the user authenticates with the primary user directory, Office365 launches in the local browser if enhanced security is disabled.
  If enhanced security is enabled, a Secure Browser instance launches Office365.

Microsoft 365 Related Domains

A related domain field is available when creating a new app within Citrix Secure Private service. The enhanced security policies utilize these related domains to determine when to enforce the policy.

The following list are the current domains associated with Microsoft 365 apps.

Note:These domains can change at any time

• *.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

Microsoft 365 Apps

Suppose it is preferable to launch a specific Microsoft 365 app (Word, PowerPoint, or Excel) instead of the Microsoft 365 portal. In that case, the administrator must create a separate application instance within Citrix Secure Private Access service for each app. Each app has a unique URL, which must include the correct value for the federated domain configured in this guide. The federated domain entry informs Azure to redirect to the correct federated domain configuration.

Note: IdP-initiated flow does not honor the relay state. Use SP-initiated flow to land on the app directly.

• 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 Online:https://.crm.dynamics.com/?whr=federated domain
• OneDrive for Business:https://login.microsoftonline.com/login.srf?wa=wsignin1%2E0&rver=6%2E1%2E6206%2E0&wreply=https%3A%2F%2F-my.sharepoint.com%2F&whr=federated domain
• Outlook Calendar:https://outlook.office.com/owa/?realm=federated domain&path=/calendar/view/Month
• Outlook Web Access to 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.sharepoint.com%2F&whr=federated domain
• Teams: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

Stay Signed In

In the default configuration, Azure Active Directory displays a dialog box during the logon process allowing the users to remain signed in.

This is an Azure setting that can be easily changed by doing the following:

• Within Azure, selectAzure Active Directory
• SelectCompany Branding
• Select the enabled Locale
• In the Edit company branding pane, selectNoin theShow option to remain signed in

• SelectSave

Troubleshooting

User Account Does Not Exist in the Directory

When trying to launch Microsoft 365, the user might receive the following error:
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.

The following are suggestions on how to solve this issue:

• Verify that the user is licensed to use Microsoft 365 within the Microsoft 365 administrator console
• Verify that the identified email address within the error matches the primary user directory, Azure Active Directory, and Microsoft 365.

• Verify that the attributeimmutableIdis set at the user object.
  (This is not the case in pure AAD environments!)
  TheimmutableIdcan be easily calculated and set using the following PowerShell commands:

  美元userUPN = " john.doh@company.com " #改变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 

Federation Realm Object

During validation, a user might receive the following error:
AADSTS50107: The requested federation realm object 'https:///adfs/services/trust' does not exist.

This is often caused by the domain not being verified or properly federated. Review the following sections of the PoC guide:

• Verify Authentication Domain
• Configure Domain Federation

Enhanced Security Policies Failing

Users might experience enhanced security policy (watermark, printing, or clipboard access) failure. Typically, this happens because the SaaS application uses multiple domain names. Within the application configuration settings for the SaaS app, there was an entry forRelated Domains.

The enhanced security policies are applied to those related domains. TheMicrosoft 365 Related Domainssection of this PoC guide contains the initial set of related domains, which Microsoft can change at any time.

A related domain still needs to be added if the enhanced security policies fail to function within certain app sections. To identify missing domain names, an administrator can access the SaaS app with a local browser and do the following:

• Navigate to the section of the app where the policies fail
• In Google Chrome and Microsoft Edge (Chromium version), select the three dots in the upper right side of the browser to show a menu screen.
• SelectMore Tools.
• SelectDeveloper Tools
• Within the developer tools, selectSources. This provides a list of access domain names for that application section. To enable the enhanced security policies for this portion of the app, those domain names must be entered into therelated domains领域内的应用程序配置。相关的领域s are added like the following*.domain.com