moving from WPA2 to WPA2 Enterprise

[Arran Cudbard-Bell]

> On Jun 26, 2015, at 11:39 AM, Jochen Demmer <jochen.demmer at peakwork.com> wrote:
> 
> rpm -qi freeradius
> Name        : freeradius
> Version     : 3.0.4
> Release     : 6.el7
> Architecture: x86_64
> 
> This is what comes with CentOS 7 Base repos

The server comes with perfectly good spec files. Roll your own RPMs.

> Actually it's working now. It didn't work because I queried the LDAP DB anonymously which isn't granting access to the password attribute of course.
> Anyway it didn't give a reasonable error message in the radius.log about that.

It should have given you an error about no known good password being found. Other than that, if you request an attribute, and you either don't have access, or it doesn't exist, you simply don't get the attribute value in the entry.

Indicating the possibility of an attribute being present, for which you don't have access, was probably, rightly, determined by the overlords of the LDAP working group, to be a security flaw.

So I'm not sure what the 'reasonable' error message would be in this case, other than the one we provide.

...and you may want to re-read your statement above. If the LDAP server allowed consumers of the LDAP directory to read the password attribute after an *ANONYMOUS* bind, it wouldn't be a very secure setup would it. That would mean that anyone who could communicate with the LDAP directory could download the credentials of *ANYONE* stored within that LDAP directory.

But wait THERE'S MORE! The message that does get emitted EXPLICITLY SAYS CHECK THE PERMISSIONS *EXPLICITLY*

/** Verify we got a password from the search
 *
 * Checks to see if after the LDAP to RADIUS mapping has been completed that a reference password.
 *
 * @param inst rlm_ldap configuration.
 * @param request Current request.
 */
void rlm_ldap_check_reply(rlm_ldap_t const *inst, REQUEST *request)
{
       /*
	*	More warning messages for people who can't be bothered to read the documentation.
	*
	*	Expect_password is set when we process the mapping, and is only true if there was a mapping between
	*	an LDAP attribute and a password reference attribute in the control list.
	*/
	if (inst->expect_password && (rad_debug_lvl > 1)) {
		if (!pairfind(request->config, PW_CLEARTEXT_PASSWORD, 0, TAG_ANY) &&
		    !pairfind(request->config, PW_NT_PASSWORD, 0, TAG_ANY) &&
		    !pairfind(request->config, PW_USER_PASSWORD, 0, TAG_ANY) &&
		    !pairfind(request->config, PW_PASSWORD_WITH_HEADER, 0, TAG_ANY) &&
		    !pairfind(request->config, PW_CRYPT_PASSWORD, 0, TAG_ANY)) {
			RWDEBUG("No \"known good\" password added. Ensure the admin user has permission to "
				"read the password attribute");
			RWDEBUG("PAP authentication will *NOT* work with Active Directory (if that is what you "
				"were trying to configure)");
		}
       }
}

I thought i'd accounted for all the common mistakes in rlm_ldap. But apparently some special flavour of idiocy has escaped my attention. So please enlighten me, what steps of progressive misthought led you to claim that there was no reasonable error message.

AH, AH! you weren't running the server in *DEBUG* mode, like every other goddamn post says to do. If you *HAD* been running in the mode SPECIFICALLY CREATED TO HELP DIAGNOSE CONFIGURATION ISSUES, you would have *SEEN* the error message that told you that you BROKE THE SERVER CONFIGURATION.

sigh...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150626/6bc1f19d/attachment.sig>