Portal＋MAC 速成指南

最新 05-24

Portal在英語中是入口的意思。Portal認證通常也稱為Web認證，一般將Portal認證網站稱為門戶網站。

未被認證的用戶上網時，網路設備強制用戶登錄到特定站點，必須在門戶網站進行認證，只有認證通過後才可以使用互聯網資源。

當然在Portal 認證前，可以為用戶設置白名單，讓未認證的用戶可以主動訪問白名單中的Portal認證網站;對於非白名單的網站，則提供頁面強制跳轉，並要求輸入用戶名和密碼進行認證，從而開始Portal認證過程，這種方式稱作強制認證。

Portal業務可以為用戶提供方便的管理功能，門戶網站可以開展廣告、社區服務、個性化的業務等。在Portal 認證過程並不完美，用戶在連接超時後會出現重認證的問題，在日常應用中可能會出現多次認證，為了避免這樣的問題，提出在Portal 認證中，可智能緩存用戶的MAC地址，將用戶賬號與MAC地址做捆綁，在預設的捆綁期內，用戶可以通過MAC地址直接無感無線重關聯，多次認證，提高用戶接入體驗感。

補充說明： MAC地址在OSI模型中是屬於二層，Portal 認證是基於IP地址，將用戶流量重定向到Portal門戶，並進行認證，因此用戶會先獲取到IP地址，涉及到IP，那麼該認證模型在OSI模型中是三層認證；因此MAC認證的順序是高於Portal 認證，並且在MAC地址認證通過後，就可以避免掉基於3層的Portal 認證。如果用戶認證不通過，則需要進行Portal 認證。

在對Portal + Mac 認證有了初步了解之後，接下來將介紹實現過程以及配置。

1)MAC 認證流程圖：

a)當用戶連接到無線後，無線控制器會要求進行MAC認證

b)無線控制器依據系統配置的【MAC認證配置文件】及【MAC認證伺服器】，向AAA 平台送出認證請求

【MAC認證配置文件】：規範了認證時MAC地址的格式，如MAC地址分割符，可選 " : " (引號)或 " - " (減號), 對於MAC地址的寫法，如字元大寫或小寫，也可以規定，因此務必注意配置時MAC地址的格式，配置與存在賬號的賬號不一致，則會導致認證失敗

【MAC認證伺服器】：基於AAA框架定義的機制來實現，並通過radius協議來傳遞整個認證過程，授權及記賬過程。該認證伺服器，可以是控制器自身，也可以是外置支持radius協議的平台(如aruba clearpass)

c) 在【MAC認證伺服器】檢查過認證報文中的MAC地址與存在的白名單匹配之後，則會發送radius-accept 通知控制器放行終端。反之不在白名單的MAC地址，則會向控制器發送radius-reject 報文，因此MAC地址認證失敗

d)對於MAC地址認證失敗的用戶，在aruba 的設計中，終端將會獲得在aaa profile 下initial-role所對應的role(角色)；如果不配置認證，那麼用戶將會獲得initial-role

注意：連接無線時輸入靜態密碼的，不是認證，而是在關聯時雙方匹配加密密碼； MAC認證與802.1x認證都屬於二層認證，並且MAC認證優先於802.1x認證，會先進行mac認證，但通過mac認證後還需要進行802.1x認證。

2)Portal 認證流程圖：

Portal 認證流程圖：

當用戶在獲得initial role 之後，那麼接下來就需要執行Portal 的認證流程

a)默認情況下，智能終端或智能終端里安裝的程序，在網路變更後都會網路自動發起一個檢測報文，確認網路的可達性，因為有了這個機制，部分機器在連上無線後會自動跳出Portal 頁面，要求進行Portal鑒權的過程。如果沒有自動跳出，則需要用戶手動打開瀏覽器，訪問任意網站，來實現跳轉！

注意：

配置不當會導致重定向頁面的時候，出現空白頁；出現問題時可參考如下思路：

