Office 365自動ライセンス認証：以前の実装

Okta Office 365の自動ライセンス認証を使用すると、Microsoft Officeにシームレスにアクセスできます。このオプションでは、OktaをIDプロバイダーとして使用することで、共有ワークステーションまたはVDI環境の自動ライセンス認証が可能になります。ドメインに参加しているWindowsマシンにログインしたユーザーは、Office 365アプリケーションに自動的にサインインできます。

Microsoft Office 365の共有ワークステーションをセットアップする方法については、Microsoft Webサイトの「Overview of shared computer activation for Office 365 ProPlus」を参照してください。

前提条件

• Okta組織に統合したActive Directoryドメインがある。 OktaでADを統合する方法については、「Active Directory統合」を参照してください。

• Active Directoryでサービス・プリンシパル名（SPN）を構成する権限を持っている。権限の詳細については、「Delegating Authority to Modify SPNs」を参照してください。

• サービス・アカウントを作成済みである。アカウントの作成時には
  • セキュリティー上のベスト・プラクティスとして、OktaテナントのKerberosサービス用には、ドメイン管理者アカウントではなく、ドメイン・ユーザー・アカウントをお勧めします。
  • アカウント・ロックを強化するために、架空のホスト名を使用して[ログオン先]の制限を有効にするとともに、[アカウントは重要なので委任できない]をオンにすることができます。これも、セキュリティー上の理由によるものです。
• ユーザーのActive Directory UPNが、Office 365のUPNと一致している。 Office 365アプリケーションのユーザー名は、任意のAD属性にマッピングするように構成できます。 詳細については、Microsoft Webサイトの「Prepare to provision users through directory synchronization to Office 365」を参照してください。
• すべてのOffice 365エンド・ユーザーが有効なライセンスを持っている。
• すべてのエンド・ユーザーが、特定のドメインに関連付けられたOffice 365インスタンスに割り当てられている。
• ユーザーがドメイン・コントローラーに到達できる。

制限事項

次の構成と制限に該当する場合、Office 365の自動ライセンス認証を利用できません。

• Office 365のクライアント・アクセス・ポリシーを、Webブラウザーを拒否するように設定している場合、自動ライセンス認証もブロックされます。
• アプリまたはOktaのサインオン・ポリシーでWebブラウザーでのMFAを設定していても、自動ライセンス認証によるログインではMFAを利用できません。
• SWAサインオンはサポートされていません。

サポートされている構成

• Microsoftが現在サポートしているすべてのバージョンのWindows
• Office 2016以降

設定手順

OktaはKerberos認証を使用してOffice 365の自動ライセンス認証を有効にします。このための情報交換を可能にするには、新しいサービス・アカウントの作成と、そのアカウントの一意のサービス・プリンシパル名（SPN）が必要です。

手順1：サービス・アカウントを作成して、SPNを構成する

1. [Active Directory ユーザーとコンピューター]にアクセスできるサーバーにサインインします。

2. 次のプロパティを使用してアカウントを新規作成します。

   プロパティー	値
   [ユーザー ログオン名]	<username>
   [ユーザー ログオン名]（Windows 2000以前）	<username>（任意のユーザー名を使用できます）

   

   注

   サービス・アカウントには管理者権限は必要ありませんが、Microsoftサイトの「Delegating Authority to Modify SPNs」に記載されているように、SPNの設定には特定の権限が必要です。

3. 次に示すように、パスワードを作成して、[パスワードに期限を設定しない]ボックスをオンにします。

   

4. コマンド・プロンプトを開き、次の構文を使用してサービス・アカウントのSPNを構成します。

Setspn -S HTTP/yourorg.kerberos.oktapreview.com <username>

HTTP/yourorg.kerberos.oktapreview.comはSPN、<username>はこのセクションの手順2で指定した値を表します。

5. 次のテキストを入力して、SPNが正しいことを確認します。

Setspn -l <username>

手順2：レジストリー・キーを展開する

1. クライアント・マシンにレジストリー・キーを展開します。「Active Directoryデスクトップ・シングル・サインオン」を参照してください。
2. 単一のマシンにレジストリー・キーを展開する場合、次の内容を使用してクライアント・マシンにREGファイルを作成します。

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_CNAME_FOR_SPN_KB911149] "winword.exe"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_CNAME_FOR_SPN_KB911149] "powerpnt.exe"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_CNAME_FOR_SPN_KB911149] "outlook.exe"=dword:00000001

