最近做Active Sessions限制，發現，運作不如預期。怪了，以前這樣可以，現在卻異常，讓LLM搜尋，是6.11版本之後發生的。我那時候做的版本記得是6.9，那不行了，要如何修正呢？
要做Active Sessions，首先要做RADIUS Accounting，ClearPass才能透過查詢RADIUS Accounting過濾出Active Sessions。
在6.11版本不好使，原因就出在於過濾使用的語法。
本文會用自訂語法，修復查詢失敗的錯誤，並且得到更符合標題型式，即MAC Cache訪客認證的情境，要如何查出。
前置條件
RADIUS：一定要做RADIUS認證，才能用RADIUS Accounting。
RADIUS Accounting：有計量才能知道Username使用狀況，是否在線。Client上線或是離線，Network Authentication Server(NAS)都會發送訊息給ClearPass，讓ClearPass能即時掌握Client上線情況。
RADIUS Interim：定期更新Client使用量，主要作為網路使用量偵測並即時觸發限制，需要在NAS與ClearPass開啟對應的功能。※然而Active Session查詢是用不到。
ClearPass Insight：要Enable，ClearPass才會有insight方面相關數據，而Active Session數據來源即是 [Insight Repository]。
[Insight Repository]：用語法查詢RADIUS Accounting，得到Active Sessions。
Service Authorization：認證服務授權源要套用[Insight Repository]。
認證做MAC Cache功能的概念
在網路認證，如果走Captive Portal的型式，那麼Initial Role的目的就是讓Client跳出Captive Portal。然而登入成功之後，使用者因故，像是出去吹風吃午餐，可能裝置斷線五分鐘進而被NAS判定為斷線而清除認證快取，於是回到Initial Role。
於是變成，上午一次完整Captive Portal認證，下午一次，當然還有可能更多，於是變成「困擾」。
「能不能認證成功一次之後，一天就輸入一次，不要更多次？」
這個想法就催生出MAC Cache的概念，認證成功過的MAC，在一定時間內重新認證時，就直接取得通過認證的Role。
於是認證被拆成兩個階段：MAC、Web。
MAC認證檢查MAC是否存在有效的MAC Cache，此時Username是MAC Address。
Web認證檢查Account是否有效，此時Username是Account的Username。如果有效，就在該裝置屬性寫入一個MAC Cache的有效時間。
於是就能完成一個MAC Cache型式的Captive Portal認證。
Sessions限制運作
在ClearPass，Guest的部分可以限制同時使用數，這部分要生效，需要套上一個Profile，如果只限制一個Active Session，Profile內容如下：
※Guest User的同時使用數限制，只要把Session-Check Active-Session-Count的值改為「%{GuestUser:simultaneous_use}」則可。
運作方式是，在「登入成功」後，也就是套用配置之後，檢查Active Session，超過1就斷線。
但是如果沒有講清楚說明白，網路使用者會覺得是不是網路怪怪的，為什麼登入成功後就一直跳掉？
我認為做成 Reject 型式，不要讓人登入成功，就不會產生一下能用，一下不能用的感覺，因為從始至終都不能正常用。
原生Active Sessions Filter的狀況
以下是從ClearPass 6.11版，[Insight Repository]取出的Filter，然後稍微整理。
SELECT COUNT(*) AS active_count
FROM radius_acct
WHERE
(username = '%{Authentication:Username}'
OR calling_station_id = '%{Connection:Client-Mac-Address-NoDelim}'
)
AND start_time >= NOW() - INTERVAL '2 day'
AND end_time is NULL;
這邊可以看到使用 username 與 calling_station_id 同時符合做搜尋，有開始但沒有結束的Session有幾個。
剛剛沒提的狀況，就是語法沒有整理，整理成上面的型式就能用，複製程式碼區塊蓋過原本的，此外，整理後也比較好看懂條件。
順一次認證流程，先來個一臺裝置的情境：
MAC認證時，Accounting寫入，username是mac，calling_station_id也是mac。由於Active Session是在認證前查詢，應該要是0。
Web認證時，Accouting改變，username是username，calling_station_id是mac。由於Active Session是在認證前查詢，應該要是1。
MAC Cache狀態，MAC認證時，Accounting寫入，username是mac，calling_station_id也是mac。由於Active Session是在認證前查詢，有可能是0或1。1是如果來不及清除，就會是1。
透過CoA，就會導致馬上重新認證，就可能會發生Active Sessions是1的狀況。
如果我在MAC認證時限制Active Session是0才算符合MAC Cache，這情況就會出狀況。若改為1，又可能出現實際上兩個裝置同時連線。
如果兩臺情況之下，就複雜一點，可分為：無、初次MAC認證、Web認證、MAC Cache階段MAC認證，然後兩臺裝置都可能處於不同階段。
我們要堵上漏洞應該換個想法，不要抓Active Session數值，而是抓跟認證裝置不同MAC的Active Session數值。
不是Active Sessions，而是Diff MAC Active Sessions。
在[Insight Repository]新增兩個Filters，「diff_mac_active_sessions_mac」作為MAC Mache認證時使用，「diff_mac_active_sessions_web」作為Web認證時使用。
至於屬性Endpoint:Guest_Username則在下個段落會說明。
SELECT count(DISTINCT calling_station_id) AS diff_mac_active_sessions_mac
FROM radius_acct
WHERE end_time IS NULL
AND username = '%{Endpoint:Guest_Username}'
AND calling_station_id != '%{Connection:Client-Mac-Address-NoDelim}'
AND start_time >= NOW() - INTERVAL '2 day'; SELECT count(DISTINCT calling_station_id) AS diff_mac_active_sessions_web
FROM radius_acct
WHERE end_time IS NULL
AND username = '%{Authentication:Username}'
AND calling_station_id != '%{Connection:Client-Mac-Address-NoDelim}'
AND start_time >= NOW() - INTERVAL '2 day'; 用這想法，再次順一臺情形：
MAC認證時，Accounting寫入，username是mac，calling_station_id也是mac。由於Diff MAC Active Session是在認證前查詢，應該要是0。
Web認證時，Accounting改變，username是username，calling_station_id是mac。由於Diff MAC Active Session是在認證前查詢，應該要是1。
MAC Cache狀態，MAC認證時，Accounting寫入，username是mac，calling_station_id也是mac。由於Active Session是在認證前查詢，應該要是0。即便裝置先前的Accounting是如果來不及清除，也不會影響。
現在一臺能夠順利了，換成兩臺。
第一臺裝置直接做完Web認證，目前Sessions是
- username是username，calling_station_id是mac1。
那換第二臺Web認證，由於Active Session是在認證前查詢，應該要是1，於是我在Web認證設定Diff MAC Active Sessions等於0才能通過認證，就能順利攔劫。
不過第一臺不小心斷開，重新以MAC Cache階段連上，目前Sessions是：
- username是mac1，calling_station_id是mac1。
那換第二臺Web認證，由於Diff MAC Active Session是在認證前查詢，此時mac2或是username都查不到第一臺的Session，得到結果應該是0，於是第二臺順利通過Web驗證。
這個漏洞是基於MAC Cache是MAC認證，MAC認證Username是裝置的MAC，要修補它，我們要做的是讓MAC Cache通過的Username是之前Web認證通過時的Username。
在裝置紀錄Web認證時的Username作為MAC Cache使用
這邊推薦新增一個屬性，範例為「Guest_Username」。
新增兩個Enforcement Profiles，一個把username寫入裝置屬性。一個把裝置屬性作為Username。
當然如果要用既有的裝置屬性「Username」也是可以，但是，這個屬性也可能會用於其他認證流程，新增一個專用的，可以避免衝突發生，也能讓屬性用途更清楚，讓維運者更好懂。
Update_Guest_Username套用在Web認證成功後。
Use_Guest_Username套用在MAC Cache認證成功後。
回到上個段落有狀況情境：第一臺MAC Cache階段，第二臺進入Web認證。因為Use_Guest_Username，讓第一臺的Username是呈現本來Web認證通過時的username，所以目前Sessions是：
- username是username，calling_station_id是mac1。
那換第二臺Web認證，由於Diff MAC Active Session是在認證前查詢，此時username都查到第一臺的Session，得到結果應該是1，因此命中Session大於0的配置，於是第二臺在Web驗證被拒絕。(提示：情境要求同帳號不能有兩個Session在線。)
當然，第一臺可以斷線讓Session回到0，第二臺Web認證就能登入成功，來到兩臺裝置都有MAC Cache的情況。
假設這狀態，是第一臺裝置先連上，於是Session是：
- username是username，calling_station_id是mac1。
第二臺連線做MAC認證，由於Diff MAC Active Session是在認證前查詢，而Endpoint:Guest_Username是在Web認證時成功就寫好的，於是以Endpoint:Guest_Username查詢運作下，應該得到1。然後命中Session大於0的情況，也就不該直接配置MAC Cache的Role，給與Captive Portal的Initial Role，讓第二臺裝置跳出Captive Portal，就能完成阻擋。
AI用圖示整理
後記
最近在準備ACX，開始籌備大量LAB與實作。
這篇文章來自於一個Trouble Shooting，因為標準範例不好使。
剛好ACX實作考試要求就是夠快夠準，正好可以練練手感。
我快速識別限制，克服限制，快速造出一個過程，探索是否意外？然後封閉意外可能性。
這過程不簡單，邏輯要好要能模擬，還要改動認證源過濾器。
希望分享給各位參考，增加更多想法上的可能性。