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を構成する
- [Active Directory ユーザーとコンピューター]にアクセスできるサーバーにサインインします。
-
次のプロパティを使用してアカウントを新規作成します。
プロパティー
値
[ユーザー ログオン名] <username> [ユーザー ログオン名](Windows 2000以前) <username>(任意のユーザー名を使用できます) 注
サービス・アカウントには管理者権限は必要ありませんが、Microsoftサイトの「Delegating Authority to Modify SPNs」に記載されているように、SPNの設定には特定の権限が必要です。
-
次に示すように、パスワードを作成して、[パスワードに期限を設定しない]ボックスをオンにします。
-
コマンド・プロンプトを開き、次の構文を使用してサービス・アカウントのSPNを構成します。
-
次のテキストを入力して、SPNが正しいことを確認します。
Setspn -S HTTP/yourorg.kerberos.oktapreview.com <username>
HTTP/yourorg.kerberos.oktapreview.com
はSPN、<username>
はこのセクションの手順2で指定した値を表します。
Setspn -l <username>
手順2:レジストリー・キーを展開する
- クライアント・マシンにレジストリー・キーを展開します。「Active Directoryデスクトップ・シングル・サインオン」を参照してください。
- 単一のマシンにレジストリー・キーを展開する場合、次の内容を使用してクライアント・マシンに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つの手順が含まれます。
-
ブラウザーでIWAを有効にする
-
OktaをInternet Explorer(IE)のローカル・イントラネット・ゾーンに信頼済みサイトとして追加する
-
すべてのクライアント・マシンにこれらの設定を適用するGPOを作成する
ブラウザーを設定するには
-
ブラウザーでIWAを有効にする
-
Internet Explorerで、[ツール] > [インターネット オプション]の順に選択します。
- [詳細設定]タブをクリックして、[セキュリティ]設定まで下にスクロールし、[統合 Windows 認証を使用する]をオンにします。
-
[OK]をクリックします。
注
Internet ExplorerでセッションCookieが保存できることを確認します([インターネット オプション] > [プライバシー]タブ)。 保存できない場合、SSOも、標準のサインイン機能も動作しません。
-
-
ローカル・イントラネット・ゾーンを構成してOktaを信頼済みサイトに指定する
- Internet Explorerで、[オプション] > [セキュリティ]を開きます。
-
[ローカル イントラネット] > [サイト] > [詳細設定]をクリックして、前の手順で構成したOkta組織のURLを追加します。
例:
https://<myorg>.kerberos.okta.com
- [閉じる]をクリックして、他の構成オプションでは[OK] をクリックします。
- GPOを作成して、自動ライセンス認証を使用するすべてのクライアント・マシンに展開します。
手順4:自動ライセンス認証を有効にする
次の手順では、Okta内でエージェントレス・デスクトップSSOを有効にします。
- [管理ダッシュボード]の[セキュリティー]ドロップダウン・メニューにカーソルを合わせます。
- 下にスクロールして、[委任認証]を選択します。
- [委任認証]ページで、[Active Directory]タブをクリックします。
- 下にスクロールして、[エージェントレス・デスクトップSSO]セクションを探します。
-
[エージェントレス・デスクトップSSO]セクションの右上にある[編集]ボタンをクリックします。
- [ADインスタンス]で、サービス・アカウントのユーザー名を構成したインスタンスを探します。
-
このインスタンスを次のユーザー名形式で構成します。
フィールド
値
[デスクトップSSO] 有効 [サービス・アカウントのユーザー名] <username>
注:これは手順1「サービス・アカウントを作成して、SPNを構成する」で作成した、ドメインのサフィックスや、NetBIOS名のプレフィックスのない、Active Directoryのサインオン名です。sAMAccountName、またはUPNのユーザー名部分を使用できます。組織管理者が異なる値を使用しない限り、この2つは同じ文字列である可能性があります。
[サービス・アカウントのパスワード] ADパスワード -
[保存]ボタンをクリックします。
これで、Active Directoryに参加しているマシン(VDIまたは共有ワークステーション)でOffice 365の自動ライセンス認証をテストできます。
手順5:Office 365の自動ライセンス認証を検証する
Office 2016クライアントがインストールされているマシンで次の手順を実行します。
- Office 365クライアントを起動します。
- Microsoft WordなどのOffice 2016クライアント・アプリケーションを開きます。
-
サインインできることと、クライアントが自動的にライセンス認証されることを確認します。
次のようなメッセージが表示されます。
- Oktaの[システム・ログ]ページにアクセスして、Kerberosエンドポイント経由の認証を確認します。
- [管理ダッシュボード]の[レポート]ドロップダウン・メニューにカーソルを合わせます。
-
下にスクロールして、[システム・ログ]を選択します。
[システム・ログ]ページで、該当のイベントを探し、矢印を使用して[イベント] > [システム] > [LegacyEventType]にドリル・ダウンします。
このエントリーは、ユーザーがKerberosエンドポイント経由で認証されたことを示しています。
自動ライセンス認証が検証できたら、セットアップが正常に完了したことになります。