FreeRadius 3.0.27中require_message_authenticator配置未生效问题咨询

问题分析 #

你遇到的核心矛盾是：全局配置require_message_authenticator = yes后，不含Message-Authenticator的Access-Request仍被接受，且服务器日志显示收到的请求带有该属性。这通常由以下几种原因导致：

• radclient自动添加Message-Authenticator：部分版本的radclient会自动为包含User-Password的请求生成并添加该属性，即使你在auth.txt中未指定。
• NAS客户端配置覆盖全局设置：如果在clients.conf中给发送请求的NAS单独设置了require_message_authenticator = no，会优先于全局security配置生效。
• 服务器模块自动补全属性：preprocess等模块可能在请求进入验证流程前自动添加Message-Authenticator，导致绕过检查。

验证与解决步骤 #

1. 确认客户端配置是否存在例外 #

打开clients.conf检查对应NAS的配置段：

cat /etc/raddb/clients.conf

如果存在类似以下内容，删除或修改require_message_authenticator的值为yes：

client xxx.xxx.xxx.xxx {
    secret = radiussecret
    require_message_authenticator = no  # 该配置会覆盖全局设置
}

修改后重启radius服务：

systemctl restart radiusd

2. 抓包验证实际发送的数据包 #

用tcpdump抓取radius流量，确认发送的请求是否真的不含Message-Authenticator：

tcpdump -i any port 1812 -vvv -X

执行radclient请求后，查看抓包结果。如果数据包中出现Attribute 8 (Message-Authenticator)，说明radclient自动添加了该属性。此时可以改用更原始的工具（如手动构造数据包）测试，或尝试使用radclient的-k参数禁用自动添加（部分版本支持）。

3. 检查服务器配置是否生效 #

用以下命令验证配置语法并查看最终生效的require_message_authenticator值：

radiusd -XC | grep require_message_authenticator

如果输出结果中存在多个值，说明存在配置覆盖，需要找到优先级更高的配置（如sites-enabled中的设置）并调整。

4. 调试服务器处理流程 #

以debug模式启动radiusd，观察请求的完整处理路径：

radiusd -X

发送不带Message-Authenticator的请求后，查看日志中是否有模块自动添加该属性的记录（如preprocess: Adding Message-Authenticator attribute）。如果有，需要调整preprocess模块的配置，或确保全局security设置的优先级高于模块设置。

总结 #

最常见的原因是clients.conf中的NAS单独配置覆盖了全局要求，或radclient自动补全了属性。通过抓包和debug日志可以快速定位问题，确保全局require_message_authenticator = yes的配置未被局部配置或模块行为绕过。

内容的提问来源于stack exchange，提问作者Sundararajan