Workspace ONE UEM の管理者権限をうまく絞る

最終更新日

Workspace ONE UEM には、デバイスを使う通常のユーザーとは別に、UEM の管理コンソールにログインし、運用管理を行う管理者がいます。管理者はそれぞれロールを持ち、デフォルトではおおよそすべての操作ができるConsole Administrator というロールを持つ管理者が作成されています。基本的な操作はこのデフォルトの管理者から行えばよいのですが、運用を複数人で担当するなどのケースで管理者を複数追加したい時があります。その際、Console Administrator ロールでは強すぎるため、ロールを調整して特定の操作に限定させることで操作ミスなどのリスクを減らすことができます。

幸い、Workspace ONE UEM の場合、非常に柔軟に管理者のロールを指定できます。

参考:管理者ロールに設定できる権限一覧

……柔軟すぎるがゆえに数がとても多く、これを一から作り上げるのは中々しんどいです。

ということで、デフォルトのロールがいくつかあります。たとえばRead Only というロールでは、その名の通りUEM の編集権限は与えず、あくまでもコンソールからすべてのリソースを読み取るだけのロールであり、中身を見ればわかりますが、UEM の各リソースのRead 権限が与えられています。

いくつかのリソースにはRead のチェックが入っていませんが、これはEdit 権限しかないためです。

他にも、例えばReport Viewer はレポート機能に特化したロールで、レポートの出力などの操作はできるのですが、デバイスのワイプなどはできません。

こんな感じでいくつかのデフォルトのロールが用意されているものの、数は結構少ないです。デフォルトで要件を満たさない場合は作り込む必要があるのですが、その場合は既存で定義済みのデフォルトロールをベースにしていきます。つまり、UEM にはロールのコピー機能があるのですが、まずはデフォルトロールをコピーし、そこから調整をしていくのがよさそうです。調整の際には、役割同士の比較機能(どのリソースにチェックが入っているか、入っていないかを比較)もあるので、うまく活用しましょう。

さて、今回のメイントピックはここからなのですが、実はこの調整も一苦労だったりします。実際に遭遇したのですが、デバイスのワイプだけを許可したロールを作りたい、という要望を例に、役割の調整を考えてみましょう。

まずは安直に、どのリソースに対して権限を与えるべきかを調べるために、「wipe」 で検索してみましょう。

こういう場合英語UI にした方が楽です。

ワイプ関連のリソースがいくつか出てきたので、すべてにEdit 権限を与えます。まずはこれで試してみましょう。作ったロールを任意の管理者に割り当てて、コンソールにログインします。

ダメなようです。

デバイスのワイプの操作を思い出してください。デバイスのリストビューから、デバイスを選択し、ワイプをする流れでした。上記画面ではそもそもデバイスのリストが見えていませんので、ワイプの画面にすらたどり着けていません。

したがって、楽をするなら、Read Only ロールをコピーして、そこをベースにワイプの権限を与えるのがよさそうです。が、今回はあえていばらの道を進みましょう。

デバイスのリスト表示の読み取り権限を与えてみましょう。リソースの探し方のコツとしては、ある程度カテゴリ分けされているので、それで判断するか、あとは例えばデバイスのリスト画面にアクセスしたときのURL ***/AirWatch/#/Device/List から判断していくと良いでしょう。

確認します。
個人情報を多く含んでいたのでマスクしている部分が多いことはご容赦ください。

画像からは分かりづらいですが、デバイスをクリックできません。クリックできないと、デバイス詳細画面に遷移せず、ワイプの操作もできません。詳細を見る権限を見つけます。Device Details → General にそれっぽいリソースがあるのでチェックを入れます。Description を読んで判断しますが、いかんせんよく分からない場合も多いので、ある程度試行錯誤で調整していきます。もしくは、Read なのでそれほど影響はないだろうと判断してチェックを多めに入れるのも一つの手です。

ようやくこれでデバイスの画面に行けました。ワイプを試してみます。

……PIN 入力画面でスタックします。PIN 自体は適切で、画面としてもSuccessful と出ているのにもかかわらず、ワイプができません。どうやらまだ権限が足りないようです。お手上げです。

最後の手段として、Chrome のデベロッパーツールを使います。

もう一度、デバイスワイプを試しますが、今度はChrome のデベロッパーツールを起動し、クライアントからのAPI リクエストをトラッキングします。

すると、ConfirmSecurityPin の後にAdd というPOST リクエストが投げられていることが分かります。

このリクエストURL に注目してください。***/AirWatch/DeviceNotes/Action/Add 、すなわち、ノートの操作が入っています。これは、デバイスワイプの時に入力したノートを指します。その後AccessDenied となっていることから、ノート周りの権限が不足しているのではないか?と推測できます。

まさかお前に権限が必要とは思わなかった……

note で検索し、該当のリソースのEdit 権限を与えればOK です。

Add Note だけでいいと思いますが、念のため。

これで、無事デバイスワイプができるようになりました。

まとめ

役割の調整の際には下記手順に従うと良いと思います。

  1. デフォルトのロールで代替可能かをまずは確認
  2. 代替できない場合、ReadOnly ロールをコピーして新規ロールを作成
  3. 追加で必要な権限を、リソース名、リソースの説明、URL などから検索してあたりをつけてチェックを入れる
  4. 試してみて、ダメだったら再度調整。その際にはChrome デベロッパーツールが有効になる場合がある。

なお、役割の調整中に、権限の設定は正しいにもかかわらず、謎のドアに操作をブロックされる事象がたまに発生します。この場合、Console Administrator を持つ管理者アカウントで一度ログインして、操作できることを確認した後に再度対象のユーザーでログインするとうまくいくようです。もしくは、対象のユーザーに一時的にConsole Administrator ロールを与えて同様にドアが開くことを確認してもよいです。

baba

無職です。 投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。と思いましたが現在どこにも所属してないので好き放題書きます。