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のサインオンポリシーで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を構成します：

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（セキュリティ）］設定まで下にスクロールし、［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エンドポイント経由で認証されたことを示しています。

   

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

関連項目

• Office 365サインオン・ポリシー・スタート・ガイド

• アプリサインオンポリシーについて