Windows Server 搭建企業無線認證(Radius認證方案)

認證協議介紹：

擴展認證協議EAP(Extensible Authentication Protocol)

是一個在無線網絡或點對點連線中廣泛使用的認證框架。它被定義在RFC 3748中，而且使RFC 2284過期，後又被RFC 5247更新。EAP不只能夠用於無線局域網，還能夠用於有線局域網，但它在無線局域網中使用的更頻繁。WPA和WPA2標準已經正式採納了5類EAP做爲正式的認證機制。

EAP是一個認證框架，不是一個特殊的認證機制。EAP提供一些公共的功能，而且容許協商所但願的認證機制。這些機制被叫作EAP方法，如今大約有 40種不一樣的方法。IETF的RFC中定義的方法包括：EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-SIM，和EAP-AKA, 還包括一些廠商提供的方法和新的建議。無線網絡中經常使用的方法包括EAP-TLS, EAP-SIM, EAP-AKA, PEAP, LEAP，和EAP-TTLS。

IEEE 802.1x協議認證就使用了EAP認證框架，由於EAP提供了可擴展的認證方法，可是這些認證方法的安全性徹底取決於具體的認證方法，好比EAP-MD五、EAP-LEAP、EAP-GTC等，而802.1x最開始是爲有線接入設計的，後來被用於無線網的接入，有線接入在安全性方面考慮畢竟少，若是要竊取信息須要物理上鍊接網絡，而無線網徹底不一樣，無線網信號沒有物理邊界，因此要使用802.1x的話，須要對802.1x進行安全性方面的加強，也就是加強EAP認證框架的安全性，並且要進行雙向認證，那麼EAP使用了IETF的TLS（Transport Layer Security）來保證數據的安全性。

如今主流的安全認證方法：EAP-TLS，PEAP，EAP-TTLS

分別介紹這三種方法：

1. EAP-TLS：
EAP-TLS使用TLS握手協議做爲認證方式，TLS有不少優勢，因此EAP選用了TLS做爲基本的安全認證協議，併爲TTLS和PEAP創建安全隧道，TLS已經標準化，而且進過了長期應用和分析，都沒有發現明顯的缺點。
TLS認證是基於Client和Server雙方互相驗證數字證書的，是雙向驗證方法，首先Server提供本身的證書給Client，Client驗證Server證書經過後提交本身的數字證書給Server，客戶端的證書能夠放到本地、放到key中等等.
TLS有一個缺點就是TLS傳送用戶名的時候是明文的，也就是說抓包能看到EAP-Identity的明文用戶名。
TLS是基於PKI證書體系的，這是TLS的安全基礎，也是TLS的缺點，PKI太龐大，太複雜了，若是企業中沒有部署PKI系統，那麼爲了這個認證方法而部署PKI有些複雜，固然，若是企業已經部署了PKI，那麼使用EAP-TLS仍是不錯的選擇。

2. EAP-TTLS：下同

3. EAP-PEAP:
正由於TLS須要PKI的缺點，因此設計出現了TTLS和PEAP，這兩個協議不用創建PKI系統，而在TLS隧道內部直接使用原有老的認證方法，這保證了安全性，也減少了複雜度。

把TTLS和PEAP放到一塊兒介紹的緣由是他們倆很像，兩個都是典型的兩段式認證，在第一階段創建TLS安全隧道，經過Server發送證書給Client實現Client對Server的認證（這裏TTLS和PEAP仍然使用證書，可是這裏的證書都是服務器證書，管理起來比TLS客戶端證書要簡單那的多）；當安全隧道一旦創建，第二階段就是協商認證方法，對Client進行認證；
TTLS利用TLS安全隧道交換相似Radius的AVPs（Attribute-Value-Pairs），實際上這些AVPs的封裝和Radius都十分類似，TTLS這種AVPs有很好的擴展性，因此它幾乎支持任何認證方法，這包括了全部EAP的認證方法，以及一些老的認證方法，好比PAP、CHAP、MS-CHAP、MS-CHAPv2等，TTLS的擴展性很好，經過新屬性定義新的認證方法。

PEAP之因此叫Protected EAP，就是它在創建好的TLS隧道之上支持EAP協商，而且只能使用EAP認證方法，這裏爲何要保護EAP，是由於EAP自己沒有安全機制，好比EAP-Identity明文顯示，EAP-Success、EAP-Failed容易仿冒等，因此EAP須要進行保護，EAP協商就在安全隧道內部來作，保證全部通訊的數據安全性。其實PEAP最大的優勢就是微軟支持開發，微軟在Windows系統內集成了客戶端，微軟和Cisco都支持PEAP，可是他們的實現有所區別。

