Windows Hello for Business キー信頼の構成

今更ですが…皆様あけましておめでとうございます。Miyaです。

2018年度は社会人、SEとして3年目を迎えた年であり、仕事内容も複雑かつ一人でのカバー領域がぐんと広がったため、精神的にも肉体的にも疲弊した1年ではありました…が、Microsoft MVPを受賞できたこと、同じMVPの目代さんが主催するOffice365勉強会(https://jpo365ug.connpass.com/)に登壇者として参加させていただいたこと、勉強会を通じて様々な方々とお会いできたこと等々…自身にとってかなり貴重な経験ができた1年でした。

最近は業務過多でなかなかBlogを更新出来ておりまんが、2019年も引き続き本Blogから積極的にアウトプットしていくのでどうぞよろしくお願いいたします。

前置きが長くなりましたが、今回はWindows Hello for Business(WhfB)についてご紹介したいと思います。

WHfBは Active Directory / Azure AD にパスワードレスな認証を提供する次世代の認証の在り方で、その構成方法が昔は面倒だったのですが、今は改良されて割と簡単に構成出来るらしいので、作ってみました。

本記事は、筆者のWHfBのPOC環境構築の中でメモした内容を整理した記事になります。

スポンサーリンク:

Windows Hello for Businessとは?

WHfBとは、その名の通りWindows HelloのEnterprise向けの位置づけで、デバイスにWindows Helloでサインインするだけではなく、そのままActive Directory / Azure ADへのSSOも提供する認証サービスの総称です。

Windows Hello とは?

PINコード、生体認証(指紋/顔/虹彩…etc)を使ってデバイスにサインインする認証方式である。Windows 10で標準サポートされており、従来のパスワードを入力する必要なくデバイスにサインイン出来る便利な機能。

 

Windows HelloはWindows 10の生態認証フレームワークで、デバイスに格納されたユーザーID/パスワードを認証サーバー側に受け渡す仕組みです。

表面的にはパスワードレスな認証に見えますが、裏ではパスワードをサーバーに受け渡しているため、本当の意味でのパスワードレスとは言えません。

一方、WHfBはサーバーとデバイス間でデバイス固有のキーペアを使った公開鍵暗号方式を採用しており、認証フローにパスワードは介入しないことから、まさにパスワードレスと言えるでしょう。

Windows Hello for Business

 

WHfBはキーペアの内、認証要素として重要な秘密鍵をPIN/生体認証で暗号化してからTPM内に格納しておき、対となる公開鍵を認証サーバーに渡しておくことでPKI形式の認証構成が成立します。(デバイスにTPMが無い場合、秘密鍵はソフトウェアTPMに格納されるそうです。)

つまり、PINコード/生体認証はあくまでTPMに格納された秘密鍵を取り出すためだけの要素で、認証サーバーで管理されているユーザーのパスワードには直接関連しない、ということがお分かりいただけるかと思います。

上図の構成において、よくあるメリットが「パスワード情報がデバイスから外に出ない」や、「デバイスに関連づいた認証情報だから流出のリスクがパスワードに比べ低い」など挙げられますが、結局は利用者がパスワード運用をしなくても済むというのが最大のメリットだと思います。

Windows Hello for Businessとは、生体認証(指紋/顔/虹彩…)でデバイスにサインインする「Windows Hello」に、キーペア/証明書を要素に公開鍵暗号方式でサインインする「Microsoft Passport」が組み合わさった新しい認証の在り方である。利用者は従来のパスワード運用をすることなく、Active Directory / Azure AD に対してSSOが可能。

Windows Hello for Businessの構成パターン

WHfBを組織のActive Directoryに展開する計画の第一段階として、適切な構成パターンを選択する必要があります。WHfBには3つの展開モデル、2つの信頼方法、計6つの構成パターンがあります。

それぞれのモデル・信頼の種類については下記URLに記載されている通りです。
参考:http://Windows Hello for Business 展開の計画

展開モデル

展開モデルには、「クラウド」「ハイブリッド」「オンプレミス」の3つがあります。

「クラウド」

Active Directoryでユーザー&アプリケーションを管理しておらず、Azure ADでクラウドIDとしてユーザーをプロビジョニングしている組織向けの展開モデルです。デバイスをAzure AD Join(Azure AD 参加)させる展開モデルになります。

構成にオンプレミスのサーバーは関与しないことから一番構成が簡単であるものの、Active Directoryが使われていないことが前提となっているため、本構成が該当するケースは少ないかもしれません。

Azure AD 参加 とは?

Azure AD 参加により、オンプレ AD でドメイン参加ユーザーがオンプレ AD ドメイン参加しているデバイスに自由にサインインできるのと同じようにAzure 上のユーザーで Azure AD 参加デバイスに自由にサインインすることができます。

オンプレ AD を持っていない組織でも、ローカル アカウントを使用するのではなく、 Azure AD 上のユーザーでデバイスにサインインできるようになるため、オンプレ AD と同様にユーザー アカウントを Azure AD 上で一元管理ができるようになります。

参考:Azure AD 登録 と Azure AD 参加 の違い

ハイブリッド

Active Directoryでユーザー&オンプレリソースを管理しており、Azure ADに対してAADConnect経由でディレクトリ同期をしている組織向けの展開モデルです。以前に本Blogで紹介したHybrid AD JoinをベースにActive DirectoryとAzure ADの両方に対してデバイスを参加させるいいとこ取りな構成をベースとした展開モデルです。
参考:【Azure AD】Windows 10 Hybrid AD Join + MDM の構成

以前はPRT(Primary Refresh Token)をKerberosに変換するためにWindows Server 2016のAD FSが必要でしたが、Windows Server 2016以降のDomain Controllerが在れば、パススルー・パスワードハッシュ同期でも展開可能になりました。

オンプレミス

Azure ADで管理しているアプリケーションにサインインする要件がない、もしくはそもそもAzure ADを使っていない組織向けの展開モデルです。Active Directoryにドメイン参加している端末が対象になります。

キー・デバイス登録にWindows Server 2016以降のAD FSが必要であるため、少し敷居が高いかもしれません。

Office 365を利用している組織では「ハイブリッド」展開モデルが該当しやすいと思うので、本記事ではハイブリッド展開モデルの構成方法を選定したいと思います。

 

展開モデルは、「クラウド」「ハイブリッド」「オンプレミス」の3つがある。自組織のActive Directory / Azure AD の構成に適した展開モデルが選定する必要がある。

信頼の種類

次に信頼の種類についてです。各展開モデルを選定したら次に信頼モデルを選択しましょう。WHfBの信頼の種類には「証明書信頼」「キー信頼」の2つがあります。それぞれの種類でWHfBの機能面に差異はありませんが、サーバー要件や展開方法が異なるので要注意です。

「証明書信頼」

証明機関からユーザーに認証証明書を配布し、証明書の登録機関としてWindows Server 2016のAD FSを使用します。デバイス登録をAADConnect経由でAzure ADからデバイス書き戻すことも出来るらしいですが、Azure AD Premiumライセンス必要になります。

キー信頼とは違って、証明機関からクライアントに証明書を配布する必要があるので、展開難易度はキー信頼と比較すると少し高いかもしれません。

キー信頼

デバイスがAzure ADに公開鍵一式を受け渡し、AADConnect経由でActive Directoryに公開鍵を書き戻しする方式です。公開鍵情報の書き戻しには、Windows Server 2016のDomain Controllerの属性(msDS-KeyCredentialLink)が必要になります。

証明書信頼とは違って証明書を配布する必要はありませんし、Azure AD Premiumが必須ではないことから、構築・展開ともに一番負荷が掛からない構成パターンではないでしょうか?

以下は、Microsoft Docsにまとめられている各パターンの要件です。③、④はデバイス管理をGPOではなく、MDM(Intune)で管理するModern方式です。

今回は、キー信頼&GPO管理なので①のパターンで構築することとします。

①Key trust Group Policy managed ②Certificate trust Mixed managed ③Key trust Modern managed ④Certificate trust Modern managed
Windows 10, version 1511 or later Hybrid Azure AD Joined: Minimum: Windows 10, version 1703 Best experience: Windows 10, version 1709 or later (supports synchronous certificate enrollment). Azure AD Joined: Windows 10, version 1511 or later Windows 10, version 1511 or later Windows 10, version 1511 or later
Windows Server 2016 Schema Windows Server 2016 Schema Windows Server 2016 Schema Windows Server 2016 Schema
Windows Server 2008 R2 Domain/Forest functional level Windows Server 2008 R2 Domain/Forest functional level Windows Server 2008 R2 Domain/Forest functional level Windows Server 2008 R2 Domain/Forest functional level
Windows Server 2016 Domain Controllers Windows Server 2008 R2 or later Domain Controllers Windows Server 2016 Domain Controllers Windows Server 2008 R2 or later Domain Controllers
Windows Server 2012 or later Certificate Authority Windows Server 2012 or later Certificate Authority Windows Server 2012 or later Certificate Authority Windows Server 2012 or later Certificate Authority
N/A Windows Server 2016 AD FS with KB4088889 update (hybrid Azure AD joined clients), and Windows Server 2012 or later Network Device Enrollment Service (Azure AD joined) N/A Windows Server 2012 or later Network Device Enrollment Service
Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter Azure MFA tenant, or AD FS w/Azure MFA adapter, or AD FS w/Azure MFA Server adapter, or AD FS w/3rd Party MFA Adapter
Azure Account Azure Account Azure Account Azure Account
Azure Active Directory Azure Active Directory Azure Active Directory Azure Active Directory
Azure AD Connect Azure AD Connect Azure AD Connect Azure AD Connect
Azure AD Premium, optional Azure AD Premium, needed for device write-back Azure AD Premium, optional for automatic MDM enrollment Azure AD Premium, optional for automatic MDM enrollment

構築する環境

今回、Office 365の定番であるAD FSでフェデレーションを構成している環境にWHfBを展開します。尚、下図の構成が既に構成されている環境を前提とします。

Windows Hello for business

先の表のパターン「①Key trust Group Policy managed」に記載されている各サーバー要件を満たしていることを確認しておきましょう。

機能

要件

備考

Active Directoryフォレスト機能レベル Windows Server 2008 R2~

Active Directoryドメイン機能レベル Windows Server 2008 R2~

Domain Controller Windows Server2016~ 各サイトに必要な数のWindows Server 2016のDomain Controllerが必要

https://docs.microsoft.com/ja-jp/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers

Windows OS Windows 1703~

Windows 証明基盤 Windows Server 2012~

AD FS Windows Server 2012 R2~ PHS、PTAで構成している場合は、本項目は無関係。3rd PartyのIdPを利用している場合はベンダーに対応可否を確認する必要あり。
MFA Azure MFA / MFA Server / 3rd Party MFA Adapter Office 365を利用しているので、Azure MFAで構成する。

Windows Hello for Business キー信頼の構成

それでは、Windows Hello for Businessを展開していきます。構築の流れはザッと以下の通りです。

  1. AADConnect(Hybrid AD Join)の構成
  2. AD FSの発行変換規則の更新
  3. KEY ADMINSの構成
  4. 証明書テンプレートの構成(PKI)&DC 2016への証明書配布
  5. GPOの構成&配布
  6. Windows Clientのプロビジョニング

1.AADConnect(Hybrid AD Join)の構成

まずはHybrid AD Join環境を構成するためにAADConnectで構成ウィザードを実行します。

以前の記事でHybrid AD Joinを紹介した時、構成にはPowerShellから小難しいコマンドを実行する必要がありましたが、Ver1.1.819.0~は、AADConnectのウィザードから構成出来るようになりました。
参考:【Azure AD】Windows 10 Hybrid AD Join + MDM の構成

本記事では2019年1月時点で最新のVer1.2.69.0で構成したいと思います。

まずは、Azure AD Connectを起動して、[Configure]をクリックします。

Windows Hello for Business

 

[Configure device options]を選択し、[Next]をクリックします。

Windows Hello for Business

 

[Configure Hybrid Azure AD join]を選択して[Next]をクリックします。

Windows Hello for Business

 

SCPを展開するフォレストとカスタムドメイン名を選択します。オンプレミス環境に異なるフォレストが存在する場合は、スクリプトをダウンロードして展開する必要があります。

SCPとは?

Service Connection Pointの略で、Active Directoryの構成パーティション内にあるサービスの接続先情報を示すオブジェクトのこと。

Windows Hello for Business

 

[Windows 10 or later domain-joined devices]にチェックを付けて、[Next]をクリックします。今回はダウンレベルのWindows(Windows7、8.1)をHybrid AD Joinさせる要件がないこと、WHfBの要件はWindows 1703~であるため、Windows 10のみを対象として進めます。

Windows Hello for Business

 

今回のようにAD FSでフェデレーションを構成している場合は、デバイス認証用に発行変換規則を更新する必要がありますよというメッセージです。そのまま進めてウィザードを完了させます。

Windows Hello for Business

 

ADSI Editorから構成パーティションにSCPが生成されていることを確認できました。

Windows Hello for Business

2.AD FSの発行変換規則の更新

フェデレーション環境の場合、デバイスはAzure ADに対する認証をAD FSまたは 3rdのIdPに委任します。

PHS、PTAの場合は、AD FSを経由せずにAzure DRS(Device Registration Service)に登録するためのアクセストークンを取得するので、本手順はスキップしてください。

まず、AD FSの以下2つのエンドポイントを有効であることを確認します。

・adfs/services/trust/13/windowstransport

・adfs/services/trust/2005/windowstransport

AD FSの管理コンソールを立ち上げ、[AD FS] – [Service] – [Endpoints]からエンドポイントを選択し、[Enable]をクリックします。

Windows Hello for Business

 

Proxy(WAP)に対してもEnableにします。

Windows Hello for Business

 

同じ手順で/trust/13/のエンドポイントも有効にしておきましょう。

次に、Azure DRSへの要求に以下3つのクレームを含めるために、発行変換規則を追加します。

・http://schemas.microsoft.com/ws/2012/01/accounttype

・http://schemas.microsoft.com/identity/claims/onpremobjectguid

・http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid

AD FSの管理コンソールを開き、[AD FS] – [Relying Party Trusts] – [Microsoft Office 365 Identity Platform]を右クリック、[Edit Claim Issuance Policy]をクリックします。

Windows Hello for Business

 

[Add Rule]からクレームルールの新規作成します。Claim rule templateを[Send Claims Using a Custom Rule]を選択、[Next]をクリックします。

Windows Hello for Business

 

以下のクレームルールで作成しましょう。以下のクレームは/ws/2012/01/accounttypeに”DJ”という値を含ませており、これでデバイスがドメイン参加済みデバイスとして認識されます。

■Issue accounttype for domain-joined computers

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “-515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(Type = “http://schemas.microsoft.com/ws/2012/01/accounttype”, Value = “DJ”);

上記の他にコンピューターアカウントのobjectSID、objectGUIDもクレームに含めるよう以下2つのクレームルールを同じ手順で新規作成します。

■Issue onpremobjectguid for domain-joined computers

c1:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “-515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
&& c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/identity/claims/onpremobjectguid”), query = “;objectguid;{0}”, param = c2.Value);

