ADFSでデバイス認証を実装

Windows Server 2012 R2のADFSからトークンを発行するときに、デバイス認証を同時に行うことができるようになりました。これにより、Office 365にアクセスするときに、特定のデバイスからのみアクセスを許可する、などの実装が可能になっています。

ADFSサーバーによるデバイス認証の処理を分解すると、こんな感じの処理をしていたわけです。

image

このとき、ADFSサーバーが提供するデバイス認証機能をDevice Registration Services(DRS:デバイス認証サービス)クライアント側からデバイス認証のために行う、事前デバイス登録機能をWorkplace Joinと呼んでいたりするわけです。

そして、DRSを使ってiOSのデバイス認証を行う方法については「Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする」シリーズで解説をさせていただきました。

便利な世の中になったなあ、なんて思っていたら、今度はAzure Active Directory(Azure AD)でWorkplace Join機能を新しくサポートするようになり、さらに私たちのデバイス認証機能に幅が広がってきました。

そこで、今回はAzure ADのWorkplace Join機能について、見てみたいと思います。

■ ■ ■

2014年7月8日追記
Azure ADのWorkplace Join機能では、デバイス登録の部分だけをAzure ADが担当し、
デバイス認証そのものは、引き続きADFSサーバーで行うようです。

Azure ADのWorkplace Join機能はデバイス認証だけをAzure ADで行い、ユーザー認証部分は引き続きADFSサーバーで行うというものです。

image

(ちなみに、この図は現状の動作から私が動きを推測して書いているものであり、オフィシャルなアナウンスがある前に作っているものです。ですのでオフィシャルなアナウンス後に間違っていることが発覚するかもしれません。そのときは、どうぞお気軽にご指摘ください)

このような実装方法を選択できるようになって、何がうれしいか?というのを私なりに考えてみたところ、次の結論にたどり着きました。

ADFSサーバーにデバイス登録するために、Workplace Joinを利用するには、enterpriseregistration.<ドメイン名>という名前がSubject Alternative Name (SANs) に含まれる証明書を用意する必要があったため、証明書取得の敷居が高いという課題がありました。

image

それに対して、Azure ADにデバイス登録する場合、Workplace Joinで接続するFQDNはenterpriseregistration.<ドメイン名>で変わらないのですが、enterpriseregistration.<ドメイン名>でアクセスする先はADFSサーバーではなく、Azure ADホストなので、対応する証明書を用意する必要がない、というメリットがあります。

image

Office 365とADFSサーバーでシングルサインオンを実装している組織にとって、デバイス認証を有効にするために、SANs入りの証明書を改めて取得しなければならないのは面倒です。その意味で、証明書のとり直しをしないでデバイス認証機能が利用できるAzure ADのWorkplace Join/DRS機能は意味のあることではないかと考えています。

■ ■ ■

ではメリットも確認できたところで、実装方法を確認してみましょう。
ここの手順はマイクロソフトのサイト、Azure Device Registration Serviceを参考にしています。

まずは前提条件と実装全体の流れから。

・前提条件
1.Azure ADテナントの用意
2.Active Directoryドメインコントローラー
3.ADFSサーバー
4.Webアプリケーションプロキシ
5.ディレクトリ同期ツールをオンプレミスのサーバーにインストールし、Azure ADと同期できている状態

ADFSサーバーとWebアプリケーションプロキシを用意するところを除いては、
Office365のシングルサインオン環境を既にお持ちの組織にとっては特別な要件はないことが分かると思います。


・実装全体のながれ
1.Azure ADをAzure管理ポータルに登録
2.Azure管理ポータルからAzure ADのWorkplace Joinを有効にする
3.DNSサーバーにレコードを登録
4.Device Registration Servicesの有効化
5.Active Directoryへのデバイス登録の許可
6.クライアントからデバイスを登録

では、順番に確認します。

1.Azure ADをAzure管理ポータルに登録

この手順は、色々なところで紹介されているので、そちらをご覧ください。

・参考サイト
Windows Azure Active Directoryのアプリケーション連携」
の「Windows Azure Active Directoryテナントを作成する」の項

2.Azure管理ポータルからAzure ADのWorkplace Joinを有効にする

Azure管理ポータルから、Azure ADテナントを開き、[構成]タブの中に[ENABLE WORKPLACE JOIN]があります。これを[はい]に設定します。

image

設定できたら、保存しておきましょう。
(上の図ではMultiFactor Authenticationを有効にしていますが、
話をシンプルにするために、ここでは結局無効にしました)

3.DNSサーバーにレコードを登録

Workplace JoinでDRSにアクセスするとき、
EnterpriseRegistration.<ドメイン名>というFQDNにアクセスします。

そのため、名前解決ができるように次の名前をDNSサーバーに登録します。

CNAMEレコード
EnterpriseRegistration.<ドメイン名>
→ enterpriseregistration.windows.net

