Re: [External Mail] Re: [External Mail] [External Mail] Issue with authentication for certain users
I have looked up documentation on configuring FreeRADIUS to authenticate using the users' mail addresses. I have everything set up correctly from looking at the documentation, I have the filter set to mail={%User-Name}. The FreeRADIUS server looks for the user by the email address when looking at the Google LDAP logs. Google's LDAP server responds with the UID of the user. Then, the FreeRADIUS server attempts to log in using the UID. I do not want this as this is causing all the users in our subdomain to fail the bind. This is because for the subdomain, it would need to be dc=student,dc=madeupdomain,dc=com and that is not how Google responded for the UID of the user. Do I have something configured wrong or is there a way to force the mail address only? Wayne Sprouse, CNA,CCNA,CEH,A+ Wayne Sprouse, CNA,CCNA,CEH,A+ Long Beach School District Network Administrator Work Phone: 228-575-4056 On Thu, Apr 3, 2025 at 1:38 PM Wayne Sprouse <wayne.sprouse@lbsdk12.com> wrote:
The point is to tell Google that you were using ldapsearch.
My mistake, I didn't fully understand that. I have told Google about doing the ldapsearch and not being able to bind with the subdomain credentials.
Yes, you can configure the LDAP module to search using the User-Name. This is the default configuration.
It is currently set to search using the filter of their email address. It then gets back the full UID DN from the Google LDAP. I was wanting it to not bother with the UID and instead use the email address as the complete User-Name to authenticate into LDAP.
Wayne Sprouse, CNA,CCNA,CEH,A+
-- "The foregoing electronic message and any files transmitted with it are confidential and are intended only for the use of the intended recipient named above. This communication may contain material protected by the Family Educational Rights and Privacy Act (FERPA). If you are not the intended recipient, copying, distribution or use of the contents of this message is strictly prohibited. If you received this electronic message in error, please notify us immediately at (228-864-1146**)."**
On Apr 7, 2025, at 10:22 AM, Wayne Sprouse via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I have looked up documentation on configuring FreeRADIUS to authenticate using the users' mail addresses. I have everything set up correctly from looking at the documentation, I have the filter set to mail={%User-Name}. The FreeRADIUS server looks for the user by the email address when looking at the Google LDAP logs. Google's LDAP server responds with the UID of the user. Then, the FreeRADIUS server attempts to log in using the UID.
This isn't the normal way that FreeRADIUS works with LDAP. If you configured the LDAP module in FreeRADIUS, it will do one of two things; 1) look up the users password in LDAP during the "authorize" section. The user will then be authenticated by the PAP / CHAP / MS-CHAP module 2) do "bind as user" with the supplied User-Name and password during the "authenticate" section. The LDAP module will return success / fail, and the user will be authenticated. That's it. The only minor point here is that either LDAP query may result in redirects. But at no point does the serve replace with email address with the UID of the user.
I do not want this as this is causing all the users in our subdomain to fail the bind. This is because for the subdomain, it would need to be dc=student,dc=madeupdomain,dc=com and that is not how Google responded for the UID of the user. Do I have something configured wrong or is there a way to force the mail address only?
It's not at all clear what you're doing. Perhaps you could post the debug output. The previous debug output you posted was using "radiusd -Xx", which includes timestamps. That makes it harder to read. Follow the documentation, and just do "radiusd -X". The previous debug output you post also showed an error which was *not" User-Name or UID based. Instead, it Thu Apr 3 08:21:22 2025 : WARNING: (8) ldap: No "known good" password added. Ensure the admin user has permission to read the password attribute That is pretty definitive. Alan DeKok.
participants (2)
-
Alan DeKok -
Wayne Sprouse