製品ドキュメント
Citrix Secure Private Access
2311 - Current Release 2308 Legacy Service
PDFを表示

O365の構成

January 9, 2024
寄稿者: 
C

前提条件

Citrix WorkspaceアプリでO365アプリを構成するには、次のことを必ず完了してください。

  • 他のサービスとフェデレートされていないプライマリドメインをAzure AD で使用できる場合は、そのドメインを使用してCitrixSecure Private Accessにフェデレートできます。このドメインは、その親ドメインまたは子ドメインのいずれかがフェデレーションされておらず、その親ドメインが Azure Active Directory (AAD) に既に追加されていないことを確認します。

    たとえば、user1@demo.citrix.com を使用してユーザーがログインした場合、demo.citrix.com はプライマリドメイン、citrix.com は親ドメインであり、us.demo.citrix.com は子ドメインです。

  • プライマリドメインをフェデレートできない場合は、新しいドメインをAzureADに追加し、それをCitrix Secure Private Accessにフェデレートします。ドメインを作成し、検証を完了します。詳しくは、https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domainを参照してください。

    または

    Azure AD にサブドメインを追加して、SSO向けCitrix Secure Private Access へのフェデレーションに活用できます。そのためには、サブドメインを追加してルートドメインに昇格させる必要があります。詳しくは、https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/domains-verify-custom-subdomainを参照してください。

    注: サブドメインをルートドメインに変更する POST 要求には、Microsoft Graph Explorer の代わりに Azure AD Graph Explorer を使用する必要がある場合があります。

    フェデレーションドメインが必要な理由の詳細については、「 ドメインフェデレーションの仕組み」を参照してください。

  • 追加した新しいドメインまたはサブドメインが Azure AD で「検証済み」状態であることを確認します。

  • SAML ID プロバイダーと Azure AD の間の信頼を設定します。信頼を設定するには、AAD で検証されたドメインが必要です。ドメインを使用して AAD でフェデレーションが設定されている場合、AAD は、ユーザーがフェデレーションドメインとは異なるドメインに属している場合でも、AAD に対するユーザー認証について SAML プロバイダーを信頼します。SP 開始フローで、AAD が認証に使用する IdP を特定する必要がある場合（ユーザーをフェデレーション IdP に高速化する）、次のURLに渡される whr query paramまたはdomain_hintを使用して識別されます。https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-authentication-for-federated-users-portal。

    新しいドメインのフェデレーションを追加しても、セットアップにある既存のフェデレーションには影響しません。ドメインにフェデレーション済みのADFSがある場合、すでにフェデレーションされたドメインのサブドメインでも親ドメインでもない別のドメインでフェデレーションしているため、ADFSは影響を受けません。

    SSO には、次の 2 つのフローを使用できます。

    IDP が開始されたフロー: 通常、Azure AD ポータルにログインするときに使用されます。Citrix Secure Private Access サービスは、SAMLアサーションをAzure AD（AAD）に投稿します。AAD は、以前に行ったフェデレーション設定に基づいて検証します。検証に合格すると、SAMLのnameid属性を抽出します。nameid 属性は、AADに存在するユーザーのimmutableIdと一致する必要があります。

    SP 開始フロー: 通常、AAD ポータルの代わりに直接アプリにアクセスする場合に使用します。このフローでは、Citrix Secure Private Accessサービスは、アプリの設定で構成されたURLを読み込みます。URLはAADに送信され、URLにはフェデレーションドメインを示す何らかの情報があるため、ユーザーはSAML要求とリレー状態とともにCitrix Secure Private Accessサービスにリダイレクトされます。Citrix Secure Private Access サービスは、要求と同じリレー状態でSAMLアサーションをAADに送信します。SAML が検証されると、AAD はリレー状態のコンテキストにユーザーをリダイレクトし、したがって、ユーザーは直接アプリに着陸します。

  • Citrix Secure Private Access サービスでO365アプリを構成します。詳しくは、「SaaSアプリのサポート」を参照してください。

ドメインフェデレーションの仕組み

次の図は、ドメインフェデレーションが完了した後の一般的なフローを示しています。

