この記事では、Akamai と Microsoft Entra ID を統合する方法について説明します。 Akamai と Microsoft Entra ID を統合すると、次のことができます。
- Akamai にアクセスできるユーザーを Microsoft Entra ID で制御する。
- ユーザーが自分の Microsoft Entra アカウントを使用して Akamai に自動的にサインインできるようにする。
- 1 つの場所でアカウントを管理します。
Microsoft Entra ID と Akamai Enterprise Application Access の統合により、クラウドまたはオンプレミスでホストされているレガシ アプリケーションにシームレスにアクセスできます。 統合ソリューションでは、Microsoft Entra 条件付きアクセス、Microsoft Entra ID Protection、Microsoft Entra ID Governance などの Microsoft Entra ID のすべての最新機能を利用して、アプリの変更やエージェントのインストールなしでレガシ アプリケーションにアクセスできます。
次の図では、Akamai EAA がハイブリッド セキュリティで保護されたアクセスの広範なシナリオに適合する場所について説明します。
キー認証のシナリオ
先進認証プロトコル (Open ID Connect、SAML、WS-Fed など) に対する Azure Active Directory のネイティブ統合のサポートとは別に、Akamai EAA は、Microsoft Entra ID を使用することで、内部と外部の両方のアクセスに関してレガシベース認証アプリの安全なアクセスを拡張し、それらのアプリケーションへの最新のシナリオ (パスワードレス アクセスなど) を実現します。 これには、次のものが含まれます。
- ヘッダーベースの認証アプリ
- リモート デスクトップ
- SSH (Secure Shell)
- Kerberos 認証アプリ
- VNC (仮想ネットワーク コンピューティング)
- 匿名認証または非ビルトイン認証アプリ
- NTLM 認証アプリ (ユーザーに対する二重プロンプトでの保護)
- フォームベースのアプリケーション (ユーザーに対する二重プロンプトでの保護)
統合シナリオ
Microsoft と Akamai EAA のパートナーシップにより、ビジネス要件に基づく複数の統合シナリオがサポートされるため、柔軟にビジネス要件を満たすことができます。 これらを使用することで、すべてのアプリケーションにわたるカバレッジをゼロデイで実現し、適切なポリシー分類を段階的に分類および構成できます。
統合シナリオ 1
Akamai EAA が Microsoft Entra ID 上で単一のアプリケーションとして構成されます。 管理者はそのアプリケーション上で条件付きアクセス ポリシーを構成することができ、条件が満たされると、ユーザーは Akamai EAA ポータルにアクセスできます。
長所: :
- IDP の構成が 1 回だけで済む。
短所:
ユーザーは最終的に 2 つのアプリケーション ポータルを持つことになる。
すべてのアプリケーションを対象とする、共通する 1 つの条件付きアクセス ポリシー。
統合シナリオ 2
Akamai EAA アプリケーションが Azure portal 上で個別に設定されます。 管理者は、アプリケーションで個別の条件付きアクセス ポリシーを構成でき、条件が満たされたら、ユーザーを特定のアプリケーションに直接リダイレクトできます。
長所: :
個々の条件付きアクセス ポリシーを定義できます。
すべてのアプリが O365 のワッフルと myApps.microsoft.com パネルに表示される。
短所:
- 複数の IDP を構成する必要がある。
前提条件
この記事で説明するシナリオでは、次の前提条件が既にあることを前提としています。
- アクティブなサブスクリプションを持つ Microsoft Entra ユーザー アカウント。 まだアカウントがない場合は、無料でアカウントを作成することができます。
- 次のいずれかのロール:
- Akamai でのシングル サインオン (SSO) が有効なサブスクリプション。
シナリオの説明
この記事では、テスト環境で Microsoft Entra SSO を構成してテストします。
- Akamai では、IDP Initiated SSO がサポートされます。
重要
以下に示す設定はすべて、統合シナリオ 1 とシナリオ 2 で同じです。 統合シナリオ 2 では、Akamai EAA で個々の IDP を設定する必要があり、URL プロパティはアプリケーション URL を指すように変更する必要があります。
ギャラリーからの Akamai の追加
Microsoft Entra ID への Akamai の統合を構成するには、ギャラリーからマネージド SaaS アプリの一覧に Akamai を追加する必要があります。
- クラウド アプリケーション管理者以上として Microsoft Entra 管理センターにサインインします。
- Entra ID>のEnterprise apps>に移動し、新しいアプリケーションを選択します。
- [ギャラリーから追加する] セクションで、検索ボックスに「Akamai」と入力します。
- 結果のパネルから [Akamai] を選択し、アプリを追加します。 お使いのテナントにアプリが追加されるのを数秒待機します。
または、Enterprise App Configuration ウィザードを使用することもできます。 このウィザードでは、テナントにアプリケーションを追加したり、ユーザー/グループをアプリに追加したり、ロールを割り当てたり、SSO 構成を確認したりできます。 Microsoft 365 ウィザードの詳細を確認します。
Akamai 用の Microsoft Entra SSO の構成とテスト
B.Simon というテスト ユーザーを使用して、Akamai に対する Microsoft Entra SSO を構成してテストします。 SSO が機能するためには、Microsoft Entra ユーザーと Akamai の関連ユーザーとの間にリンク関係を確立する必要があります。
Akamai との Microsoft Entra SSO を構成してテストするには、次の手順を実行します:
-
Microsoft Entra SSO を構成する - ユーザーがこの機能を使用できるようにします。
- Microsoft Entra テスト ユーザーの作成 - B.Simon で Microsoft Entra のシングル サインオンをテストします。
- Microsoft Entra テスト ユーザーを割り当てる - B.Simon が Microsoft Entra シングル サインオンを使用できるようにします。
-
Akamai の SSO の構成 - アプリケーション側でシングル サインオン設定を構成します。
- IDP の設定
- ヘッダー ベースの認証
- リモート デスクトップ
- SSH
- Kerberos 認証
- Akamai テスト ユーザーの作成 - Akamai で B.Simon に対応するユーザーを作成し、Microsoft Entra の B.Simon にリンクさせます。
- SSO のテスト - 構成が機能するかどうかを確認します。
Microsoft Entra SSO の構成
次の手順に従って Microsoft Entra SSO を有効にします。
クラウド アプリケーション管理者以上として Microsoft Entra 管理センターにサインインします。
Entra ID>エンタープライズ アプリ>Akamai>シングルサインオンに移動します。
[シングル サインオン方式の選択] ページで、 [SAML] を選択します。
[ SAML でのシングル サインオンの設定 ] ページで、[ 基本的な SAML 構成 ] の鉛筆アイコンを選択して設定を編集します。
[基本的な SAML 構成] セクションで、アプリケーションを IDP 開始モードで構成する場合は、次のフィールドの値を入力します。
ある。 [識別子] ボックスに、
https://<Yourapp>.login.go.akamai-access.com/saml/sp/responseの形式で URL を入力します。b。 [応答 URL] ボックスに、
https:// <Yourapp>.login.go.akamai-access.com/saml/sp/responseのパターンを使用して URL を入力します注意
これらの値は実際の値ではありません。 実際の識別子と応答 URL でこれらの値を更新します。 この値を取得するには、Akamai クライアント サポート チームにお問い合わせください。 [基本的な SAML 構成] セクションに示されているパターンを参照することもできます。
[SAML によるシングル サインオンのセットアップ] ページの [SAML 署名証明書] セクションで、 [フェデレーション メタデータ XML] を探して [ダウンロード] を選択し、証明書をダウンロードして、お使いのコンピューターに保存します。
[Set up Akamai](Akamai の設定) セクションで、要件に基づいて適切な URL をコピーします。
Microsoft Entra テスト ユーザーの作成と割り当て
ユーザー アカウントの作成と割り当ての クイックスタートのガイドラインに従って、B.Simon というテスト ユーザー アカウントを作成します。
Akamai の SSO の構成
IDP の設定
AKAMAI EAA IDP の構成
Akamai Enterprise Application Access コンソールにサインインします。
Akamai EAA コンソールで、[ID>Identity プロバイダー] を選択し、[ID プロバイダーの追加] を選択します。
[新しい ID プロバイダーの作成] で次の手順を実行します。
ある。 一意の名前を指定します。
b。 [サード パーティの SAML] を選択し、[CREATE Identity Provider and Configure]\(ID プロバイダーの作成と構成\) を選択します。
全般設定
[General] タブで、次の情報を入力します。
ID インターセプト - ドメインの名前を指定します (SP ベース URL は Microsoft Entra 構成に使用されます)。
注意
独自のカスタム ドメイン (DNS エントリと証明書が必要) を選択できます。 この例では、Akamai ドメインを使用します。
[Akamai Cloud Zone](Akamai クラウド ゾーン) - 適切なクラウド ゾーンを選択します。
[Certificate Validation](証明書の検証) - Akamai ドキュメントをチェックします (省略可)。
認証の構成
[URL] - ID インターセプトと同じ URL を指定します (認証後、ユーザーはここにリダイレクトされます)。
[Logout URL](ログアウト URL): ログアウト URL を更新します。
[Sign SAML Request](SAML 要求に署名する): 既定ではオフです。
IDP メタデータ ファイルには、Microsoft Entra ID コンソールでアプリケーションを追加します。
セッションの設定
設定は既定値のままにします。
ディレクトリ
[Directories] タブで、ディレクトリの構成をスキップします。
カスタマイズ UI
IDP にカスタマイズを追加できます。 [Customization] タブには、[Customize UI]、[Language settings]、[Themes] の設定があります。
詳細設定
[Advanced settings] タブで、既定値を受け入れます。 詳細については、Akamai のドキュメントを参照してください。
展開
[ デプロイ ] タブで、[ID プロバイダーのデプロイ] を選択します。
展開が正常に実行されたことを確認します。
ヘッダー ベースの認証
Akamai ヘッダー ベースの認証
アプリケーションの追加ウィザードから [Custom HTTP](カスタム HTTP) を選択します。
[Application Name](アプリケーション名) と [Description](説明) を入力します。
認証
[Authentication](認証) タブを選択します。
[Assign identity provider] を選択します。
サービス
[保存] を選択し、[認証に移動] を選択します。
詳細設定
[Customer HTTP Headers](カスタマー HTTP ヘッダー) で、カスタマー ヘッダーと SAML 属性を指定します。
[ 保存] を選択し、[デプロイ] ボタンに移動 します。
アプリケーションのデプロイ
[ アプリケーションのデプロイ] ボタンを選択します。
アプリケーションが正しくデプロイされたことを確認します。
エンドユーザー エクスペリエンス。
条件付きアクセス。
リモート デスクトップ
ADD Applications ウィザードから [RDP] を選択します。
[Application Name] に SecretRDPApp などの名前を入力します。
[Description] を選択します (Protect RDP Session using Microsoft Entra Conditional Access など)。
これを処理するコネクタを指定します。
認証
[ 認証 ] タブで [ 保存] を選択し、[サービス] に移動します。
サービス
[ 保存] を選択し、[詳細設定] に移動します。
詳細設定
[ 保存] を選択し、[デプロイ] に移動します。
エンド ユーザー エクスペリエンス
条件付きアクセス
または、RDP アプリケーションの URL を直接入力することもできます。
SSH
[Add Applications](アプリケーションの追加) に移動し、 [SSH] を選択します。
[Application Name] と [Description] を入力します (Microsoft Entra modern authentication to SSH など)。
アプリケーション ID を構成します。
ある。 名前と説明を指定します。
b。 アプリケーション サーバーの IP (または FQDN) と SSH のポートを指定します。
c. SSH ユーザー名とパスフレーズを指定します (Akamai EAA を確認してください)。
d. 外部ホスト名を指定します。
え コネクタの場所を指定し、コネクタを選択します。
認証
[ 認証 ] タブで [ 保存] を選択し、[サービス] に移動します。
サービス
[ 保存] を選択し、[詳細設定] に移動します。
詳細設定
[保存してデプロイ] を選択します。
展開
[ アプリケーションのデプロイ] を選択します。
エンド ユーザー エクスペリエンス
条件付きアクセス
Kerberos 認証
次の例では、 http://frp-app1.superdemo.live で内部 Web サーバーを発行し、KCD を使用して SSO を有効にします。
[全般] タブ
[認証] タブ
[Authentication] タブで、ID プロバイダーを割り当てます。
[サービス] タブ
詳細設定
注意
Web サーバーの SPN は、このデモの HTTP/frp-app1.superdemo.live@SUPERDEMO.LIVE など、SPN@Domain形式になっています。 残りの設定は既定値のままにします。
[Deployment](デプロイ) タブ
ディレクトリの追加
ドロップダウン リストから [AD] を選択します。
必要なデータを入力します。
ディレクトリの作成を確認します。
アクセスを必要とするグループ/OU を追加します。
以下では、グループが EAAGroup と呼ばれ、1 名のメンバーが含まれています。
ディレクトリを ID プロバイダーに追加するには、>を選択し、ディレクトリタブを選択して、ディレクトリの割り当てを選択します。
EAA チュートリアル用の KCD 委任の構成
手順 1:アカウントの作成
この例では、 EAADelegation という名前のアカウントを使用します。 これを行うには、 [Active Directory ユーザーとコンピューター] スナップインを使用します。
注意
このユーザー名は ID インターセプト名に基づく特定の形式にする必要があります。 図1から、それはcorpapps.login.go.akamai-access.comです。
ユーザー ログオン名は次のとおりです。
HTTP/corpapps.login.go.akamai-access.com
手順 2:このアカウントの SPN の構成
このサンプルに基づいて、SPN は次のようになります。
setspn -s Http/corpapps.login.go.akamai-access.com eaadelegation
手順 3:委任の構成
EAADelegation アカウントの場合は、[委任] タブを選択します。
- [任意の認証プロトコルを使う] を選択します。
- Kerberos Web サイト用にアプリ プール アカウントを追加するために、「追加」を選択します。 正しく構成されていれば、自動的に正しい SPN に解決されます。
手順 4:AKAMAI EAA 用の keytab ファイルの作成
一般的な構文を次に示します。
ktpass /out ActiveDirectorydomain.keytab /princ
HTTP/yourloginportalurl@ADDomain.com/mapuser serviceaccount@ADdomain.com /pass +rdnPass /crypto All /ptype KRB5_NT_PRINCIPAL例の説明は次のとおりです。
スニペット 説明 Ktpass /out EAADemo.keytab // 出力 keytab ファイルの名前 /princ HTTP/corpapps.login.go.akamai-access.com@superdemo.live HTTP/yourIDPName@YourdomainName /mapuser さん eaadelegation@superdemo.live // EAA 委任アカウント /pass RANDOMPASS // EAA 委任アカウントのパスワード /crypto すべての ptype KRB5_NT_PRINCIPAL // Akamai EAA のドキュメントを参照してください Ktpass /out EAADemo.keytab /princ HTTP/corpapps.login.go.akamai-access.com@superdemo.live /mapuser eaadelegation@superdemo.live /pass RANDOMPASS /crypto All ptype KRB5_NT_PRINCIPAL
手順 5:Akamai EAA コンソールでの keytab のインポート
[System>Keytabs] を選択します。
[Keytab Type](keytab の種類) で [Kerberos Delegation](Kerberos 委任) を選択します。
keytab がデプロイ済みおよび確認済みとして表示されていることを確認します。
ユーザーの作業
条件付きアクセス
Akamai のテスト ユーザーの作成
このセクションでは、Akamai で B.Simon というユーザーを作成します。 Akamai クライアント サポート チームと連携し、Akamai プラットフォームにユーザーを追加してください。 シングル サインオンを使用する前に、ユーザーを作成し、有効化する必要があります。
SSO のテスト
このセクションでは、次のオプションを使用して Microsoft Entra のシングル サインオン構成をテストします。
[ このアプリケーションをテストする] を選択すると、SSO を設定した Akamai に自動的にサインインします。
Microsoft マイ アプリを使用することができます。 マイ アプリで [Akamai] タイルを選択すると、SSO を設定した Akamai に自動的にサインインします。 マイ アプリの詳細については、マイ アプリの概要に関するページを参照してください。
関連コンテンツ
Akamai を構成したら、組織の機密データを流出と侵入からリアルタイムで保護するセッション制御を適用することができます。 セッション制御は、条件付きアクセスを拡張したものです。 Microsoft Defender for Cloud Apps でセッション制御を強制する方法をご覧ください。