我们已经部署了 Radius 服务器（Freeradius 3.x）并将其连接到我们的 LDAP 数据库（ForgeRock OpenDJ）。
我们已经成功配置认证协议使用有效证书并将其设置为默认连接方法。（几乎所有其他设置都保留为默认设置）
然而，当 EAP-TTLS 建立时，密码使用 PAP 传输。我不是网络专家，但我读到过 PAP 不安全，不应该使用？（我觉得网上有很多令人困惑的材料）
如果我尝试使用任何其他方式（例如 MS-CHAPv2）登录，则会失败并出现各种错误：
FAILED: No NT/LM-Password. Cannot perform authentication'
或者
freeradius_1 | (22) eap_md5: ERROR: Cleartext-Password is required for EAP-MD5 authentication
显然它需要额外的配置。
问题是，从 2019 年开始，当我们拥有 EAP-TTLS 时，使用 PAP 可以吗？或者我们应该考虑将不同的类型设置为默认类型？
我们的 LDAP 已对密码进行了哈希处理（显然如此），那么我们还有其他选择吗？基于这个文件我发现，这似乎是我们唯一的选择。
答案1
在这种情况下，只要服务器提供的证书得到请求者的正确验证，EAP-TLS/TLS 就能提供机密性（防止窥探）和完整性（防止修改）。
这里的关键是服务器的证书是验证正确。如果不正确，那么攻击者可以设置蜜罐网络，向请求者提供伪造的证书，并获取纯文本凭证。
任何认真对待安全的组织都会在其无线客户端上实施 EAP-TLS（无需密码）或运行可溶解的安装程序（SecureW2、Cloudpath、eduroamCAT - 如果用于 eduroam）以正确配置 802.1X 身份验证设置。
上次我检查 Windows 10 时，它没有实现任何类型的证书/SSID 固定，因此在初始身份验证尝试期间表明您信任服务器的证书实际上并没有增加任何安全性。对于使用不同证书的后续身份验证尝试，请求者会很乐意向您提供新证书的指纹，而不会出现任何不匹配的迹象。解决此问题的唯一方法是明确设置无线网络的证书验证设置（受信任的 CA、预期的主体名称模式），可以手动设置，也可以使用可分解的安装程序（如上所述）。
回答您关于哪些 TTLS/PEAP 内部方法可与 LDAP 配合使用的另一个问题，如果您使用 LDAPv3 身份验证绑定来验证用户，那么是的，只有 PAP 或 GTC（参见 PEAPv0/GTC）可以工作。它们的操作方式几乎相同。
如果您在 RADIUS 服务器上本地提取哈希并进行比较，并存储用户密码的 NT-Password 哈希以及您正在使用的任何其他哈希，那么这允许您执行 MSCHAPv2。
不过，老实说，NT 密码使用非常弱的哈希算法 (MD4)，因此它几乎和在 OpenLDAP 中存储明文一样糟糕。您需要权衡 OpenLDAP 安装被破坏的可能性、所有哈希被盗/破解的风险、有人发起 MITM 攻击的可能性以及部分密码被盗的风险。
最后要注意的是，如果您使用 EAP-PWD，那么在请求方和 RADIUS 服务器上使用密码的散列副本的支持有限，但这种 EAP 方法在 Linux 环境之外并不被广泛支持。
老实说，我对这种情况非常不满意，但让每个人都采用新的 EAP 方法需要多个供应商付出巨大努力。
在 FreeRADIUS 端唯一可以实现的是设置证书验证设置的“抽查”，并补救任何未通过这些设置的用户。具体做法是动态地将提供给请求者的证书替换为无效证书，并验证请求者是否向 RADIUS 服务器返回正确的警报 (invalid_ca)。这将导致身份验证失败（如果一切正常），但请求者也会相当快地重试，因此只要抽查频率不高，就没什么大不了的。