10今更ですが...皆様あけましておめでとうございます。MVPを受賞できたこと、同じMVPの目代さんが主催するOffice365勉強会(https://jpo365ug.connpass.com/)に登壇者として参加させていただいたこと、勉強会を通じて様々な方々とお会いできたこと等々...自身にとってかなり貴重な経験ができた1年でした。最近は業務過多でなかなかBlogを更新出来ておりまんが、2019年も引き続き本Blogから積極的にアウトプットしていくのでどうぞよろしくお願いいたします。Business(WhfB)についてご紹介したいと思います。パスワードレスな認証を提供する次世代の認証の在り方で、その構成方法が昔は面倒だったのですが、今は改良されて割と簡単に構成出来るらしいので、作ってみました。本記事は、筆者のWHfBのPOC環境構築の中でメモした内容を整理した記事になります。ADへのSSOも提供する認証サービスの総称です。?PINコード、生体認証(指紋/顔/虹彩...etc)を使ってデバイスにサインインする認証方式である。10で標準サポートされており、従来のパスワードを入力する必要なくデバイスにサインイン出来る便利な機能。10の生態認証フレームワークで、デバイスに格納されたユーザーID/パスワードを認証サーバー側に受け渡す仕組みです。表面的にはパスワードレスな認証に見えますが、裏ではパスワードをサーバーに受け渡しているため、本当の意味でのパスワードレスとは言えません。WHfBはサーバーとデバイス間でデバイス固有のキーペアを使った公開鍵暗号方式を採用しており、認証フローにパスワードは介入しないことから、まさにパスワードレスと言えるでしょう。WHfBはキーペアの内、認証要素として重要な秘密鍵をPIN/生体認証で暗号化してからTPM内に格納しておき、対となる公開鍵を認証サーバーに渡しておくことでPKI形式の認証構成が成立します。(デバイスにTPMが無い場合、秘密鍵はソフトウェアTPMに格納されるそうです。)つまり、PINコード/生体認証はあくまでTPMに格納された秘密鍵を取り出すためだけの要素で、認証サーバーで管理されているユーザーのパスワードには直接関連しない、ということがお分かりいただけるかと思います。上図の構成において、よくあるメリットが「パスワード情報がデバイスから外に出ない」や、「デバイスに関連づいた認証情報だから流出のリスクがパスワードに比べ低い」など挙げられますが、結局は利用者がパスワード運用をしなくても済むというのが最大のメリットだと思います。Passport」が組み合わさった新しい認証の在り方である。Directoryに展開する計画の第一段階として、適切な構成パターンを選択する必要があります。WHfBには3つの展開モデル、2つの信頼方法、計6つの構成パターンがあります。それぞれのモデル・信頼の種類については下記URLに記載されている通りです。展開モデル展開モデルには、「クラウド」「ハイブリッド」「オンプレミス」の3つがあります。ADでクラウドIDとしてユーザーをプロビジョニングしている組織向けの展開モデルです。参加)させる展開モデルになります。Directoryが使われていないことが前提となっているため、本構成が該当するケースは少ないかもしれません。参加デバイスに自由にサインインすることができます。上で一元管理ができるようになります。ADに対してAADConnect経由でディレクトリ同期をしている組織向けの展開モデルです。ADの両方に対してデバイスを参加させるいいとこ取りな構成をベースとした展開モデルです。Controllerが在れば、パススルー・パスワードハッシュ同期でも展開可能になりました。ADを使っていない組織向けの展開モデルです。Directoryにドメイン参加している端末が対象になります。FSが必要であるため、少し敷居が高いかもしれません。365を利用している組織では「ハイブリッド」展開モデルが該当しやすいと思うので、本記事ではハイブリッド展開モデルの構成方法を選定したいと思います。展開モデルは、「クラウド」「ハイブリッド」「オンプレミス」の3つがある。構成に適した展開モデルが選定する必要がある。次に信頼の種類についてです。各展開モデルを選定したら次に信頼モデルを選択しましょう。WHfBの信頼の種類には「証明書信頼」「キー信頼」の2つがあります。Premiumライセンス必要になります。キー信頼とは違って、証明機関からクライアントに証明書を配布する必要があるので、展開難易度はキー信頼と比較すると少し高いかもしれません。Directoryに公開鍵を書き戻しする方式です。Controllerの属性(msDS-KeyCredentialLink)が必要になります。Docsにまとめられている各パターンの要件です。3、4はデバイス管理をGPOではなく、MDM(Intune)で管理するModern方式です。今回は、キー信頼&GPO管理なので1のパターンで構築することとします。FSでフェデレーションを構成している環境にWHfBを展開します。下図の構成が既に構成されている環境を前提とします。managed」に記載されている各サーバー要件を満たしていることを確認しておきましょう。PHS、PTAで構成している場合は、本項目は無関係。PartyのIdPを利用している場合はベンダーに対応可否を確認する必要あり。Businessを展開していきます。構築の流れはザッと以下の通りです。Join環境を構成するためにAADConnectで構成ウィザードを実行します。Joinを紹介した時、構成にはPowerShellから小難しいコマンドを実行する必要がありましたが、Ver1.1.819.0~は、AADConnectのウィザードから構成出来るようになりました。本記事では2019年1月時点で最新のVer1.2.69.0で構成したいと思います。Connectを起動して、[Configure]をクリックします。options]を選択し、[Next]をクリックします。join]を選択して[Next]をクリックします。SCPを展開するフォレストとカスタムドメイン名を選択します。オンプレミス環境に異なるフォレストが存在する場合は、スクリプトをダウンロードして展開する必要があります。Directoryの構成パーティション内にあるサービスの接続先情報を示すオブジェクトのこと。devices]にチェックを付けて、[Next]をクリックします。10のみを対象として進めます。FSでフェデレーションを構成している場合は、デバイス認証用に発行変換規則を更新する必要がありますよというメッセージです。そのまま進めてウィザードを完了させます。Editorから構成パーティションにSCPが生成されていることを確認できました。3rdのIdPに委任します。Service)に登録するためのアクセストークンを取得するので、本手順はスキップしてください。FSの以下2つのエンドポイントを有効であることを確認します。[Endpoints]からエンドポイントを選択し、[Enable]をクリックします。Proxy(WAP)に対してもEnableにします。同じ手順で/trust/13/のエンドポイントも有効にしておきましょう。DRSへの要求に以下3つのクレームを含めるために、発行変換規則を追加します。Policy]をクリックします。Rule]からクレームルールの新規作成します。Rule]を選択、[Next]をクリックします。以下のクレームルールで作成しましょう。以下のクレームは/ws/2012/01/accounttypeに”DJ”という値を含ませており、これでデバイスがドメイン参加済みデバイスとして認識されます。“DJ”);上記の他にコンピューターアカウントのobjectSID、objectGUIDもクレームに含めるよう以下2つのクレームルールを同じ手順で新規作成します。FSの構成は完了です。ADに複数のカスタムドメインがある場合や、代替ログインIDを利用している場合は、上記とは別のクレームを追加する必要があります。DirectoryのmsDS-KeyCredentialLink属性に対して書き戻します。Adminsグループのメンバーとして構成します。Adminsグループのメンバーを追加します。※AADConnectのサービスアカウントは、AADConnectの構成情報から確認することが出来ます。2016への証明書配布キー信頼は、証明書信頼みたくデバイスに証明書を配布する必要はありませんが証明機関は必要です。Controllerに配布する必要があります。テンプレートを構成しましょう。Templates]を右クリック、[Manage]をクリックします。Template]で複製します。[General]タブから任意のテンプレート名を入力します。期間は適当で構いません。nameを選択します。hashを[SHA256]を選択します。Templates]タブから、以下3つのテンプレート追加します。Authenticationテンプレートのカスタムは以上です。[OK]ボタンでテンプレートを作成します。テンプレートは作成しただけでは発行が出来ません。Issue]で先ほど作成したテンプレートを公開します。Authenticationテンプレートで証明書が生成されるとため、非公開にしておくことが推奨されていますが、既存DCの認証への影響については未検証ですので慎重に。Controllerに対して、先ほど作成したテンプレートで証明書を生成します。Controllerのmmcスナップインからローカルコンピューターの[Certificate]を追加します。Certificate...]をクリックします。KDCの証明書テンプレートを選択して、[Enroll]をクリックします。新しい証明書が登録されていることが確認できます。KDC証明書が登録されている場合は、念のため削除しておきます。Businessの有効化をGPOで構成、デバイスに配布します。Management]からGPOを新規作成、編集コンソールを立ち上げます。Joinの自動登録を構成します。Business]をEnableで構成します。Business上記の他に、PINコードの複雑さなどをGPOで定義することが出来ます。4桁数字のPINコードでは盗聴されやすいので、英数字の6桁ぐらいにしておいても良いかと思います。構成したGPOを対象のコンピューターアカウントに適用します。ClientのプロビジョニングGPOが適用されているコンピューターにドメインユーザーとしてログインします。Join]にAutomatic-Device-JoinがReady状態でセットされているのが確認できます。Historyからログイン後にタスクが実行されていることが確認出来ます。上記タスクでデバイス登録が試行され、デバイスが証明書が生成します。ADにデバイスが同期されます。[デバイス]に表示されます。この時点ではWHfBでサインインは出来ません。一度ログオフしてから、サインインを試すとGPOによってWHfBのウィザードが実行されました。MFAの登録が要求されます。ウィザードに従って登録します。登録後、直ぐにログオフ、WHfBでサインインすることは出来ません。DirectoryのmsDS-KeyCredentialLinkに反映されていないためです。ADからmsDS-KeyCredentialLink属性が書き戻されていることが分かります。Credentials)がsetされていれば、TPMに秘密鍵が登録されている状態というのが分かります。klistコマンドでKerberosチケットも取得出来ていることが確認出来れば、両リソースにシングルサインオン出来ている状態となります。Token)がデバイスのLSAにキャッシュされます。FSで設定しているクレームルールが適用されない状態となります。アクセス制御ポリシーやら、発行変換規則が適用されずに認証が成功する動作となります。FS経由の認証にすることは可能ですが、あまり意味もありません。FSを目指す構成を検討しても良いかもしれません。■WHfBの登録フローWHfBの登録&サインインは従来のパスワードによる認証と比べてかなり複雑なフローかつ、登場する要素が多くて難しいです。Joinも絡まると、どのフローで、どの鍵・トークンが交換されているのかが中々読めません。パケットキャプチャで詳細に調査すれば自信を持ってシーケンス図が書けるのですが、現時点では中々ハッキリしたものを書けないため、本記事においても省略させていただきました。モデル現時点では証明書信頼展開モデルでの構成は検証出来ておらず、ワールドワイドでも参考記事が中々見つからないため、自分の中でも比較・整理が出来ていません。Directoryへデバイス書き戻しする構成を混在が可能(?)なのであれば試す価値はありかなと思ってます。機会があれば検証&キー信頼との比較もしてみたいと思います。おわりに企業のサインインがWHfBに置き換われば、毎朝のサインインが楽だよなぁとか思いながら検証してみたのですが、ハイブリット展開&キー信頼であれば意外と簡単に展開が可能なので導入の敷居はかなり下がっているように思えます。本記事は検証ベースでのメモ書きとなりますので、あまり正確な情報ではないかもしれませんが、POC環境の構築なんかにはお役に立つと思うので、是非参考にお試しください。2019.02.11皆さんこんにちは、Miyaです。ProPlusをIISで更新管理する方法についてご紹介したいと思います。2018.09.09みなさん、こんにちはMiyaです。NLBの概要部分や各設定値についてご紹介しました。コメントをキャンセルメールアドレスが公開されることはありません。date*日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)プロフィールこんにちは、Miya(@miya_microsoft)です。高校~大学では情報科学部としてプログラミングを学び、SEとして某Sierに入社しました。Microsoftプロダクトをメインに設計から構築までを担当しております。本ブログは筆者の業務範囲の中で得た学びをより深めることと、その情報が皆さまのお役に立てればという思いから設立しました。キャンセル投稿を送信できませんでした。メールアドレスを確認してください。メール送信チェックに失敗しました。このブログではメールでの投稿共有はできません。