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 Office 365 ProPlus」を参照してください。

前提条件

  • 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 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 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で指定する値です。

    例:

  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で、[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. [Close(閉じる)]をクリックして、ほかの構成オプションでは[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(システムログ)]ページにアクセスして、Kerberosエンドポイント経由の認証を確認します。
  3. 管理者ダッシュボードで、[Reports(レポート)]のドロップダウンメニューにカーソルを合わせます。
  4. 下方にスクロールして[System Log(システムログ)]を選択します。

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

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

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