手順3：Windowsでブラウザーを設定する

Windowsでのブラウザーの構成には、主に3つの手順が含まれます。

1. ブラウザーでIWAを有効にする

2. OktaをInternet Explorer（IE）のローカル・イントラネット・ゾーンに信頼済みサイトとして追加する

3. すべてのクライアント・マシンにこれらの設定を適用するGPOを作成する

ブラウザーを設定するには

1. ブラウザーでIWAを有効にする

   1. Internet Explorerで、[ツール] > [インターネット オプション]の順に選択します。

   2. [詳細設定]タブをクリックして、[セキュリティ]設定まで下にスクロールし、[統合 Windows 認証を使用する]をオンにします。

   3. [OK]をクリックします。

      

      注

      Internet ExplorerでセッションCookieが保存できることを確認します（[インターネット オプション] > [プライバシー]タブ）。 保存できない場合、SSOも、標準のサインイン機能も動作しません。

2. ローカル・イントラネット・ゾーンを構成してOktaを信頼済みサイトに指定する

   1. Internet Explorerで、[オプション] > [セキュリティ]を開きます。

   2. [ローカル イントラネット] > [サイト] > [詳細設定]をクリックして、前の手順で構成したOkta組織のURLを追加します。

      例：https://<myorg>.kerberos.okta.com

   3. [閉じる]をクリックして、他の構成オプションでは[OK] をクリックします。
3. GPOを作成して、自動ライセンス認証を使用するすべてのクライアント・マシンに展開します。

手順4：自動ライセンス認証を有効にする

次の手順では、Okta内でエージェントレス・デスクトップSSOを有効にします。

1. [管理ダッシュボード]の[セキュリティー]ドロップダウン・メニューにカーソルを合わせます。
2. 下にスクロールして、[委任認証]を選択します。
3. [委任認証]ページで、[Active Directory]タブをクリックします。
4. 下にスクロールして、[エージェントレス・デスクトップSSO]セクションを探します。

5. [エージェントレス・デスクトップSSO]セクションの右上にある[編集]ボタンをクリックします。

6. [ADインスタンス]で、サービス・アカウントのユーザー名を構成したインスタンスを探します。

7. このインスタンスを次のユーザー名形式で構成します。

   フィールド	値
   [デスクトップSSO]	有効
   [サービス・アカウントのユーザー名]	<username> 注：これは手順1「サービス・アカウントを作成して、SPNを構成する」で作成した、ドメインのサフィックスや、NetBIOS名のプレフィックスのない、Active Directoryのサインオン名です。sAMAccountName、またはUPNのユーザー名部分を使用できます。組織管理者が異なる値を使用しない限り、この2つは同じ文字列である可能性があります。
   [サービス・アカウントのパスワード]	ADパスワード

8. [保存]ボタンをクリックします。

これで、Active Directoryに参加しているマシン（VDIまたは共有ワークステーション）でOffice 365の自動ライセンス認証をテストできます。

手順5：Office 365の自動ライセンス認証を検証する

Office 2016クライアントがインストールされているマシンで次の手順を実行します。

1. Office 365クライアントを起動します。
1. Microsoft WordなどのOffice 2016クライアント・アプリケーションを開きます。

2. サインインできることと、クライアントが自動的にライセンス認証されることを確認します。

   次のようなメッセージが表示されます。

   

2. Oktaの[システム・ログ]ページにアクセスして、Kerberosエンドポイント経由の認証を確認します。
3. [管理ダッシュボード]の[レポート]ドロップダウン・メニューにカーソルを合わせます。

4. 下にスクロールして、[システム・ログ]を選択します。

   [システム・ログ]ページで、該当のイベントを探し、矢印を使用して[イベント] > [システム] > [LegacyEventType]にドリル・ダウンします。

   このエントリーは、ユーザーがKerberosエンドポイント経由で認証されたことを示しています。

   

自動ライセンス認証が検証できたら、セットアップが正常に完了したことになります。