■Issue objectSID for domain-joined computers

c1:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “-515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
&& c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(claim = c2);

以上で、AD FSの構成は完了です。

Azure ADに複数のカスタムドメインがある場合や、代替ログインIDを利用している場合は、上記とは別のクレームを追加する必要があります。
参考:Azure AD に複数の検証済みドメイン名があるときにコンピューターの issuerID を発行する
参考:ユーザーに対する ImmutableID が存在する (たとえば、代替ログイン ID が設定されている) 場合は、コンピューターの ImmutableID を発行する

3.KEY ADMINSの構成

Windows Hello for Businessのセットアップの中で、AADConnectがActive DirectoryのmsDS-KeyCredentialLink属性に対して書き戻します。

msDS-KeyCredentialLink属性に書き込むための権限を付与する必要があるので、AADConnectのサービスアカウントをKey Adminsグループのメンバーとして構成します。

[Active Directory ユーザーとコンピューター]から、Key Adminsグループのメンバーを追加します。

Windows Hello for Business

※AADConnectのサービスアカウントは、AADConnectの構成情報から確認することが出来ます。

Windows Hello for Business

4.証明書テンプレートの構成&DC 2016への証明書配布

キー信頼は、証明書信頼みたくデバイスに証明書を配布する必要はありませんが証明機関は必要です。

