Office 365自動ライセンス認証:新しいリリースの実装

注
このトピックの手順は、2019年9月1日以降にこの機能(2019.09.0リリースより後)を初めて実装したorgに適用されます。2019.09.0リリースより前のこの機能の早期アクセスバージョンを実装した場合、「Office 365サイレントアクティベーション:以前の実装」の手順を参照してください。
Microsoft Office 365向けのOktaサイレントアクティベーションにより、共有ワークステーションまたはVDI環境で、Microsoft Officeにシームレスにアクセスできるユーザーエクスペリエンスを実現できます。OktaをIDプロバイダーとして使用することで、ドメインに参加しているWindowsマシンにログインしたエンドユーザーが、Office 365アプリケーションに自動的にサインインできるようになります。
開始する前に
- Active DirectoryドメインをOkta orgと統合済みである。Active Directory統合を参照してください。
- サービスプリンシパル名(SPN)を構成するためのActive Directoryの権限を持っている。次のMicrosoftのドキュメント「Delegating Authority to Modify SPNs」を参照してください。
- ユーザーのActive Directory UPNが、Office 365のUPNと一致している。Office 365アプリケーションのユーザー名は、任意のAD属性にマッピングするように構成できます。詳細については、Microsoftのドキュメント「Prepare to provision users through directory synchronization to Office 365」を参照してください。
- すべてのOffice 365エンドユーザーが有効なライセンスを持っている。
- すべてのエンドユーザーが、特定のドメインに関連付けられたOffice 365インスタンスに割り当てられている。
- ユーザーがドメインコントローラーに到達できる。
サポートされているアプリと構成
- Microsoftが現在サポートしているすべてのバージョンのWindows
- Office 2016以降
- サポートされているアプリ:Word、Excel、Outlook、OneNote、Skype for Business、PowerPoint、Access、Publisher
-
RC4_HMAC_MD5暗号化は、ADシングルサインオンとOffice 365の自動ライセンス認証ではサポートされていません。ADSSOまたはOffice 365のサイレントアクティベーションを使用する場合、AES 128ビット(AES-128)またはAES 256ビット(AES-256)暗号化の使用を推奨します。
この手順を開始する
この手順には次の作業が含まれます。
E. Office 365サイレント アクティベーションをテストする

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

