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

情報

このトピックの手順は、この機能の早期アクセス・バージョン(2019.09.0リリースより前)を実装した組織に適用されます。2019年9月1日以降にこの機能(2019.09.0リリース以降)を初めて実装する場合は、「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を構成します。

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

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

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

  7. 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エンドポイント経由で認証されたことを示しています。

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