デバイス⇔Domain Controller間でより構成な信頼を構成するためにKSP&SHA256で生成されたKerberos KDCの証明書をWindows Server 2016のDomain Controllerに配布する必要があります。

まずはテンプレートを構成しましょう。AD CSの管理コンソールを開き、[Certificate Templates]を右クリック、[Manage]をクリックします。

Windows Hello for Business

 

[Kerberos Authentication]テンプレートを[Duplicate Template]で複製します。

Windows Hello for Business

 

[General]タブから任意のテンプレート名を入力します。期間は適当で構いません。

Windows Hello for Business

 

[Compatibility]タブから、[Windows Server 2012 R2]を選択します。

 

Windows Hello for Business

[Subject Name]タブから、DNS nameを選択します。

Windows Hello for Business

 

 

[Cyptography]タブから、Providerを[Key Storage Provider]、Algorithmを[RSA]、Request hashを[SHA256]を選択します。

Windows Hello for Business

 

[Superseded Templates]タブから、以下3つのテンプレート追加します。

・Domain Controller

・Domain Controller Authentication

・Kerberos Authentication

Windows Hello for Business

 

テンプレートのカスタムは以上です。[OK]ボタンでテンプレートを作成します。

テンプレートは作成しただけでは発行が出来ません。テンプレート編集コンソールは閉じて、[Certificate Templates] – [New] – [Certificate Template to Issue]で先ほど作成したテンプレートを公開します。

