MDM管理対象Androidデバイスのネイティブアプリとブラウザーに対してOktaDevice Trustを強制適用する
早期アクセスリリース。セルフサービス機能を有効にするを参照してください。
Android向けのOkta Device Trustは、アンマネージドAndroidデバイスがブラウザーやネイティブアプリを通してエンタープライズサービスにアクセスすることを防ぎます。
前提条件
- Android 5.1(Lollipop)以降を実行するAndroidデバイス
- Google Playサービス
- Androidエンタープライズ管理
- マネージドアプリの構成をサポートする任意のモバイルデバイス管理(MDM)プロバイダー
- アプリ:
- Android SAMLあるいはWS-Fedクラウドアプリ
- Okta Mobile 5.14.0+ for Android、MDMプロバイダーが管理
開始する前に
- 戻る([Back)]ボタンをタップするとアプリにアクセスできない場合がある:Okta MFAを実装している組織では、MFAチャレンジに合格した後にAndroidデバイスの戻る(Back)ボタンをタップすると、ユーザーがアクセスを試みていたDevice Trustで保護されたアプリではなく、Oktaホームページにリダイレクトされます。影響を受けるエンドユーザーには、戻る(Back)ボタンをタップせずに再試行するようにアドバイスします。
- Okta Mobileと管理上のヒントをデバイスにプッシュすると遅延が生じる可能性がある:MDMが管理対象のOkta Mobileアプリと管理上のヒントをAndroidデバイスにプッシュするのを待機する際に、長い遅延が発生する場合があります。この遅延は、場合によっては無期限です。この問題はGoogleに起因しており、Googleが認識しています。
- 信頼(Trust)またはNot trusted(非信頼)条件でのサインオンポリシールール:信頼(Trust)または非信頼(Not trusted)条件で構成されたアプリのサインオンポリシールールを処理する場合、Oktaは通常のルール処理を一時停止し、Okta Mobileを使用してデバイスが信頼できるかどうかを評価します。Oktaによってデバイスが非信頼と評価された場合、以下のいずれかが行われます。
- 非信頼デバイスを拒否するようにサインオンポリシールールを構成した場合、ユーザーはMDMプロバイダーへ登録するように求められます。
- 非信頼デバイスを使用するユーザーにMFAチャレンジを与えるようにサインオンポリシールールを構成した場合、そのユーザーにMFAチャンレンジが提示されます。
- エンドユーザーがアプリサインインページにリダイレクトされないことがある:Device Trustソリューションが有効になっている場合、エンドユーザーがOkta連携認証GmailまたはSalesforceアカウントにサインインした後そのアカウントを削除すると、アプリのサインインページではなくOktaホームページにリダイレクトされます。
- Oktaがパスワードレス認証をサポートするのはOffice 365アプリのみ(Okta Mobileがインストールされていることが前提):他のすべてのアプリでは、資格情報を入力するためのOktaサインインページがエンドユーザーに表示されます。ユーザーはその後、Okta MobileでDevice Trustステータスを評価することが求められます。デバイスが信頼されている(MDMに登録されている)場合、エンドユーザーはアプリにアクセスできますOkta Mobileがデバイスを信頼できないと評価した場合、次のいずれかが発生します。
- 非信頼デバイスを拒否するようにサインオンポリシールールを構成した場合、該当するデバイスを使用するユーザーはMDMプロバイダーへ登録するように求められます。
- 非信頼デバイスを使用するユーザーにMFAチャレンジを提示するようにサインオンポリシールールを設定した場合、該当するユーザーにはMFAチャレンジが提示されます。
- このDevice TrustソリューションでOkta連携認証MDMアプリケーションを保護する:Oktaでは、Not Trusted - Deny(非信頼 - 拒否)アプリサインオンポリシーをOkta連携認証MDMアプリケーションに適用しないよう推奨しています。適用した場合、新規ユーザーがデバイスをMDMアプリケーションに登録できなくなり、その他のDevice Trustで保護されたアプリにアクセスすることができなくなります。
-
Device Trustによって保護されたアプリは、Okta End-User Dashboardにロック済みとして表示されます。次の条件下でDevice Trustによって保護されたアプリの横に、ロックアイコンが表示されます。
- エンドユーザーがデスクトップまたはモバイルのブラウザー(Okta Mobile以外)でダッシュボードにアクセスした。
- OrgでDevice Trustが有効になっている。
- デバイスが信頼されていない。
- エンドユーザーがダッシュボードからDevice Trustで保護されたアプリにアクセスしようとした。
手順
ステップ1. orgのグローバルのDevice Trustの設定を有効化する
-
Admin Consoleでに移動します。
- Device Trust向けDevice Trust(Edit)セクションで、[Edit(編集)]をクリックします。
- Android を有効化(Enable Android )Device Trust を選択します。
- MDMプロバイダーに対応するオプションを選択します。
MDM オプション Workspace ONE UEM (旧称AirWatch)
- 信頼の確立元:Workspace ONE
- 統合タイプ([Integration type)]:Oktaクライアントベース(Workspace ONE UEM)
Microsoft Intune 信頼の確立元([Trust is established by)]:Microsoft IntuneMobileIron 信頼の確立元([Trust is established by)]:MobileIron上記以外 - 信頼の確立元([Trust is established by)]:その他
- 統合タイプ([Integration type)]:Oktaクライアントベース
注: 重要:SAMLベース・オプションは選択しないでください。このDevice Trustソリューションには適用されません。 - 次へ(Next)をクリックします。
-
フィールドの横にあるコピーアイコンをクリックして、提供された秘密鍵(Secret Key)をクリップボードにコピーします。この秘密鍵(Secret Key)は、手順2で説明するように、後でMDMプロバイダーのアプリ構成に入力します。
注:提供された秘密鍵の値がOktaに表示されるのはこの時だけなので、メモしておいてください。[Reset (Secret Key)Androidの秘密鍵をリセット(Android Secret Key)]]をクリックして新しい秘密鍵(Reset AndroidSecret Key)を生成する場合は、ご使用のMDM構成も新しいキーで更新してください。
- モバイルデバイス管理プロバイダー(Mobile device management provider)フィールドでMDMプロバイダーの名前を追加または変更します。このフィールドの内容は、エンドユーザーがデバイスを登録したときに表示されます。
- 登録リンク(Enrollment link)フィールドに、未登録のデバイスがあるエンドユーザーをリダイレクトするためのWebアドレスを入力します。たとえば、これらのユーザーを登録手順が記載されたページや選択したMDMの登録ページにリダイレクトすることができます(MDMプロバイダーがWebベースの登録をサポートしている場合)。
- 保存(Save)をクリックします。
- ステップ2に進みます。
ステップ2. OktaをサードパーティMDMプロバイダーに統合する
推奨MDM機能
最低限、MDMはマネージドアプリの構成をサポートしている必要があります。最良の結果が得られるよう、以下の機能を持つMDMと統合することをお勧めします。
- 選択したMDMにエンドユーザーが登録したときに、エンドユーザーのデバイスにサイレントかつ自動的にインストールされるようにOkta Mobileを設定する
- エンドユーザーが選択したMDMに登録したときに、Okta Mobileワークプロファイルがサイレントかつ自動的にインストールされるようにOkta Mobileを設定する
- マネージドアプリの構成を使用してキーと値のペアを構成する
ベストなエンドユーザーエクスペリエンスを提供
エンドユーザーのOkta MobileデバイスがMDMプロバイダーにすでに登録されていて、Okta MobileがMDMプロバイダーのアプリストアを通じてデバイスのワークプロファイルにサイレントにインストールされている場合、管理対象の企業リソースにアクセスする際のエクスペリエンスが向上します。Okta Mobileがまだワークプロファイルにインストールされていない場合、MDMアプリストアからインストールするためのガイドがエンドユーザーに表示されます。Okta Mobileがインストールされているが、まだMDMプロバイダーによって管理されていない場合、エンドユーザーはDevice Trustで保護されたアプリにアクセスする前に、アプリ管理プロセスを通して手順が示されます。
- Okta Mobileを管理し、まだインストールされていない場合はエンドユーザーのデバイスにインストールするようにMDMプロバイダーを構成します。
- それぞれのドキュメントに記載されているように、MDMプロバイダーのマネージドアプリ構成を通じてキーと値のペアを構成します。
- キー([Key)]:(Key:)ドメイン
- 値([Value)]:(Value:)Okta orgのURLを入力します
- キー([Key)]:(Key:)managementHint
- 値(Value)(Value:):ステップ1(Secret Key)で保存した秘密鍵(Secret Key)の値を使用します。
注:キーと値のペアでは大文字と小文字が区別されます。
例:MDMがXMLを必要とする場合、次のようなXML形式を使用します。
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" http://www.apple.com/DTDs/PropertyList-1.0.dtd> <plist version="1.0"> <dict> <key>Domain</key> <string>https://"Your domain".okta.com</string> <key>managementHint</key> <string>"secret key goes here"</string> </dict> </plist>構成のヒント
以下は、選択されたMDMアプリケーションでキーと値のペアを構成する際のヒントです。MDM構成は予告なしに変更される場合があるため、常にMDMのドキュメントを参照し、最新情報を確認することをおすすめします。
Workspace ONE
Workspace ONE UEMのあるOkta Mobileの追加、割り当て、管理には、以下のWorkspace ONE UEM資料に示す手順に従ってください。
アプリケーションの割り当て手順で、以下の設定を次のように構成してください。
- 管理アクセス(Managed Access)有効(:[Enable)]
- アプリの配信方法(App Delivery Method)自動(:[Auto)]
- アプリケーションの構成(Application Configuration)
- ドメイン(Domain):Okta orgのURLを入力します。
- ユーザー名(Username):Okta orgのユーザー名を入力します。
- 管理のヒント(Management Hint):ステップ1(Secret Key)で保存した秘密鍵(Secret Key)の値を入力します(注:この値では大文字と小文字が区別されます)。
Microsoft Intune
Microsoft IntuneでOkta Mobileを管理する方法については、Microsoft Intuneのドキュメント「管理対象のAndroid Enterpriseデバイスのアプリ構成ポリシーを追加する」に記載されている手順を実行します。
- デバイス登録タイプ(Device enrollment type)管理対象デバイス( :[Managed devices)]
- 関連アプリ(Associated App):Okta Mobile
- 構成設定の形式(Configuration settings format):構成デザイナーを使用
- Domain (string)(ドメイン(文字列)):Okta orgのURLを入力します
- Username (string)(ユーザー名(文字列)):Okta orgのユーザー名を入力します
- Management Hint (string)(管理のヒント(文字列)):ステップ1(Secret Key)で保存した秘密鍵(Secret Key)の値を入力します(注:この値では大文字と小文字が区別されます)。
MobileIron
MobileIronでOkta Mobileを管理する方法については、MobileIronのドキュメントApp Configurationに記載されている手順を実行してください。
アプリ構成(App Configurations)画面で、以下の設定を構成します。
- デバイスへのインストール(Install on device)
- Android用のマネージド構成(Managed Configurations for Android)
ドメイン(Domain):Okta orgのURLを入力します。
ユーザー名(Username):Okta orgのユーザー名を入力します。
管理のヒント(Management Hint):ステップ1(Secret Key)で保存した秘密鍵(Secret Key)の値を入力します(注:この値では大文字と小文字が区別されます)。
- ステップ3に進みます。
ステップ3. Oktaでアプリサインオンポリシールールを構成する
アプリサインオンポリシールールについて
アプリサインオンルール([App Sign On Rule)]ダイアログボックス内のすべてのクライアントオプションはデフォルトで事前選択されています。アプリへのアクセスを詳細設定するには、以下を反映させるルールを作成します。
- 対象となるユーザー、または対象者が属するグループ
- 対象者がネットワークに接続しているか、接続していないか、定義されたネットワークゾーンに属しているか
- 対象者のデバイスで実行されているクライアントのタイプ(Office 365アプリのみ)
- 対象者のモバイルまたはデスクトップデバイスのプラットフォーム
- 対象者のデバイスが信頼されているかどうか
サインオンポリシールールへの許可リストによるアプローチ
- アプリへのアクセスを許可するシナリオをサポートする1つまたは複数の許可ルールを作成し、これらのルールに最高優先度を割り当てます。
- ステップ1で作成した許可シナリオに一致しないユーザーに適用するキャッチオール拒否ルールを作成します。キャッチオール拒否ルールに、デフォルトルールのすぐ上の最低優先度を割り当てます。ここで説明した許可リストアプローチでは、デフォルトルールは事実上キャッチオール拒否ルールで否定されるため、これに達することはありません。
アプリサインオンポリシールールの作成についての重要なセキュリティ情報は、「アプリのサインオンポリシーについて」を参照してください。
手順
Device Trust:この例は、Office 365へのアクセスを管理するためのDevice Trustルールを示しています。他のアプリでは、ユーザーのクライアントが次のいずれかに該当する場合(If the user's client is any of these)セクションは表示されません。
- Admin Consoleでに進み、Device Trustで保護するSAMLまたはWS対応アプリをクリックします。
- サインオン(Sign On)タブをクリックします。
- 下にスクロールしてサインオンポリシー(Sign On Policy)に移動し、ルールを追加(Add Rule)をクリックします。
- 次の例をガイドとして使用して、1つ以上のルールを構成します。
この例では、WebブラウザーおよびModern Authクライアントへのアクセスを許可してすべてのアクセスにMFAを要求し、非信頼Androidデバイスへのアクセスは拒否するアプリサインオンポリシーを作成する手順を示します。
ルール例1:Webブラウザーまたはモダン認証、Android、信頼できる、アクセスを許可 + MFA
- ルールの記述名を入力します。
- ユーザー(PEOPLE)で、ルールを個人のみに適用するか、個人とグループに適用するかを指定します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- ロケーション(LOCATION)で、ルールを適用するユーザーのロケーションを指定します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- クライアント(CLIENT)で、次の設定を構成します。
Webブラウザー(Web browser)を選択します。
Modern Authクライアント(Modern Auth client)を選択します。
Exchange ActiveSyncクライアント(Exchange ActiveSync client)を選択解除します。
モバイル(Mobile)
iOS を選択解除します。
Android を選択します。
他のモバイル(Other mobile)を選択解除します。
デスクトップ
Windows を選択解除します。
macOS を選択解除します。
他のデスクトップ(Other desktop)を選択解除します。
- Device Trust(DEVICE TRUST)で以下を構成します。
Device Trust セクションの信頼(Trusted)と非信頼(Not trusted)オプションは、クライアント(Client)セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- Exchange ActiveSyncまたはレガシー認証クライアント(Exchange ActiveSync or Legacy Auth client)
- Other mobile (for example, BlackBerry)(他のモバイル(BlackBerryなど))
- Other desktop (for example, Linux)(他のデスクトップ(Linuxなど))
すべて(Any)を選択解除します。
信頼(Trusted) を選択します。
非信頼( [Not trusted)]を選択解除します。
- アクセス(Access)を構成します。
許可(Allowed)を選択します。
要素をプロンプト(Prompt for factor)を選択します。
- 保存(Save)をクリックします。
- ルール2を作成します。
ルール例2:Webブラウザーまたはモダン認証、Androidを除くすべてのプラットフォーム、任意の信頼、アクセスを許可+ MFA
- ルールの記述名を入力します。
- ユーザー(PEOPLE)で、ルール1(Rule 1)で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- ロケーション(LOCATION)で、ルール1(Rule 1)で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- クライアント(CLIENT)で、次の設定を構成します。
Webブラウザー(Web browser)を選択します。
Modern Authクライアント(Modern Auth client)を選択します。
Exchange ActiveSyncクライアント(Exchange ActiveSync client)を選択解除します。
モバイル(Mobile)
iOS を選択します。
Android(Androd)を選択解除します。
他のモバイル(Other mobile)を選択します。
デスクトップ
Windows を選択します。
macOS を選択します。
他のデスクトップ(Other desktop)を選択します。
- Device Trust(DEVICE TRUST)で以下を構成します。
Device Trust セクションの信頼(Trusted)と非信頼(Not trusted)オプションは、クライアント(Client)セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- Exchange ActiveSyncまたはレガシー認証クライアント(Exchange ActiveSync or Legacy Auth client)
- Other mobile (for example, BlackBerry)(他のモバイル(BlackBerryなど))
- Other desktop (for example, Linux)(他のデスクトップ(Linuxなど))
すべて(Any)を選択します。
信頼(Trusted)を選択解除します。
非信頼(Not trusted)を選択解除します。
- アクセス(Access)を構成します。
許可(Allowed)を選択します。
要素をプロンプト(Prompt for factor)を選択します。
- 保存(Save)をクリックします。
- ルール3を作成します。
ルール例3:Webブラウザーまたはモダン認証、Android、信頼できない、アクセスを拒否
- ルールの記述名を入力します。
- ユーザー(PEOPLE)で、ルール1(Rule 1)で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- ロケーション(LOCATION)で、ルール1(Rule 1)で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- クライアント(CLIENT)で、次の設定を構成します。
Webブラウザー(Web browser)を選択します。
Modern Authクライアント(Modern Auth client)を選択します。
Exchange ActiveSyncクライアント(Exchange ActiveSync client)を選択解除します。
モバイル(Mobile)
iOS を選択解除します。
Android を選択します。
他のモバイル(Other mobile)を選択解除します。
デスクトップ
Windows を選択解除します。
macOS を選択解除します。
他のデスクトップ(Other desktop)を選択解除します。
- Device Trust(DEVICE TRUST)で以下を構成します。
Device Trust セクションの信頼(Trusted)と非信頼(Not trusted)オプションは、クライアント(Client)セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- Exchange ActiveSyncまたはレガシー認証クライアント(Exchange ActiveSync or Legacy Auth client)
- Other mobile (for example, BlackBerry)(他のモバイル(BlackBerryなど))
- Other desktop (for example, Linux)(他のデスクトップ(Linuxなど))
すべて(Any)を選択解除します。
信頼(Trusted)を選択解除します。
非信頼(Not trusted)を選択します。
- アクセス(Access)を構成します。
拒否(Denied)を選択します。
- 保存(Save)をクリックします。
例:Rule 4 – Any client type; All platforms; Any Trust; Deny access
- ルールの記述名を入力します。
- ユーザー(PEOPLE)で、ルール1(Rule 1)で選択したものと同じユーザーオプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- ロケーション(LOCATION)で、ルール1(Rule 1)で選択したものと同じ[Location(ロケーション)]オプションを選択します。このオプションは、この例で作成するすべてのルールで同じにする必要があります。
- クライアント(CLIENT)で、次の設定を構成します。
Webブラウザー(Web browser)を選択します。
Modern Authクライアント(Modern Auth client)を選択します。
Exchange ActiveSyncクライアント(Exchange ActiveSync client)を選択します。
モバイル(Mobile)
iOS を選択します。
Android を選択します。
他のモバイル(Other mobile)を選択します。
デスクトップ
Windows を選択します。
macOS を選択します。
他のデスクトップ(Other desktop)を選択します。
- Device Trust(DEVICE TRUST)で以下を構成します。
Device Trust セクションの信頼(Trusted)と非信頼(Not trusted)オプションは、クライアント(Client)セクションの以下のオプションがどれも選択されていない場合にのみ選択可能です。
- Exchange ActiveSyncまたはレガシー認証クライアント(Exchange ActiveSync or Legacy Auth client)
- Other mobile (for example, BlackBerry)(他のモバイル(BlackBerryなど))
- Other desktop (for example, Linux)(他のデスクトップ(Linuxなど))
すべて(Any)を選択します。
信頼(Trusted)を選択解除します。
非信頼(Not trusted)を選択解除します。
- アクセス(Access)を構成します。
拒否(Denied)を選択します。
- 保存(Save)をクリックします。
Rule 5: Default sign on rule – Any client, All platforms; Any Trust; Allow access
デフォルトサインオンルールは作成済みであり、編集できません。この例では、デフォルトルールがルール4により実質的に無効化されているため、デフォルトルールに到達することはありません。
既知の問題
- IntuneがMDMプロバイダーである場合、このDevice Trustソリューションを使用するときO365はサポートされていない - Microsoft IntuneがMDMプロバイダーで、Oktaに連携認証されている場合、Not Trusted --> Deny(非信頼 --> 拒否)アプリ認証ポリシーをOkta連携認証済みO365アプリに適用すると、アンマネージドAndroidデバイスを使用するエンドユーザーはデバイスをIntuneに登録できなくなります。これは、O365アプリ認証ポリシーがIntuneにも適用されるためです。Oktaはこの問題を調査中です。それまでの間、Microsoft Intune MAMを使用してO365アプリへのアクセスを管理し、このOkta Device Trustソリューションは他の機密性の高いアプリへのアクセスを管理するために使用することをお勧めします。
- Android 10(Q)以降のバージョンがこのソリューションではサポートされない:Googleが実施した変更により、Android 10以降が搭載されたデバイスはOktaなどのISVに信頼状態(信頼/非信頼)を通知することができません。その結果、Android 10以降のバージョンを実行しているデバイス上のネイティブアプリまたはChromeからの認証リクエストは非認証(Not Trusted)として表示されます。このシナリオでは、デバイス・ポスチャーが正しく評価されるよう、OktaはユーザーにOkta Mobileを通して保護リソースにアクセスするように求めます。
- このDevice Trustソリューションに登録していない iPadユーザーに追加のプロンプトが表示される場合がある:Safariを使用して未登録iPadからDevice Trustで保護されたアプリにアクセスするエンドユーザーは、ここをタップして接続(Tap here to connect)リンクをタップするように求められます。リンクをタップすると、デバイスの登録フローを通して手順が表示されます。Okta Mobileダッシュボードからネイティブアプリにアクセスする場合、このプロンプトは表示されません。
- Outlookへの認証でUXの問題が生じる可能性がある:Outlook用に構成されているDevice Trustサインオンポリシーを使用するOrgのAndroidデバイスユーザーが、Outlookに対して認証するときにOutlookがハングするなどのUXに関する問題が発生することがあります。この問題は、Microsoftが最近Outlookアプリに加えた変更に関連しており、これにより連携認証フロー中でのOkta Sign-In Widget の取り扱いに影響が出たことによるものです。解決策は、Outlookを強制的に閉じてから再試行することです。Oktaはこの問題をMicrosoftに通知済みです。