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

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. ［Security（セキュリティ）］［Delegated Authentication（委任認証）］に移動します。
2. ［Delegated Authentication（委任認証）］ページで［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アプリインスタンスが割り当てられ、古い自動ライセンス認証の構成で動作するテストユーザーアカウント。
• テストユーザーアカウントの次の資格情報：
  • Domain（ドメイン）：<yourorg>.kerberos.<oktaorgtype>.com
  • External ID（外部ID）：テストユーザーが存在するOrgの外部ID。これは、OrgのWS-Fed設定に使用したスクリプト内にあります。
  • Username（ユーザー名）：テストユーザーのUPNのユーザー名部分。
  • Password（パスワード）：テストユーザーのアカウントのパスワード。
• 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>