危険な端末を探す
永らくチェックインしてこない端末は、「脱獄」「ルート化」された可能性があります
MobiControlに登録した端末は、MobiControlサーバに、デフォルトでは、2時間に1回はチェックインします。 端末が、永らくチェックインしてこない原因には、次に掲げるどれかが、考えられます。
チェックインしてこない原因 原因の原因 MobiControlサーバに対しオフライン a. 端末操作で、MobiControlから登録解除
- a-1. ルート化された
- a-2. 端末が初期化された
- a-3. MobiControlエージェントの「登録ステータス」を長押しして、登録解除
- a-4. MobiControlエージェントが、アンインストールされた
b. ネットワーク接続をしていない
(WiFi圏外、SIMカード抜き取り)
- b-1. 盗まれた (WiFi専用端末が、事業所以外に移動)
- b-2. WiFi アクセスポイント不調
c. 端末の電源オフ d. Apple端末が、APNsとの同期不調。但し、ネットワークとは正常接続。
- d-1. 脱獄された
- d-2. 7日間以上、ネットワーク接続しなかった
端末は、ロック中でもスリープ中でも、チェックインをしてくるのが仕様です。
このページは、オフラインが長く続く端末、またはチェックインをしてこない端末を、コンソールで見つける方法を説明します。
端末がチェックインしてこない原因は、コンソール側では、すぐには、わかりません。
そこで、「ルート化された」、「脱獄された」、または「盗まれた」可能性を念頭に、 オフラインが長く続く端末、またはチェックインをしてこない端末がないかを、コンソールで監視してください。端末がチェックインをしてこない背景理由は、Apple端末と、Apple端末以外では、やや異なります。
Apple端末以外では、MobiControlサーバにオンラインでない端末は、必ずチェックインをしません。 Apple端末以外の端末では、MobiControlサーバと切断、それも、切断してから長時間経過した端末が、要注意です。
Apple端末以外 端末がMobiControlサーバにオンラインでない 端末がチェックインしない
MobiControlサーバに接続中の端末は、コンソールの端末一覧では、Apple端末:チェックインと接続を参照ください。 Apple端末では、最後のチェックイン時刻から長い時間が経過した端末が、要注意です。
Apple端末 (端末はMobiControlサーバに、通常オフラインだが、サーバからAPNs経由で、チェックイン要求を、端末に送ったときは、チェックインをするのが仕様) ① 端末がネットワークに接続していない または ② 端末がAPNsと接続していない 端末がチェックインしない または、
と緑色の アイコンで表示されます。Apple端末以外は、これが、正常です。
または、
とグレイのアイコンで表示されている端末は オフラインの状態です。
「ルート化」や「脱獄」をされても、稀ですが、MobiControlエージェントがアンインストールされず、MobiControlサーバとの接続が回復することがあります。 その場合は、コンソールで、「ルート化」や「脱獄」を認識できます。
また、上記 a-3 は、コンソールで認識できます。A. 端末が、チェックインしてこないことの悪影響
「ルート化」「脱獄」「盗難」が原因でないとしても、端末がオンラインでない、または端末がチェックインしてこないことは、様々な悪影響を及ぼします。 例えば、次の様な悪影響があります。
- 構成プロファイルやアプリの配布を試みても、それがサーバに滞留するので、「インストールの保留中」になる
- 端末への働きかけができなくなる。例えば、リモートWIPEができなくなる。
- 端末のアラートイベント(例えば、ウィルス検知)が、サーバに届かなくなり、適切な対応ができなくなる
B. 長期間オフラインの端末を見つける (Apple端末、Windows Modernを除く)
B-1. グラフを見て、すぐに見つける
端末一覧の画面で、(図1)のようなフィルタ条件式を適用しておきます。 これで、端末一覧には、Windows Modern端末が表示されなくなります。(図1)
フィルタ条件式は、保存できます。必要なときは、保存しておいたフィルタ条件式を、再掲示できます。詳しくは、「フィルタ条件式に名前をつけて保存」を参照コンソールの端末一覧の上部に表示されるグラフの1つの端末プロパティを「エージェント切断時間」にしておきます。(図2)が、それです。
(図2)
「エージェント切断時間」は、端末が、MobiControlサーバから切断してからの経過時間を指します。
(図2)の横軸の単位は、時間です。 現在を0とし、過去に向かって、1時間、2時間、・・と24時間前までを表示しています。
縦軸は、端末台数です。 (図2)では、MobiControlサーバから切断して、1時間以内の端末が2台あることを示しています。
24時間以上前に切断した端末、つまり24時間以上オフラインの端末は、「不明」の棒に含まれます。 「不明」の台数が多いのは、問題です。端末一覧で、(図2)は、目立ちやすく、長期間オフラインの端末があるかどうかに、すぐ、気が付くことができます。
グラフが示す「端末プロパティ」を変更する方法は、「グラフが示す端末プロパティの変更」を参照ください。(図1)のフィルタ条件式を設定していない場合は、(図2)の「不明」に、全てのWindows Modernの端末台数が、加算されてしまいます。 Windows Modernの切断時刻を、MobiControlはログに記録していないからです。B-2. どの端末が、長期間、オフラインかを見つける
端末一覧のコラムに、「エージェント切断時間」を加えておきます。(図3)の② です。(図3)
(図3)で、コラムの「エージェント切断時間」タイトルの右端の下向き矢印を押すと、日時の若い順に、端末を並べることができます。 エージェント切断日時が古くなるほど、下の方に表示されます。オフライン時間が長い端末を、見つけやすくなります。
③ の2台の端末が、他の端末に比べて、切断してから、かなり長い期間が過ぎているのが分かります。これは、異常です。 端末ユーザにコンタクトして、端末をルート化したり、または電源をオフにしていないかなどを訊いてください。コラムに、「エージェント切断時間」タイトルを、表示する方法は、「端末一覧の端末プロパティの入れ替え」を参照ください。オフラインのAndroid端末をオンラインにする方法は、「端末のオフライン対策」を参照ください。
オンラインのAndroid端末が、MobiControlサーバにチェックインするトリガーについては、 「チェックイン。3種類のトリガー。」を参照ください。B-3. 正常なAndroid端末のイベントログ
(図4)は、正常なステータスのAndroid端末に関するイベントログです。コンソールで、「イベントログ」タブを開くと、見ることができます。(図4)
ログは、下から読みます。
端末が不正常なステータスの場合、① を最後に、ログ表示が停止されます。
- ① 何らかの理由で端末がMobiControlサーバとの接続を切断
- ② 再び端末がMobiControlサーバと接続
- ③ 接続直後のチェックイン。オフラインの間に、滞留していたオブジェクトを送受します。
- ④ 更新スケジュールの時刻になったので、チェックイン
- ⑤ 更新スケジュールの時刻になったので、チェックイン。 ④ から2時間後が、デフォルト。
C. 永らくチェックインをしてこないApple端末を見つける
C-1. グラフを見て、すぐに見つける
端末一覧の画面で、(図5)のようなフィルタ条件式を適用しておきます。 これで、端末一覧には、Apple端末しか表示されなくなります。
端末一覧の上部に表示されるグラフの1つの端末プロパティを「MDMステータス更新」にしておきます。(図6)が、それです。 「MDMステータス更新」とは、Apple端末が、MobiControlサーバに、最後にチェックインした日時です。(図5)
端末は、ロック中(スリープ中)でも、デフォルトで、2時間に1回はチェックインをします。(図6)
(図6)は、最後のチェックインから何時間経過しているかを示しています。 (図6)の横軸の単位は、時間です。 現在を0とし、1時間、2時間、・・と24時間までを表示しています。
縦軸は、端末台数です。
最後のチェックインから24時間以上経過した端末は、「不明」の棒に含まれています。端末一覧で、(図6)は、目立ちやすく、長期間チェックインしていないApple端末があるかどうかに、すぐ、気が付くことができます。
(図5)の端末フィルタ条件式を適用しておかないと、Apple端末以外の端末台数も(図6)の「不明」に加算されます。C-2. どのApple端末が、長期間、チェックインをしてこないかを見つける
端末一覧のコラムに、「MDMステータス更新」を加えておきます。(図7)の② です。(図7)
③ の端末の「MDMステータス更新」日時が、他の端末のそれに比べて、かなり古いことが分かります。 他の端末の「MDMステータス更新」の日時より55時間以上古くなっています。これは、異常です。
端末ユーザにコンタクトして、端末を脱獄(Jail break)したり、電源をオフにしていないかなどを訊いてください。
コラムに、「MDMステータス更新」タイトルを、表示する方法は、「端末一覧の端末プロパティの入れ替え」を参照ください。B-3. 正常なApple端末のイベントログ
(図8)は、正常なステータスのApple端末に関するイベントログです。コンソールで、「イベントログ」タブを開くと、見ることができます。(図8)
ログは、下から読みます。
更新スケジュールを2時間間隔にセットしてあるので、サーバは2時間毎に、チェックイン要求を送り、端末もそれに応えて、チェックインをしています。 端末のステータスが不正常な場合は、① のみが、表示され、② は、表示されません。
- ① 更新スケジュールの時刻になったので、MobiControlサーバから、端末に向けてのチェックイン要求を、APNsに中継依頼。 この時点では、チェックイン要求は、端末に届いていません。APNsと端末の間の通信が正常のときのみ、端末に届きます。
- ② 端末のMDMプロトコルの働きで、MobiControlサーバにチェックイン
D. 永らくチェックインしてこないWindows Modernエンドポイントを見つける
D-1. 正常性構成証明書の受信から、長い期間経過したエンドポイントを抽出
Windows Modernエンドポイントが、MobiControlにチェックインをすると、MobiControlサーバは、すぐに、当該エンドポイントに関する 正常性構成証明書を、取得します。その取得元は、Microsoft DHA(Device Health Attestation)サーバ、または、 オンプレミスのDHAサーバです。
従って、正常性構成証明書の取得日時は、Windows Modernのチェックイン日時の数秒後となります。 そこで、正常性構成証明書の取得日時が、チェックイン日時の近似値となります。「デバイス正常性構成証明書の項目を種別する」のページの 「K. 正常性構成証明書の取得までのスキーム」をクリックしてください。MobiControlサーバによる 正常性構成証明書の受信の仕組みが記述されています。(図9)のようなフィルタ条件式を入力すると、コンソールの端末一覧には、正常性構成証明書の最後の受信日時が、 7月22日以前であったWindows Modern エンドポイントのみを、抽出表示します。(図9)のフィルタ条件式を入力する方法を、説明します。(図9)
下記の「正常性構成証明書の最後の受信日時が指定日時以前のエンドポイントを抽出する」をクリックしてください。
(図10)
赤矢印部分にマウスを載せ、クリックします
(図11)
プルダウンメニューが現れるので、「ヘルス検証」を選択します。
(図12)
プルダウンメニューが現れるので、「最終レポート日」を選択します。
(図13)
プルダウンメニューが現れるので、「以下」を選択します。「以下」は、指定日時より、「古い」を指します。
(図14)
カレンダーが現れるので、月日を指定し、「完了」ボタンを押します。
(図15)
フィルタ条件式の完成です。 フィルタ条件式の入力が終わると、右端に、が、現れます。 これを押すと、フィルタ条件式を充たす端末群が表示されます。
ここでは、正常性構成証明書の最後の受信が、指定日時より以前であったエンドポイント群のみを、コンソールの端末一覧に抽出表示します。 「端末の詳細」タブの右下部分が、(図17)と異なり、(図16)のように表示されているエンドポイントPCがあることがあります。
(図16)
Microsoft DHAサーバは、 (図16)のように表示されているエンドポイントの正常性構成証明書を、作成できていません。
従って、MobiControlサーバも、それを受信できていません。
この場合、(図15)のようなフィルタ条件式を適用しても、当該エンドポイントは抽出表示されません。
(図16)のエンドポイントは、MobiControlサーバに、永らくチェックインしていないという問題とは、別の重大な問題を抱えています。 それは、エンドポイントの、セキュリティ脆弱性に関する情報を、入手できなくなっているからです。 一部のウィルス対策ソフトをインストールすると、それが、Microsoft DHAサーバに、セキュリティ脆弱性に関する情報を、送ることを阻止することがあります。
ウィルス対策ソフトとして、Windows Defenderを適用している場合、 これが、Microsoft DHAサーバに、セキュリティ脆弱性に関する情報送信を阻止することはありません。 正常性構成証明書の詳細に関しては、「デバイス正常性構成証明書」を参照ください。
D-2. チェックイン日時と、正常性構成証明書の受信日時の関係
(図17)は、コンソールで、個別のWindows Modern エンドポイントを選択したときに、表示される「端末の詳細」タブの右下部分です。
(図17)
(図17)の「最終レポート日」に記されている日時は、 Microsoft DHAサーバが、正常性構成証明書を作成した日時です。 (図18)は、Windows Modernの「イベントログ」タブを開いたときに表示されるログのサンプルです。エンドポイントからのチェックインの2秒後に、MobiControlサーバが、 ヘルス証明書(=正常性構成証明書)を受信したことが分かります。 従って、正常性構成証明書の最後の受信日時は、ほぼ、Windows Modernエンドポイントの最後のチェックイン日時とみなすことができます。(図18)
E. アラートメールを関係者に発信
E-1. 端末が長期間オフラインになるとアラート (Apple端末以外)
端末がオフラインになってから指定時間が、経過すると、MobiControlサーバが関係者に、その旨のアラートメールを自動発信することができます。 指定時間を、アラートルールで設定します。 (図19)は、アラートルールの設定画面です。(図19)
- (図19)の① にチェックを入れます。
- ② に、数値を入力します。単位は、「分(Minutes)」です。オフラインになってから、何分間経てば、アラートメールを発報するかを指定します。 1440は、24時間です( = 60 X 24)。2880は、48時間です。
- ③ にもチェックを入れます。③ にチェックを入れておくと、 該当のエンドポイントがオンラインになるまで、1時間に1回、アラートメールを発報します。 アラートメール発報は、1回だけでよいとする場合は、③ には、チェックを入れません。
- 「アラート文(編集可)」の文章を編集します。
デフォルトの文章: 「これまで%MINUTES%時間、端末が未接続」
編集後の文章: 「これまで、%DAYS%日間、または%MINUTES%分間、端末が未接続」
(図20)が、編集後の例です。このように編集しておくと、受信するメール本文のアラート文は
例えば、 「これまで、8.2日間、または11824分間、端末が未接続」という文章に変換されます。(図20)
(図19)での② は、(図20)では、2880 としています。つまり、48時間経過を、「しきい値」としています。適宜、変更ください。アラートルールを設定すると、(図21)で、指定した宛先に、アラートメールが送られてきます。 エンドポイントがオフラインになってから、(図19)の② で指定した分数を経過すると、送られてきます。
- (図21)で、「メールのプロファイル」や「メール宛先」を指定します。
(図21)
(図21) の表示方法は、「電子メールプロファイルの作成」を参照ください。
(図20)や(図21)の編集例の場合、次の様な本文のメールが送られてきます\\名古屋支店\企画部 の Windows73 で
これまで、8.5日間 または12184分間、端末が未接続が、2021/07/23 21:04:21 に発生。ここで、Windows73は、端末一覧での端末の名前
アラートルールの設定は、E-2. 端末が長期間チェックインしないとアラート (Apple端末)
対象端末が、Apple端末の場合、直近のチェックイン時刻から、指定時間経過すると、MobiControlサーバが関係者に、その旨のアラートメールを自動発信するようにします。 その指定時間を、アラートルールで設定します。(図22)は、Apple端末に対するアラートルールの設定画面です。(図22)の表示方法は、 「Apple端末:アラートルール」を参照ください。(図22)
(図22)の赤枠部分に、指定時間を入力ください。単位は、「分」単位です。メール宛先の指定などは、(図21)を参照ください。 その後に、「メールのプロファイル」で「メール宛先」を指定します。(図21)を参照ください。 Apple端末の場合でも、(図20)のように、切断してから経過時間をアラートイベントとすることはできます。 しかし、それよりも、直近のチェックイン時刻からの経過時間の方が、より重要なアラートイベントです。
(図23)
Apple端末のMobiControlサーバへのアクセス手段は、2本立てです。 各々で、送受するオブジェクトは、異なります。 MobiControlエージェントによる「接続」では、クリティカルなオブジェクトは送られません。 せいぜい、端末の今までの立ち寄り先の地理的位置情報(緯度経度情報)です。これは「接続」のときに、 端末からサーバへ送られます。オフラインだと、次の接続まで、端末内に保留されます。 コンソールで作成した構成プロファイルや、アプリカタログルールの展開などの重要なオブジェクトは、MDMプロトコルによる チェックインの時に端末に送られます。
アラートルールが指定した端末のアラートイベントも、MDMプロトコルによる チェックインの時に、端末からサーバに送られます。 詳しくは、「Apple端末:チェックインと接続」を参照ください。F. 「脱獄」「ルート化」されても、MobiControlエージェントが生存していたら
Android端末が「ルート化」されても、もし、MobiControlエージェントがアンインストールされなかったら、 MobiControlエージェントは、サーバに「ルート化」された旨を通報します。
iPhone、iPadが脱獄されても、もし、MobiControlエージェントがアンインストールされず、且つ、端末ユーザが、MobiControlエージェントの アイコンをタップしたら、MobiControlエージェントは、サーバに「脱獄」された旨を通報します。 端末一覧に、「OSセキュア」のグラフを掲げておきます。(図24)
(図24)のFalseの部分が、「脱獄」または「ルート化」された端末です。
本来、この端末台数はゼロになっていなければなりません。 従って、(図24)を表示しておけば、「脱獄」または「ルート化」された端末があることに、すぐ気が付きます。 (図24)のTRUE の棒は、「脱獄」されてないApple端末、及び「ルート化」されてないAndroid端末の台数を示します。 (図24)での「不明」の棒は、Android、iOS/iPad以外の端末を示します。
グラフが示す「端末プロパティ」を変更する方法は、「グラフが示す端末プロパティの変更」を参照ください。 (図24)で、「False」の棒が現れたら、(図25)のフィルタ条件式を入力します。(図25)
(図25)を入力すると、「脱獄」または「ルート化」されたとして、MobiControlエージェントが通報してきた端末のみが表示されます。 至急、端末ユーザにコンタクトしてください。 「脱獄」または「ルート化」された端末が、(図24)や(図25)で、「OSセキュア = FALSE」として表示されることは、稀れです。 それは、MobiControlエージェントもアンインストールされる可能性があるからです。
従って、「脱獄」または「ルート化」された端末の検出は、(図2)や(図6)のグラフで、 永らくオフラインの端末や、永らくチェックインしてこない端末を見つけることが、確実な方法といえます。G. びっくりマーク
(図26)をご覧ください。
端末アイコンの左側に、びっくりマーク(エクスクラメーション・マーク)が付いている場合があります。これらの端末は問題がある端末です。
(図26)
⑥の端末は、「脱獄」または「ルート化」されたが、MobiControlエージェントがアンインストールされず、 なんとか、MobiControlサーバとオンラインができている端末です。
③と④の端末は、端末ユーザによって、MobiControlへの登録が解除された端末です。
Apple端末またはAndroid端末のMobiControlサーバへの登録を、端末側操作では、解除させないようにする方法があります。iPhone/iPadがMobiControlサーバに、7日間チェックインしないと、MobiControlサーバは、「脱獄」をしたとみなして、登録解除をすることがあります。 この場合も、「UnenrolledByUser」となります。 びっくりマーク
- 端末側から登録解除をさせない方法を参照ください。
H. 更新スケジュールの時間間隔
Apple端末以外の端末は、オンラインであることを前提に、2時間に1回、MobiControlサーバにチェックインをするのが、 デフォルトです。 この時間間隔を変更するには、更新スケジュールを修正します。 更新スケジュールの設定変更は、Apple端末がオフラインであっても、更新スケジュールの時刻になると、サーバは、APNs経由で、端末にチェックイン要求を出します。 端末が正常なら、例え、オフライン状態でも、すぐにチェックインをしてきます。 更新スケジュールの変更を考慮しなければならないケースは、次の通りです。
- 更新スケジュールの設定変更を参照ください。
- 端末で発生したアラートイベントを、なるべく早く、サーバに通知したい。例えば、ウィルス検知アラートなど
- データ収集ルールで指定した端末のステータスデータを、なるべく早く、サーバに通知したい
例えば、端末のIPアドレスの変化に応じて、端末が所属する端末グループを変更する。