a.1)DNS不可解析域名；用戶在初始化訪問任意網站時，先要解析該網站的地址，然後才發現報文；如果無法解析，終端則無法封裝報文，則無法進行重定向；

a.2)跳轉的地址不被允許訪問；如果是外置Portal server ，則需要在initial-role 里放開對portal server 的訪問，否則無法重定向；

b)當用戶獲得Portal頁面後，輸入用戶名密碼後，並點擊提交；提交的地址是控制器的域名，當控制器收到後，將提交的信息轉換為radius 數據包，遞送給 radius 伺服器（可以是控制器自己，也可以是外部認證伺服器）

c) 當radius 收到報文後，解開數據包後則開始找賬號數據源進行查找，在這裡可以是AD/LDAP/或控制器自己的本地資料庫（在portal 中將會採用pap 採用明文格式發送用戶賬號）

d)當驗證用戶名密碼正確後，radius 會利用AAA 機制，向控制器返回認證成功；在採用Clearpass 作為外置認證源時，可以利用clearpass將portal 認證中的MAC地址提取，寫入到endpoint 資料庫里標識為 "Known"，未來可以用於MAC地址的認證；

個人推薦：向endpoint 里寫入mac地址時，建議將同時也給該mac地址推入 role 、用戶名等信息

e) 如果用戶未通過認證，則一直處於Portal 的角色中，需要注意的是，不要讓這樣的用戶存在非常多，否則會導致控制器繁忙的處理跳轉請求。

在理解了大致的流程之後，那麼開始來進行實戰演練(所有有帶顏色的字體，為配置文件的名字，可依據自己的實際情況進行修改). 將配置分為2塊，1塊為控制器，另外一塊為外置的Clearpass：

1.無線控制器配置

1.1) 無線客戶端地址段

將這個配置擺放在最前面，原因是很多工程師在配置Portal認證的時候，忘記給控制器配上IP地址，如果控制器沒有IP地址，就沒有辦法跟客戶端進行通訊，地址轉換的任務也沒辦法完成。因此務必先配置地址。

假設用戶獲得的VLAN 號是 100，那麼VLAN 100 對應的地址段是 192.168.100.0/24，配置如下：

vlan 100 //創建vlan

interface vlan 100

ip address 192.168.100.x 255.255.255.0

no shut

//如果是AOS 8.0 則進入設備的組裡，將如上配置進行適應性修改即可，如：

(MM-A) [mm] #cd /md/group1

(MM-A) [group1] #configure ter

Enter Configuration commands, one per line. Endwith CNTL/Z

(MM-A) [group1] (config) #

也可以配置採用dhcp 客戶端的形式， ip address dhcp-client

1.2) 認證伺服器配置

無論是portal 或是mac 認證，都需要配置相應的認證伺服器，否則控制器無法基於AAA架構對用戶進行認證。因此在這裡開始定義配置：

aaa authentication-server radiusportal-server

host x.x.x.x //輸入伺服器的IP地址

key xxxx. // 輸入radius 密碼，自定義，密碼需要與外置radius伺服器上的密碼一致

nas-identifier xx //用來標識作用，隨意取值；建議可以寫portal or mac

配置完成radius server，還需要將radius server 套入到server-group 中，才能應用到認證配置文件中，因此需要在定義server-group

aaa server-groupportal-server-group

auth-serverportal-server

默認情況下，控制器就內置了本地認證，伺服器組名字為 default 及internal ,如果採用本地認證可不需要配置認證伺服器組；

為了在之後的環節中，方便在一個SSID下對portal 及mac認證容易區分，因此建議在這裡在做一個mac 認證伺服器的相關配置

aaa authentication-server radiusmac-server

host x.x.x.x

key xxxxx

nas-identifiermac //方便做區分，配置了標識符為mac

aaa server-groupmac-server-group

auth-servermac-server

1.3) captive-portal profile 的配置

在接入過程中，需要重定向用戶的任何數據到某個頁面，因此就需要定義captive-portal profile , 如下是配置：

