figured it out I had not included the line require-message-authentication=no in my clients.conf. Thank you for your help Alan! From: Freeradius-Users <freeradius-users-bounces+kevin.virk=faithlife.com@lists.freeradius.org> on behalf of freeradius-users-request@lists.freeradius.org <freeradius-users-request@lists.freeradius.org> Sent: Wednesday, August 8, 2018 8:38 AM To: freeradius-users@lists.freeradius.org Subject: Freeradius-Users Digest, Vol 160, Issue 11 Send Freeradius-Users mailing list submissions to freeradius-users@lists.freeradius.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeradius.org/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to freeradius-users-request@lists.freeradius.org You can reach the person managing the list at freeradius-users-owner@lists.freeradius.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeradius-Users digest..." Today's Topics: 1. Re: ldap module for user and mac authentication (Alan DeKok) 2. Re: ldap module for user and mac authentication (Dave Macias) 3. Re: ldap module for user and mac authentication (Michael Ströder) 4. Re:Re: Accounting-Request packet shared secret fail (Alan DeKok) (Kevin Virk) ---------------------------------------------------------------------- Message: 1 Date: Wed, 8 Aug 2018 10:03:29 -0400 From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: ldap module for user and mac authentication Message-ID: <88B6B2EF-CE79-45C3-9BFE-C4E6DDE90764@deployingradius.com> Content-Type: text/plain; charset=us-ascii On Aug 7, 2018, at 4:04 PM, Dave Macias <davama@gmail.com> wrote:
Yes, I had thought of something to the effect of (suggestions welcomed) : ... But this does not account for the scenario of openldap being dead.
Unfortunately, the dynamic expansions don't deal well with this kind of problem. We're fixing that in v4, but it's hard to do for v3.
Unless there is a way to query the "live" ldap server which the ldap module found %{ldap:ldap://%{live.ldap.server}/...} , if that makes sense
No, there's no way to do that. The fail-over in this case is handled by libldap. So it's completely out of our control. Alan DeKok. ------------------------------ Message: 2 Date: Wed, 8 Aug 2018 10:12:13 -0400 From: Dave Macias <davama@gmail.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: ldap module for user and mac authentication Message-ID: <CA+nFYV81mUH-ry5sgZERODxKo2nQ0rQkG7FFH3=AEdZPDxgAvg@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Understood Thank you for the kind assistance Alan! Best Regards, dave On Wed, Aug 8, 2018 at 10:03 AM Alan DeKok <aland@deployingradius.com> wrote:
On Aug 7, 2018, at 4:04 PM, Dave Macias <davama@gmail.com> wrote:
Yes, I had thought of something to the effect of (suggestions welcomed) : ... But this does not account for the scenario of openldap being dead.
Unfortunately, the dynamic expansions don't deal well with this kind of problem.
We're fixing that in v4, but it's hard to do for v3.
Unless there is a way to query the "live" ldap server which the ldap module found %{ldap:ldap://%{live.ldap.server}/...} , if that makes sense
No, there's no way to do that. The fail-over in this case is handled by libldap. So it's completely out of our control.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------ Message: 3 Date: Wed, 8 Aug 2018 17:01:33 +0200 From: Michael Ströder <michael@stroeder.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: ldap module for user and mac authentication Message-ID: <e554d80f-d1b6-8751-4e86-cc112f13fa50@stroeder.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" On 8/8/18 4:03 PM, Alan DeKok wrote:
On Aug 7, 2018, at 4:04 PM, Dave Macias <davama@gmail.com> wrote:
Unless there is a way to query the "live" ldap server which the ldap module found %{ldap:ldap://%{live.ldap.server}/...} , if that makes sense
No, there's no way to do that. The fail-over in this case is handled by libldap. So it's completely out of our control.
Maybe I missed something in the thread. But I understand '"live" LDAP server' that you want to know which LDAP server behind connection pooling, load-balancer or similar was really reached. For this particular case I always I add the service FQDN of a particular (OpenLDAP) instance to be readable via LDAP, e.g. in the rootDSE. So a LDAP client can find out to which particular instance it connected even though it does not control the fail-over. Ciao, Michael.