用户文件的工作原理
对于下面的答案,pairs 指的是属性值对 (AVP),即由属性、运算符和值组成的元组。
可以从用户文件访问三个属性列表(对)。这些绑定到服务器当前正在处理的请求,并且它们不会在多个请求/响应轮次中持续存在。
- request - 包含通过网络从 NAS(网络访问服务器)收到的原始请求中的所有对。
- control - 最初不包含对,但填充了控制模块如何处理当前请求的对。这是通过用户文件或 unlang(虚拟服务器中使用的 FreeRADIUS 策略语言)完成的。
- 回复- 包含要通过网络发送回 NAS 的对。
用户文件模块确定将用于插入/搜索的列表、条目中列出的对的位置以及运算符。
条目的第一行包含必须匹配才能使用条目的检查对。第一行还包含控制对,如果所有检查对都匹配,您希望将其插入到控制列表中。
注意:这些对的列出顺序无关紧要。除非所有检查对都评估为真,否则不会插入控制对。
检查和控制对由使用的操作员区分。如果使用赋值运算符,即':=' 或'=',则该对将被视为控制对。如果使用了等式运算符,例如 '>'、'<'、'=='、'>='、'<='、'=~',则该对将被视为检查对。
同一条目中的后续行仅包含回复对。如果所有检查对都匹配,则回复对将插入回复列表中。
明文密码
Cleartext-Password 是严格意义上的控制对。它不应出现在任何其他列表中。
Cleartext-Password 是一组属性之一,它应该包含“参考”(或“已知良好”)密码,即用户密码的本地副本。该集合中另一对的示例是 SSHA-Password - 它包含用户密码的加盐 SHA 哈希。
参考密码对由能够使用“用户密码”对验证用户的模块搜索(在控制列表中)。在这种情况下,该模块是“rlm_pap”。
用户密码
User-Password 严格来说是一个请求对。它不应出现在任何其他列表中。
用户密码包含在来自 NAS 的请求中。它包含用户提供给 NAS 的密码的明文版本。为了对用户进行身份验证,模块需要将 User-Password 的内容与Cleartext-Password 等控制对进行比较。
在设置参考密码时,在用户文件条目中,您会看到如下条目:
my_username Cleartext-Password := "known_good_password"
也就是说,如果用户名与左侧的值 (my_username) 匹配,则插入值为“known_good_password”的控制对 Cleartext-Password。
回答第一个问题的原因:
shad Cleartext-Password == "test"
不起作用,这是因为您告诉 files 模块在请求列表中搜索请求列表中不存在且不应该存在于请求列表中的一对。
您现在可能在想,哦,我将使用 User-Password == "test" 代替,它会起作用的。不幸的是它不会。如果密码匹配,则条目将匹配,但用户仍将被拒绝,原因见下文。
认证类型
Auth-Type 严格来说是一个控制对。它不应出现在任何其他列表中。
服务器中有三个主要部分用于处理请求“授权”、“身份验证”、“身份验证后”。
授权是信息收集部分。这是进行数据库查找以授权用户并检索参考密码的地方。这也是确定 Auth-Type 的地方,即我们要为用户执行的身份验证类型。
身份验证是调用特定模块来执行身份验证的地方。模块由 Auth-Type 确定。
Post-Auth 主要用于记录日志,并应用进一步的策略,在 Post-Auth 中运行的模块由在 Authenticate 中运行的模块返回的响应确定。
authorize 中的模块检查请求,如果他们认为可以对用户进行身份验证,并且未设置 Auth-Type,则将其设置为自己。例如,如果 rlm_pap 模块在请求中找到用户密码,它将设置 Auth-Type = 'pap'。
如果未设置 Auth-Type,则请求将被拒绝。
因此,要回答您的第二个问题,您正在强制进行 pap 身份验证,这是错误的,您应该让 rlm_pap 通过在授权部分的 files 模块之后列出 pap 来设置 Auth-Type。
当 rlm_pap 在身份验证中运行时,它会查找上述“参考”密码组中的一个成员,如果找不到,它会拒绝请求,这就是上面发生的情况。
还有一个“神奇”的身份验证类型“接受”,它完全跳过身份验证部分,只接受用户。如果您希望在没有 rlm_pap 的情况下使用用于明文密码比较,您可以使用:
shad Auth-Type := Accept, User-Password == "test"