aaa authenticationcaptive-portalportal-cp

server-group portal-server // 將Portal的認證伺服器組關聯, 默認不配置的情況下，是採用本地認證

no logout-popup-window //登陸成功後，不顯示「登出」按鈕

switchip-in-redirection-url //建議在重定向過程中，可以將控制器的IP地址帶到頁面中，未來一些特殊應用會用到

no welcome-page // 登陸成功後，不重定向到歡迎頁面

redirect-pause 0 //登陸成功後，等待跳轉的時間

server-groupportal-server-group //關聯Portal認證時採用的伺服器！！！不要忘記哦！

1.4) initial-role 的配置

在上面的介紹中，可以理解到，portal的過程是依靠user-role 里配置了相關訪問控制列表，及重定向Portal的策略，當用戶訪問網路資源時觸發了策略，從而將流量導流到captive-portal profile ,讓用戶訪問captive-portal profile 中指定的登錄頁面（login page）

如下是兩個默認系統的策略合集(不需要配置，但要懂得原理)，在inital-role 里將會引用到

ip access-list session logon-control

user any udp 68 deny

any any svc-icmp permit

any any svc-dns permit

any any svc-dhcp permit

any any svc-natt permit

any network 169.254.0.0 255.255.0.0 any deny

any network 240.0.0.0 240.0.0.0 any deny

//在上面的策略集里，定義里終端連接上無線後，可以獲得IP地址，可以進行DNS查詢，並可以進行ping 及源地址轉換（同時不允許無線客戶端作為DHCP伺服器向其他無線客戶端派發DHCP地址）；如果需要設計更嚴謹，可自己定義策略，不用默認的；但是建議要允許dhcp ,dns

ip access-list session captiveportal

user alias controller svc-https dst-nat 8081

user any svc-http dst-nat 8080

user any svc-https dst-nat 8081

user any svc-http-proxy1 dst-nat 8088

user any svc-http-proxy2 dst-nat 8088

user any svc-http-proxy3 dst-nat 8088

//將用戶的80, 443,http 代理(3128, 8080, 8888)的所有訪問進行目的地址轉換並送入到8080 埠，對於https 則送入到8081埠；

如果採用控制器內置Portal認證，那麼初始化的用戶角色可以這樣配置：

user-role ac-portal

access-list session logon-control

access-list session captiveportal

對於我們需要配置外置Portal認證，那麼在上面的角色還是不夠的，需要客戶端對portal 的訪問,因此需要增加：

ip access-list sessionpermit-cppm

user host x.x.x.x svc-http permit

user host x.x.x.x svc-https permit

user-roleext-portal

access-list session logon-control

access-list sessionpermit-cppm

access-list session captiveportal

captive-portalportal-cp //將角色中關聯 portal-cp 認證配置文件

通過如上配置，就配置好了user-role 及相關的策略，但還沒有關聯到無線的相關配置文件中！

1.5) WLAN 相關配置

可選配置，增加MAC認證

先mac 認證的白名單格式，同時這也是規範控制器遞交MAC地址作為用戶名時的格式；按照如下寫法，MAC地址的格式為： 00:1a:2b:3c:4d:5e. , 分隔符是" : " , 同時字元全部小寫

aaa authentication macmac-auth-profile//MAC 地址庫白名單格式

delimiter colon //分隔符為冒號：

case lower//全部小寫：

wlan ssid-profileopen-ssid-profile

essid open-ssid

aaa profileopen-aaa-profile

initial-role ext-portal

authentication-macmac-auth-profile // 引用mac地址庫白名單格式

mac-default-roleauthenticated

mac-server-groupmac-server-group //注意，這裡引用了1.2）配置的mac 認證伺服器

wlan virtual-apopen-vap

aaa-profileopen-aaa-profile

vlanxx // 輸入VLAN 號碼（用於獲得的VLAN ，注意該VLAN號碼下，控制器必須有IP地址）

