レジストリキーベースの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を追加する

注意:

現在使用しているのと同じサービスアカウントを使用します。サービスアカウントを変更すると、サイレントアクティベーションの認証要求が失敗する可能性があります。

Active Directory環境で、管理者としてコマンドプロンプトを開きます。

次のコマンドを実行して、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に適用できます。

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

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

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

Windows PowerShellで次のコマンドを入力し、新しいDNSとSPNのエントリーが更新されていることを確認します。
```
klist get HTTP/<yourorg>.kerberos.<oktaorgtype>.com
```
例：
```
klist get HTTP/atko.kerberos.oktapreview.com
```
チケットが正常に取得されたというメッセージが表示されることを確認します。

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

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

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をクリックします。

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

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

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

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

セキュリティ（Security） > 委任認証（Delegated Authentication）に移動します。
委任認証（Delegated Authentication）ページでActive Directory（Active directory）タブをクリックします。
下にスクロールしてエージェントレスデスクトップSSOおよびサイレントアクティベーション（Agentless Desktop SSO and Silent Activation）セクションに移動して、編集（Edit）をクリックします。
サービスアカウントのユーザー名（service account username）が古い形式（例：HTTP/<yourorg>.<oktaorgtype>.com）の場合は、sAMAccountname、またはパートAでSPNを設定したサービスアカウントのUPNのユーザー名部分に変更します。

注:
サービスアカウントのユーザー名は、大文字と小文字が区別されます。
保存時にサービスアカウント資格情報を検証する（Validate service account credential on save）を選択します。
保存（Save）をクリックします。

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

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

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

注:

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

Macの場合

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

例：

Windowsの場合

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

例：

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

前提条件

Office 365アプリインスタンスが割り当てられ、古いサイレントアクティベーションの構成で動作するテストユーザーアカウント。
テストユーザーアカウントの次の資格情報：
- ドメイン（Domain）：<yourorg>.kerberos.<oktaorgtype>.com
- 外部ID（External ID）：テストユーザーが存在するOrgの外部ID。これは、OrgのWS-Fed設定に使用したスクリプト内にあります。
- ユーザー名（Username）：テストユーザーのUPNのユーザー名部分。
- パスワード（Password）：テストユーザーのアカウントのパスワード。
Windowsの管理者権限。

手順

Windowsで、管理者として次のPowerShellコマンドを実行します。
```
Get-ExecutionPolicy
```
出力ポリシーを書き留めます。この値は最後の手順で必要になります。
次のコマンドを使用して、実行ポリシーをUnrestrictedに変更します。
```
Set-ExecutionPolicy Unrestricted
```

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

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

param (
[Parameter(Mandatory=$true,
HelpMessage="Domain for 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.")

PowerShellで次のコマンドを実行します。

.\Test_windowsTransport.ps1 -domain <yourorg>.kerberos.<oktaorgtype>.com -externalId <orgexternalid> -username <testusername> -password <-testpassword>

次のSAML正常メッセージが表示されることを確認します。
```
Valid SAML ticket received.
```
これにより、テストユーザーの自動ライセンス認証が成功したことを確認できます。

次のコマンドを使用して、実行ポリシーを元の値に戻します。
```
Set-ExecutionPolicy <initialPolicy>
```

Office 365サイレントアクティベーション：新しいリリースの実装

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

Microsoft Office 365デプロイメントガイド