PoCガイド：Citrix の安全なプライベートアクセスによるOffice 365への安全なアクセス
概要
ユーザーが Microsoft 365 (Office 365) 内の機密コンテンツにアクセスする場合、組織は認証標準を適用しながら、ユーザーのログイン操作を簡素化できる必要があります。組織は、データセンターの範囲を超えて存在している場合でも、Microsoft 365 のセキュリティを確保できる必要があります。Citrix Workspaceでは、Microsoft 365の強化されたセキュリティコントロールが組織に提供されます。
このシナリオでは、ユーザーは、いずれかのActive Directoryをプライマリユーザーディレクトリとして使用してCitrix Workspaceに対して認証を行います。
Citrix Secure Private AccessサービスがCitrixサブスクリプションに割り当てられている場合、画面ベースのウォーターマークの適用、印刷/ダウンロードアクションの制限、画面取得の制限、キーボードの難読化、信頼できないリンクからのユーザーの保護など、強化されたセキュリティポリシーがMicrosoft 365アプリケーション上に適用されます。
次のアニメーションは、SSOを使用してMicrosoft 365にアクセスし、Citrix Secure Private Access で保護されているユーザーを示しています。
このデモでは、ユーザーがCitrix Workspace内からアプリケーションを起動するIDP起動SSOフローを示します。このPoCガイドは、ユーザーが好みのブラウザから直接SaaSアプリにアクセスしようとする、SPが開始するSSOフローもサポートしています。
この概念実証ガイドでは、次の方法について説明します。
- Citrix Workspace のセットアップ
- プライマリ・ユーザー・ディレクトリの統合
- SaaS アプリケーションにシングルサインオンを組み込む
- ウェブサイトフィルタリングポリシーを定義する
- 構成を検証する
Citrix Workspace のセットアップ
環境を設定するための最初の手順は、Citrix Workspaceを組織用に準備することです。これには、
- ワークスペース URL の設定
- 適切なサービスの有効化
ワークスペースの URL を設定
- Citrix Cloudに接続し、管理者アカウントでログインします
- Citrix Workspaceで、左上のメニューから［ワークスペース構成］にアクセスします
- [アクセス] タブで、組織の一意の URL を入力し、[有効] を選択します。
サービスを有効にする
サービスインテグレーションタブから、SaaS アプリケーションへの安全なアクセスをサポートする以下のサービスを有効にします。
- Secure Private Access
- Secure Browser
確認
Citrix Workspaceでは、サービスとURL設定の更新にしばらく時間がかかります。ブラウザから、カスタムワークスペース URL がアクティブであることを確認します。ただし、プライマリユーザーディレクトリを定義して構成すると、ログオンが可能になります。
プライマリ・ユーザー・ディレクトリの統合
ユーザーが Workspace で認証される前に、プライマリユーザーディレクトリを設定する必要があります。Workspace内のアプリに対するすべてのリクエストは、セカンダリIDへのシングルサインオンを使用するため、プライマリユーザーディレクトリはユーザーが必要とする唯一のIDです。
組織では、Microsoft 365 では、次のいずれかのプライマリユーザーディレクトリを使用できます。
- Active Directory: Active Directory 認証を有効にするには、Cloud Connectorのインストールガイドに従って、AcActive Directory ドメインコントローラーと同じデータセンター内にクラウドコネクタをデプロイする必要があります。
- 時間ベースのワンタイムパスワードを使用する Active Directory: Active Directory ベースの認証には、時間ベースのワンタイムパスワード (TOTP) を使用した多要素認証を含めることもできます。このガイドでは、この認証オプションを有効にするために必要な手順を詳しく説明します。
- Azure Active Directory：ユーザーは、Azure Active Directory の ID を使用してCitrix Workspace に対して認証できます。このガイドでは、この認証オプションを有効にするために必要な手順を詳しく説明します。
注
AAD をプライマリ認証ディレクトリとして使用する場合、ループが発生するため、プライマリドメイン (ユーザーのログインドメイン) をフェデレートできません。このような場合は、新しいドメインをフェデレーションする必要があります。
AADユーザーアカウントには属性
immutableIDが設定されている必要があります。そうしないと、「AADSTS51004 Azure AD
Connect 同期アカウントにはこの属性が自動的に設定される」というエラーメッセージが表示されて認証が失敗します。 - Citrix Gateway：組織は、オンプレミスのCitrix Gateway を利用して、Citrix WorkspaceのIDプロバイダーとして機能できます。このガイドでは、統合の詳細について説明します。
- Okta：組織はOktaをCitrix Workspaceのプライマリユーザーディレクトリとして使用できます。このガイドでは、このオプションを設定する手順について説明します。
Azure 認証を Citrix Workspace にフェデレートする
Microsoft 365をCitrix Workspaceと正常に連携させるには、管理者は次の操作を行う必要があります。
- SaaS アプリの設定
- SaaS アプリを認証する
- 認証ドメインの確認
- ドメインフェデレーションの構成
SaaS アプリの設定
Azure 内でドメインを検証すると、Microsoft 365 SaaS アプリを Citrix Workspace 内で構成できます。
- Citrix Cloud 内で、［安全なプライベートアクセス］タイルから［管理］を選択します。
- Secure Private Accessメニューで、「アプリケーション」を選択します
- 「アプリケーション」セクションで、「アプリを追加」を選択します。
アプリケーション-テンプレート
- [テンプレートの選択] ウィザードで、[Office 365] を選択します。
- 次を選択
アプリケーション-アプリの詳細
- アプリの詳細セクションで、必要に応じて名前、アイコン、説明を変更し、残りのエントリはすべて変更しません。
*注:データセンターにデプロイされたConnector Appliance スを介してトラフィックをルーティングすることもできます。そのため、「社内ネットワーク外」から「社内ネットワーク内」に切り替える必要があります。*
- 次を選択
アプリケーション-シングル・サインオン
- 「シングル・サインオン」ウィンドウで、「名前 ID フォーマット」が「固定」、「名前 ID」が「Active Directory GUID(1)」であることを確認します。
- [詳細属性] で、[属性名] = [IDPEmail]、[属性形式] = [未指定]、[属性値] = [電子メール]を確認します (2)
注
Citrix Workspaceへのユーザー認証中にユーザーがすでにMFAを入力している場合、MFA認証要求を抑制するために、2つ目の詳細属性オプションが自動的に追加されます。
属性名:
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
属性フォーマット:Unspecified
属性値:Custom value
カスタム値:http://schemas.microsoft.com/claims/multipleauthnAzure AD がこの要求を受け入れるには、ドメインフェデレーションの設定時にパラメータ
-SupportsMfa $trueを追加する必要があります。
続行するには、手動または自動のドメインフェデレーション設定の 2 つのオプションがあります。
自動処理(PowerShell スクリプト)を使用する場合は、「ドメインフェデレーション設定の自動化」セクションを参照してください。
手動でのドメインフェデレーション設定
- CRT ベースの証明書を取得するには、[ダウンロード] を選択します。(3)
- [ログイン URL] の横にある [コピー] ボタンを選択して、ログイン URL をキャプチャします。この URL は後で使用します。(4)
- SAML メタデータリンクを選択(5)
- SAML メタデータファイル内で、entityIdを探します。URL 全体をコピーして、後で使用できるように保存してください。キャプチャすると、SAML メタデータファイルを閉じることができます。
- 次を選択
- 次のセクションをスキップして、「アプリケーション-アプリケーション接続」に進んでください。
ドメインフェデレーション設定の自動化
- [Azure AD にログイン] を選択すると、新しいタブが開き、認証のための Azure AD ポータルに移動します。(3)
- 「グローバル管理者」権限が割り当てられているユーザーアカウントを指定します。
- ログインが成功すると、次のメッセージが表示されます。
- エンドユーザーの選択 MFA オプションは、デフォルトで有効になっています。
- Azure AD ドメインを取得してすべてのドメインのリストを表示するには、ここをクリックしてください。(4)
- フェデレーションするドメインをドロップダウンリストから選択します。(5)
- 「ドメインを統合」をクリックします (6)
注
- [ドメインを統合] をクリックすると、PowerShell スクリプトがバックエンドで実行され、ドメインが統合されます。
- 必要に応じて、インターフェイスから PowerShell スクリプトをダウンロードします。ドメインフェデレーション PowerShell スクリプトで、Azure AD ドメイン (7) を入力し、[ダウンロード] (8) をクリックします。
- 次を選択
アプリケーション-アプリケーション接続
- App Connectivityウィンドウで、トラフィックのルーティング方法（この場合は、クライアントから SaaS アプリケーションへの直接）を確認します。
- 次を選択
- [完了] を選択して、Microsoft Office 365 SaaS アプリケーションの構成を完了します。
SaaS アプリの認証と強化されたセキュリティの設定
- セキュア・プライベート・アクセス・メニューで「アクセス・ポリシー」を選択します
- 「アクセスポリシー」セクションで、「ポリシーの作成」を選択します。
- 「アプリケーション」ドロップダウンリストで「Office365」を検索して選択します。
- アプリを起動する権限のある適切なユーザー/グループを追加します。
- セキュリティ強化の有無にかかわらず、アプリにアクセスできるかどうかを指定します。
上のスクリーンショットには、強化されたセキュリティが設定されていません。
セキュリティを強化する必要がある場合は、「アクセスを許可」を「制限付きで許可」に変更し、適用されるものをすべて有効にしてください。
*注:初期の SSO テストでは、必ず「リモートブラウザで開く」オプションを設定してセキュリティ強化を設定することをおすすめします。*
認証ドメインの確認
認証をCitrix Workspaceにフェデレーションするには、Azureが完全修飾ドメイン名を確認する必要があります。Azure ポータルで、次の操作を行います。
- Azure Active Directory にアクセスする
- ナビゲーションウィンドウで [カスタムドメイン名] を選択します。
- [カスタムドメインの追加] を選択します。
- 完全修飾ドメイン名を入力してください
- [ドメインの追加] を選択します
- Azure は、ドメイン名レジストラに組み込むためのレコードを提供します。完了したら、[確認] を選択します。
- 完了すると、ドメインには検証済みマークが含まれます
ドメインフェデレーションの構成
注
自動ドメインフェデレーション構成を使用した場合は、このセクションをスキップできます。
「検証」セクションに進んでください。
最終的な構成では,検証済みドメインのフェデレーション権限としてをCitrix工作区Azure で使用します。フェデレーションの構成は、PowerShell で実行する必要があります。
- PowerShell の起動
- 次のコマンドを使用して、適切なモジュールを追加します。
Install-Module AzureAD -Force Import-Module AzureAD -Force Install-Module MSOnline -Force Import-module MSOnline -Force - PowerShell 経由でMicrosoft オンラインに接続し、Microsoftクラウドアカウント (例:
admin.user@onmicrosoft.com) を使用して認証します。
Connect-MSOLService - 次の PowerShell コマンドを実行して、ドメインが現在 Azure内で管理に設定されていることを確認します
Get-MsolDomain 
- PowerShellスクリプトで次のコードを使用して,環境に合わせて変数を変更して、このドメインをフェデレートします
$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("") # 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 - 次の PowerShell コマンドを実行して、ドメインが現在 Azure内でフェデレーションに設定されていることを確認します
Get-MsolDomain 
- 次の PowerShell コマンドを実行して、Azure のフェデレーション設定を確認します
Get-MsolDomainFederationSettings -DomainName $dom 
注
フェデレーション設定を削除する必要がある場合は、次の PowerShell コマンドを実行します。
Set-MsolDomainAuthentication -DomainName $dom -Authentication Managed
検証
IDP が開始する検証
- ユーザーとしてCitrix Workspace にログインします
- Office 365 アプリケーションを選択してください
- URLを観察して、Azure 経由で簡単にリダイレクトしてください
- Office 365 ポータルは正常に起動します
SPが開始する検証
- ブラウザを起動する
- SaaS アプリケーションの会社定義の URL に移動します
- ブラウザは認証のためにAzure AActive Directory にリダイレクトし、次にCitrix Workspaceにリダイレクトします
- ユーザーがプライマリユーザーディレクトリで認証されると,SaaSアプリが起動し,Citrixによってシングルサインオンが提供されます
ウェブサイトフィルタリングポリシーを定義する
Citrix Secure Private Accessは、ユーザーをフィッシング攻撃から保護するために、SaaSおよびWebアプリ内でWebサイトをフィルタリングします。以下に、Web サイトフィルターポリシーを設定する方法を示します。
- Citrix Cloud から、［Secure Private Access］タイル内で管理する
- このガイドに従えば、「エンドユーザー認証の設定」ステップと「SaaS、Web、仮想アプリケーションへのエンドユーザーアクセスの設定」ステップは完了です。[設定] を選択します。
- [Web フィルタリング] タブに切り替え
- [編集] を選択します。
- **ウェブサイトカテゴリを絞り込むオプションを有効にします**
- [ブロックされたカテゴリ] ボックスで、[追加]を選択します
- ユーザーのアクセスをブロックするカテゴリを選択してください
- 適用可能なカテゴリをすべて選択したら、[追加]
- 許可されたカテゴリについても同じ操作を行います
- リダイレクトされたカテゴリについても同じ操作を行います。これらのカテゴリは、セキュアブラウザインスタンスにリダイレクトされます。
- 必要に応じて、管理者は、カテゴリの定義と同じプロセスに従って、特定の URL の拒否、許可、リダイレクトされたアクションをフィルタリングできます。ウェブサイトの URL はカテゴリよりも優先されます。
構成を検証する
IDP が開始する検証
- ユーザーとしてCitrix Workspace にログインします
- 「オフィス365」を選択します。
セキュリティ強化が無効になっている場合、アプリケーションはローカルブラウザ内で起動します。それ以外の場合は、エンタープライズブラウザが使用されます。 - ユーザーがアプリに自動的にサインオン
- 適切な拡張セキュリティポリシーが適用される
- 構成されている場合は、ブロック、許可、およびリダイレクトされたカテゴリにある SaaS アプリケーション内の URL を選択します
- 構成されている場合は、ブロック、許可、およびリダイレクトされた URL にある SaaS アプリ内の URL を選択します。
- SaaS アプリが正常に起動する
SPが開始する検証
- ブラウザを起動する
- Office 365の Web サイトにアクセスし、[サインイン] を選択します
- ユーザー名を入力します。
- ブラウザは認証のためにブラウザをCitrix Workspaceにリダイレクトします
- ユーザーがプライマリユーザーディレクトリで認証すると、セキュリティ強化が無効になっている場合、Office365はローカルブラウザで起動します。
強化されたセキュリティが有効になっている場合、Secure Browser インスタンスは Office 365 を起動します。
Microsoft 365 関連ドメイン
関連するドメインフィールドは、Citrix Secure Privateサービス内で新しいアプリケーションを作成する際に使用できます。強化されたセキュリティポリシーでは、これらの関連ドメインを使用して、ポリシーを施行するタイミングを決定します。
次のリストは、Microsoft 365 アプリに関連付けられている現在のドメインです。
*注:これらのドメインはいつでも変更できます*
- *.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 アプリ
たとえば、Microsoft 365 ポータルではなく、特定の Microsoft 365 アプリ (Word、PowerPoint、または Excel) を起動する方が望ましいとします。その場合、管理者はCitrix Secure Private Accessサービス内でアプリケーションごとに個別のアプリケーションインスタンスを作成する必要があります。各アプリには固有のURLがあり、このURLには、このガイドで設定されたフェデレーテッドドメインの正しい値が含まれている必要があります。フェデレーションドメインエントリは、正しいフェデレーションドメイン構成にリダイレクトするように Azure に通知します。
*注:IdP が開始するフローはリレーステートを考慮しません。SP が開始するフローを使用して、アプリに直接アクセスします。*
- 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=フェデレーションドメイン - 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=フェデレーションドメイン - 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=フェデレーションドメイン - CRM/Dynamics オンライン:
https://フェデレーションドメイン.crm.dynamics.com/?whr= - 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= - Outlook 予定表:
https://outlook.office.com/owa/?realm=フェデレーションドメイン&path=/calendar/view/Month - Exchange オンラインへの Outlook Web アクセス:
https://outlook.com/owa/フェデレーションドメイン - 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= - 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=フェデレーションドメイン
サインインの滞在
既定の構成では、Azure Active Directory はログオンプロセス中にダイアログボックスを表示し、ユーザーはサインインしたままにします。
これは Azure の設定で、次の操作を行うことで簡単に変更できます。
- Azure 内で、Azure Active Directoryを選択します
- 会社のブランディングを選択
- 有効なロケールの選択
- [会社のブランディングの編集] ウィンドウで、[表示] オプションで [ **いいえ] を選択し、サインインしたままにする**
- [保存] を選択します
トラブルシューティング
ユーザーアカウントがディレクトリに存在しません
Microsoft 365 を起動しようとすると、ユーザーに次のエラーが表示されることがあります。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.
この問題の解決方法に関する提案を次に示します。
- Microsoft 365 管理者コンソールで、ユーザーが Microsoft 365 を使用するためのライセンスを取得していることを確認します。
- エラー内で特定された電子メールアドレスが、プライマリユーザーディレクトリ、Azure Active Directory、および Microsoft 365 と一致することを確認します。
属性
immutableIdがユーザーオブジェクトに設定されていることを確認します。（これは純粋な AAD 環境には当てはまりません！）immutableIdは、次の PowerShell コマンドを使用して簡単に計算および設定できます。$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
フェデレーションレルムオブジェクト
検証中に、ユーザーに次のエラーが表示されることがあります。AADSTS50107: The requested federation realm object 'https://
これは、多くの場合、ドメインが検証されていないか、適切にフェデレーションされていないことが原因です。PoC ガイドの次のセクションを確認します。
強化されたセキュリティポリシーが失敗する
ユーザーには、拡張セキュリティポリシー (ウォーターマーク、印刷、またはクリップボードアクセス) の障害が発生する可能性があります。通常、これは SaaS アプリケーションが複数のドメイン名を使用しているために発生します。SaaS アプリケーションのアプリケーション構成設定に、関連ドメインのエントリがありました。
強化されたセキュリティポリシーは、これらの関連ドメインに適用されます。このPoCガイドのMicrosoft 365関連ドメインセクションには、Microsoftがいつでも変更できる関連ドメインの初期セットが含まれています。
拡張セキュリティポリシーが特定のアプリセクション内で機能しない場合は、関連するドメインを追加する必要があります。不足しているドメイン名を識別するために、管理者はローカルブラウザーで SaaS アプリにアクセスし、次の操作を実行できます。
- ポリシーが失敗するアプリのセクションに移動します
- Google ChromeとMicrosoft Edge（Chromium版）では、ブラウザの右上にある 3 つのドットを選択してメニュー画面を表示します。
- [その他のツール] を選択します。
- 開発者ツールの選択
- 開発者ツールで、[ソース] を選択します。これにより、そのアプリケーションセクションのアクセスドメイン名のリストが表示されます。アプリのこの部分で強化されたセキュリティポリシーを有効にするには、それらのドメイン名をアプリ構成の [関連ドメイン] フィールドに入力する必要があります。関連ドメインは以下のように追加されます。
*.domain.com
