レジストリーキーベースのOffice 365サイレントアクティベーションを新しい構成に移行する

  • このトピックは、この機能の早期アクセス・バージョン(2019.09.0リリースより前)を実装したOrgを想定したものです。これがOrgに当てはまる場合は、この移行手順を完了する必要があります。

  • 2019.09.0リリース以降にこの機能を初めて実装する場合は、「Office 365の自動ライセンス認証:新しいリリースの実装」の手順に従ってください。

この手順では、レジストリーキーベースのOffice 365自動ライセンス認証の構成を新しいKerberosベースの構成に移行する方法について説明します。新しい構成では、レジストリー・キーが不要なKerberos認証を使用します。

この手順を開始する

この手順には次の作業が含まれます。

A. 新しいKerberosサブドメインを作成してテストする

B. Orgの新しいDNSレコードを作成して確認する

C. 新しい設定をテストする

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

A. 新しいKerberosサブドメインを作成してテストする

1. 新しいKerberosサブドメインSPNを追加する

現在使用しているのと同じサービス・アカウントを使用します。サービス・アカウントを変更すると、自動ライセンス認証の認証要求が失敗する可能性があります。

  1. Active Directory環境で、管理者としてコマンド・プロンプトを開きます。
  2. 次のコマンドを実行して、KerberosサブドメインSPNを追加します。

    setspn -S HTTP/<yourorg>.kerberos.<oktaorgtype>.com <serviceAccountName>

    プレースホルダー

    HTTP/<yourorg>.kerberos.<oktaorgtype>.com

    お客様のSPN。

    oktaorgtype

    お客様のOkta orgタイプ。例:oktapreview、okta-emea、okta-gov

    serviceAccountName

    お客様のサービス・アカウント名。これは、早期アクセス・バージョンのエージェントレス・デスクトップSSOを構成するときに使用した名前です。

    例:

    setspn -S HTTP/qa-synth.kerberos.oktapreview.com spndefault

    このコマンドでActive Directoryユーザーアカウントは作成されません。代わりに、既存のADユーザーアカウントに新しいSPNが追加されます。このコマンドは、カスタムURLを使用しているorgを含む、すべてのorgに適用できます。

  3. 複数のADフォレストがある場合は、フォレストごとに手順2を繰り返します。

    SPNはフォレスト全体で一意であるため、これを行う必要があるのは各フォレストで1回だけです。

2. 新しいKerberosサブドメインSPNを確認する

  1. Windows PowerShellで次のコマンドを入力し、新しいDNSとSPNのエントリーが更新されていることを確認します。

    klist get HTTP/<yourorg>.kerberos.<oktaorgtype>.com

    例:

    klist get HTTP/atko.kerberos.oktapreview.com

  2. チケットが正常に取得されたというメッセージが表示されることを確認します。

3. 新しいKerberosサブドメインをイントラネット・ゾーンに追加する

サイレントアクティベーションを使用する必要があるすべてのデバイスのインターネット設定のイントラネットサイトリストにhttps://<yourorg>.kerberos.<oktaorgtype>.comを追加します。

Internet Explorerで次の手順を実行します。

  1. [Settings(設定)][Internet Options(インターネットオプション)][Security(セキュリティ)]に移動します。
  2. [Security(セキュリティ)]タブで、[Local Intranet(ローカルイントラネット)][Sites(サイト)][Advanced(詳細設定)]をクリックします。
  3. 前の手順で構成したOkta orgのURLを追加します。

    https://<yourorg>.kerberos.<oktaorgtype>.com

    例:https://atkodemo.kerberos.oktapreview.com

  4. [閉じる]をクリックして、ほかの構成オプションでは[OK]をクリックします。

B. Orgの新しいDNSレコードを作成して確認する

前提条件:SPNを設定するためのドメイン管理者権限。

1. OrgのDNSレコードを作成する

Okta Admin Consoleで次のように操作します。

  1. [セキュリティ][委任認証]に移動します。
  2. [委任認証]ページで[Active Directory]タブをクリックします。
  3. 下にスクロールして[Agentless Desktop SSO and Silent Activation(エージェントレスデスクトップSSOおよびサイレントアクティベーション)]セクションに移動して、[Edit(編集)]をクリックします。

  4. サービスアカウントのユーザー名が古い形式(例:HTTP/<yourorg>.<oktaorgtype>.com)の場合は、sAMAccountname、またはパートAでSPNを設定したサービスアカウントのUPNのユーザー名部分に変更します。

    サービス・アカウントのユーザー名は、大文字と小文字が区別されます。

  5. [Validate service account credential on save(保存時にサービスアカウント資格情報を検証する)]を選択します。
  6. [Save(保存)]をクリックします。

これにより、Orgの新しいDNSレコードの作成がトリガーされます。新しいDNSレコードの作成には、数分、場合によっては数時間かかることがあります。

2. 新しいDNSレコードの作成を確認する

次のdigコマンド(Mac)またはnslookupコマンド(Windows)を使用して、新しいKerberos URLが到達可能であることを確認します。

成功メッセージが表示されない場合は、数分後に再度コマンドを実行してください。レコードの作成には数時間かかる場合があります。出力メッセージの詳細については、それぞれのコマンド・リファレンス・ドキュメントを参照してください。

Macの場合

$ dig <yourorg>.kerberos.<oktaorgtype>.com

例:

Or

Windowsの場合

$ nslookup <yourorg>.kerberos.<oktaorgtype>.com

