Bug #8439
closed
Trailing whitespace on username not respected in LDAP filter
0%
Description
When a user attempts to authenticate with LDAP, if they incorrectly enter their username with a trailing space the LDAP filter still successfully finds and validates the user. Local auth and RADIUS both reject this case, so LDAP should handle it consistently if possible.
This can cause a quirk with OpenVPN where the user will still be considered logged in with the trailing space as a part of their username, which can lead to failing to match a CSC/Override or other weirdness.
Updated by Jim Pingle about 6 years ago
I have tried various ways to encode spaces but the LDAP server itself (OpenLDAP, in this case) appears to find the trailing space insignificant in each case that functioned.
So far I've tried:
- Using \x20, and variations to specify octal 20 (space) in the string, which worked for "spa ce" usernames but still allowed "space " usernames.
- Quoting the string with singles and doubles (whole key=value string as well as just the value) -- this didn't work for any case
- Using %20 and variations like '\\x20' in the string to ensure the escaping is preserved in the query -- this didn't work for any case
I'll leave this open for now in case we find a viable way to encode the space in the query, but at the moment it appears to be the LDAP server which needs to reject this and not pfSense.
As for OpenVPN, to avoid the problem it would require an option in OpenVPN itself to strip extra whitespace from usernames. Using ccd-exclusive will reject the user since it doesn't match an override. Alternately, using strict user/cn matching for users with certificates will prevent the problem.
Updated by Jim Pingle almost 6 years ago
- Status changed from Assigned to Not a Bug
- Target version deleted (
2.4.4)
After talking with others this is all up to the target server. AD respects the space, for example, while OpenLDAP does not. Must be handled on the server end.