Windows Hello for Business

 

既定で作成されているKerberos Authenticationテンプレートが公開されたままだと、後続の自動登録もKerberos Authenticationテンプレートで証明書が生成されるとため、非公開にしておくことが推奨されていますが、既存DCの認証への影響については未検証ですので慎重に。

次にWindows Server 2016のDomain Controllerに対して、先ほど作成したテンプレートで証明書を生成します。

Domain Controllerのmmcスナップインからローカルコンピューターの[Certificate]を追加します。

[Personal] – [Certificate]を右クリック、[All Tasks] – [Request New Certificate…]をクリックします。

Windows Hello for Business

 

先ほど公開したKerberos KDCの証明書テンプレートを選択して、[Enroll]をクリックします。

Windows Hello for Business

 

新しい証明書が登録されていることが確認できます。古いKerberos KDC証明書が登録されている場合は、念のため削除しておきます。

5.GPOの構成&配布

Hybrid AD Joinの自動登録とWindows Hello for Businessの有効化をGPOで構成、デバイスに配布します。

まずはGPOを新規作成・構成するために、[Group Policy Management]からGPOを新規作成、編集コンソールを立ち上げます。

Windows Hello for Business

 

以下のグループポリシーをEnableに構成し、Hybrid AD Joinの自動登録を構成します。

Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration > Register domain joined computers as devices

