Linux向けのOkta Verifyの構成設定

LinuxでOkta Verifyのデバイスポリシーファイルの構成設定を確認します。

Linux版のOkta Verifyには、レジストリやインストーラーのコマンドラインフラグはありません。その代わりに、/etc/okta/adminconfig.jsonというJSONポリシーファイルを1つ作成し、MDMソリューションを使用して各デバイスにデプロイする必要があります。Okta Verifyがこのファイルを作成することはなく、インストーラーによって上書きされることもありません。

ポリシー設定

/etc/okta/adminconfig.json内のすべての設定は、最上位のconfigurationオブジェクトの下に記述します。このファイルはJSON形式で、設定はキーと値のペアとしてフラットに指定します。

{
  "configuration": {
    "EnrollmentOptions": "Enabled",
    "OrgUrl": "https://example.okta.com",
    "ReportDiagnostics": "False",
    "LogLevel": "Debug"
  }
}

構成オプション

以下のオプションと値を使用して、Okta Verifyのポリシーファイルを構成します。

EnrollmentOptions

認証時にエンドユーザーにOkta Verifyへの登録を求めるかどうかを構成します。

このオプションを使用すると、ユーザーに表示される登録プロンプトの数を減らしたり、orgでのOkta VerifyとOkta FastPassの展開を制御したりできます。

値［文字列］ 説明
SilentEnrollmentDisabled

ユーザーがOkta Verifyでサインインする（Sign in with Okta Verify）を選択した場合にのみ、認証時にアカウントの登録を促すプロンプトを表示します。

これはデフォルトです。
Enabled

Okta FastPassの認証時にアカウントの登録を促すプロンプトをユーザーに表示します。ユーザーによる操作が不要なフローも含まれます。
Disabled

認証時にOkta Verifyへの登録を促すプロンプトをユーザーに表示しません。

登録するには、ユーザーがOkta Verifyアプリを開いてアカウントを追加（Add an account）を選択する必要があります。

LogLevel

ログファイルに記録するログの詳細度を構成します。

値［文字列］ 説明
None

ログに記録されたメッセージはありません。ログ記録を無効にする場合は、これを使用します。
Critical

重大なメッセージは、回復不能な障害を示し、アプリがクラッシュする可能性があります。
Error

エラーメッセージは、回復できる可能性があるものの、コンポーネントや処理に重大な障害が発生していることを示します。
Warning

警告メッセージは、障害には至らないものの、潜在的な問題や予期しない動作が発生していることを示し、対処が必要になる場合があります。
Info

情報メッセージは、処理の開始や終了、その他の重要な進行状況など、処理に関する一般的な情報を提供します。

これらのメッセージは通常、モニタリングと診断に使用されます。
Debug

デバッグメッセージは、問題の診断とアプリの内部状態の理解に関する詳細情報を提供します。

通常、開発時やトラブルシューティング時に使用されます。

Linux版Okta Verifyのデフォルトのログレベルです。

OrgUrl

このオプションを構成すると、ユーザーの登録ページにorgのURLが表示されます。

このオプションにデフォルト値はありません。

値［文字列］ 説明
<fully-qualified-domain-name>

https://プレフィックスを含む、orgの完全なURL。例：https://okta.okta.com
<org-sign-in-URL>

プロトコルのプレフィックスを含まない、orgのドメイン名。例：okta.okta.com

ReportDiagnostics

クラッシュレポートをOktaの診断・テレメトリツールに送信するかどうかを構成します。

値［文字列］ 説明
True

クラッシュレポートを送信します。

これはデフォルトです。
False

クラッシュレポートは送信されません。

UserVerificationEnrollment

早期アクセスリリース

Okta Verifyのユーザー検証登録動作を構成します。このオプションが構成されていない場合、登録動作はサーバー構成によって決まります。

値［文字列］ 説明

Disabled

登録時にユーザー検証への登録を求められることはありません。

アカウント（Accounts）ページでユーザー検証を有効にするオプションは、Okta Verifyアプリでは利用できません。

Deferred

Okta Verifyはユーザー検証登録ページをスキップします。

ユーザーはOkta Verifyアプリのアカウント（Accounts）ページで、後からユーザー検証を有効にできます。

Preferred

Okta Verifyでユーザーはユーザー検証に登録するように求められますが、今はしない（Not now）をクリックするとスキップできます。

Required

ユーザーはユーザー検証に登録する必要があり、後から削除することはできません。

ファイルの権限

以下の表に、ポリシーファイルとその親ディレクトリの所有者とモードのオプションを示します。

