Office 365サイレントアクティベーション：以前の実装

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

Microsoft Office 365の共有ワークステーションをセットアップする方法については、Microsoft Webサイトの「Microsoft 365アプリ向け共有コンピューターのアクティブ化の概要」を参照してください。

前提条件

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

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

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

制限事項

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

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

サポートされる構成

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

設定手順

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

ステップ1：サービスアカウントを作成してSPNを構成する

  1. Active Directoryユーザーとコンピューター（［Active Directory Users and Computers）］にアクセスできるサーバーにサインインします。

  2. 次のプロパティで新しいアカウントを作成します：

    プロパティ

    値
    ユーザーログオン名（User logon name） <username>
    User logon name (pre-Windows 2000)（ユーザーログオン名（Windows 2000以前）） 任意のユーザー名でかまいません（<username>）

  3. 次に示すように、パスワードを作成して、パスワードに期限を設定しない（Password never expires）ボックスをオンにします：

  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で、ツール（Tools） > インターネットオプション（Internet Options）の順に選択します。

    2. 詳細設定（Advanced）タブをクリックして、下にスクロールしてセキュリティ（Security）設定に移動し、統合Windows認証を使用する（Enable Integrated Windows Authentication）をオンにします。

    3. OK（OK.）をクリックします。

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

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

    2. ローカルイントラネット（Local Intranet） > サイト（Sites） > 詳細設定（Advanced）をクリックして、先に設定したOkta orgのURLを追加します。

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

    3. 閉じる（Close）をクリックして、ほかの構成オプションではOKをクリックします。
  3. GPOを作成して、サイレントアクティベーションを使用するすべてのクライアントマシンに適用します。

ステップ4：サイレントアクティベーションの有効化

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

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

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

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

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

    フィールド

    値
    デスクトップSSO（Desktop SSO） 有効
    サービスアカウントのユーザー名（Service Account Username）

    <username>

    注：これはステップ1：サービスアカウントを作成してSPNを構成する（「STEP 1: Create a service account and configure an SPN）」で作成した、ドメインのサフィックスや、NetBIOS名のプレフィックスのない、Active Directoryのサインオン名です。sAMAccountName、またはUPNのユーザー名部分を使用できます。Org管理者が異なる値を使用しない限り、この2つは同じ文字列である可能性があります。
    サービスアカウントのパスワード（Service Account Password） ADパスワード

  8. 保存（Save）ボタンをクリックします。

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

ステップ5：Office 365サイレントアクティベーションの検証

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

  1. Office 365クライアントを実行します：
    1. Office 2016クライアントアプリケーション（Microsoft Wordなど）を開きます。

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

      次のようなメッセージが表示されるはずです：

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

  4. 下方にスクロールしてシステムログ（System Log）を選択します。

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

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

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

関連項目

アプリケーションのサインオンポリシーを追加する