Windows Hello for Business

次に、Windows Hello for Businessを使うように[Use Windows Hello for Business]をEnableで構成します。

Computer Configuration > Policies > Administrative Templates > Windows Components> Windows Hello for Business > Use Windows Hello for Business

Windows Hello for Business

 

上記の他に、PINコードの複雑さなどをGPOで定義することが出来ます。4桁数字のPINコードでは盗聴されやすいので、英数字の6桁ぐらいにしておいても良いかと思います。

構成したGPOを対象のコンピューターアカウントに適用します。

Windows Hello for Business

6.Windows Clientのプロビジョニング

GPOが適用されているコンピューターにドメインユーザーとしてログインします。

初回のログイン後、GPOが正常に適用されていれば、タスクスケジューラーの[Microsoft] – [Windows] – [Workplace Join]にAutomatic-Device-JoinがReady状態でセットされているのが確認できます。Historyからログイン後にタスクが実行されていることが確認出来ます。

Windows Hello for Business

 

上記タスクでデバイス登録が試行され、デバイスが証明書が生成します。

証明書はComputerオブジェクトのuserCertificate属性に値がセットされ、AADConnectの差分同期によってAzure ADにデバイスが同期されます。(差分同期は既定で1回/30分のサイクルで実行される)

登録が完了すると、Azure Portalの[Azure Active Directory] – [デバイス]に表示されます。

