どうも！コーポレートIT部 IT企画推進課の小川敬三です。
ID管理クエスト第2話は、Intune導入について語りたいと思います。

前回、ゼロトラストのセキュリティモデルをベースとし、ハイブリックワーク環境を実現するクラウドシフトの青写真を描いたところまでをお話しました。
その中核を成すID管理基盤には、EntraID（当時はAzureAD※）を採用し、EntraIDを中心にMDMのサービスを決定、環境構築をしていくことになります。
※ここではEntraIDではなく当時の名称であったAzureADと表記します。

なぜ、Intuneか？

以前のMDMサーバはオンプレミス（正確にはAWS EC2ですが、弊社ではオンプレミスと同義で捉えています）で構築していたため、社内LANに端末を接続しなければ、情報のアップデートやデバイス設定の追加・変更を行うことができませんでした。世はコロナ禍だったため、これではMDMの意味がなく、早急にリモートでのデバイス管理を実現する必要がありました。そのため、次期MDMの要件の1つとしてクラウドサービスである必要がありました。

次に、デバイス管理はそのOSと親和性の高いサービスの方ができることが多いと考えました。当時の端末制御は、ADのグループポリシーで行っていたため、これらを代替できるサービスであることが2つ目の要件でした。

最後にAzureADをID管理基盤とし、ゼロトラストの環境構築を進める計画だったため、AzureADとシームレスに連携できるサービスが必要でした。
結果、自ずとIntuneを選択するに至ったわけです。

余談ですが、MacやiPhone、iPadも同じで、これらApple製品の管理には、それらOSと親和性の高いJamf Proを採用しました。

参考に当時の新旧MDMの機能・コスト比較の一部抜粋を載せておきます。あくまで当社における判定であり、価格もおおよその情報であることにご留意ください。

Intune導入までの道のり

検証期間を含めて2021年1月末から3月末の約2ヶ月間のスケジュールでIntune導入を計画し、段取りは次のように考えていました。

  1. カスタムドメインの登録
  2. AzureADコネクターでのADとAzureADの連携
  3. Intuneのライセンス付与
  4. AzureAD登録からIntuneへの自動デバイス登録

将来的にはAzureADによるSSOと条件付アクセスの導入を前提にしているためMicrosoftから初期に割り当てられる「onmicrosoft.com」の初期ドメインではなく当社のコーポレートドメインをカスタムドメインとして登録する必要がありました。

また、リモートによるデバイス管理の環境構築が最優先だったため、いきなりEntraID Joinedの環境に切り替えるのではなく、一旦Hybrid Azure AD Joinedの環境で進めることにしました。

このステップを進めていく上で、3度の大きな壁にぶつかることになります。同じようにハマるポイントかもしれませんので、以下ご参考になれば幸いです。

カスタムドメインを追加できない

1つ目の壁は、弊社が契約しているMicrosoft365管理センターにコーポレートドメインをカスタムドメインとして追加しようとしたところ、既に他のテナントで使用されているという理由から追加することができませんでした。

原因
カスタムドメインを追加できない原因は、PowerBIやOffice365（Teams）を利用するために、弊社社員がコーポレートドメインのメールアドレスでフリー版のユーザ登録を行っていたのですが、そのタイミングで、社員も知らない内にコーポレートドメインを使用した別のMicrosoft365のテナントが作成されてしまっていたことにありました。

対応
PowerBIやOffice365（Teams）を利用しているユーザーには事情を説明し、会社契約のアカウントでの利用に移行してもらいました。移行が完了後、意図せず作成されてしまったテナントを削除することで、無事にカスタムドメインを登録することができました。

仕組み上致し方ない部分もあるのでしょうが、このような仕様はコーポレートIT泣かせですね。
とはいえ、無事、カスタムドメインの登録ができたので、次はAuzreADコネクトの導入に進むことができます。

Intuneに自動でデバイス登録されない