次の手順でサービスアカウントを作成します:
- OktaテナントのKerberosサービスには、ドメイン管理者アカウントではなく、ドメインユーザーアカウントを使用します。
- アカウントロックを強化するために、架空のホスト名を使用して[logon to(ログオン先)]の制限を有効にするとともに、[Account is sensitive and cannot be delegated(アカウントは重要なので委任できない)]をオンにします。
- [Active Directory Users and Computers(Active Directoryユーザーとコンピューター)]にアクセスできるサーバーにサインインします。
-
新しいサービスアカウントを作成するフォルダを右クリックして、[New(新規作成)]>[User(ユーザー)]を選択します。
-
次の値を使用してアカウントを新規作成します:
フィールド
値
User logon name(ユーザーログオン名) <username> [User logon name (pre-Windows 2000)(ユーザーログオン名(Windows 2000以前))] <username>(任意のユーザー名でかまいません) サービスアカウントのユーザー名は、ドメイン名を含めて16文字以上にする必要があります。また、サービスアカウントには管理者権限は必要ありませんが、SPNの設定には特定の権限が必要です。次のMicrosoftのドキュメント「Delegating Authority to Modify SPNs」を参照してください。
- [Next(次へ)]をクリックします。
-
14文字以上のパスワードを作成して、[Password never expires(パスワードに期限を設定しない)]ボックスをオンにします。
- [Next(次へ)]をクリックします。
-
次のコマンドを実行して、サービスアカウントのSPNを構成します:
setspn -S HTTP/<yourorg>.kerberos.<oktaorgtype>.com <username>プレースホルダー 値 yourorg お客様のOkta org名 oktaorgtype お客様のOkta orgタイプ。例:okta、oktapreview、okta-emea、okta-gov。 username 前の手順で作成したユーザー名 例:setspn -S HTTP/atkodemo.kerberos.oktapreview.com OktaSilentActivation
-
次のコマンドを実行して、SPNが正しいことを確認します。
setspn -l <username>
B. Windowsでブラウザーを構成する
-
ブラウザーでIntegrated Windows Authenticationを有効化します。
Internet Explorerで次の手順を実行します。
- [Settings(設定)]>[Internet Options(インターネットオプション)]>[Advanced(詳細設定)]に移動します。
- [Advanced(詳細設定)]タブで、[Security(セキュリティ)]設定まで下方にスクロールして、[Enable Integrated Windows Authentication(Integrated Windows Authenticationの有効化)]を選択します。
-
[OK]をクリックします。
重要
Internet ExplorerでセッションCookieが保存できることを確認します([Internet Options(インターネットオプション)]>[Privacy(プライバシー)]>[Settings(設定)][Advanced(詳細設定)])。保存できない場合、SSOも、標準のサインイン機能も動作しません。
-
ローカルイントラネットゾーンを構成してOktaを信頼済みサイトに指定する
Internet Explorerで次の手順を実行します。
- [Settings(設定)]>[Internet Options(インターネットオプション)]>[Security(セキュリティ)]に移動します。
- [Security(セキュリティ)]タブで、[Local Intranet(ローカルイントラネット)]>[Sites(サイト)]>[Advanced(詳細設定)]をクリックします。
-
前の手順で構成したOkta orgのURLを追加します。
https://<yourorg>.kerberos.<oktaorgtype>.com
例:https://atkodemo.kerberos.oktapreview.com
- [Close(閉じる)]をクリックして、ほかの構成オプションでは[OK]をクリックします。
- グローバルポリシーオブジェクト(GPO)を作成して、サイレントアクティベーションを使用するすべてのクライアントマシンに展開します。
C. Kerberos認証を有効化する
Okta Admin Consoleで、以下の手順を実行します。
- [Security(セキュリティ)]>[Delegated Authentication(代理認証)]に移動します。
- [Delegated Authentication(代理認証)]ページで、[Active Directory]タブをクリックします。
- [Agentless Desktop SSO and Silent Activation(エージェントレスデスクトップSSOおよびサイレントアクティベーション)]セクションまで下方にスクロールして、[Edit(編集)]をクリックします。
- [Active Directory Instances(Active Directoryインスタンス)]で、サービスアカウントを構成したインスタンスを探します。
-
このインスタンスを次のユーザー名形式で構成します。
フィールド 値 [Desktop SSO(デスクトップSSO)] 有効 [Service Account Username(サービスアカウントのユーザー名)] <username>
これは手順1で作成した、ドメインのサフィックスや、NetBIOS名のプレフィックスのない、Active Directoryのサインオン名です。sAMAccountName、またはUPNのユーザー名部分を使用できます。org管理者が異なる値を使用しない限り、この2つは同じ文字列である可能性があります。このフィールドでは大文字と小文字が区別されます。UPNプレフィックスがsAMAccountNameと異なる場合、サービスアカウントユーザー名はUPNと同じものにし、ドメインのサフィックスを含める必要があります。例:agentlessDsso@mydomain.com
[Service Account Password(サービスアカウントのパスワード)] お客様のActive Directoryパスワード -
[Save(保存)]をクリックします。
これで、Office 365アプリインスタンスのKerberos認証が有効になりました。
D. サイレントアクティベーションを有効化する
Okta Admin Consoleで、以下の手順を実行します。
- [Applications(アプリケーション)]>[your Office 365 app instance(お客様のOffice 365アプリインスタンス)]>[Sign on(サインオン)]タブ >[Edit(編集)]に移動します。
- [Silent Activation(サイレントアクティベーション)]セクションで、チェックボックスをオンにしてアプリインスタンスのサイレントアクティベーションを有効にします。
- 設定を[Save(保存)]します。
これで、Office 365アプリインスタンスのサイレントアクティベーションが有効化されます。
E. Office 365の自動ライセンス認証をテストする
-
Office 365クライアントを起動します。
Office 2016クライアントがインストールされているマシンで、
-
OktaのKerberosエンドポイントによる認証を確認します。
Okta Admin Consoleで、以下の手順を実行します。
これで、Office 365のサイレントアクティベーションが正常にセットアップされました。