ドメインフェデレーションの仕組み

Office365アプリをCitrix Workspace に追加し、ウォーターマークを有効にしてダウンロードを制限することを検討してください。典型的な流れは次のとおりです。

  1. Office365アプリは、Citrix Workspace で起動します。
  2. リクエストはCitrix Secure Private Access サービスに送られます。
  3. Citrix Secure Private Access サービスは、SAML アサーションを作成し、Azure AD に転送します。

  4. リクエストは信頼された SAML IdP から送信されるため、Azure AD は作成されたドメインフェデレーションを通じてリクエストを識別し、SAML アサーションを Office 365 アプリに渡します。

    Office365 アプリが起動します。

Office365アプリでサポートされている認証方法

デフォルトでは、Citrix IDプロバイダーを使用して、Citrix CloudアカウントのすべてのユーザーのID情報を管理します。

Citrix Workspace は、Office365の次の認証方法をサポートしています。Okta と Google IdP は現在サポートされていません。

  • オンプレミスActive Directory
  • Active Directory とトークン

  • Azure Active Directory

    注: AAD を使用してワークスペースへの認証を行うと、ループが発生するため、プライマリドメイン (ユーザーのログインドメイン) をフェデレートできません。そのような場合は、新しいドメインをフェデレートする必要があります

  • Citrix Secure Private Access
  • Active Directory とRADIUS

詳しくは、「ID とアクセス管理」を参照してください。

Secure Private Accessサービスで O365 アプリを構成する

以下は、Secure Private Accessサービスで O365 アプリを構成する手順の概要です。詳しくは、「SaaSアプリのサポート」を参照してください。

  1. Citrix Cloud のSecure Private Accessサービスに移動します。
  2. Office 365 を検索し、テンプレートを選択します。詳細については、「 サービスとしてのソフトウェアアプリのサポート」を参照してください。

  3. アプリの詳細に次の関連ドメインを追加します。O365ドメインのリストを次に示します。利用可能な場合、新しいドメインが追加されます。

    • *.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
  4. 必要に応じて、強化されたセキュリティ制御を有効にします。

  5. SSO を設定します。

    注: 行う必要がある唯一の変更は、「名前 ID」が Active Directory の GUID であることを確認することです。

  6. 詳細属性はIDPEmailも送信することを確認します。
    • 属性名:IDPEmail
    • 属性形式:未指定
    • 属性値:電子メール
  7. [SAML メタデータ] をクリックして、新しいタブで開きます。
    • 「entityId」をコピーする
    • 「ログイン URL」をコピーする
    • 証明書を CRT 形式でダウンロードする

Azure ADからCitrix Workspaceへのドメインフェデレーションを構成する

前提条件：

  • Azure AD で PowerShell を有効にする
  • Microsoft MSOnlineモジュールをインストールする

必要なモジュールをインストールするための PowerShell コマンドを次に示します。

`PS> Install-Module AzureAD -Force`

`PS> Import-Module AzureAD -Force`

`PS> Install-Module MSOnline -Force`

`PS> Import-module MSOnline -Force`
<!--NeedCopy-->

モジュールがすでにインストールされている場合は、次のコマンドを実行します。

PS> connect-msolservice
<!--NeedCopy-->

注: msolserviceに接続するには、Microsoft クラウドアカウントが必要です。たとえば、 admin.user@onmicrosoft.comのように指定します。

