雖然使用802.1x，但是(加入網域的)公司電腦，對於802.1x走電腦驗證，可以確認是公司電腦，但是無法確認使用者是否是公司內部的人，或是正確持有者。
雖然使用802.1x，但是使用使用者帳號，即使不是公司設備，也可以認證通過，讓BYOD(Bring You Owen Device)能連上，增加了一些不確定性。
既要也要的方式，就是要一次通過網域電腦(公司電腦)跟網域使用者(公司員工)，才能確保兩者吻合。
然而，我的公司電腦上也是可以讓其他員工登入帳號，達到通過辨識條件，那如果要高度綁定呢？派發我的公司電腦只能我去使用？又要如何設定？
身份辨識
相信會點進來的，都是有一定水準的，這邊就不過度敘述前置知識。
就務實面來說，網域電腦會有網域電腦的特徵，網域使用者或有網域使用者的特徵，針對特徵，這是去構思一套既要也要的認證系統。
一般常見的認證伺服器串接，往往就只是身份是否存在，在則通過，不在則不通過。而這個身份往往只是一種來源，因此就沒有辦法做到「既要也要」的考量多種來源的身份辨識。
網域電腦的特徵之一就是能通過電腦驗證，這是在Windows電腦加入網域時，電腦資訊會存於AD，相當於給電腦的帳號密碼，電腦驗證是電腦向AD做電腦帳號驗證，只有網域電腦才會進行與通過。
網域使用者的特徵之一就是使用者帳號密碼，但這不去認裝置，而是看輸入的帳號密碼是否存在於AD。網域使用者在一般狀況之下不會外洩與誤用，但不保證他們不會用自己的裝置使用自己的網域使用者帳號去連線公司網路。
因此，要具有網域電腦 + 網域使用者才能使用，這是一個IT資安考量難題。
解決方案
易維護是一個圈圈，使用者方便是一個圈圈，夠安全又是一個圈圈，想要「易維護、方便又夠安全」的方案，就看$$$是否足夠，藉由讓廠商去提供服務達成。
Windows MFA登入
在Windows登入時，使用者MFA登入是一個可以達到「既要也要」的方式。
=> MFA可以搭配離線或是在線，離線是輸入TOTP(Time-based One Time Password )，在線可以使用手機推播到APP進而使用生物辨識。
就方便性與安全性來說，在線使用推播加生物辨識勝出，前提是「在線」。
在線也可能意味者，如果windows登入畫面時，為了讓在線認證成功，就已經有完全連線能力，某種程度上也代表可以去接觸內部網路。
不在線，使用不方便，TOTP操作就是硬生生多了幾步。每天登入都要敲，看到畫面心已經累。
然而MFA卻只是在身份驗證上對於使用者多一種來源檢驗，沒有做到電腦與使用者同時進行驗證，因此，還是可以登入別的公司筆電。(前者是人但有兩個證明方式去證明人屬實，後者是人與設備都要同時證明。)
此外，要具有連線能力的控管也不是MFA可以控管的，MFA並不能達到Role-based的網路存取控制。
換個角度想，MFA搭配Role-based網路存取控制，可以達到易維護、方便、安全的三者重疊小圈圈。
某種程度上，網域電腦能通過的802.1x網路提供連線能力，windows登入作為身份驗證，也是完成了網域電腦與網域使用者的目標條件。
Role-based Network Access Control
把這個放在第二個順序講，是因為這個相比前者，具有更大的設定維護成本。
為什麼？因為需要先具備知識並做功課，不單單只是說說什麼身份就取得什麼權限這麼簡單，而是要透過身份獨有的特徵、網路管理規則與習慣、基礎網路的配合等等，準備責任將落於IT人員身上，而不能只是都拋給廠商去處理。
為了避免無止境分類，只針對網路情境先做粗分類，後續有需求再細分更多Role。
802.1x網路，一般來說，不論使用者或是電腦驗證都能通過，因此如果搭配MFA，有可能變成登入時使用者身份驗證，網路存取也是使用者身份驗證，於是就沒有驗證電腦裝置了。
網域電腦可以透過群組原則(Group Policy)去派送網路設定檔，強制使用特定且無法修改的網路設定檔連線，能固定在電腦驗證、使用者驗證、電腦或使用者驗證等三者身份資訊去驗證。
難題來了，網路、系統在一定規模公司容易分組，這環境，網路往往不會瞭解GP是什麼，系統也往往不懂網路控管要如何進行。更大的規模，更專業的劃分，更井水不犯河水，系統整合對於IT人員來說很難以想像。
Role-base Authentication，簡單來說，除了驗證裝置傳送的身份訊息，認證伺服器還會藉此身份資訊撈出更多相關訊息，藉此判斷角色，然後再去判斷認證是否通過與配置。
因此，能引入更多資訊就能判斷更準確，至於需要多少資訊？就是依照認證服務去決定，大多很基本都可以拿現成資訊使用。
Authentication Method
講完RBNAC，在規劃上最重要的是，身份資訊是否能符合角色特徵？
EAP-TLS
先前文章有提到TLS，這是非常簡單的部署，使用者憑證能自動簽發，一定是因為它是網域電腦，然後套用GP，接著在使用者登入時自動簽發。
EAP-TLS這個方法若是做完整，網路認證是拿使用者憑證做驗證，而且使用者憑證又是因為網域電腦的GP而來，就相當於網域電腦加上使用者驗證。BYOD就不會有這樣的憑證。
然而，憑證是進階知識，EAP-TLS也不是預設驗證方法，萬一有狀況，IT很難走其他路先暫時解決。
TEAP
TEAP(Tunnel Extensible Authentication Protocol) ，這個驗證方法可以把驗證分為兩個階段：方法一、方法二，因此可以方法一做電腦驗證、方法二做使用者驗證，達到一次認證，兩種身份資訊都確認。
※更多說明可參考Aruba文件
但是，TEAP是Windows 10特定版本後支援的，Windows 11全面支援，而Windows Server是2022以後。考量到公司的Windows Server都會用很久，現在2026，要能看到環境中現在主力是WIndows Server 2022以後的，可能不容易見到。
若要完成「網域電腦加上網域使用者同時驗證」，這方法還是可以透過驗證系統去輕易達成。前提是設備與AD夠新的話就很簡單了。
Role-base Control
前面提到的方法，我認為對於「網域電腦與網域使用者」驗證都能解釋也算合理。
但離終極目標「網域電腦與特定網域使用者」還有一段差距。
Role-base的概念很重要，因為概念才會去驅使系統套配，才會在各處選擇方法，而方法並不會反過來讓系統能完整配套。
各方法的危機
MFA登入需要有一定的連線能力，那就在未登入前當作一個Role。
Windows登入後，又需要另外一種一個連線能力，稱為角色存取權限轉變，就需要規劃Role to Role的時機與方式。
角色存取權限轉變，像是重新驗證或是強制門戶(Captive Portal)都是一種方式。
Captive Portal又會讓連線能力受限，任何網頁瀏覽會被轉導到門戶頁面，但也可能連MFA該連線的地方卻因此沒有辦法使用。
重新驗證？相當於使用者要關掉網路，或者透過精妙的設定觸發。前者不方便，兩者可能都不穩定。
疑慮會表列，然而危機不是在於單個疑慮逐個想方法去擊破，而是一套方案需要將全部疑慮擊破。
有辦法制訂這套方案的人，不是只深耕網路，也不是深耕系統，而是兩者兼具加上懂角色識別，能造出來也是有經歷很多奇特的要求與考量吧。
系統整合與Role Base去解決
對於「網域電腦驗證與網域使用者驗證」在本文提到三種能解釋。
那，對於「Windows登入時，MFA在線能用。又要達成網域電腦驗證與網域使用者驗證」呢？
多一個條件，就感覺難上不少。
那，對於「Windows登入時，MFA在線能用。又要達成網域電腦驗證與網域使用者驗證。且使用者帳號每天都要驗證且不能暫存」呢？
比原先多兩個條件，感覺已經很不可思議的難題了。
那，對於「Windows登入時，MFA在線能用。又要達成網域電腦驗證與網域使用者驗證。使用者帳號每天都要驗證且不能暫存。網域電腦上只能有特定網域使用者能驗證通過。還要維運簡單」呢？
一口氣比原先多四個條件，對於一個專精某項產品的工程師，已經是想要直接攤手的處境了。
然而以Role-base去拆分網路角色各階段，在輔以系統整合去達到多方配合，其實做得到。
電腦驗證，跳出Captive Portal驗證的角色，使用者驗證，通過Captive Portal驗證後角色。
MFA，MFA登入成功，直接跳出Captive Portal，登入，MAC Cache。
電腦帳號，管理者，驗證條件。
以上是三個層面的關鍵，不同設備，就是能規劃起來就可以了。
讓網域電腦與網域使用者綁定的驗證方式
MFA：網域電腦自動連上有所有權限，網域使用者MFA登入成功後，使用者才可以正常使用。
TLS：使用者憑證驗證通過擁有所有權限，然而網域電腦才能讓網域使用者自動註冊憑證。
TEAP：一次驗證分兩階段，各階段分別驗證電腦與使用者。
MFA且非TLS與非TEAP：網域電腦有限權限，網域使用者可MFA登入，Captive Portal做使用者驗證。