ssid-profileopen-ssid-profile //關聯無線信號名稱

band-steering

broadcast-filter all

broadcast-filter arp

ap-groupdefault

wlan virtual-apopen-vap //將VAP 配置文件關聯到 AP註冊的組中

//如果是AOS 8.0 則進入設備的組裡，將如上配置進行適應性修改即可，如：

(MM-A) [mm] #cd /md/group1

(MM-A) [group1] #configure ter

Enter Configuration commands, one per line. Endwith CNTL/Z

(MM-A) [group1] (config) #

截止到此，無線控制器這一側的配置已完成；只要AP註冊到default 組下，就可以放出無線信號為 open-ssid 的信號,如果沒有，請仔細核對上面的配置。

如下開始進行clearpass 這一側的配置

2.1) Clearpass 配置,NAS客戶端

登錄CPPM的配置頁面， https://x.x.x.x/tips ,默認用戶名admin/eTIPS123

在上面的ip or subnet address ,可以填入固定IP 、網段或地址範圍，比如

192.168.1.10 //固定IP

192.168.1.0/24 //網段

192.168.1.1-100 //地址範圍

固配置網段或地址範圍的時候，面臨多個設備可以向NAS伺服器（CPPM）進行認證請求，但這樣的情況下，如果密碼太簡單就容易遇到安全問題，為了安全性，建議radius key 里的密碼設置複雜性高；注意，這裡的radius key 必須跟控制器里的radius key 秘鑰一致【radius key 配置詳見文章中 1.2）的配置範本】

2.2) 配置登陸頁面

登錄CPPM的【訪客配置頁面】， https://x.x.x.x/guest ,默認用戶名admin/eTIPS123

配置完成上述頁面後，頁面下拉，獲得如下：

點擊 save and reload ，則完成配置

2.3) 配置認證源

本例中以添加的是 LDAP作為舉例

登錄到clearpass 管理頁面中，點擊configuration—source，即可看到當前clearpass 內置當前的認證源

在新建過程中可選擇需要創建的認證源的類型，如ldap , sql , http 等等

填入認證源的名字

下圖為LDAP資料庫，具體信息請聯繫LDAP管理員填入，格式參見如下：

配置後可利用過濾器向LDAP進行查詢，通過查詢語句獲取，賬號信息及對應在LDAP中的其他屬性信息，通過獲悉屬性，可以用來做授權

在創建好的LDAP認證源，點擊屬性，並點擊如下圖的「便簽圖標」

在下圖中的Filter Query語句通常要向LDAP管理員詢問，並填入；下圖展示的為默認語句，可不需要額外配置

在configuration 下點擊memberof並在enabled as 處，選擇為attributes ，保存即可

如果網路中有多台LDAP或多個相同的ODBC,在同一個認證員下，可點擊添加備份，即可實現認證源的添加

由於創建的是LDAP的備份，因此只需要修改IP及LDAP管理員再次輸入密碼信息

注意上面的userPassword,如果LDAP欄位存儲密碼不是採用userPassword，則需要修改，具體需要詢問LDAP管理員；【同時注意，如果用LDAP 要用來做802.1X 認證，默認LDAP的密碼hash 不是採用NTHASH，因此一定要讓LDAP管理員去修改資料庫密碼存儲方式，並且支持NTHASH，否則無法進行802.1x認證,如果是微軟的AD域控，則不需要考慮這部分，默認密碼存放採用NTHASH】

2.4) 配置服務---服務1 （預驗證的錯誤信息返回）

這個配置是為了提升用戶的體驗感，很多用戶用Portal認證的其中一個原因就是Portal的交互感好，因此希望藉由Portal認證，告訴接入的用戶，用戶名或密碼錯誤，或其他首先原因。由於在前一步我們設置了預驗證，並啟用為app-auth ，可以很好幫助我們解決這塊問題，下面將對這塊的配置進行介紹：

配置錯誤信息提示：

