FreeRADIUS 與 LDAP 與 Kerberos
以下站點討論瞭如何設置 FreeRADIUS 以針對 LDAP 後端進行身份驗證（它通過一個教程展示瞭如何在 FreeIPA 中公開 NT 散列密碼，以便 FreeRADIUS 可以讀取它們）。
https://firstyear.id.au/blog/html/2016/01/13/FreeRADIUS:_Using_mschapv2_with_freeipa.html
它還不鼓勵使用 Kerberos 密鑰選項卡將 FreeRADIUS 連接到 IPA，因為在使案例如 PAP 身份驗證時，
"FreeRADIUS can either read the NTHash and do a comparison (as above), or it can directly bind to the LDAP server. This means in the direct bind case, that the transport may not be encrypted due to the keytab."另一方面，各種 FreeRADIUS 指南不鼓勵使用 LDAP（例如，請參閱預設內部隧道站點的註釋，其中指出：
# We do NOT recommend using this. LDAP servers are databases. # They are NOT authentication servers. FreeRADIUS is an # authentication server, and knows what to do with authentication. # LDAP servers do not.除了通用免責聲明之外，上述聲明背後的基本原理是什麼？
有人可以從安全的角度解釋一種方法與另一種方法的優缺點嗎？
我已使用 LDAP 後端（無 KRB）成功設置，並且正在使用 PEAP 進行 WiFi 身份驗證。我想更好地了解這種情況下的安全權衡。
對於 FreeRADIUS
該評論作為通用免責聲明並解決 FreeRADIUS 中的缺陷。
在大多數情況下，您不知道執行綁定的使用者 DN 是什麼。因此，首先，您需要以匿名使用者身份綁定，或使用一組特權憑據來執行該搜尋並找到 DN。
FreeRADIUS 不會為不同的目的維護單獨的連接池，因此必須將連接重新綁定為身份驗證使用者。
這意味著為了在 LDAP 中對使用者進行身份驗證，您最終需要執行三個操作：
- 綁定為特權/匿名使用者。
- 搜尋使用者的 DN。
- 綁定為使用者。
如果 LDAP 伺服器和 RADIUS 伺服器之間的延遲很高，這可能會嚴重限制吞吐量（在 auth/s 方面），因為版本 <= v3.0.x 中的 FreeRADIUS 實現了同步 I/O。
絕對沒有充分的理由不使用綁定操作對使用者進行身份驗證，尤其是在 LDAP 伺服器使用專門的後端身份驗證外掛來執行身份驗證的情況下。LDAP 的設計目的並不重要。RADIUS 協議當然不是為多層身份驗證方案中的國際漫遊聯盟和隧道 TLS 設計的，但它很好地填補了這些角色。
對於國際音標
您連結的文件令人困惑。好像是在說使用服務賬號通過Kerberos（GSSAPI）綁定到LDAP伺服器，由於389DS的不足，GSSAPI不能和StartTLS或者LDAPS結合，這意味著什麼時候使用者的憑證會被送出到在第二次綁定操作期間清除。
或者可能是因為您不能將 GSSAPI 與 StartTLS 或 LDAPS 與 389DS 一起使用，因此如果您使用 Kerberos 執行使用者綁定操作，則憑據將以明文形式送出。
無論哪種情況，我都非常確定這只是 389DS 的限制，並且大多數其他 LDAP 伺服器將支持 GSSAPI over TLS 加密的 LDAP 連接。
無論如何，如果不使用 StartTLS 或 LDAPS ，您絕不應該向 LDAP 目錄送出或檢索憑據，如文章所述：
今天，保護您的帳戶的唯一安全、有保證的方法是 TLS。您應該使用 LDAPS，這可以保證所有通信都是安全的。它更簡單、更快、更好。
如果與目錄伺服器的通信是明文的，那麼攻擊者可以輕鬆地窺探送出給目錄伺服器的明文密碼或返回的 NTPassword。NTPassword 只是密碼的 16 位小端編碼，用 MD4 散列，它幾乎和明文一樣好。