Azure AD から Citrix Workspace へのドメインフェデレーションを構成する手順

  1. PowerShell で次のコマンドを実行して、フェデレーションを構成します。

    • PS> $dom = "ad-domain.com"

    注: ad-domain.com は Azure AD に追加された新しいドメインです

    • PS> $IssuerUri = "https://citrix.com/[customerID]"

    注: CustomerID は次の場所から見つけることができます。

    • Citrix Cloud > IDとアクセス管理 > APIアクセス

    • Citrix Cloud > Citrix Secure Private Access。 顧客 ID は、アプリ構成の詳細 ([シングルサイン] > [SAML メタデータファイル] > [EntityID]) にあります。

    • PS> $fedBrandName = “CitrixWorkspace”
    • PS> $logoffuri = "https://app.netscalergateway.net/cgi/logout"
    • PS> $uri = "https://app.netscalergateway.net/ngs/[customerID]/saml/login?APPID=[AppID]”

    注： $uriは 、 ［Citrix Secure Private Access サービス］>［Web/SaaSAppの追加］>［シングルサインオン］>［ログインURL］ または［ SAMLメタデータ］>［場所］からコピーできます。

    • PS> $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<location of certificate downloaded from Citrix Secure Private Access service/filename.crt>”)

      例： PS> $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\cert\saml_idp.crt")

    PS> $certData = [system.convert]::tobase64string($cert.rawdata)

  2. PS文字列を実行して、Citrix Secure Private Access へのフェデレーションを完了します。

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

  3. 次のコマンドを実行して、ドメインフェデレーション設定を確認します。

    Get-MsolDomainFederationSettings -DomainName <domain name>

フェデレーション設定の検証

Azure ADからCitrix Workspace へのドメインフェデレーションの自動化

「Azure AD から Citrix Workspace へのドメインフェデレーションの構成」で説明したように、Azure AD から Citrix Workspace への手動ドメインフェデレーションでは、データをコピーしてスクリプトを実行するには、クラウドポータルと PowerShell を切り替える必要があります。たとえば、

  • クラウドポータルから顧客 ID やアプリ ID などのデータをコピーします。
  • クラウドポータルから証明書をダウンロードします。
  • PowerShell スクリプトを実行します。

この手動コピー/貼り付け操作では、フェデレーションが正常に行われないため、エラーが発生する可能性があります。

ドメインをフェデレートする手順が、Citrix Secure Private Serviceのユーザーインターフェイスに統合され、フェデレーションプロセスが自動化されました。PowerShell スクリプトは、ユーザーがインターフェイス内の適切なリンクをクリックすると、バックエンドで実行されます。ユーザーは、クラウドポータルと PowerShell を切り替える必要はありません。

ドメインを自動的にフェデレーションする手順

  1. O365アプリを構成します。詳細については、「 Secure Private Accessサービスで O365 アプリを構成する」を参照してください。

  2. [シングルサインオン] で、[ SAML] を選択します。

    ユーザーインターフェイスでのドメインフェデレーション

  3. 資格情報を使用して Azure AD にログオンします。 [ Azure AD にログイン] をクリックすると、認証用の Azure AD ログオンポータルが表示されます。
    • 認証には OAuth プロトコルが使用されます。認証が成功したら、ドメインのフェデレーションに対する同意を提供する必要があります。
    • エンドユーザーの選択 MFA オプションは 、デフォルトで有効になっています。
  4. Azure AD ドメインを取得するにはここをクリックして 、すべてのドメインの一覧を表示します。
  5. フェデレートするドメインを選択し、[ ドメインのフェデレーション] をクリックします。

    注：

    • [ ドメインのフェデレーション] をクリックすると、PowerShell スクリプトがバックエンドで実行され、ドメインがフェデレーションされます。
    • 必要に応じて、インターフェイスから PowerShell スクリプトをダウンロードすることもできます。[ ドメインフェデレーション PowerShell スクリプト] で、[ ダウンロード] をクリックします。

多要素認証 (MFA) の抑制

O365アプリの詳細属性には、Citrix Workspaceへのユーザー認証時にユーザーがすでにMFAを入力したときにMFAを抑制するオプションが追加されます。

  • 属性名: “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”,
  • 属性値: “http://schemas.microsoft.com/claims/multipleauthn”

AAD がこの要求を受け入れるには、次の PowerShell コマンドを使用してフェデレーションを実行します。

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

注：

IdP 開始フローはリレー状態を考慮しません。SPが開始したフローを使用して、直接アプリに着陸します。

Citrix Workspace での個々のOfficeスイートアプリケーションの構成

個々のオフィススイートアプリケーションを構成するには、次の手順を実行します。

  1. 前のセクションで説明したように、ドメインフェデレーションを完了します。
  2. O365 テンプレートを選択します。
  3. アプリの名前を、たとえば MS Word に変更します。
  4. アプリの URL を適宜に変更します。

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/ダイナミクスオンライン: https://<tenant>.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<tenant>-my.sharepoint.com%2F&whr=<federated domain>

