365皆さんいかがお過ごしでしょうか?Miyaです。10のデバイス登録について色々と試行しておりました。本記事は筆者のその経験をベースに構成方法を紹介したいと思います。構成方法をメインに取り上げておりますので、中身の動作などについては次の記事でご紹介したいと思います。条件付きアクセスによるアクセス制限を可能にする画期的なソリューションです。Directoryにドメイン参加させることが一般的でした。Directoryにドメイン参加させることで、KerberosのTGT・STによって資格情報を入力することなく社内リソースにアクセスすることが出来ました。その他にもグループポリシーを使った社用端末をガチガチに制御することも出来るのが特徴です。Directoryはドメイン(レルム)内でしかメリットを活かすことが出来ず、クラウドアプリケーションが普及する現代において、活躍するシナリオはお世辞にも多いと言えませんでした。DirectoryのTGT、STは利用出来ません。FSやサードパーティのIdPとフェデレーション(SAML,WS-Federation)構成を取る必要がありましたね。ADに参加させることで、以下のような恩恵を授かることが出来ます。Directoryを利用しているケースが多いですね。Directoryを導入している組織では検討対象にすらなりませんでした。従来のKerberos認証を活かしつつ、クラウドアプリケーションにもSSO出来るといういいとこ取りなソリューションです。ADの両方にデバイスを参加させることで、両者のメリットを活かす新しいデバイス参加の方式。10での構成方法を取り扱います。構成にはAADConnectによってディレクトリ同期・パススルー認証がセットアップ済みであることを前提としています。Joinを構成するにあたり、前提条件と要件を確認しておきましょう。7)は「ダウンレベルのWindows」と呼ばれています。Connect)の準備をしていきましょう。Connectでモジュールのインストールが発生しますが、作業による再起動は発生しません。Directoryにドメイン参加することで生成されるComputerオブジェクトを、AADConnectで同期することで成立します。AADConnectの同期対象OUにComputerオブジェクトを放り込む必要があります。Bookさんをドメイン参加させ、同期対象OUに移動しておきました。ADにComputerオブジェクトが同期されることはありません。後に説明しますがuserCertificateに値がセットされることで同期が開始されます。DSツールとMSOnlineモジュール(ver1.1.166.0~)をインストールしておく必要があります。DSツールをインストールしておきましょう。Intuneのライセンスを付与しておきます。ADのポータル画面(https://portal.azure.com)へアクセス、テナント管理者のアカウントでログインします。Intuneを選択します。MDMユーザースコープを[すべて]に設定し、[保存]します。[一部]を選択し、特定のグループオブジェクトを選択することで、スコープを限定的にすることが可能です。以上でMDMの構成は完了です。Intuneライセンスをユーザーに割り当てます。Directory]メニューから、目的のユーザーを選択し、[ライセンス]メニューからライセンスを割り当てます。DRS)のサービスエンドポイントを探すために、下記の接続名を名前解決します。DRSエンドポイントに到達するよう、CNAMEレコードを外部/内部DNSに追加します。Point(SCP)を構成します。使用して以下の場所から確認することが可能です。JAPANAADConnectサーバーにサインインし、PowerShellから下記コマンドを実行します。name]にはEnterpriseAdminsの権限(多分)を持ったアカウントで構成してあげると上手くいきます。Complete」と表示されていれば成功です。念のために、下記コマンドを実行し、SCPオブジェクトが正しく構成されているかを確認しておきましょう。Configuration,CN=Services,CN=Configuration,DC=fabrikam,DC=com";$scp.Keywords;AzureADNameに接続先テナント名、AzureADIdに接続先テナントのGUIDが表示されていることを確認してください。以上で、SCPオブジェクトの生成が完了しました。Joinするための準備は整ったので、次にグループポリシーで自動的にデバイス登録、MDM登録するように構成してあげましょう。ADにデバイス登録するよう、グループポリシーを構成します。Directoryにインポートしておきましょう。オブジェクト(GPO)を作成します。[編集]で、グループポリシー管理エディターを開きます。[デバイスの登録]から、[ドメインに参加しているコンピューターをデバイスとして登録する]を[有効]で構成します。登録]を[有効]で構成します。グループポリシー管理エディターを×閉じ、構成したGPOを同期対象のComputerオブジェクトが含まれるOUにリンクします。以上で、グループポリシーの構成は完了です。Joinの準備は整いましたので、早速クライアントを立ち上げ挙動を確認していきます。Join・MDM登録のプロセスが開始されます。いずれもタスクスケジューラーで構成されており、利用者の操作は不要です。Join、MDM登録それぞれ少し時間が掛かるので気長に待ちましょう。Join)、MDM登録をバックグラウンドで行います。BookさんのComputerオブジェクトを確認します。属性エディターからuserCertificateを確認すると、キー情報がセットされていることが確認できます。AD側で保管され、ユーザー/デバイス情報にマッピングします。(この辺りのプロセスについては次の記事で解説します。BookのComputerオブジェクトがAzureAD方向にエクスポートされていることが確認できます。Bookが同期されていることが確認出来ます。Joinであるということが分かります。MDM登録が完了していませんが、(Sign-out/Sign-in)して、しばらく待つと、正常に構成されていることが確認出来ました。ADとの同期状態を確認、レポーティングすることが可能です。試しにOffice365へアクセスすると、アカウント名/パスワード入力なしでサインインされることが確認出来ました。参加済みのデバイスが必要]を構成することが出来ます。Joinしているデバイスに限定するPolicyを作成し、ユーザーに割り当てました。Joinのデバイスであればアクセス出来ることが確認できました。Join、MDM登録が上手くいかない場合、イベントビューワーなどを確認するとよいでしょう。登録に失敗しました(致命的なエラーです)」が出続け、中々MDM登録されませんでした。DRSのエンドポイントを名前解決出来ておらず、それっきりになっていたので、内部DNSにCNAMEを構成することで上手く動作しました。/statusコマンドを実行することで、デバイスの登録状態が出力されます。StateセクションのAzureAdprtの値がNull、もしくはNOである場合、SSOするためのPRTが取得・キャッシュできていないことが分かります。これ関係のトラブルシューティングについての情報は、インターネットで検索すると結構ヒットするのでトラシューしやすいかと。おわりにいかがでしたでしょうか?特に複雑な手順もなく構成できました。FS環境の場合、クレーム辺りを触る必要がありますが...)IntuneによるMDM管理などを行うにあたって、こういったセットアップがユーザーの操作なしで構成できるのは管理者としても有り難い話ですね。今後も機能Updateによってより便利な使い方が出来ることを期待しています。2017.12.032017年11月30日にAzureクラシックポータルが閉鎖されました。コメントをキャンセルメールアドレスが公開されることはありません。date*日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)プロフィールこんにちは、Miya(@miya_microsoft)です。高校~大学では情報科学部としてプログラミングを学び、SEとして某Sierに入社しました。Microsoftプロダクトをメインに設計から構築までを担当しております。本ブログは筆者の業務範囲の中で得た学びをより深めることと、その情報が皆さまのお役に立てればという思いから設立しました。キャンセル投稿を送信できませんでした。メールアドレスを確認してください。メール送信チェックに失敗しました。このブログではメールでの投稿共有はできません。