enterpriseregistration.region.<ドメイン名>
→ enterpriseregistration.windows.net

4.Device Registration Servicesの有効化

ADFSサーバーでDRSを有効にする理由は、Azure ADに送られてきたデバイス登録要求は最終的にActive Directoryのデータベースに格納されます。そのため、デバイスオブジェクトをActive Directoryに格納できるよう、以下のコマンドレットを実行します。

Initialize-ADDeviceRegistration

Enable-AdfsDeviceRegistration

5.Active Directoryへのデバイス登録の許可

Azure ADでのデバイス登録はディレクトリ同期ツールを使って、Active Directoryにデバイスオブジェクトとして書き込まれます。ディレクトリ同期ツールは本来、Active DirectoryからAzure ADに同期処理を行うツールなので、逆の処理(Azure ADから Active Directoryへ同期)を有効にする設定が必要になります。
それが以下のコマンドレットです。

Import-Module DirSync
$ADCred=Get-Credential
$AADCred=Get-Credential
Enable-MSOnlineObjectManagement –ObjectTypes Device `
–Credential $ADCred –TargetCredential $AADCred

$ADCredにはドメイン管理者の資格情報、$AADCredにはAzure AD管理者の資格情報がそれぞれ入ります。

6.クライアントからデバイスを登録

クライアントはWindows 7以降のWindows PC、またはiOSをサポートしています。

Windows PCの場合はWorkplace Joinの操作でデバイスを登録します。
Windows 8.1の場合、チャームから[設定]-[PC設定の変更]-[ネットワーク]-[社内ネットワーク]から登録します。[参加する]ボタンしかないですが、ボタンを押すことで、ドメインにサインインしたときのユーザー情報(UPN?)を利用してデバイス登録を行います。ADFSサーバーに直接アクセスできる環境から[参加する]を押せば、自動的に登録は完了してくれます。

image

一方、Webアプリケーションプロキシを経由しなければならないような環境の場合は、そもそもドメインへのサインインができていないので(キャッシュによるサインインをしている)、ドメインユーザーとパスワードを入力してサインイン操作をしなければなりません。
ということで、以下のような画面が登場します。

image

いずれかの方法でサインインに成功すると、以下の画面になります。

image

あとは、「Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする(3)」で紹介しているようなクレームルールを実装していただければ、ADFSで実装しているデバイス認証(認可)のルールをAzure ADでも活用できると思います。

一方、iOSは以下のURLにアクセスしてプロファイルをダウンロードし、デバイス登録します。

https://enterpriseregisration.windows.net/enrollmentserver/otaprofile/
<ドメイン名>

すると、次のような画面推移で登録できます。

image image

image image

課題

Azure管理ポータルからAzure ADに作られたユーザー一覧を見ることができますが、
私はharaguchi@<ドメイン名>というユーザーで、すべての検証をしたのですが、
1台のPCと1つのiPhoneを使っただけなのに、ご覧のありさま。

特に、Workplace Joinは参加する/参加をやめる を繰り返すごとにデバイスが増えていく!
この部分をどうするか?が今後の課題になると思います。

image

お試しあれ。

2014年7月8日追記
ご要望にお応えして、デバイス認証の設定を続編として記載しました。
よろしければご覧くださいませ。

2014年6月30日追記
一部の方からご指摘をいただきましたが、このブログに掲載されているのは
デバイス認証のためのデバイスの登録方法であって、デバイスによるアクセス制御方法ではありません。
デバイスによるアクセス制御方法については「
Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする(3)で紹介しているクレームルールを書いてください。
(と言ってみたものの、私の環境ではADFSによるデバイス認証と同じクレームルールが利用できませんでした。環境依存の問題なのか、私の設定の問題なのか、そのあたりはもう少し調べてから改めて紹介させてください)

スポンサーリンク

コメント

  1. Takehiko Kodama より:

    興味深い機能で、さっそく一部試してみました。それで感じたメリットなんですが、このデバイス認証はWeb Application Proxyの認証基盤として動作することでVPNと同等の効果を狙っているように思いました。

    しかし、なぜそこであえてオンプレのADFSでの認証を必須とさせるのかは疑問に思います。

    • sophiakunii より:

      Kodamaさん、こんにちは。
      ADFSの認証を必須とさせるのは仕様なのですが、Azure AD側で実装している機能なので、Azure AD側で完結するような仕組みは確かに欲しいところですよね。

  2. […] 前回、Microsoft Azureで提供されているWorkplace Join機能(正確にはDevice Registration Servicesだと思うんだけど)を利用して、ADFSサーバーでデバイス認証ができる様子を紹介しました。 […]

  3. […] Azure ADのデバイス認証機能はADFSと組み合わせることで、 Azure ADでデバイス認証+ADFSでユーザー認証という使い方が可能 出展:ADFSでデバイス認証を実装 […]

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


*