無事、AzureADコネクタの導入が完了し、Intuneのライセンス割当も完了しました。ところが、AzureADからIntuneにデバイスが自動登録ができません。下図のような流れを想定していたのですが、AzureAD登録した後の自動デバイス登録が正常に行われなかったのです。これが2つ目の壁です。

原因
なぜ、自動登録されないのか？この理由は単純明快で、自動登録に必要なライセンスがなかったためです。自動登録するための要件はいくつかありますが、その1つにAzureAD P1ライセンスが必要であり、この要件を見逃してしまっていました。

対応
これは調査不足としか言えないので猛省ですが、しかし、Microsoftのライセンス体系は少々複雑なのでシンプルにしてほしいという他責に似た気持ちが湧いてきたのは否定しません。
この時はデバイスの自動登録は諦め、手動登録で対応することにしました。

デバイスの登録状態がおかしい

デバイス登録は手動で進めることにしましたが、登録を進める中でどうもAzureADやIntune上のデバイスの登録状態がすっきりとしません。AzureAD上では主に次の2パターンの登録状態に陥りました。これが3つ目の壁です。

おかしい状態パターン1
端末Aが2行登録され、上はAzure AD registerdで、AzureADとIntuneの情報が正常に紐づいているが、下はHybrid Azure AD joinedでの端末登録されているがIntuneと情報が紐づいていない

おかしい状態パターン2
端末Bが2行登録され、上は結合の種類も所有者も正常に登録されておらず、下は所有者とMDMが正常に登録されていない、どちらもなんとも言えない中途半端な登録状態

2つのおかしい登録状態になりましたが、当初期待していた正しい状態は、パターン1の端末A（上）の登録状態でした。では、なぜ、このような歪な登録状態になってしまったのか…？

原因
まず、パターン1では、Hybrid Azure AD Joinedでのデバイス登録は不要なものでした。この登録ができてしまっていた理由は、AzureADコネクタの連携対象にADのComputersを含めてしまっていたことでした。
次にパターン2は、正常に登録されている端末もあったため、当初はデバイス登録の作業手順に問題があると考えていました。原因は、手順の問題ではなく、OSのバージョンにありました。Windows10（1809）よりHybrid AzureAD JoinedとAzureAD Registerdの二重登録を防ぐための機能が追加されていたのです。
つまり、パターン1のようにHybrid Azure AD Joinedで登録された端末は、後から手動でデバイス登録をしても正常にAzureAD Registeredできなかったということになります。一部正常に登録できていた端末はOSのバージョンが古かった可能性があり、OSのバージョンが高かった端末は失敗していたと思われます。

対応
調査に掛けられる時間はあまりなく、当初の目的であるリモートでのデバイス管理は、Intuneへのデバイス登録が成功していれば実現できるため、AzureAD上の登録状態には目を瞑り、Intune上に正常にデバイス登録ができていれば良しとしました。
最終的にHybrid AzureAD Joinedではなく、AzureAD Joinedの環境に切り替え、デバイスの自動登録が可能なAzureAD P1ライセンスも購入し、今はおかしい状態の端末登録はなく、すっきり綺麗な状態になっています。

AzureAD、Intuneの仕様を十分に理解できておらず、苦労していた記憶があります。ドキュメントの調査と読み込み、そして理解は本当に大事なことだと痛感しました。また、当時は、AzureAD、Intuneもサービスとしての過渡期で、AzureADはEntraIDに、IntuneはEndpoint Managerと名前が変わったりと、何かと変更が多い時期でもあり、それに翻弄されてしまっていたかもしれません。

少々長くなってしまいましたが、第2話はこれで閉話となります。
当時の記憶を思い出しながら書いているので多少事実と異なる点があるかもしれませんが、ご容赦ください。次回は、EntraID Joinedに切り替える話です。お楽しみに！

今回もこの場を借りて、IT企画推進課ではイルグルムグループの社内ITインフラ環境を一緒に支えてくれる仲間を募集しています。ITを通して経営課題に挑戦してみたい！という熱意のある方のご応募をお待ちしております！
※募集は、ブログ執筆（2025.4.9）時点となりますので、応募を締め切っている場合はご了承ください。