登陸CPPM--enforcement--profile ,添加add

配置- application enforcement profile，參考如下：

定義返回給用戶顯示的信息

在如上配置完成後，未來可調用向用戶顯示"用戶名錯誤"，因此可依照如上方式，重新建立一個enforcement profile, 並將顯示信息寫為「密碼錯誤」

在如上配置完成後,只是學會了發送動作，但是還還沒有跟事件關聯

我們最終要的效果是，如果用戶進行認證時，CPPM 內置返回代碼錯誤為 xxx ,那麼就在頁面上顯示對應的錯誤信息！

接下來開始配置策略：

新建一個enforcement policies

點擊rules ，開始添加規則

最後規則添加成類似如下：

代碼說明：

201=用戶名未找到

202=密碼錯誤

216=密碼錯誤 //採用LDAP時會出現錯誤216

到此為止，規則動作都已配置完成，通過如上我們可以預設的是，如果用戶進行Portal預驗證的時候，認證源沒找到用戶名，錯誤代碼為201，通過動作，我們會提示用戶用戶名錯誤；如果是密碼錯誤，會出現202或216，那麼就可以向用戶返回密碼錯誤的情況，如果是用戶名、密碼都對，那麼就可以直接通過。默認，其他情況都會被拒絕。

雖然規則完成了，但是還要進入下一個階段，配置【認證服務】，才能將整個預驗證完成；

在認證中可能網路環境下會存在多個無線SSID,並且有多種認證方式，要合理並且不重疊的區分這相對來說非常複雜，但是CPPM里可以利用認證跟蹤器，幫助用戶快速找出唯一的屬性，去實現認證服務的區分。

我們可以做一條認證服務，裡面不配置任何參數，那麼就可以對認證的過程進行便利捕捉：

添加一個服務：

編輯服務的規則

選擇認證源

將之前編輯的enfocement profile 套入 (因為用的是application 的服務，因此如果沒有新建application 的enforcement policy ，這裡是看不到策略的)

此時可以通過網頁做個認證，在進入到access tracker 里查看日誌，點擊Input-- computed attributes , 就看到如下：

（細心的人也可以發現，上面紅框的標識為創建的訪客登陸表單的網頁名字, portal）

通過如上的舉例，我們已知曉了Portal預驗證時會產生的報文，並且可以用來做區分，那麼我們就對之前配置的認證服務，做服務規則的修改，就可以正式使用了，進入認證服務，添加service rule

通過這樣的配置，在網頁上登錄時，就會顯示如下效果：

//在完成了如上配置之後，我們還要接著往下做，在app-auth 後，需要實現的是基於radius 的認證，並讓radius 通知控制器，放行用戶

2.4) 配置服務---服務2（通知控制器放行用戶）

服務區分參數

認證方法選擇PAP，並選擇相應的認證源

選擇預設的sample allow access policy即可

到此為止portal 的配置及portal 門戶預驗證的配置都已完成（沒有複雜的控制）

如果需要實現mac 無感知認證，那麼就需要接著往下，進行配置

2.5) Portal智能記錄MAC功能

MAC地址認證對應用而言是最無感，最便利的認證；但因為收集MAC地址則會帶來非常複雜，繁瑣的過程；因此對於Portal+MAC地址認證而言，就需要實現將MAC地址記錄的功能；那麼接下來將會介紹，在Portal認證後進行MAC地址存放、備註、標記等功能。

默認情況下，只要通過PORTALmac802.1x認證的終端，在CPPM的endpoint 都會產生一條記錄，不過只是寫了個MAC地址，並且標記為【未知】；未來我們希望在標記這個MAC地址的時候，可以關聯用戶名，設置為了方便，還給這個終端mac地址寫入【角色】，那麼可以這樣操作：

進入到endpoint 下，點擊現有的任何一個mac地址

點擊這個終端的屬性，添加一個role 及對應的「值」. \默認情況下，endpoint 資料庫，沒有role 這個屬性可以寫，但在這裡手動創建後，未來就可以用； username 默認系統有，可以不用寫。

