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

情報

注

このトピックの手順は、この機能の早期アクセスバージョン（2019.09.0リリースより前）を実装したorgに適用されます。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 Microsoft 365 Apps（Microsoft 365アプリ向け共有コンピューターのアクティブ化の概要）」を参照してください。

前提条件

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

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

  • サービスアカウントを作成済みである。サービスアカウントの作成時には
    • セキュリティ上のベストプラクティスとして、OktaテナントのKerberosサービス用には、ドメイン管理者アカウントではなく、ドメインユーザーアカウントをお勧めします。
    • アカウントロックを強化するために、架空のホスト名を使用して［logon to（ログオン先）］の制限を有効にするとともに、［Account is sensitive and cannot be delegated（アカウントは重要なので委任できない）］をオンにすることができます。これも、セキュリティ上の理由によるものです。
  • ユーザーのActive Directory UPNが、Office 365のUPNと一致している。Office 365アプリケーションのユーザー名は、任意のAD属性にマッピングするように構成できます。詳細については、Microsoft Webサイトの「Prepare for directory synchronization to 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 Users and Computers（Active Directoryユーザーとコンピューター）］にアクセスできるサーバーにサインインします。

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

    プロパティ

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

    注

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

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

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

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

    HTTP/yourorg.kerberos.oktapreview.comはSPNで、<username>はこのセクションのステップ2で指定する値です。

    例：

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

    6. 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（セキュリティ）］設定に移動し、［Enable Integrated Windows Authentication（Integrated Windows Authenticationを使用する）］をオンにします。

    3. ［OK］をクリックします。

      情報

      注意

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

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

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

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

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

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

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

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

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

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

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

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

    フィールド

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

    <username>

    注：これは「ステップ1：サービスアカウントを作成して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 System Log（Oktaシステムログ）］ページにアクセスして、Kerberosエンドポイント経由の認証を確認します。
  3. 管理者ダッシュボードで、［Reports（レポート）］のドロップダウンメニューにカーソルを合わせます。

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

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

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

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

関連項目