EUC Man

Workspace ONE UEMの比較的最近のバージョンアップにより、順守ポリシーのルールで「 [デバイス] タグ 」というものが選択できるようになりました。 順守ポリシーといえば、各OSごとに予め定義されたルールの中から目的のものを選択し、デバイスが望ましくない状態になった場合に「 非順守状態 」としたり、何らかのアクションを実行することができる機能ですが、この「 [デバイス] タグ 」ルールが追加されたことによって、順守ポリシーの使い方の幅がかなり広がったと思います。 今回は、Windows10デバイスの特定の設定値が変更されたことを検知してデバイスを非順守状態にするということを試してみたいと思います。 大まかな流れは以下の通りです。      1．タグと順守ポリシーの作成     2 ．センサーの作成     3 ．Intelligenceワークフローの作成     4 ．動作確認 1．タグと順守ポリシーの作成 まずは順守ポリシーの判定に使用するためのタグを作成して、そのタグが付与されているデバイスを非順守とする順守ポリシーを作成します。 「すべての設定>デバイスとユーザー>高度な設定>タグ」をクリック後「タグを作成」をクリックします。 適当な名前を入力して「保存」をクリックします。 ここでは「Compliance-Test」としましたが、名前はなんでも構いません。 次は順守ポリシーの作成です。 デバイス>順守ポリシー>リスト表示をクリック後、「追加」をクリックします。 今回はWindowsで動作確認するため「Windows」をクリックします。 プラットフォームは「Windowsデスクトップ」をクリックします。 順守ポリシーの[1 ルール]の画面で「[デバイス]タグ」を選択し、右の入力画面で先ほど作成したタグを選択します。 [2 アクション]の画面では、「非順守としてマーク」にチェックを入れ、今回は管理者に通知としておきます。割り当てや概要は適当に設定して、アクティブ化します。 2．センサーの作成 今回は「PCにリモートデスクトップ接続でログインすることを許可しない」というケースを想定して、リモートデスクトップ接続が有効化されていたら順守違反状態にする、ということをしてみます。 そのため、リモートデスクトップ接続の設定が保存され

WS1 Accessに新しい認証方法が追加されました。 https://docs.vmware.com/en/VMware-Workspace-ONE-Access/services/rn/vmware-workspace-one-access-release-notes/index.html 「User Choice of Authentication」というもので、簡単に言うとWS1 Accessにログインするときの認証時にユーザー自身で認証方法を選択することができるという機能です。 利用イメージとして、WS1 Accessの認証時に①パスワード認証（知識要素）＋②OTP認証（所有要素）を要求する構成としたときに、②OTP認証の方を選択方式にして、管理者が許可した方式であればどれを利用してもいいよ、といった形でユーザーが利用しやすい認証方法を選択することができるようになります。 今回は、まず選択式認証の設定方法を確認して、例として「パスワード認証＋OTP認証」の構成で認証子アプリケーションを使用してログインするということを試してみます。 大まかな流れは以下の通りです。      1．Workspace ONE Accessの認証ポリシーの設定     2 ．動作確認 1．Workspace ONE Accessの認証ポリシーの設定 WS1 Accessにログインして[統合]>[認証方法]をクリックして認証方法の一覧を見てみますが、特に認証方法の設定に「選択式認証」といった設定があるわけではなさそうです。 どうやらポリシー設定内で完結する設定のようなので[リソース]>[ポリシー]をクリック後、ポリシーにチェックを入れて[編集]をクリックします。 設定方法はシンプルで、1つ目の認証方法(今回は「パスワード(クラウドデプロイ)」)を設定後、[ 認証の追加 ]をクリックすると[ および ]という形で追加の認証方法を定義できるようになるので、その後[ 追加 ]をクリックして認証方法を並べていくことで、[ または ]でつなげられたいずれかの方法を認証時に選択することができるようになるという具合です。 一通り設定し終わったら[ 保存 ]をクリックします。 【補足】 [ および ]で認証方法を複数にすることは以前からできましたが、[ または ]を定義できるようになっ

  WS1 IntelligenceはWS1 UEMとの連携設定をすることでアクション（アプリのインストールなど）を実行することができます。 プリセットされたものでも様々なアクションを実行することができるのですが、今回はカスタムコネクタを利用することで、標準では用意されていないWS1 UEMのアクションを実行してみます。 今回は例として「デバイスログを要求」というアクションをIntelligenceから実行します。 大まかな流れは以下の通りです。      1．UEM管理コンソール上の操作を実行するAPIの調査      2．Postman Collectionの作成     3 ．Intelligenceでカスタムコネクタを作成     4 ．動作確認 1．UEM管理コンソール上の操作を実行するAPIの調査 IntelligenceからUEMのAPIを実行するにあたり、そもそもUEMで目的の処理をするためのAPIが存在するかどうかを調査し、テスト実行するところまでを行います。 まずはUEMの管理コンソールのGUI上で実行する場合の該当箇所を探します。 デバイス詳細画面で「その他のアクション」>「デバイスログを要求」が今回実行する操作なので、これをAPIで実行することができるかを確認します。 WS1 UEMで実行できるAPIは以下のURLにアクセスして確認します。 ※XXXXの部分は環境によって異なるので、利用する環境の値に置き換えます。 URL：https://asXXXX.awmdm.com/api/help 今回実行したい操作は以下赤枠内にありました。 認証情報などをセットして「Try it out!」をクリックするとAPIのテスト実行ができます。 するとAPIを実行するためのCurlコマンドが生成されますので、これをPostmanにインポートすることでAPIコールを一から作成する手間が省けるのでコピーしておきます。 2．Postman Collectionの作成 Intelligenceのカスタムコネクタを設定する際、連携先となるサービスのAPIをテスト的に実行したりする必要があるため、Postmanとは仲良くしておくといいことがあります。 Postmanを起動し、「File」>「Import」をクリックします。 Import画面で「Raw te