Outlook 予定表: https://outlook.office.com/owa/?realm=<federated domain>&path=/calendar/view/Month

Exchange オンラインへの Outlook Web アクセス: 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>

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>

Azure AD に統合されたサードパーティ製アプリ

Box、Salesforce、ServiceNow、Workday などのサードパーティアプリケーションを統合している場合は、Azure AD からこれらのアプリケーションのスマートリンクを取得できます。

以下の手順を実行します。

  1. Azure ADポータルhttps://portal.azure.comにログインします。

  2. [ すべてのサービス] > [Azure Active Directory] の順に選択し、ディレクトリを選択します。

    すべてのサービスを選択

  3. 「 エンタープライズ・アプリケーション 」を選択し、スマート・リンクの生成先となるアプリケーションを選択します。

    エンタープライズアプリケーションの選択

  4. [ プロパティ ] を選択し、[ユーザーアクセス] の URL をコピーします。

    プロパティを選択

  5. whrをURLに追加すると、URLの例に示すように、 whrパラメーターが表示されます。

    URL の例: https://myapps.microsoft.com/signin/Workday/1234567891234567891234567896d64b&whr=ctxnsqa.net

    注: フェデレーション設定に基づいてユーザーを認証するために使用する IdP を AAD が認識し、その IdP への自動リダイレクトを行うように、URL にwhrを追加します。

  6. 強化されたセキュリティコントロールを設定します。
  7. SSO を設定します。
    • 名前 ID = 広告 GUID
    • [SP 開始を有効にする] チェックボックス

    • アサーション URL = ログイン URL

      IdP 開始フローを実行すると、常に Azure AD ポータルページにユーザーが表示されます。アプリページに直接配置する場合は、SAML アサーションで正しいリレー状態を送信するため、SP 開始フローが必要です。

注：

  • プライマリドメインのフェデレーションを有効にすると、Office 365アプリケーションへの認証時に、すべてのAADユーザーがCitrix Workspaceにリダイレクトされます。影響を理解しないまま実行すると、お客様にシステム停止/インシデントが発生する可能性があります。

  • ユーザーがAADを使用してCitrix Workspaceにログオンする場合、ログインに使用するユーザーのプライマリドメインをNetScaler Gatewayサービスにフェデレーションすることはできません。その結果、ループが発生します。このような場合は、AADにログインするユーザーのドメインとは異なる別のドメインを使用して、Citrix Secure Private Accessサービスにフェデレートします。

  • プライマリドメインがCitrix Secure Private Accessサービスにフェデレートされている場合、AADでそのドメイン上のすべてのユーザーログインはCitrix Secure Private Accessサービスにリダイレクトされます。POC では、必要に応じて、プライマリドメインをフェデレートする前にテストドメインをフェデレートできます。
  • AAD でロケーションポリシーが有効になっている場合、ユーザは企業ネットワークの許可された IP アドレスの一覧からのみ存在する必要があります。このような場合、O365アプリをWebアプリとして公開し、そのトラフィックをConnector Appliance 経由でルーティングできます。
  • AAD にログオンするときに、[ サインインしたままにする] を避けたいですか？ プロンプトが表示されたら、AAD を使用してこの設定を変更できます。設定を変更し、必要に応じて元に戻すときに表示される重要なメッセージに注意してください。![設定を元に戻す場合は、[

![サインインしたままメッセージ] を選択します](/en-us/citrix-secure-private-access/media/stay-signed-in.png)

。](/en-us/citrix-secure-private-access/media/message-when-reverting.png)

参照リンク

Azure PowerShell モジュールリファレンス

Azure PowerShell コマンドリファレンス

Microsoft Azure で Office 365 ディレクトリ同期を展開する

O365の構成
January 9, 2024
寄稿者: 
C
January 9, 2024
寄稿者: 
C

この記事の概要

サイトに関するフィードバック | プライバシーと法令 | Cookieの設定 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.