オブジェクト 所有者とグループ モード（Mode） 理由（Reason）
/etc/okta（ディレクトリ） root:okta-ff 1775

インストーラーによってこれらのモードが設定されます。

グループの書き込み設定により、Okta機能フラグサービスがキャッシュを管理できます。

スティッキービットにより、rootが所有するポリシーファイルをこのサービスが置き換えるのを防ぎます。

全ユーザーに対するr-x設定により、デスクトップアプリがディレクトリを通過できます。
/etc/okta/adminconfig.json（ファイル） root:root 0444 すべてのユーザーに読み取り専用ですが、rootのみがこのファイルに書き込めます。

ポリシー変更の適用

ポリシーファイルをデプロイまたは更新した後、コンポーネントによって変更の反映方法が異なります。以下の表で、各コンポーネントでの変更の反映方法と、変更を直ちに反映させる方法を確認してください。

構成要素 変更の反映方法

Okta Verifyデスクトップアプリ

アプリは構成ファイルの変更を検知します。

一部の設定は起動時に読み込まれますが、ほとんどの変更では、ユーザーがOkta Verifyを終了して再起動する必要があります。

Okta authenticatorサービス

サービスは起動時に構成ファイルを読み込みます。

変更を直ちに反映するには、sudo systemctl restart okta-authenticator.serviceを実行してサービスを再起動します。

Okta機能フラグサービス

このサービスは構成ファイルの変更を監視しますが、次のコマンドを実行してサービスを再起動することもできます：sudo systemctl restart okta-feature-flag.service

関連ファイル

/etc/oktaにある以下のファイルは、Okta Verifyの正常動作に関係するファイルです。

ファイル 所有者、グループ、モード 目的（Purpose）
oktaverify.json root:root 0444

インストーラーの基本設定です。

adminconfig.jsonに同じキーが設定されている場合は、そちらが優先されます。

このファイルではなく、adminconfig.jsonを編集してください。
azureconfig.json root:okta-ff 0440

Oktaサービスの構成ファイルです。

このファイルは意図的に、すべてのユーザーから読み取れるようにはなっていません。この権限設定を変更しないでください。
featureflagscache.json okta-ff:okta-ff 0644 Okta機能フラグサービスが管理する実行時キャッシュです。このファイルを編集または削除しないでください。
authenticator/Plugins/ root:root デバイス証明プラグインのマニフェストを格納するディレクトリです。デプロイ環境でプラグインを使用している場合に使用されます。

アプリのライフサイクル

パッケージとポリシー設定をインストールした後、アプリのライフサイクルでは、今後次の3つの操作を行う可能性があります。

アップグレード

adminconfig.jsonはパッケージマネージャーによって管理されないため、 Okta Verifyアプリをアップグレードまたは再インストールしても、このファイルが変更、置換されることはなく、ファイルについて確認を求められることもありません。

削除（Remove）

パッケージを削除するには、apt remove okta-verifyを実行します。

この操作ではポリシーファイルは削除されないため、パッケージを再インストールした場合も、ポリシー設定はそのまま維持されます。

パージ

パッケージをパージするには、apt purge okta-verifyを実行します。

パージすると、adminconfig.jsonファイルを含む /etc/oktaディレクトリが削除されます。パージ後にパッケージを再インストールする場合は、ポリシーファイルを再度デプロイする必要があります。

パージすると、/var/log/oktaフォルダーも削除されます。このフォルダーには、Okta authenticatorと機能フラグサービスのログファイルが含まれています。 サポートケースに必要なログがある場合は、パッケージをパージする前に収集してください。

ログファイル

サポートケースでは、次のログを使用します。

スコープ パス（Path） 内容
システムサービス

/var/log/okta/OktaLinuxAuthenticatorService*.log

/var/log/okta/OktaLinuxFeatureFlagService*.log

これらのシステムサービスのログは毎日、またはファイルサイズが5MiBに達した時点でローテーションされます。

ログは7日間保持されます。

ログはサイズ制限に達した場合にもローテーションされるため、使用量が多い日には複数のファイルが生成されることがあります。

つまり、7日間の保持期間だからといって、ログの合計サイズが5MiB × 7に制限されるわけではありません。
デスクトップアプリ ~/.local/share/okta/Logs/OktaVerify*.log これらのアプリログはユーザーごとに作成され、システムサービスのログと同じローテーションポリシーが適用されます。
systemd journal journalctl -u okta-authenticator -u okta-feature-flag これらのログには、アプリの起動とクラッシュに関する詳細情報が含まれます。

Linux版Okta VerifyのデフォルトのログレベルはDebugです。