修改完成後，開始對智能記錄MAC地址的策略進行修改：

進入enforcement-profiles ，新建一個profile

修改送入的屬性：

配置完成後，點擊保存；

在這裡做個舉例，我們有三種類別的人群，未來要實現對這些人群擁有不同的無感知時間，如下表

為了方便未來調用，我通常喜歡將role 信息也推送到mac 地址里，所以上一步的操作，我們要執行多次；這裡省略（但是裡面輸入不同的role 名字,注意大小寫）

同時為了方便管理，我一般也建議將username 更新到endpoint 庫里，因此也要在創建一條update username

在屬性里，添加如下

注意：因為用戶名不是固定的，所以在這個過程中填入了一個變數 % , 會自動將用戶在portal 里填入的用戶名推送至endpoint 里（注意：寫的時候要採用英文鍵盤，注意大小寫）

完成規則後，我們開始來配置enforcement policy ,新建一個enforcement policy

選擇後，開始進入rules ,編輯規則

上面的意思是：如果在LDAP伺服器里，這個用戶組是IT，那麼就採用哪些enforcement profile, 在這裡，我調用了4個profile, 分別將MAC地址的用戶名，role, 及MAC地址辨識為「已知」

如果沒有LDAP，但是想完成這個部分的驗證，可以選擇用CPPM 的本地資料庫，就可以採用如下配置

先配置名為IT 的role

配置一個賬號，並且role 為IT

在回到之前配置enforcement pocliy 下，去創建規則，檢查本地賬號的role 為IT，就用相應的enforcement profiles 進行操作

完成後，enforcement policy 類似如下：

進入到認證服務，並更換之前配置的enforcement policy ,即可完成智能Portal的切換

驗證：

(忽略Portal認證截圖，請自行測試)

進入CPPM 的endpoint 里查看，發現變化：

進入到MAC地址之後點擊attributes ，發現到自動加入了username 及role , 跟之前配置的目標一致，表明測試成功。

2.6) 配置服務---服務3（開啟MAC認證功能）

接下來，如果我們配置了一個MAC認證服務，那麼結合之前在控制器上開啟的MAC認證，就可以自動的實現無感知認證了，但是這樣的認證是沒有時間限制的；換句話說就是，用戶一旦Portal認證通過後，自動的記錄了MAC地址，以後永遠都不需要回到Portal認證了。為此，我們需要做一些修改，時間基於時間的控制。

點擊primary ,參考如下信息，用戶名是appuser ,密碼隨便寫

點擊attributes , 添加filters 語句

貼入如下語句，

SELECT FLOOR(EXTRACT(EPOCH FROM (NOW() - user_auth_at)))::integer AS seconds_since_auth, FLOOR((EXTRACT(EPOCH FROM (NOW() - user_auth_at)))/60)::integer AS minutes_since_auth, FLOOR((EXTRACT(EPOCH FROM (NOW() - user_auth_at)))/3600)::integer AS hours_since_auth, FLOOR((EXTRACT(EPOCH FROM (NOW() - user_auth_at)))/86400)::integer AS days_since_auth FROM endpoints WHERE endpoints.user_auth_at

配置過濾器格式為如下：

配置完成後點擊保存，如下圖：

配置enforcement policy

配置規則：

規則編輯成如下：

注意：配置規則的時候,不要選擇為Authorization:[Endpoints Repository]!!!!!

完成後，開始配置MAC地址的認證服務，進入到configuration---service , 點擊add ,並按照下圖進行操作：

在認證方式這裡選擇MAC AUTH ,不要添加ALLOW ALL MAC AUTH , 如果選擇了ALLOW ALL MAC AUTH 那麼如果這個MAC地址是「未知」狀態，也可以通過MAC認證，這不是我們需要的；我們需要的是通過PORTAL 認證後，將MAC地址標識為「已知」的，才有資格進行MAC認證。