皆さんこんにちは。国井です。
Office 365を導入されるお客様で、シングルサインオンも一緒に導入したいと考えるお客様は最近増えてきているように思います。と同時に、お客様からよくご相談を受けるのが「特定のデバイスからのアクセスを制限したい」ということです。
当ブログでは何回かに渡って、このテーマはお話ししていますが、ざっくり言うと、
Windows 8.1の時代にはAzure ADまたはADFSを利用したデバイス登録(DRS)と、
登録されたデバイス情報に基づくADFSサーバーによるデバイス認証機能を利用することで要件を満たしてきました。
(下の図はAzure ADを利用したDRSの仕組み)
つまり、「特定のデバイスからのアクセスを制限したい」というニーズを満たすためには、
・DRSという機能で、事前にデバイスを登録 (Azure ADまたはADFSで登録)
・デバイス認証の機能でアクセス可否を決定 (ADFSで設定)
の2つを行う必要があるのです。
このうち、今日はAzure ADでのデバイス登録の話をします。
Azure ADでのデバイス登録方法とその結果の確認方法は過去のポストでも紹介しましたが、
Azure ADからデバイス登録を行うと、デバイス登録の結果はAzure管理ポータルから確認できます。
しかし、この画面、ユーザーごとにしかデバイスの登録状況を確認できません。
しかも、デバイス登録と登録解除を繰り返すと、過去に登録されたデバイス情報が残り続けるので、ゴミが溜まっていくシステムなのです。
Azure Active Directory PowerShellモジュールの活用
そんな折、最近マイクロソフトではAzure ADをPowerShellで操作するツールの新しいバージョンをリリースしました。
Azure AD PowerShellモジュールはADAL対応により、多要素認証が利用できるようになったことがクローズアップされていますが、私が注目したいのはPowerShellコマンドレットで、Azure ADに登録されたデバイスの管理ができるようになった点です。
新しいAzure AD PowerShell モジュールでは、
Get-MSOLDeviceを使えばAzure ADに登録されているデバイスの一覧表示、
Enable-MSOLDeviceを使えばAzure ADに登録されているデバイスの有効化、
Disable-MSOLDeviceを使えばAzure ADに登録されているデバイスのブロック、
Remove-MSOLDeviceを使えばAzure ADに登録されているデバイスの削除、
をそれぞれ設定できます。
実際に利用してみた様子がこちら。
Get-MsolDevice –Allを実行すると、Azure ADに登録されている、すべてのデバイス情報が一覧で確認できます。単純にGet-MsolDevice –Allと実行してしまうと、リスト形式で表示されてしまい、見にくいので、Get-MsolDevice –All | Ft Displayname, DeviceIdなどと実行すると、見やすく整形してくれていいのと思います。その中から、特定のデバイスだけ取り出して詳細な情報を見たければ、Get-MsolDevice –DeviceId <デバイスID番号>と実行すれば、上の画面のように表示してくれます。ちなみに、Enabled:Trueというところがデバイスの有効化/ブロックに関わるステータス、RegisteredOwnersというところが、デバイスを登録したユーザーの情報です。
では、続いてデバイスの有効化/ブロックを行ってみます。
Disable-MsolDevice –DeviceId <デバイスID> -Forceを実行すると、そのデバイスはブロックの設定になります。
この情報はディレクトリ同期ツールによって、Active Directoryに送られ、ADFSサーバーでアクセス可否を決定するときの材料として利用されるようになります。
特定のユーザーが不正アクセスに遭ったので、そのユーザーのデバイスをとりあえず全部使えないようにしたいということであれば、
Get-MsolDevice –RegisteredOwnerUpn <ユーザーのUPN> |Disable-MsolDevice –Forceを実行すると、すべてのデバイスがブロックされます。
それから削除について。
デバイス登録と登録解除を繰り返すと、ゴミが残るといいましたが、これもGet-MsolDeviceで発見して、Remove-MsolDeviceで削除すればいいのです。
Get-MsolDevice –RegisteredOwnerUpn <ユーザーのUPN>| Ft Displayname, DeviceId,ApproximateLastLogonTimestampと実行し、タイムスタンプが古いものを見つけてきて、Remove-MsolDeviceで削除しています。
(ApproximateLastLogonTimestamp属性はサインインの日時ではないようなのですが、詳細はわかりません。。)
いかがですか?Azure管理ポータルから操作するよりも、まとめて操作しやすい環境が整ったと思いませんか?
(本当はAzure ADだけでデバイス認証もできるようになってくれると、もっとうれしいんだけど)
■ ■ ■
今日の最後のトピックは、「Windows 10デバイスはWindows8.1と同じようにデバイス認証ができるか?」という点です。
まず、結論から先に言うと、私が検証している限りでは、ADFSのデバイス認証でWindows10のアクセス制御ができないようです。
(このことについては山市さんのブログでも紹介されています)
簡単に引っかかっているポイントをお話しすると、
ADFSのデバイス認証では、ADFSサーバーがトークンを発行するタイミングで
ユーザーがあらかじめ登録されたデバイスからアクセスしているかをチェックし、
登録されたデバイスからのアクセスであれば、isRegisteredUserというクレームにTrueという値を入れ、
そしてisRegisteredUser=TrueならADFSとしてトークンを発行することを許可しましょう(アクセスを許可しましょう)、という流れです。
実際に、このとおりの動きになるのか見てみると、Windows 8.1ではisRegisteredUser=Trueというクレームが発行されるのですが、
Windows 10ではisRegisteredUserクレーム自体、全く発行されません。
デバイス登録自体は問題なくできているし、登録されたデバイス情報のディレクトリ同期もWindows8.1を同じ情報を同期できているので(下記、おまけ参考)、ADFSサーバー側の処理の問題でWindows10にisRegisteredUserクレームが発行されず、デバイス認証がうまく動作しないようです。
結構これってニーズが高いので、何か回避策を早いところ見つけたいものですね。
■ ■ ■
おまけ – Azure ADのDRSで登録されたデバイスはADにどのような属性が同期されるか?
Windows 10デバイスがADFSでデバイス認証できないのはディレクトリ同期で同期される属性に違いがあるからなのかと思い、
ディレクトリ同期の結果をチェックしてみた結果は以下のとおりです。結果は「違いなし」です。
■Windows 10デバイス(Azure AD参加済み)をAzure AD から同期した時の結果
■Windows 8.1デバイス(ドメイン参加済み+Workplace Join)をAzure AD から同期した時の結果
■Windows 8.1デバイス(ワークグループ+Workplace Join)をAzure AD から同期した時の結果
ドメイン参加しているPCの場合、isManaged=Trueになるという結果以外は、OS種類による違いは特にないようです。