用戶文件如何工作
對於下面的答案,對指的是屬性值對(的AVP),也就是由一個屬性的運算符和值的元組。
有三個可以從用戶文件訪問的屬性(對)的列表。這些列表與特定的請求相關聯。
- 要求 - 包含通過網絡從NAS(網絡接入服務器)接收到的原始請求中的所有對。
- 控制 - 最初不包含對,但是填充了控制模塊如何處理當前請求的對。這是從用戶文件或unlang完成的。
- 回覆 - 包含想要通過網絡發送回NAS的對。
用戶文件模塊確定它將用於插入/搜索條目和操作員列出的對的列表。
條目的第一行包含檢查對必須匹配才能使用該條目。它還包含控制對,如果所有檢查對匹配,那麼您要插入到控制列表中的那些對。
注:這並不重要下令對列於控制對不會被插入,除非所有檢查對評估爲true。
檢查和控制對由使用的操作員區分。如果使用賦值運算符,即':='或'=',那麼該對將被視爲控制對對。如果使用'>','<','==','> =','< =','=〜'等等運算符,則該對將被視爲檢查對。
相同條目中的後續行僅包含回覆對。如果全部檢查對匹配,回覆對將被插入到回覆列表中。
明文口令
明文口令是一個嚴格的控制對。它不應該出現在其他任何列表中。
Cleartext-Password是一組屬性之一,它應該包含'reference'(或'known good')密碼,也就是用戶密碼的本地副本。此組中另一對的示例是SSHA密碼 - 它包含用戶密碼的醃製SHA散列。
參考密碼對由服務器中的模塊搜索,該模塊使用'用戶密碼'對'rlm_pap'對用戶進行身份驗證。
用戶密碼
用戶密碼是嚴格的請求對。它不應該出現在其他任何列表中。
用戶密碼包含在來自NAS的請求中。它包含用戶提供給NAS的密碼的純文本版本。爲了對用戶進行身份驗證,模塊需要將用戶密碼的內容與一個控件對比如Cleartext-Password進行比較。
在用戶設定的參考密碼時,你會看到類似的條目文件條目:
my_username Cleartext-Password := "known_good_password"
也就是說,如果用戶名在左邊(my_username)的值相匹配,然後將控制對Cleartext-值爲「known_good_password」的密碼。
要回答第一個問題的原因所在:
shad Cleartext-Password == "test"
不行的話,那是因爲你說的是文件模塊中的請求列表進行搜索,爲一對不要求存在列表,並且不應該存在於請求列表中。
你現在可能會想哦,我會使用用戶密碼==「測試」,而它會工作。不幸的是,它不會。如果密碼匹配,則條目將匹配,但用戶仍將被拒絕,請參閱下面的原因。
驗證型
的Auth-Type是嚴格意義上的控制對。它不應該出現在其他任何列表中。
服務器中有三個主要部分用於處理請求「授權」,「驗證」,「後驗證」。
授權是信息收集部分。這是完成數據庫查詢以授權用戶並檢索參考密碼的地方。這也是確定Auth-Type的原因,也就是我們要爲用戶執行的身份驗證類型。
身份驗證是調用特定模塊執行身份驗證的地方。該模塊由Auth-Type確定。
Post-Auth主要用於日誌記錄,並且應用更多策略,Post-Auth中運行的模塊由在Authenticate中運行的模塊返回的響應決定。
授權中的模塊檢查請求,如果他們認爲他們可以驗證用戶,並且未設置Auth-Type,則將其設置爲自己。
如果在請求中發現用戶密碼,rlm_pap模塊將設置Auth-Type ='pap'。
如果沒有設置Auth-Type,請求將被拒絕。
所以要回答你的第二個問題,你強制pap認證,這是錯誤的,你應該讓rlm_pap設置Auth-Type,然後你做的是密碼的平等檢查,而不是設置控制對其中rlm_pap使用。
當rlm_pap在身份驗證中運行時,它會查找上述「引用」密碼集中的成員,如果找不到該密碼,它會拒絕該請求,這就是上述情況。
還有一種'神奇的'Auth-Type'Accept',它完全跳過了認證部分,只是接受用戶。如果您希望用於在不使用rlm_pap的情況下進行明文密碼比較,則可以使用:
shad Auth-Type := Accept, User-Password == "test"