On Feb 14, 2007, at 2:05 PM, Matt Ashfield wrote:
During a pap conversation, the radius server ends up with the username/password passed to it from the client. It then encrypts the password to match the encryption of the stored password in ldap (or other directory) and tries a bind. Correct?
There are two methods when it comes to LDAP, bind or compare. In the bind option, as used when "ldap" is in the authenticate section, does not encrypt the password received from the client, it just uses that in an LDAP bind operation and checks the return status for success or failure. In the compare option, as would be used if you retrieved the password hash from LDAP during the authorize phase and used the PAP module in the authenticate section, the password hash is actually *retrieved* from LDAP and compared against the password retrieved from the client (possibly encrypting the password from the client to see if the hashes match in the case of an encrypted password stored in LDAP).
During a PEAP conversation, the radius server also would end-up with a username/password received from the client (either via clear-text or via the mschap conversation). Why can it not then encrypt the password just like PAP did? Does it do the comparison to LDAP stored passwords via MSCHAP as well?
That depends on the inner authentication. During what most people thing of as PEAP, which is PEAP with EAP-MSCHAPv2 inside the tunnel, the RADIUS server does not received a password for the user. Rather, it received a hash based on information previously sent by the RADIUS server. Since it is not receiving the actual password from the client, there is no way to translate what it receives into what would be needed to do a comparison or bind using the pap or ldap modules. You *can* store a plain-text password or an NTLM-hashed password in your LDAP tree to be used by rlm_mschap for the EAP-MSCHAPv2 portion of the conversation, but that's pretty much your only choice when dealing with LDAP (and is what we do). --Mike