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を構成する
- [Active Directory Users and Computers(Active Directoryユーザーとコンピューター)]にアクセスできるサーバーにサインインします。
-
次のプロパティで新しいアカウントを作成します:
プロパティ
値
User logon name(ユーザーログオン名) <username> [User logon name (pre-Windows 2000)(ユーザーログオン名(Windows 2000以前))] <username>(任意のユーザー名でかまいません) 注
サービスアカウントには管理者権限は必要ありませんが、Microsoftサイトの「Delegating Authority to Modify SPNs」に記載されているように、SPNの設定には特定の権限が必要です。
-
次に示すように、パスワードを作成して、[Password never expires(パスワードに期限を設定しない)]ボックスをオンにします:
-
コマンドプロンプトを開いて、次の構文を使用し、サービスアカウント用のSPNを構成します:
Setspn -S HTTP/yourorg.kerberos.oktapreview.com <username>
-
次のテキストを入力して、SPNが正しいことを確認します。
Setspn -l <username>
HTTP/yourorg.kerberos.oktapreview.com
はSPNで、<username>
はこのセクションのステップ2で指定する値です。
例:
ステップ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で、
の順に選択します。 - [Advanced(詳細設定)]タブをクリックして、下にスクロールして[Security(セキュリティ)]設定に移動し、[Enable Integrated Windows Authentication(Integrated Windows Authenticationを使用する)]をオンにします。
-
[OK]をクリックします。
注意
Internet Explorerがセッションクッキーを保存できることを確認します(
タブ)。保存できない場合は、SSOも、標準のサインイン機能も動作しません。
-
-
ローカルイントラネットゾーンを構成してOktaを信頼済みサイトに指定します。
- Internet Explorerで、 を開きます。
-
をクリックして、先に設定したOkta orgのURLを追加します。
例:
https://<myorg>.kerberos.okta.com
。 - [Close(閉じる)]をクリックして、ほかの構成オプションでは[OK]をクリックします。
- GPOを作成して、サイレントアクティベーションを使用するすべてのクライアントマシンに展開します。
ステップ4:サイレントアクティベーションの有効化
次の手順では、Okta内でエージェントレスデスクトップSSOを有効にします。
- 管理者ダッシュボードで、[Security(セキュリティ)]のドロップダウンメニューにカーソルを合わせます。
- 下方にスクロールして、[Delegated Authentication(委任認証)]を選択します。
- [Delegated Authentication(委任認証)]ページで、[Active Directory]タブをクリックします。
- 下にスクロールして[Agentless Desktop SSO(エージェントレスデスクトップSSO)]セクションに移動します。
-
[Agentless Desktop SSO(エージェントレスデスクトップSSO)]セクションの右上にある[Edit(編集)]ボタンをクリックします。
- [AD Instances(ADインスタンス)]で、サービスアカウントのユーザー名を構成したインスタンスを探します。
-
このインスタンスを次のユーザー名の形式で構成します。
フィールド
値
[Desktop SSO(デスクトップSSO)] 有効 [Service Account Username(サービスアカウントのユーザー名)] <username>
注:これは「STEP 1: Create a service account and configure an SPN(ステップ1:サービスアカウントを作成してSPNを構成する)」で作成した、ドメインのサフィックスや、NetBIOS名のプレフィックスのない、Active Directoryのサインオン名です。sAMAccountName、またはUPNのユーザー名部分を使用できます。Org管理者が異なる値を使用しない限り、この2つは同じ文字列である可能性があります。
[Service Account Password(サービスアカウントのパスワード)] ADパスワード -
[Save(保存)]ボタンをクリックします。
これで、Active Directoryに参加しているマシン(VDIまたは共有ワークステーション)でOffice 365の自動ライセンス認証をテストできます。
ステップ5:Office 365サイレントアクティベーションの検証
Office 2016クライアントがインストールされているマシンで次の手順を実行します。
- Office 365クライアントを実行します:
- Office 2016クライアントアプリケーション(Microsoft Wordなど)を開きます。
-
サインインできることと、クライアントが自動的にライセンス認証されることを確認します。
次のようなメッセージが表示されるはずです:
- [Okta System Log(Oktaシステムログ)]ページにアクセスして、Kerberosエンドポイント経由の認証を確認します。
- 管理者ダッシュボードで、[Reports(レポート)]のドロップダウンメニューにカーソルを合わせます。
-
下方にスクロールして[System Log(システムログ)]を選択します。
[System Log(システムログ)]ページで該当のイベントを探し、矢印を使用して にドリルダウンします。
このエントリーは、ユーザーがKerberosエンドポイント経由で認証されたことを示しています。
自動ライセンス認証が検証できたら、セットアップが正常に完了したことになります。