こんにちは、富士榮です。
Azure Active Directory（Azure AD）に参加したWindows 10デバイスでのデバイス・サービス間のシングルサインオンの仕組み（Microsoft Passport）については、これまでもidconや本ブログなどでも解説をしてきました。
[Windows10]デバイス＆サービス間のシングルサインオンの仕組み
http://idmlab.eidentity.jp/2015/05/windows10.html
[FIDO/Windows10]idcon vol.20（別名fidcon）が開催されました
http://idmlab.eidentity.jp/2015/05/fidowindows10idcon-vol20fidcon.html
しかし、現実のエンタープライズ・シナリオでは一気にAzure ADへPCを参加させて、クラウドだけで生きていく、ということは考えにくく、まずは現存のオンプレミスのドメインとWindows 10をどうやって組み合わせて活用していくのか？が焦点になっていくものと思われます。
と、いうことで今回はオンプレミスのドメインにWindows 10のPCを参加させて、Azure ADと連携することで得られる利点について解説していきたいと思います。いわゆるハイブリッドID基盤をWindows 10を使うことで更に活用できますよ、というシナリオです。
ちなみに、やれることは単純にデバイスへのログインと社内アプリ、社外アプリへのシームレスなログイン（シングルサインオン）ですが、この環境を実現するためのシナリオとしては複数の方法があります。
１）AD FSを構築してAzure ADとID連携する方法
現在も主流となっているオーソドックスな方法です。PCはあくまでオンプレのAD DSに参加、ログインをして利用しますので、社外で利用する場合は社内ネットワークへVPN接続するか、Web Application Proxy（WAP）を用意してForm認証する必要があり、AD FSがダウンすると全滅するという弱点がありました。
２）Azure AD WAPを使う方法
上記１のパターンと似ていますが、PCはAzure ADに参加して社内アプリへのアクセス時だけAzure AD WAPを使うため、可用性の面では改善されたものの、社内にいても社内アプリケーションへのアクセスはあくまでAzure AD WAP経由となるため、ファイルサーバなどの非Webアプリケーションへの対応ができない、など機能面で現実的な選択ではありませんでした。
３）Windows Server 2016のAD FSを使い、Microsoft Passport for Workを利用する方法
おそらく今後の本命になると思います。社外はAzure ADを使ったMicrosoft Passport、社内はMicrosoft Passport for Work、社内外のつなぎはAzure ADとAD FSの連携という形になるので、オンプレのAD DSに参加したPCでもAzure ADに参加したPCでもシームレスに社内外のアプリケーションを利用できます。非WebアプリケーションについてもMicrosoft Passport for Workではカバーする予定らしいので、そうなると無敵です。弱点は基盤構築が超面倒なところですかね。SCCMとかIntuneとかのMDMが必要になりそうです。
４）Azure AD Connectを使いMicrosoft Passportに使うデバイス情報をオンプレ・クラウド間で同期する方法
今回紹介する方法です。PCはオンプレのADへ参加するので従来通り社内リソースは統合Windows認証で利用し、社外アプリケーションはAzure ADとMicrosoft Passportで利用する形をとります。認証する局面においてクラウド・オンプレの間で連携がないので、完全に環境を切り離すことが可能なので、可用性はあんまり気にしなくても良いのが利点です。ただ、この後解説しますが現状はちょっと環境を選びます。
では、さっそく解説します。
◆実現すること
おさらいですが、以下を実現します。
・ドメイン参加したWindows 10 PCがAzure ADと連携されているアプリケーションへSSO（PCログインとアプリログインのSSO）できるようにする
・社内ファイルサーバなどへのログインは従来通り統合Windows認証を利用
※つまり、Windows Server 2016のAD FSを使ったMicrosoft Passport for Workシナリオではありません。
・社外アプリ（Azure AD連携アプリ）へのログインはMicrosoft Passportを利用
◆前提および制限事項
実現するためには以下の前提や制限があります。
・Azure ADとAD DSはAzure AD ConnectでID同期を行っている
・Azure ADとAD DSはフェデレーションしていない（AD FSを使っていない）
・Azure ADとAD DSの間はパスワードハッシュ同期を行っている
・PCはWindows 10（TH2以降）
・ドメインコントローラはWindows Server 2012R2以降
・オンプレドメイン名とAzure ADドメイン名は同一であること
（Azure AD ConnectでメールなどUPN以外の属性でオブジェクト・マッチングをするとNG。代替UPNでも良いので同一UPNが必要）
・実際にデバイスがAzure ADに登録されるまでには結構時間がかかります。（ログイン、Azure AD Connectによる同期、ログインの順で処理が走るので、同期の前後でログインをする必要があります）
◆準備作業
まず、準備として以下の2点を行います。
１．クライアントPCが自動的にデバイス登録（Workplace Join）を行うためのタスクの有効化
グループポリシーの設定を行います。
Windows Server 2016のドメインだと、
コンピューターの構成
⇒ポリシー
⇒管理用テンプレート
⇒Windowsコンポーネント
⇒デバイスの登録
から「ドメインに参加しているコンピューターをデバイスとして登録する」を有効にします。
※2012 R2サーバだと、「社内参加（Workplace Join）」という名前の項目になっています。
このポリシーを有効にすることで、クライアントPCにユーザがログインしたタイミングでデバイスを登録するためのタスクスケジューラ（dsregcmd.exe）が起動するようになります。
（このあたりの細かい動きは次回解説します）
２．有効化されたタスクがAzure AD DRSのドメイン、テナントを解決するためのエントリ（SCP：Service Connection Point）をAD DS上に登録
１の作業で有効化したタスクがデバイスを登録する先となるAzure ADのサービス名（ドメイン名およびテナントID）をAD DS上に登録する作業です。
実際の作業としてはAzure AD Connectに含まれるPowerShellのコマンドレット「Initialize-ADSyncDomainJoinedComputerSync」を実行することになります。
こんな感じです。
これを行うと、CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=example,DC=comにazureADNameとazureADIdという二つの情報が登録されます。先のタスクスケジューラはこの値を見てデバイス情報を登録する先のAzure ADを判別します。
※ちなみに、Azure ADのディレクトリ内に複数のドメインが存在する場合、意図しないドメイン名が登録されてしまうことがありますので、その場合は直接AD DS上の値を修正する必要がありそうです。（これが原因かどうかはわかりませんが、うまく動かないことがありました）
◆PCをドメインに参加させ、ドメインユーザでログイン、そして同期する
ここは特に何もいりません。通常の手順です。
ただ、グループポリシーが正常に適用されると「Automatic-Device-Join」というタスクが自動的に実行されているはずです。
結果、いくつかのことが発生します。
まずは、初回ログインの際、ドメインに登録されたコンピュータオブジェクトのuserCertificate属性に証明書がセットされます。（タスクの中で自己証明書を発行します）
このあとAzure AD Connectでデバイス情報の同期を行います。Azure AD Connectの同期ルールを見るとuserCertificateに値が入っていないとAzure ADへコンピューターオブジェクトを同期しないので、この段階で初めて同期対象となるためです。
同期されるとAzure AD上にデバイスが登録されます。登録状態はGraph Exploreで確認するしか方法がありません。
そして、再度ドメインユーザでログインします。
するとAzure AD上に登録されたデバイスとログイン時に実行されるタスクによる登録要求の突合が行われ、Microsoft Passportに必要なKey Registration Serviceエンドポイントでの認証に必要なクライアント証明書がダウンロードされます。
この後、Windows 10はキーペアを生成し、秘密鍵をTPMに、公開鍵をKey Registration Serviceへ登録し、Microsoft Passportのデバイス登録フェーズが完了します。
次回Azure ADへログインする際はTPM上の秘密鍵で署名したリクエストによりPrimary Refresh Token（PRT）が取得できるので、そのあとは必要なアクセストークンを取得してアプリケーションを利用、という流れでシングルサインオンが実現します。
この際、ユーザのアカウント設定のページにはAADTokenBrokerが発現、紐づけられたAzure AD上のアカウント情報が表示されます。
◆Azure ADと連携したアプリケーションへアクセスする
ここまで来れば、これまで紹介したものと同じです。
アクセスパネルにアクセスするとAzure ADでのログインを求められることなく、アクセスできます。
かなりややこしいフローになるため、次回は少し深いところの仕組みを解説し、なぜこのような動きをするのか？を解説したいと思います。
投稿