三者對比：

 

 

 

EPA-TLS是目前爲止最安全的方式，但缺點也很明顯，不少系統客戶端並無集成，客戶端須要導入認證證書等等，因此當下WLAN認證方式最經常使用的是PEAP和EAP-TTLS這兩種。下圖是PEAP的認證粗略過程：

 

 

 

 

 

認證基本流程：

 

一、證書獲取

 

證書主要用來進行終端和網絡的相互認證。 Radius服務器首先向CA證書頒發機構申請服務器證書，用來表明Radius服務器的合法性。STA向CA證書頒發機構下載CA 根證書，用來驗證Radius服務器下發的證書是否合法（通常狀況下，若是終端不須要對網絡進行認證的狀況下，根證書能夠不用下載和安裝）。

 

二、無線接入

 

STA經過開放系統接入的方法（OPEN SYSTEM）和AP之間創建好物理鏈接。

 

三、認證初始化

 

① STA向AP設備發送一個EAPoL-Start報文，開始802.1x接入的開始；

 

② AP向客戶端發送EAP-Request/Identity報文，要求客戶端將用戶信息送上來；

 

③ STA迴應一個EAP-Response/Identity給AP的請求，其中包括用戶的網絡標識。用戶ID，對於EAP-mschchap v2認證方式的用戶ID是由用戶在STA手動輸入或者配置的；

 

④ AP以EAP Over Radius的報文格式將EAP-Response/Identity發送給認證服務器Radius,而且帶上相關的Radius的屬性；

 

⑤ Radius收到客戶端發來的EAP-Response/Identity，根據配置肯定使用EAP-PEAP認證，並向AP發送RADIUS-Access-Challenge報文，裏面含有Radius發送給客戶端的EAP-Request/Peap/Start的報文，表示但願開始進行EAP-PEAP的認證；

 

⑥ AP設備將EAP-Request/PEAP/Start發送給認證客戶端。

 

四、創建TLS通道

 

⑦ STA收到EAP-Request/Peap/Start報文後，產生一個隨機數、STA支持的加密算法列表、TLS協議版本、會話ID、以及壓縮方法（目前均爲NULL），封裝在EAP-Response/Client Hello報文中發送給AP設備；

 

⑧ AP以EAP Over Radius的報文格式將EAP-Response/Client Hello發送給認證服務器RadiusServer,而且帶上相關的Radius的屬性；

 

⑨ Radius收到STA發來的Client Hello報文後，會從STA 的Hello報文的加密算法列表中選擇本身支持的一組加密算法＋Server產生的隨機數＋Server 證書（包含服務器的名稱和公鑰）＋證書請求＋Server_Hello_Done屬性造成一個Server Hello報文封裝在Access－Challenge報文中，發送給STA；

 

⑩ AP把Radius報文中的EAP域提取，封裝成EAP-request報文發送給Client。

 

注：因爲證書比較大，一個報文是沒法承載的，因此在實際流程中第10，11完成後，後面還有3個續傳的IP分片報文，目的是把Server證書發送到客戶端。

 

⑩① STA收到報文後，進行驗證Server的證書是否合法（使用從CA證書頒發機構獲取的根證書進行驗證，主要驗證證書時間是否合法，名稱是否合法），即對網絡進行認證，從而能夠保證Server的合法。若是合法則提取Server證書中的公鑰，同時產生一個隨機密碼串pre-master-secret，並使用服務器的公鑰對其進行加密，最後將加密的信息ClientKeyExchange+客戶端的證書（若是沒有證書，能夠把屬性置爲0）＋TLS finished屬性封裝成EAP-Rsponse/TLS OK報文發送給認證點AP.若是STA沒有安裝證書，則不會對Server證書的合法性進行認證，即不能對網絡進行認證；

 

⑩② AP以EAP Over Radius的報文格式將EAP-Response/TLS OK發送給認證服務器Radius Server,而且帶上相關的Radius的屬性；

 

⑩③ Radius收到STA發了的報文後，用本身的證書對應的私鑰對ClientKeyExchange進行解密，從而獲取到pre-master-secret，而後將pre-master-secret進行運算處理，加上Client和Server產生的隨機數，生成加密密鑰、加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了，至此TLS通道已經創建成功，之後的認證過程將使用協商出的密鑰進行加密和校驗。Radius Server藉助hmac的密鑰，對要在TLS通道內進行認證的消息作安全的摘要處理，而後和認證消息放到一塊兒。藉助加密密鑰，加密初始化向量加密上面的消息，封裝在Access－Challenge報文中，發送給Client。

 