Windows Hello for Business

 

この時点ではWHfBでサインインは出来ません。一度ログオフしてから、サインインを試すとGPOによってWHfBのウィザードが実行されました。

Windows Hello for Business

セットアップにはAzure MFAの登録が要求されます。ウィザードに従って登録します。

Windows Hello for Business

 

登録後、直ぐにログオフ、WHfBでサインインすることは出来ません。

これは、ウィザード登録後にWHfBのセットアップ中に生成されるキーペアの公開鍵はAzure AD上のデバイスに紐づけされるのですが、その情報がActive DirectoryのmsDS-KeyCredentialLinkに反映されていないためです。

その後の差分同期でAzure ADからmsDS-KeyCredentialLink属性が書き戻されていることが分かります。

Windows Hello for Business

 

WHfBのサインイン後、dsregcmd /statusで確認、Ngc(Next Generation Credentials)がsetされていれば、TPMに秘密鍵が登録されている状態というのが分かります。

klistコマンドでKerberosチケットも取得出来ていることが確認出来れば、両リソースにシングルサインオン出来ている状態となります。

気になる点

■Azure PRTによるAD FSバイパス

デバイス登録によってAzure ADから既定で最大90日間有効なPRT(Primary Refresh Token)がデバイスのLSAにキャッシュされます。

このキャッシュを持っている場合、ADALトークン同様、AD FSをバイパスするフローでアクセストークンを取得&Azure ADへ認証する動きとなるため、AD FSで設定しているクレームルールが適用されない状態となります。

つまり、アクセス制御ポリシーやら、発行変換規則が適用されずに認証が成功する動作となります。

サーバー側のリフレッシュトークンは、Set-MsolUser -StsRefreshTokensValidFrom (’01/01/2020′)など、未来の日付で強制失効させて、無理やりAD FS経由の認証にすることは可能ですが、あまり意味もありません。

もうこの構成を目指すなら、アクセス制限をAzure AD Premiumの条件付きアクセスに移行させて、脱AD FSを目指す構成を検討しても良いかもしれません。

■WHfBの登録フロー

WHfBの登録&サインインは従来のパスワードによる認証と比べてかなり複雑なフローかつ、登場する要素が多くて難しいです。

また、Hybrid AD Joinも絡まると、どのフローで、どの鍵・トークンが交換されているのかが中々読めません。

パケットキャプチャで詳細に調査すれば自信を持ってシーケンス図が書けるのですが、現時点では中々ハッキリしたものを書けないため、本記事においても省略させていただきました。今後の私の課題ですね。

■証明書信頼展開モデル

現時点では証明書信頼展開モデルでの構成は検証出来ておらず、ワールドワイドでも参考記事が中々見つからないため、自分の中でも比較・整理が出来ていません。

クライアントデバイスに証明書を配布する必要があるので少々面倒に思えますが、Azure AD → Active Directoryへデバイス書き戻しする構成を混在が可能(?)なのであれば試す価値はありかなと思ってます。

機会があれば検証&キー信頼との比較もしてみたいと思います。

おわりに

企業のサインインがWHfBに置き換われば、毎朝のサインインが楽だよなぁとか思いながら検証してみたのですが、ハイブリット展開&キー信頼であれば意外と簡単に展開が可能なので導入の敷居はかなり下がっているように思えます。

本記事は検証ベースでのメモ書きとなりますので、あまり正確な情報ではないかもしれませんが、POC環境の構築なんかにはお役に立つと思うので、是非参考にお試しください。

それでは、良いWindows Hello ライフをっ♪

 

スポンサーリンク