例:

C. 新しい設定をテストする

前提条件

  • Office 365アプリ・インスタンスが割り当てられ、古い自動ライセンス認証の構成で動作するテスト・ユーザー・アカウント。
  • テスト・ユーザー・アカウントの次の資格情報:
    • ドメイン<yourorg>.kerberos.<oktaorgtype>.com
    • 外部ID:テスト・ユーザーが存在するOrgの外部ID。これは、OrgのWS-Fed設定に使用したスクリプト内にあります。
    • ユーザー名:テスト・ユーザーのUPNのユーザー名部分。
    • パスワード:テスト・ユーザーのアカウントのパスワード。
  • Windowsの管理者権限。

手順

  1. Windowsで、管理者として次のPowerShellコマンドを実行します。

    Get-ExecutionPolicy

  2. 出力ポリシーを書き留めます。この値は最後の手順で必要になります。

  3. 次のコマンドを使用して、実行ポリシーをUnrestrictedに変更します。

    Set-ExecutionPolicy Unrestricted

  4. ユーザー・アカウントをテストします。

    1. 次のスクリプトをテキスト・ファイルにコピーし、Test_windowsTransport.ps1という名前で保存します。

      コピー
      param (
      [Parameter(Mandatory=$true,
      HelpMessage="Domain for org.(orgのドメイン。)No need to pass Kerberos subdomain.")]
      [string]$domain,
      [Parameter(Mandatory=$true,
      HelpMessage="External id of the Office365 app instance.")]
      [string]$externalId,
      [Parameter(Mandatory=$true,
      HelpMessage="Username for the account on the box that should be used for authentication.")]
      [string]$username,
      [Parameter(Mandatory=$true,
      HelpMessage="Password for the account on the box that should be used for authentication.")]
      [string]$password
      )

      $HTTPREQUEST_SETCREDENTIALS_FOR_SERVER = 0;

      $path = "app/office365/{0}/sso/wsfed/windowstransport" -f $externalId
      $url = "https://{0}/{1}" -f $domain, $path
      Write-Host ("Url: {0}" -f $url)

      $soapPayload =
      @'
      <s:Envelope xmlns:s='http://www.w3.org/2003/05/soap-envelope'
      xmlns:wsa='http://www.w3.org/2005/08/addressing'
      xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
      <s:Header>
      <wsa:Action s:mustUnderstand='1'>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
      <wsa:messageID>urn:uuid:099B1123-4E9C-4244-8F51-B92937BFA08E</wsa:messageID>
      <wsa:ReplyTo>
      <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
      </wsa:ReplyTo>
      <wsa:To s:mustUnderstand='1'>{0}</wsa:To>
      </s:Header>
      <s:Body>
      <wst:RequestSecurityToken xmlns:wst='http://schemas.xmlsoap.org/ws/2005/02/trust'>
      <wsp:AppliesTo xmlns:wsp='http://schemas.xmlsoap.org/ws/2004/09/policy'>
      <wsa:EndpointReference>
      <wsa:Address>urn:federation:MicrosoftOnline</wsa:Address>
      </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wst:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType>
      <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
      </wst:RequestSecurityToken>
      </s:Body>
      </s:Envelope>
      '@ -f $url

      $winHttp = New-Object -Com "WinHttp.WinHttpRequest.5.1"
      $winHttp.open("POST", $url, $false)

      $winHttp.SetRequestHeader("Content-Type", "application/soap+xml; charset=utf-8")
      $winHttp.SetRequestHeader("SOAPAction", "http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue")
      $winHttp.SetRequestHeader("x-client-OS", "10.0.14393")
      $winHttp.SetRequestHeader("x-client-SKU", "Win32")
      $winHttp.SetRequestHeader("x-client-Ver", "v2.2.1.28801")

      $winHttp.send($soapPayload)

      if ($winHttp.Status -ne [int]401) {
      Write-Error ("Received unexpected response status: {0}, expected 401." -f $winHttp.Status)
      }

      Write-Host "Received 401 response status."

      $winHttp.SetCredentials($username, $password, $HTTPREQUEST_SETCREDENTIALS_FOR_SERVER)
      $winHttp.send($soapPayload)

      if ($winHttp.Status -ne [int]200) {
      Write-Error ("Received unexpected response status: {0}, expected 200." -f $http.Status)
      }

      Write-Host ("Received {0} response status." -f $winHttp.Status)

      $samlTicket = [XML]$winHttp.ResponseText

      if (-not $samlTicket.Envelope.Body.RequestSecurityTokenResponse.RequestedSecurityToken) {
      Write-Error ("Response did not contain saml ticket.")
      }

      Write-Host ("Valid SAML ticket received.")
    2. PowerShellで次のコマンドを実行します。

      コピー
      .\Test_windowsTransport.ps1 -domain <yourorg>.kerberos.<oktaorgtype>.com -externalId <orgexternalid> -username <testusername> -password <-testpassword>    
    3. 次のSAML正常メッセージが表示されることを確認します。

      Valid SAML ticket received.

      これにより、テスト・ユーザーの自動ライセンス認証が成功したことを確認できます。

  5. 次のコマンドを使用して、実行ポリシーを元の値に戻します。

    Set-ExecutionPolicy <initialPolicy>

次も参照

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

Office 365向けの高度な統合に関する項目

OktaにMicrosoft Office 365をデプロイするための一般的なワークフロー