五、認證過程

 

⑩④ AP把Radius報文中的EAP域提取，封裝成EAP-request報文發送給Client；

 

⑩⑤ STA收到Radius server發來報文後，用服務器相同的方法生成加密密鑰，加密初始化向量和hmac的密鑰，並用相應的密鑰及其方法對報文進行解密和校驗，而後產生認證迴應報文，用密鑰進行加密和校驗，最後封裝成EAP－response報文發送給AP，AP以EAP Over RADIUS的報文格式將EAP-Response發送給認證服務器Radius Server,而且帶上相關的RADIUS的屬性，這樣反覆進行交互，直到認證完成（注：對於不一樣的認證方法交互流程不一致，一般的認證方法爲：PEAP-MSCHAPV2或者GTC(IBM LDAP支持的,有關於PEAP-GTC的過程就是在認證的時候按照GTC/OTP的過程在PEAP添加的一個過程罷了，再注：在傳送完密碼後要傳一個長度爲1的數據爲0的包過去後纔會獲得SUCESS連通網絡)，下面由單獨認證流程,若是是SIM認證，還須要跟HLR/AUC設備進行數據交互，而且使用AS做爲認證服務器）,在認證過程當中，Radius Server會下發認證後用於生成空口數據加密密鑰（包括單播、組播密鑰）的PMK給STA；

 

⑩⑥ 服務器認證STA成功，會發送Access－Accept報文給AP，報文中包含了認證服務器所提供的MPPE屬性；

 

⑩⑦ AP收到RADIUS-Access-Accept報文，會提取MPPE屬性中的密鑰作爲WPA加密用的PMK,而且會發送EAP－success報文給STA。

 

 

 

企業無線認證方案：Windows Server NPS + CA證書 + AD域控

公司以前Windows 10客戶端認證須要手動配置EAP-TTLS進行無線網絡認證，認證服務器爲FreeRadius，如今能夠結合域控搭建Radius認證服務器(Windows Server NPS)，固然認證的用戶數據也從域控活動目錄數據庫中獲取，Windows Server NPS做爲認證服務器，利用認證方式爲PEAP，能夠免配置文件，由於Windows 10中會默認使用該認證方式進行服務器交互認證，無需設置。但Windows 7和XP須要設置(加域的用戶能夠利用組策略，沒加域的客戶端可使用腳本導入模板，後續說明)，後續若是須要作有線端口的認證也是能夠的。若是後續全部Windows客戶端加入域控，那麼就無須手動進行認證，客戶端會默認使用域控帳戶進行認證，大大方便後續的網絡接入管理工做。

 

AD域控(DNS)-->CA服務器-->NPS服務器(解決WIFI認證問題)

驗證方式：

1. PEAP驗證：使用證書＋AD用戶集成認證;
2. PEAP驗證：使用密碼+AD用戶集成認證；

若是部署基於證書的身份驗證方法，如可擴展身份驗證協議-傳輸層安全性(EAP-TLS)，受保護的可擴展身份驗證協議-傳輸層安全性(PEAP-TLS)，和 PEAP-Microsoft 質詢握手身份驗證協議版本 2 (MS-CHAP v2)，必須對全部你 NPS註冊服務器證書。 服務器證書必須：
知足最小服務器證書要求，如中所述爲 PEAP 和 EAP 要求配置證書模板
由證書頒發機構頒發(CA)受信任的客戶端計算機。 在當前用戶和本地計算機的受信任的根證書頒發機構證書存儲中存在其證書時，CA 是受信任。
如下說明幫助管理 NPS 中部署受信任的根 CA 其中是第三方 CA，如 Verisign，或已部署的公鑰基礎結構是 ca 的證書(PKI)使用處於活動狀態Directory 證書服務(AD CS)。

• 部署服務器證書用於 802.1x 有線和無線部署(拋棄)
• 部署密碼-基於 802.1x 通過身份驗證無線訪問(使用)

由於 PEAP-MS-CHAP v2 要求用戶提供密碼-基於的憑據而不是在身份驗證過程當中的證書，它是一般更容易、 成本更低比 EAP部署-TLS 或 PEAP-TLS。

部署 802.1x 身份驗證無線訪問與 PEAP-MS-CHAP v2：

• IEEE 802.1X
• RADIUS 身份驗證
• 無線身份驗證和密碼：WPA2-企業使用 AES

認證過程：客戶端輸入用戶名和密碼給AC，AC傳遞給NPS服務器，NPS服務器讀取AD目錄數據庫進行認證，認證經過後受權，從POE交換機DHCP獲取IP，而後網絡暢通。